Codex Desktop填坑 | 重连修复与4sAPI接入

【大模型API中转站】Codex Desktop填坑 | 重连修复与4sAPI接入

摘要：很多人使用新版 Codex Desktop 时，会遇到反复 Reconnecting... 2/5、3/5、4/5、5/5 的情况。日志里常见表现是 WebSocket 握手超时，根因往往不是模型没响应，而是 Codex Desktop 没有显式读取系统代理环境变量。本文先讲清楚 macOS 下如何通过 ~/.codex/.env 配置 HTTP_PROXY / HTTPS_PROXY 修复重连问题，再继续演示如何把 Codex 接入 4sAPI 大模型 API 中转站。

关键词：Codex Desktop、Reconnecting、WebSocket握手超时、HTTP_PROXY、HTTPS_PROXY、大模型API中转站、4sAPI、config.toml、model_providers、Responses API

适合读者：国内开发者、独立创作者、小团队工程师，以及想把 Codex 接到第三方模型中转站的 AI 工具用户。

本文是【大模型API中转站】系列的第3篇。本系列致力于用最低的成本、最清晰的方法，帮你打通多模型API的任督二脉。建议先收藏，随用随查。

1. 先说痛点：Codex Desktop 一直 Reconnecting

使用 Codex Desktop 时，很多人会遇到下面这种情况：

text

Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5

更气人的是，它通常不是彻底失败，而是等 5 次重连结束后才给出响应。最后确实能用，但中间白白等了很久。

这个现象在新版 Codex Desktop 里更明显。原因是 Codex Desktop 的默认连接方式改成了 WebSocket。WebSocket 握手如果走错网络链路，日志里就会体现为握手超时，然后进入重连循环。

关键点在这里：Codex Desktop 是桌面应用，不一定像浏览器那样自动使用系统代理。它启动时需要显式读取环境变量里的 HTTP_PROXY、HTTPS_PROXY，才会走代理。有些网络库还会读取小写的 http_proxy、https_proxy。如果这些变量没有设置，Codex Desktop 会以为自己可以直连，结果就是连接超时、重试、再超时。

所以，修复思路其实很简单：

text

查看本机代理端口 → 写入 ~/.codex/.env → 重启 Codex Desktop

这不是让你绕过网络限制，而是让 Codex Desktop 按照你本机已经启用、且你有权使用的代理配置去发起连接。公司网络或团队环境里，要以自己的网络合规要求为准。

2. macOS 修复：给 Codex Desktop 写入代理变量

2.1 查看系统代理

macOS 终端输入：

bash

scutil --proxy

你会看到类似输出：

text

HTTPEnable : 1
HTTPProxy : 127.0.0.1
HTTPPort : 6152
HTTPSEnable : 1
HTTPSProxy : 127.0.0.1
HTTPSPort : 6152
SOCKSEnable : 1
SOCKSProxy : 127.0.0.1
SOCKSPort : 6153

这里重点看四个字段：

HTTPProxy
HTTPPort
HTTPSProxy
HTTPSPort

如果你的输出里 HTTPProxy 是 127.0.0.1，HTTPPort 是 6152，HTTPSProxy 是 127.0.0.1，HTTPSPort 是 6152，那么 Codex Desktop 应该使用：

text

http://127.0.0.1:6152

2.2 编辑 `~/.codex/.env`

如果文件不存在，直接创建：

bash

mkdir -p ~/.codex
nano ~/.codex/.env

写入：

env

HTTP_PROXY=http://127.0.0.1:6152
HTTPS_PROXY=http://127.0.0.1:6152
http_proxy=http://127.0.0.1:6152
https_proxy=http://127.0.0.1:6152
ALL_PROXY=socks5://127.0.0.1:6153
all_proxy=socks5://127.0.0.1:6153
NO_PROXY=localhost,127.0.0.1,::1
no_proxy=localhost,127.0.0.1,::1

如果你没有启用 SOCKS 代理，可以只写：

env

HTTP_PROXY=http://127.0.0.1:6152
HTTPS_PROXY=http://127.0.0.1:6152
http_proxy=http://127.0.0.1:6152
https_proxy=http://127.0.0.1:6152
NO_PROXY=localhost,127.0.0.1,::1
no_proxy=localhost,127.0.0.1,::1

保存后，完全退出 Codex Desktop，再重新打开。注意是退出应用后重开，不只是关闭窗口。

