升级 Codex CLI 后，如果终端在真正发请求前就停在下面这句，先别查 Key、余额或模型名：
text
Error loading config.toml: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.本文实测环境是 macOS、Codex CLI 0.144.1。需要改的是用户级 ~/.codex/config.toml；自定义 Provider 的顶层字段叫 model_provider，不是搜索时常见的 api_provider。最小可运行配置如下，Key 只写环境变量名，不要把真实值放进 TOML：
toml
model = "your-exact-model-id"
model_provider = "my_proxy"
[model_providers.my_proxy]
name = "My Responses Provider"
base_url = "https://example.com/v1"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "responses"保存后先做严格配置检查和一次最小调用：
bash
codex exec --strict-config --ephemeral \
"Do not use tools. Reply with exactly CODEX_WIRE_OK."成功信号不只是"终端没有红字"，至少要同时看到：配置不再报 wire_api="chat"、服务端收到 /v1/responses，以及 CLI 得到一条完整回复。本文的脱敏回环实测记录为：
text
REQUEST method=POST path=/v1/responses model=fixture-model stream=true
FIXTURE_RESPONSE status=200 signal=CODEX_WIRE_OK
先判断：这是配置解析错误，不是接口 401
这类报错有一个很重要的时间顺序：Codex 还没有建立模型请求，配置解析器就已经拒绝启动。因此下面几件事在当前阶段都不是第一修复动作：
- 换一把 Key；
- 给账号充值；
- 修改模型 ID；
- 给 Base URL 反复加减
/v1； - 增加重试次数。
我用 CLI 参数构造了一个隔离 Provider，把 wire_api 故意写成 chat。进程退出码为 1，输出精确指出该值已不再支持，并要求改成 responses。同一条命令甚至没有抵达本地回环服务，这证明失败发生在网络之前。
这一步能帮你避免一个常见误区：看到"API"就从认证和网络开始查。实际应先按错误发生层级处理，顺序是"配置能否加载 -> 请求走到哪里 -> 服务端返回什么"。
修法一：显式写 wire_api="responses"
如果团队希望配置意图一眼可见，就保留这一行：
toml
wire_api = "responses"OpenAI 当前 Codex 配置参考把 model_providers.<id>.wire_api 的类型列为 responses，并说明这是唯一支持值。官方自定义 Provider 示例也使用 Responses 协议。
我将相同的隔离 Provider 改成 responses 后，Codex CLI 0.144.1 成功启动，向夹具发送：
text
POST /v1/responses
stream=true夹具返回一段最小 Responses SSE 事件流，CLI 最终输出 CODEX_WIRE_OK，退出码为 0。这里的"成功"只说明 Codex 的协议选择、请求路径和事件消费链路成立，不说明任意真实供应商都支持该接口。
修法二：删除 wire_api，使用当前默认值
如果不需要在配置中强调协议，可以直接删除旧行：
toml
[model_providers.my_proxy]
name = "My Responses Provider"
base_url = "https://example.com/v1"
env_key = "MY_PROVIDER_API_KEY"官方配置参考说明，省略 wire_api 时默认值同样是 responses。我也用同一个回环夹具复测了省略字段的版本，结果仍然是：
text
REQUEST method=POST path=/v1/responses model=fixture-model stream=true
FIXTURE_RESPONSE status=200 signal=CODEX_WIRE_OK这两种修法在当前版本的请求路径上没有差异。显式写出适合需要审阅配置的团队；删除字段适合希望减少过时枚举值的个人配置。不要把它改回 chat，也不要为了绕过解析器而降级 CLI，把旧协议兼容风险留到以后。
配置到底应该放在哪里
另一个容易被忽略的点是配置作用域。官方配置参考说明，用户级配置位于：
text
~/.codex/config.toml项目里的 .codex/config.toml 可以保存可信项目的部分覆盖项，但不能覆盖 model_provider 和 model_providers。所以你在项目目录里改了 Provider 表、重启后却毫无变化，不一定是缓存问题，可能只是放错了层级。
建议按下面顺序确认：
bash
codex --version
codex exec --help然后检查你编辑的是用户级配置，并用 --strict-config 让未知或过期字段直接失败。本文没有读取本机认证文件，也没有把真实 Key 打进命令或日志；回环测试使用的是只对当前进程有效的虚拟环境变量。
Base URL 为什么不要直接写到 /responses
本次夹具把 Provider 的 base_url 设置为：
text
http://127.0.0.1:43117/v1实际日志显示 Codex 在其后拼接 /responses，得到 /v1/responses。因此配置一般应停在服务基址层，不要把完整资源路径写成：
text
https://example.com/v1/responses否则客户端再次拼接资源路径时，可能变成重复路径。真实 Provider 是否要求 /v1，仍应以它自己的文档和一次可见请求为准；本文只证明 Codex 对回环基址的实际拼接结果。
修好 wire_api 后仍失败，按下一层继续查
wire_api 修复只解决第一道门。配置能加载后，如果出现新的错误，应保留新错误的原始状态码和请求标识，再进入下一层：
| 新信号 | 优先检查 | 不要先做 |
|---|---|---|
| 401 / 403 | 环境变量是否存在、认证方式是否匹配 | 反复改 wire_api |
| 404 | Base URL 层级、服务是否暴露 /responses |
把完整 /responses 塞进 Base URL |
| model_not_found | 服务端精确模型 ID、当前账号可见模型 | 用展示名猜 ID |
| SSE 中断 / 超时 | 首包、最后事件、代理、服务端断开 | 无限重试 |
| 本地夹具意外 502 | 代理是否错误接管 loopback | 推断真实 Provider 故障 |
本次第一次回环测试就遇到了最后一种情况：主机代理把 127.0.0.1 请求带走，CLI 得到 502，而夹具没有收到任何日志。把测试进程限定为 loopback 直连后，完全相同的 Responses 配置才出现 /v1/responses 和 CODEX_WIRE_OK。所以"502"也不能脱离请求是否真正抵达目标服务来判断。
一份可复制的验收清单
修复后不要只看启动成功，逐项打勾：
- 当前 CLI 版本已经记录；
- 编辑的是用户级
~/.codex/config.toml； - 顶层使用
model_provider，并与[model_providers.<id>]的 ID 一致； -
wire_api已删除或显式设为responses； -
base_url是服务基址，不是完整/responses资源 URL； - Key 通过
env_key指向环境变量，没有写入配置和日志； -
--strict-config不再报过期字段； - 可见请求路径是
/v1/responses或 Provider 文档定义的对应路径； - 最小提示词得到完整回复；
- 失败时保留状态码、请求标识和最后一个 SSE 事件，再进入下一层排查。
结论
看到 wire_api="chat" is no longer supported 时，正确动作不是先查 Key，也不是降级客户端，而是先让当前配置契约成立：把字段改成 responses，或者删除它使用默认值；确认 Provider 写在用户级配置；再用实际请求路径验证 Codex 确实走到 /v1/responses。
本文的证据边界很明确：Codex CLI 0.144.1、本地回环 Responses 夹具、虚拟 Key、无真实模型与线上账号。它证明了配置解析和客户端请求路径，不替任何第三方服务背书。只要按"配置加载 -> 请求路径 -> 服务端响应"这个顺序排查，就不会把一个启动期硬错误误判成认证、余额或网络问题。