Codex CLI 接中转站配置排错

新版 Codex CLI 想接第三方中转站，最容易卡在一个地方：明明填了中转站的地址和 key，请求却还是打到了 api.openai.com，然后一路 401 Unauthorized。

这篇文章记录我把 Codex CLI（含 ChatGPT 桌面版内置的 Codex，实测 v0.145.0）接上中转站的完整过程：正确的配置写法、三个必踩的坑，以及怎么验证真的走通了。可以直接当排错清单照抄。

结论先行：正确的 config.toml

配置文件在 ~/.codex/config.toml（Windows 在 C:\Users\你\.codex\config.toml）。下面这份是能跑通的最小配置：

model = "gpt-5.6-sol"          # 换成中转站支持的模型名
model_reasoning_effort = "high"
model_provider = "qnvip"       # 指向下面的 provider 块
experimental_bearer_token = 'sk-xxxxxxxx'   # 中转站的 key，鉴权用

[model_providers.qnvip]
name = "qnvip"
base_url = "http://中转站域名/v1"
wire_api = "responses"         # 中转站不支持 responses 就改成 "chat"

结构上只有三件事必须对上：

1. 顶层 model_provider 的值，等于 [model_providers.xxx] 里的那个 xxx。
2. base_url 写在 provider 块内部，而不是顶层。
3. 鉴权用顶层的 experimental_bearer_token，不依赖环境变量。

报错长什么样

接不通时，最典型的报错是这样的：

三个常见坑

坑 1：base_url 裸写在顶层 → 被完全忽略（主因）

这是绝大多数人卡住的原因。新版 Codex 不认顶层的 base_url。如果没有 [model_providers.xxx] 块加上 model_provider 指过去，它就退回到内置的 openai provider，硬编码打到 api.openai.com。

错误写法（顶层裸写，无效）：

base_url = "http://中转站域名/v1"   # ❌ 被忽略
wire_api = "responses"

坑 2：key 末尾多敲了一个引号

复制粘贴 key 时非常容易手滑，比如 'sk-...4eb5"' —— 结尾多出来的那个 " 会被当成 key 的一部分，污染整个 key，于是即便 provider 配对了，也会在中转站侧报 invalid_api_key。

坑 3：自定义 provider 不读 auth.json

ChatGPT 桌面版内置的 Codex 里有个 auth.json，里面的 OPENAI_API_KEY 只给内置 openai provider 用。自定义 provider 如果写 env_key = "OPENAI_API_KEY"，它读的是真·系统环境变量，而不是 auth.json，于是报：

Missing environment variable: OPENAI_API_KEY

两个解法，推荐第一个：

• ✅ 用顶层 experimental_bearer_token：不依赖环境变量，命令行启动和桌面 App 启动都稳。
• ⚠️ 或者真的 export OPENAI_API_KEY=sk-xxx，再在 provider 里写 env_key = "OPENAI_API_KEY"。注意桌面版 App 启动时不一定继承 ~/.zshrc 里的 export，容易时灵时不灵。

配置流程速览

把上面三个坑翻译成操作步骤，就是这样一条路径：

验证方法

必须在受信任目录里跑，否则会报 Not inside a trusted directory：

cd /受信任的项目目录
echo "只回复两个字:成功" | codex exec --skip-git-repo-check

看启动信息里的 provider: 是不是你的中转站名，以及能不能正常返回内容即可。能收到「成功」两个字，就说明整条链路打通了。

报错速查表

把常见报错和对应原因整理成一张表，遇到问题直接对号入座：