2.3 不想手搓：发给 Codex 的 Prompt

如果你想让 Codex 自动帮你写配置，可以在 Codex 里发下面这段：

text

请帮我修复 macOS 上 Codex Desktop 一直 Reconnecting 的问题。

要求：
1. 先运行 scutil --proxy 读取系统代理配置。
2. 从输出中提取 HTTPProxy、HTTPPort、HTTPSProxy、HTTPSPort、SOCKSProxy、SOCKSPort。
3. 创建或更新 ~/.codex/.env。
4. 写入 HTTP_PROXY、HTTPS_PROXY、NO_PROXY，同时写入小写 http_proxy、https_proxy、no_proxy。
5. 如果 SOCKS 代理启用，也写入 ALL_PROXY 和 all_proxy。
6. 不要覆盖文件中已有的无关环境变量。
7. 修改完成后告诉我需要完全退出并重新打开 Codex Desktop。

2.4 macOS 一键脚本

也可以用下面这个脚本自动读取系统代理并写入 ~/.codex/.env：

bash

#!/usr/bin/env bash
set -euo pipefail

ENV_FILE="$HOME/.codex/.env"
mkdir -p "$HOME/.codex"
touch "$ENV_FILE"

proxy_info="$(scutil --proxy)"

http_enable="$(printf '%s\n' "$proxy_info" | awk '/HTTPEnable/ {print $3; exit}')"
http_host="$(printf '%s\n' "$proxy_info" | awk '/HTTPProxy/ {print $3; exit}')"
http_port="$(printf '%s\n' "$proxy_info" | awk '/HTTPPort/ {print $3; exit}')"

https_enable="$(printf '%s\n' "$proxy_info" | awk '/HTTPSEnable/ {print $3; exit}')"
https_host="$(printf '%s\n' "$proxy_info" | awk '/HTTPSProxy/ {print $3; exit}')"
https_port="$(printf '%s\n' "$proxy_info" | awk '/HTTPSPort/ {print $3; exit}')"

socks_enable="$(printf '%s\n' "$proxy_info" | awk '/SOCKSEnable/ {print $3; exit}')"
socks_host="$(printf '%s\n' "$proxy_info" | awk '/SOCKSProxy/ {print $3; exit}')"
socks_port="$(printf '%s\n' "$proxy_info" | awk '/SOCKSPort/ {print $3; exit}')"

tmp_file="$(mktemp)"
grep -vE '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY|http_proxy|https_proxy|all_proxy|no_proxy)=' "$ENV_FILE" > "$tmp_file" || true

if [ "$http_enable" = "1" ] && [ -n "${http_host:-}" ] && [ -n "${http_port:-}" ]; then
  echo "HTTP_PROXY=http://${http_host}:${http_port}" >> "$tmp_file"
  echo "http_proxy=http://${http_host}:${http_port}" >> "$tmp_file"
fi

if [ "$https_enable" = "1" ] && [ -n "${https_host:-}" ] && [ -n "${https_port:-}" ]; then
  echo "HTTPS_PROXY=http://${https_host}:${https_port}" >> "$tmp_file"
  echo "https_proxy=http://${https_host}:${https_port}" >> "$tmp_file"
fi

if [ "$socks_enable" = "1" ] && [ -n "${socks_host:-}" ] && [ -n "${socks_port:-}" ]; then
  echo "ALL_PROXY=socks5://${socks_host}:${socks_port}" >> "$tmp_file"
  echo "all_proxy=socks5://${socks_host}:${socks_port}" >> "$tmp_file"
fi

echo "NO_PROXY=localhost,127.0.0.1,::1" >> "$tmp_file"
echo "no_proxy=localhost,127.0.0.1,::1" >> "$tmp_file"
mv "$tmp_file" "$ENV_FILE"

echo "已更新 $ENV_FILE"
echo "请完全退出 Codex Desktop 后重新打开。"

2.5 怎么确认是否修好了

重启 Codex Desktop 后，观察两点：

是否还会长时间停在 Reconnecting... 2/5 到 5/5。
一条普通消息是否能更快开始响应。

如果仍然重连，继续检查：

~/.codex/.env 是否写错端口。
是否只写了大写代理变量；建议大小写都写。
代理客户端是否正在运行。
代理是否允许终端/桌面应用访问。
公司网络是否拦截 WebSocket。

