【Bug已解决】Codex CLI 报错 Support for the chat wire API is deprecated and will soon be removed 解决方案1. 问题描述按照网上一篇教程给 Codex CLI 配置了接入第三方模型服务商的 API 中转地址配置里写了wire_api chat运行时却收到弃用警告甚至在较新版本上直接变成硬性报错导致无法正常请求⚠ Support for the chat wire API is deprecated and will soon be removed. Please update your model provider definition in config.toml to use wire_api responses.在更新版本的 Codex CLI 上这条警告已经升级为直接报错程序无法继续执行Error loading config.toml: wire_api chat is no longer supported. Update to wire_api responses.1.1 具体现象严格按照某篇 2025 年写的教程配置当时能正常运行升级 Codex CLI 版本后同样的配置突然报错或者持续弹出弃用警告接入某些第三方 API 中转/网关服务时对方文档还停留在旧协议格式直接修改配置文件里的字段值后请求仍然报不支持怀疑是自己改错了这个问题本质上是Codex CLI 在 2026 年初的一次重大协议变更——官方彻底移除了对旧版Chat Completions协议wire_api chat的支持统一改为新版Responses APIwire_api responses。任何还在使用旧协议配置格式接入第三方服务的用户都会在升级后遇到这个报错。2. 原因分析wire_api是 Codex CLI 配置文件中用于声明当前对接的 API 服务端使用哪种通信协议格式的字段。OpenAI 官方在协议演进过程中逐步用新的Responses API/v1/responses端点取代了传统的Chat Completions API/v1/chat/completions端点两者在请求/响应的数据结构上有明显差异。演进时间线大致如下早期版本同时支持 chat 和 responses 两种协议格式 ↓ 过渡阶段使用 chat 协议时会打印弃用警告但仍能正常工作 ↓ 2026 年某个版本起彻底移除对 chat 协议的支持 ↓ 配置文件中仍然写 wire_api chat 的用户 ↓ 触发报错Error loading config.toml无法启动对于接入第三方 API 网关尤其是一些聚合了多个模型厂商、对接不同协议格式的中转服务的用户来说这个问题尤为突出——很多第三方服务商的接口文档更新速度跟不上 Codex CLI 官方的协议演进节奏导致网上仍然流传着大量教你填wire_api chat的过时教程。3. 解决方案方案一将配置文件中的wire_api字段改为responses最直接# ~/.codex/config.toml # 错误的旧版写法 [model_providers.my_gateway] name My Gateway base_url https://my-gateway.example.com/v1 wire_api chat # 正确的新版写法 [model_providers.my_gateway] name My Gateway base_url https://my-gateway.example.com/v1 wire_api responses修改后重新运行codex弃用警告或报错应该会消失。方案二确认第三方 API 服务商是否已经支持 Responses API 格式如果只是简单改字段值实际请求可能会因为服务端根本不认识新协议格式而失败表现为其他类型的错误比如 404 或响应结构解析失败。这种情况下需要先确认第三方服务商是否已经适配了新的 Responses API 协议# 用 curl 手动测试一下目标端点是否支持 responses 协议 curl -X POST https://your-gateway.example.com/v1/responses \ -H Authorization: Bearer $API_KEY \ -H Content-Type: application/json \ -d {model: gpt-5-codex, input: 测试连接}如果服务商确实还没适配新协议需要联系服务商确认后续升级计划或者暂时改用其他已经支持新协议的服务商。方案三查阅当前使用的第三方网关文档中关于responses协议的具体配置说明不同网关服务商在适配新协议时可能会有一些自己特定的额外配置项比如需要额外声明支持的字段、或者调整认证头信息建议直接查阅该服务商最新的接入文档而不是照搬其他网关的配置示例[model_providers.gateway_a] name Gateway A base_url https://gateway-a.example.com/v1 wire_api responses # 部分网关可能需要额外声明的字段具体以该网关文档为准 query_params { }方案四暂时锁定 Codex CLI 版本等待第三方服务商完成协议适配如果确实依赖某个尚未完成协议迁移的第三方服务而又不想放弃使用可以考虑暂时锁定在支持旧协议的 Codex CLI 版本上等待该服务商完成适配后再升级# 查看当前安装的版本 codex --version # 如果需要安装指定的旧版本具体命令格式以包管理器实际支持为准 npm install -g openai/codex指定版本号⚠️风险提示长期锁定旧版本会错过新版本的功能改进和安全修复建议只作为过渡期的临时方案同时积极关注第三方服务商的协议迁移进度。方案五改用官方原生端点规避第三方网关的协议适配滞后问题如果条件允许直接对接 OpenAI 官方原生的 API 端点是最稳妥的方式能确保协议格式始终和 Codex CLI 官方保持同步不存在第三方中转服务迁移滞后的问题[model_providers.openai] name OpenAI base_url https://api.openai.com/v1 wire_api responses4. 各方案对比总结方案适用场景推荐指数修改 wire_api 字段所有场景下的第一步必做操作⭐⭐⭐⭐⭐确认服务商是否已适配修改字段后请求仍然失败时⭐⭐⭐⭐⭐查阅网关专属配置说明不同服务商有各自额外的配置要求⭐⭐⭐⭐暂时锁定旧版本依赖的服务商尚未完成协议迁移⭐⭐⭐改用官方原生端点追求长期稳定不受第三方迁移进度影响⭐⭐⭐⭐5. 常见问题 FAQ5.1 只看到弃用警告程序还能正常运行需要立刻处理吗建议尽早处理不要等到警告变成硬性报错才被动应对。弃用警告的出现本身就是官方明确释放即将移除的信号提前完成迁移能避免在某次版本升级后突然无法使用的被动局面。5.2Chat Completions和Responses API具体有哪些核心差异两者在请求参数结构、流式响应的数据格式、以及对工具调用function calling的表达方式上都有明显差异Responses API是官方为更好支持 Agent 类场景多轮工具调用、状态管理设计的新一代协议具体字段差异建议参考官方最新的 API 文档。5.3 如果我自己搭建的内部网关服务需要同时兼容 chat 和 responses 两种客户端应该怎么处理建议在网关服务内部做一层协议转换适配层对外根据客户端请求的协议类型分别处理而不是要求所有客户端都必须使用同一种协议这样能兼顾新旧客户端的兼容性具体实现方式取决于你的网关技术栈。5.4 团队里有些同事的配置还是旧协议格式怎么快速排查全员的配置状态可以写一个简单的脚本批量检查团队内已知配置文件路径中是否还存在wire_api chat的写法grep -rn wire_api.*.*chat ~/.codex/config.toml 2/dev/null发现后统一提醒对应同事更新配置避免个别人因为版本升级突然无法使用。5.5 这个问题和前面提到的config.toml TOML parse failed是同一类问题吗不是同一类。TOML parse failed 是纯粹的语法格式错误比如缺少引号、逗号而这里的wire_api报错是配置内容本身合法符合 TOML 语法但字段的取值在语义上已经不被当前版本的程序支持两者的报错原因和排查方向完全不同不要混淆。5.6 除了官方文档还有什么办法确认第三方服务商的协议支持情况可以直接用 curl 分别测试/v1/chat/completions和/v1/responses两个端点的响应情况参考本文方案二的测试方式实际请求的返回结果往往比阅读文档更直接可靠尤其是在服务商文档更新不及时的情况下。5.7 排查清单速查表□ 1. 确认报错信息中明确提到 wire_api / chat / responses 关键字 □ 2. 将配置文件中的 wire_api 字段统一改为 responses □ 3. 用 curl 手动测试第三方服务商是否真正支持新协议 □ 4. 查阅该服务商最新文档确认是否有额外的专属配置要求 □ 5. 评估是否需要暂时锁定旧版本等待服务商完成迁移 □ 6. 优先考虑改用官方原生端点以规避第三方迁移滞后问题 □ 7. 团队场景批量排查是否还有同事的配置停留在旧协议格式6. 总结Support for the chat wire API is deprecated报错的本质是Codex CLI 官方完成了从旧版 Chat Completions 协议到新版 Responses API 协议的迁移而配置文件中仍然使用了已被移除的旧协议声明。核心处理思路第一步永远是把配置文件中的wire_api改为responses这是解决报错本身的直接方式修改字段后如果请求仍然失败需要进一步确认对接的第三方服务商是否已经真正适配了新协议不能只改自己这一侧的配置长期来看优先考虑对接官方原生端点或协议迁移及时的服务商能避免被第三方服务的迁移进度所拖累。最佳实践建议AI 编程工具的底层协议演进速度很快遇到以前能用现在不能用的配置类报错时第一反应应该是查阅官方最新的变更日志Changelog/Release Notes而不是继续沿用可能已经过时的网上教程。