3. 为什么 Codex 也需要 API 中转站方案

上面解决的是 Codex Desktop 的连接链路问题。另一个高频需求，是把 Codex 的模型调用接入大模型 API 中转站。

AI 编程工具正在从“聊天助手”变成“真正参与工程工作流的 agent”。一旦工具开始读文件、改代码、跑测试、做 review，模型调用就不再是偶尔问几句，而会变成高频、长上下文、多轮工具调用。

这时问题就来了：

默认模型成本是否可控？
国内网络是否稳定？
能不能按项目、团队、任务类型切换模型？
能不能把 Key、额度、日志集中管理？
当某个模型不可用时，有没有备用线路？

Codex 的优势在于它已经把代码工作流做得比较完整：CLI、桌面 app、review、exec、sandbox、MCP、插件和配置体系都在同一个工具链里。4sAPI 这类大模型 API 中转站则更像“模型接入层”：统一 URL、统一 Key、统一计费和日志，并通过 OpenAI 兼容接口对接多种模型。

两者组合起来，适合做一个低门槛的多模型 Codex 工作流。

4. 原理速览：Codex + 4sAPI 的请求链路

最简单的链路如下：

text

Codex CLI / Codex Desktop
        ↓
~/.codex/config.toml 自定义 provider
        ↓
4sAPI OpenAI 兼容接口
        ↓
GPT / Claude / Gemini / DeepSeek / Qwen 等模型渠道

Codex 负责：

理解代码仓库、读取文件、修改文件、运行命令。
管理 sandbox、审批策略、MCP、插件和工作目录。
通过配置文件选择模型与 provider。

4sAPI 负责：

提供统一 API 地址，例如 https://4sapi.com/v1。
提供 API Key、模型分组、额度、日志和计费。
把 OpenAI 兼容请求路由到不同模型。

这篇文章只讨论合规的 API 接入、模型切换和成本管理，不鼓励绕过官方限制、滥用接口或处理违规内容。

5. 方案对比：官方直连 vs 中转站接入

如果只看 Codex 的模型接入，大致有两条路：

方案	优点	风险与限制	适合人群
官方直连	链路最短；官方支持最完整；兼容性最好	对网络、账号、支付和团队额度管理要求更高	海外网络稳定、合规要求高、预算充足的团队
中转站接入	一个 URL + 一个 Key 管理多模型；方便做额度、日志和模型切换	多一层中转依赖；要关注隐私、稳定性和接口兼容	国内开发者、独立创作者、小团队、原型项目

本文重点讲方案二：通过 4sAPI 这类大模型 API 中转站，把 Codex 的模型接入层统一起来。

适合：

你想用 Codex 做日常代码修改，但希望模型调用成本更可控。
你希望在 Codex 里测试不同模型的代码能力。
你已经在 4sAPI 管理多个模型，希望 Codex 也复用这套入口。
你需要给团队成员分配不同额度、不同 Key、不同模型分组。

不太适合：

强合规、强隐私、生产级代码库，且不能接受第三方中转链路。
对工具调用、Responses API 兼容性要求极高的复杂 agent 场景。
你无法接受模型能力、函数调用、流式输出在中转链路中出现兼容差异。

一句话：个人和小团队可以先用中转方案快速验证；生产环境要先做数据分级、权限隔离和 fallback。

6. 准备工作

你需要准备：

已安装 Codex CLI 或 Codex 桌面 app。
一个 4sAPI 账号，并创建好 API Key。
在 4sAPI 模型广场复制目标模型 ID。
确认你的 4sAPI Key 所在分组支持该模型。

先检查 Codex 是否可用：

bash

codex --version

Windows PowerShell 用户注意：如果直接运行 codex 报错：

text

无法加载文件 ... codex.ps1，因为在此系统上禁止运行脚本

可以改用：

powershell

codex.cmd --version
codex.cmd --help

这是 PowerShell 执行策略拦住了 .ps1 包装脚本，不代表 Codex 没安装成功。

7. 4sAPI 侧：创建单独给 Codex 用的 Key

建议不要把 Codex 和其他工具共用同一个 4sAPI Key。更稳的做法是：

text

4sAPI 控制台 → 创建令牌 → 命名为 codex-dev → 绑定模型分组 → 设置额度 → 复制 Key

这样做有几个好处：

可以单独查看 Codex 的调用日志。
可以给 Codex 设置额度上限，避免工具循环导致消耗失控。
如果 Key 泄露，可以只停用 Codex 这一个令牌。
团队协作时，可以给不同成员分配不同 Key。

模型 ID 一定从 4sAPI 模型广场复制，不要手打。比如你可能会看到类似下面这样的模型 ID：

text

gpt-5.5-xhigh
claude-sonnet-4-5-20250929
deepseek-v4-flash
qwen3.7-plus

这些只是示例，具体可用模型以 4sAPI 控制台实际显示为准。

8. Codex 配置文件位置

Codex 的用户配置通常在：

text

~/.codex/config.toml

Windows 对应路径一般是：

text

C:\Users\你的用户名\.codex\config.toml

如果文件不存在，可以手动创建。建议先备份一份：

powershell

Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.bak"

如果你是 macOS / Linux：

bash

cp ~/.codex/config.toml ~/.codex/config.toml.bak

9. 核心配置：Codex 接入 4sAPI

打开 ~/.codex/config.toml，加入或修改下面几段：

toml

model_provider = "custom"
model = "gpt-5.5-xhigh" # 替换成 4sAPI 模型广场里的真实模型 ID

[model_providers]

[model_providers.custom]
name = "4sapi"
wire_api = "responses"
base_url = "https://4sapi.com/v1"
requires_openai_auth = true

字段解释：

model_provider = "custom"：告诉 Codex 默认使用自定义 provider。
model = "gpt-5.5-xhigh"：设置默认模型名，必须替换成 4sAPI 模型广场里的真实模型 ID。
[model_providers.custom]：定义名为 custom 的模型供应商。
name = "4sapi"：展示用名称，方便自己识别。
wire_api = "responses"：让 Codex 走 Responses API 风格的请求格式。
base_url = "https://4sapi.com/v1"：4sAPI 的 OpenAI 兼容 API 根地址。
requires_openai_auth = true：让 Codex 使用 OpenAI 风格认证信息。

注意：不要把 base_url 写成完整接口路径：

text

错误： https://4sapi.com/v1/chat/completions
正确： https://4sapi.com/v1

因为 Codex 会根据 wire_api 自己拼接具体请求路径。base_url 只填 API 根地址。

10. API Key 怎么放

Codex 通常会读取 OpenAI 风格认证。最简单的方式是在当前终端设置环境变量：

Windows PowerShell：

powershell

$env:OPENAI_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxx"
codex.cmd "用一句话介绍你能做什么"

macOS / Linux：

bash

export OPENAI_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxx"
codex "用一句话介绍你能做什么"

如果你希望长期生效，可以把环境变量放到系统环境变量、shell profile，或者只在启动 Codex 的脚本里设置。不要把真实 Key 写进博客、截图、公开仓库或团队共享文档。

如果你想把 API Key 写入 Codex 的本地认证状态，可以使用 --with-api-key 从标准输入读取。macOS / Linux：

bash

printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key

Windows PowerShell：

powershell

$env:OPENAI_API_KEY | codex.cmd login --with-api-key

如果只是运行 codex login，通常会进入 Codex 的交互登录流程；它不等同于自动使用 4sAPI Key。想确认登录状态，可以运行：

bash

codex login status

Windows PowerShell：

powershell

codex.cmd login status

实际使用中，建议二选一：

临时测试：用 OPENAI_API_KEY 环境变量。
长期使用：用 codex login --with-api-key 或本机安全凭据管理，并给 4sAPI Key 单独限额。

11. 最小化测试

配置完成后，在一个测试目录里运行：

Windows：

powershell

codex.cmd "请用一句话说明当前模型名称，并不要修改任何文件"

macOS / Linux：

bash

codex "请用一句话说明当前模型名称，并不要修改任何文件"

如果你想用非交互方式测试，可以用：

bash

codex exec "输出一句 hello，不要读写文件"

Windows：

powershell

codex.cmd exec "输出一句 hello，不要读写文件"

如果你只是想临时覆盖模型，不改配置文件，可以用 -c：

bash

codex -c model_provider='"custom"' -c model='"gpt-5.5-xhigh"' "简单自我介绍"

或者在 Windows PowerShell 中：

powershell

codex.cmd -c model_provider='"custom"' -c model='"gpt-5.5-xhigh"' "简单自我介绍"

这里的引号比较绕，原因是 -c 的值会按 TOML 解析。实际长期使用还是推荐写进 config.toml。

12. 常见问题与排查

问题 1：Codex Desktop 一直 Reconnecting

优先检查 ~/.codex/.env：

env

HTTP_PROXY=http://127.0.0.1:6152
HTTPS_PROXY=http://127.0.0.1:6152
http_proxy=http://127.0.0.1:6152
https_proxy=http://127.0.0.1:6152
NO_PROXY=localhost,127.0.0.1,::1
no_proxy=localhost,127.0.0.1,::1

端口要换成你通过 scutil --proxy 查到的端口。修改后必须完全退出并重新打开 Codex Desktop。

问题 2：PowerShell 无法运行 codex

报错类似：

text

无法加载文件 codex.ps1，因为在此系统上禁止运行脚本

解决方法：

powershell

codex.cmd --help

也可以在 CMD、Git Bash 或 Windows Terminal 中换 shell 运行。

问题 3：401 或认证失败

优先检查：

OPENAI_API_KEY 是否设置在当前终端。
Key 是否从 4sAPI 控制台复制完整。
Key 是否被禁用、过期或额度耗尽。
requires_openai_auth = true 是否保留。

问题 4：404 或路径错误

检查 base_url：

toml

base_url = "https://4sapi.com/v1"

不要写成：

toml

base_url = "https://4sapi.com/v1/responses"
base_url = "https://4sapi.com/v1/chat/completions"

问题 5：模型不存在

中转站模型 ID 经常包含版本号、日期或后缀。处理方法：

从 4sAPI 模型广场复制模型 ID。
确认 Key 绑定的分组支持这个模型。
先换一个明确支持 OpenAI 兼容接口的模型测试。

问题 6：Responses API 兼容性不完整

Codex 这类 agent 工具对模型接口要求比普通聊天软件更高，尤其是工具调用、结构化输出、长上下文和流式返回。如果某个模型在 Codex 中异常，可以尝试：

换一个更接近 OpenAI Responses API 的模型或渠道。
保留 wire_api = "responses"，优先选 4sAPI 中明确支持该模式的模型。
如果 4sAPI 只提供 chat completions 兼容能力，部分 Codex 功能可能不完整。

问题 7：调用费用突然升高

Codex 会读文件、思考、生成 diff、跑命令，token 消耗可能比普通聊天高。建议：

给 Codex 单独 Key。
设置额度上限。
开发阶段用便宜模型。
大范围重构前先限制工作目录。
不要在包含大量无关文件的目录里随意启动。

13. 推荐配置策略

个人使用：

toml

model_provider = "custom"
model = "gpt-5.5-xhigh" # 替换成 4sAPI 模型广场里的真实模型 ID

[model_providers.custom]
name = "4sapi"
wire_api = "responses"
base_url = "https://4sapi.com/v1"
requires_openai_auth = true

小团队使用：

每个人一个 4sAPI Key。
每个 Key 单独限额。
统一提供一份 config.toml 模板。
不在模板里写真实 Key。
重要项目优先使用官方直连或企业级合规方案。

混合模型使用：

日常问答和小改动：便宜、响应快的模型。
复杂重构、跨文件修改：高阶代码模型。
隐私敏感代码：本地模型或官方企业通道。

14. 成本与合规提醒

Codex + 4sAPI 的成本来自：

模型调用费用。
长上下文读写带来的额外 token。
多轮工具调用带来的重复消耗。
如果远程运行，还包括服务器费用。

合规方面要注意：

不要把生产密钥、客户数据、未脱敏日志发给第三方链路。
不要用中转站绕过模型供应商的使用条款。
团队内部要明确哪些仓库可以用中转，哪些必须走官方或本地模型。
公开教程、截图、视频必须打码 API Key。

15. 一句话总结

Codex Desktop 反复 Reconnecting，很多时候不是模型慢，而是 WebSocket 连接没有吃到代理环境变量。先用 scutil --proxy 找到本机代理端口，把 HTTP_PROXY / HTTPS_PROXY 写进 ~/.codex/.env，再重启 Codex Desktop，通常就能少等很多无意义的重连。

解决连接问题之后，再看模型接入：Codex 适合负责“代码工作流”，4sAPI 适合负责“模型接入层”。通过 ~/.codex/config.toml 里的 model_providers.custom，你可以把 Codex 接到 4sAPI 的 OpenAI 兼容接口上，用一个统一入口管理模型、Key、额度和日志。

但要记住：Codex 是 agent，不是普通聊天框。它的接口兼容性、成本波动和权限边界都更敏感。先在测试仓库跑通，再逐步放到真实项目里，才是更稳的路线。

如果你已经把 Codex 接入过 4sAPI、OpenRouter、LiteLLM 或自建网关，也欢迎在评论区补充你的配置片段、模型选择和踩坑经验。

参考资料

Codex CLI 本地帮助：codex.cmd --help
Codex 本地配置文件：~/.codex/config.toml
Codex Desktop 环境变量文件：~/.codex/.env
4sAPI 快速上手调用大模型 API: https://4sapi.apifox.cn/8181987m0
4sAPI OpenAI 兼容文本生成接口: https://4sapi.apifox.cn/359535005e0
4sAPI Claude 原生 messages 接口示例: https://4sapi.apifox.cn/383153629e0

Codex Desktop填坑 | 重连修复与4sAPI接入

【大模型API中转站】Codex Desktop填坑 | 重连修复与4sAPI接入

1. 先说痛点：Codex Desktop 一直 Reconnecting

2. macOS 修复：给 Codex Desktop 写入代理变量

2.1 查看系统代理

2.2 编辑 `~/.codex/.env`

2.3 不想手搓：发给 Codex 的 Prompt

2.4 macOS 一键脚本

2.5 怎么确认是否修好了

3. 为什么 Codex 也需要 API 中转站方案

4. 原理速览：Codex + 4sAPI 的请求链路

5. 方案对比：官方直连 vs 中转站接入

6. 准备工作

7. 4sAPI 侧：创建单独给 Codex 用的 Key

8. Codex 配置文件位置

9. 核心配置：Codex 接入 4sAPI

10. API Key 怎么放

11. 最小化测试

12. 常见问题与排查

问题 1：Codex Desktop 一直 Reconnecting

问题 2：PowerShell 无法运行 codex

问题 3：401 或认证失败

问题 4：404 或路径错误

问题 5：模型不存在

问题 6：Responses API 兼容性不完整

问题 7：调用费用突然升高

13. 推荐配置策略

14. 成本与合规提醒

15. 一句话总结

参考资料

推荐阅读

用了大半年 AI 编程，我终于想明白：选 Agent 是末节，选 Skill 才是关键

从 ReAct 到 Multi-Agent：我对 AI Agent 架构演进的一次完整梳理

OpenClaw 多 Agent 实战：我用一支"AI 军团"重构了整条内容生产线

让 AI 帮你挖项目漏洞：实测开源神器 DeepAudit，它已经挖到 49 个 CVE 了

【大模型API中转站】Codex Desktop填坑 | 重连修复与4sAPI接入

1. 先说痛点：Codex Desktop 一直 Reconnecting

2. macOS 修复：给 Codex Desktop 写入代理变量

2.1 查看系统代理

2.2 编辑 ~/.codex/.env

2.3 不想手搓：发给 Codex 的 Prompt

2.4 macOS 一键脚本

2.5 怎么确认是否修好了

3. 为什么 Codex 也需要 API 中转站方案

4. 原理速览：Codex + 4sAPI 的请求链路

5. 方案对比：官方直连 vs 中转站接入

6. 准备工作

7. 4sAPI 侧：创建单独给 Codex 用的 Key

8. Codex 配置文件位置

9. 核心配置：Codex 接入 4sAPI

10. API Key 怎么放

11. 最小化测试

12. 常见问题与排查

问题 1：Codex Desktop 一直 Reconnecting

问题 2：PowerShell 无法运行 codex

问题 3：401 或认证失败

问题 4：404 或路径错误

问题 5：模型不存在

问题 6：Responses API 兼容性不完整

问题 7：调用费用突然升高

13. 推荐配置策略

14. 成本与合规提醒

15. 一句话总结

参考资料

推荐阅读

用了大半年 AI 编程，我终于想明白：选 Agent 是末节，选 Skill 才是关键

从 ReAct 到 Multi-Agent：我对 AI Agent 架构演进的一次完整梳理

OpenClaw 多 Agent 实战：我用一支"AI 军团"重构了整条内容生产线

让 AI 帮你挖项目漏洞：实测开源神器 DeepAudit，它已经挖到 49 个 CVE 了

2.2 编辑 `~/.codex/.env`