为了用上Codex，前前后后用了EchoBird、Codex++、CC Swith，有单独用的，用组合起来用的，折腾了大半个月，踩了无数坑，这两天才终于把Codex接第三方API这条路完全跑通，Codex真正可以可以稳定、顺畅干活，慢慢变成了生产力工具的一部分。

下面是把自己亲身经历总结出来的避坑指南，以及报错的修复方法。

Echobird、CC Swith、Codex++起什么作用？

由于OpenAI严格限制ChatGPT账号使用，国内想要用上Codex，只有两条路：想办法注册ChatGPT账号，申请到OpenAI API；要么就是给Codex接第三方API。

至少目前第二条路更容易走通，GitHub上有许多给Codex接第三方API的开源工具，EchoBird、CC Swith、Codex++是其中用的比较多的三个。当然，如果你对其中的原理理解的比较透彻了，也有开发基础，完全可以自己做一个第三方工具给Codex接API。

说说我对上面三款开源工具的理解，方便你想用的时候知道怎么选。

Echobird和CC Swith可以归为一类，都是给agent接入大模型API的通用工具，不仅能给Codex接第三方API，Claude Code、OpenCode、Hermes Agent、OpenClaw都能接，而且只要你有自己的API，不管是国内的还是国外的，甚至中转站的，绝大部分都可以接。

Echobird和CC Swith的工作原理基本也一样，他们就像是agent和大模型API中间的翻译，把你发给agent的指令翻译成大模型能听懂的话，大模型在后台跑命令，跑完把结果通过API交给Echobird/CC Swith，再转换成agent能听懂的话发给agent，最终就是你在agent里面看到的结果。

Codex++的作用除了可以给Codex本体配第三方API、当翻译，最大的区别就是功能增强，让你不用ChatGPT账号登录也能用到Codex的完整功能。像Codex强劲的插件生态、技能生态，computer use、browser、chrome这几个代表性的插件，在Codex++里配置好API，用Codex++启动Codex本体，就都能用了。

说完作用，用我自己的血泪经验告知你：

不管你用哪个工具或者组合，都必须避开的巨坑——

不要组合着用，坚决不要同一时间段内混着用、换着用！

最开始也是看了网上博主的教程，用Echobird➕Codex++的组合，用Echobird配置API，用Codex++做功能增强，这样一套被无数博主吹成黄金搭档的组合，真正用起来不是断连就是崩。那个时候还搞不清楚是什么缘由。

在Codex之前，用CC Swith成功给Claude桌面端配了DeepSeek API，也能稳定使用，Echobird➕Codex++的组合崩了后来，看到更新后来的Codex++ 供应商配置多了联动CC Swith功能，就自己摸索着试CC Swith➕Codex++的组合。一开始还能跑通，用着用着就开始404、504、402、500各种报错。试了关闭联动CC Swith也解决不了问题。

各种查资料、翻文档、刷视频、扒配置、问AI，终于搞清楚一件事：

如果在Codex++配置了API信息，不管是Echobird➕Codex++，还是CC Swith➕Codex++，实则都是在和Codex++抢夺“翻译”的岗位，抢着说话，会把你的指令和大模型跑出来的结果进行二次翻译，不可避免就会出现各种报错。

所以即使是我把Codex++里面联动CC Swith的开关关掉，他们两个在API配置里重复写的嵌套配置信息还是会存在，不管单独用Codex++，还是单独用CC Swith都会报错，被严重污染的配置让Codex根本没法用。

我目前的用法是：

EchoBird已经彻底卸载。

单独用Codex++来让Codex本体跑第三方API，CC Swith固定给Claude自己用，两边各玩各的，互不干扰。

而且Codex++更新到1.2.7版本后来，供应商配置里面已经去掉了联动CC Swith选项，也能避免配置信息被覆盖、被污染。

如果你像我之前一样，几个工具换着用、混着用、组合着用，配置已经被污染却无从下手不知道怎么修，还想把Codex++、CC Swith给Codex配API用，下面这份我自己踩坑整理出来的简易版修复手册，大致率能帮你快速找到问题、找到解决办法。

（当时没截图，把多次出现的报错整理成了文字）

端口连不上

报错：

stream disconnected before completion: error sending request for url (http://127.0.0.1:57321/v1/responses)

缘由：Codex 的 ~/.codex/config.toml 中 base_url 配置的端口号与实际运行的端口号不一致。

解决：手动编辑 ~/.codex/config.toml，将 base_url 改为：你的API Key提供商的官方base URL。

改完重启Codex。

供应商地址填错（死循环）

报错：

502 Bad Gateway: CC Switch local proxy failed while handling Codex endpointProvider: DeepSeek; upstream_status: HTTP 502

缘由：

CC Switch供应商的 API 地址被覆盖成了 http://127.0.0.1:15721/v1，请求被CC Switch发回给了自己，造成死循环 → 502。

解决： 将CC Switch供应商 API 地址改为正确的上游地址：

• DeepSeek：https://api.deepseek.com。
• 或其他第三方中转代理地址。

不需要 OpenAI 认证头却发送了

报错表现： Codex 向本地路由发送请求时携带了 OpenAI 认证 token，被路由拒绝。

解决： 修改 ~/.codex/config.toml：

sed -i '' 's/requires_openai_auth = true/requires_openai_auth = false/g' ~/.codex/config.toml

由于走第三方 API，不需要向 OpenAI 做认证。

Model Provider 不一致

报错： 502 或模型不存在

缘由： Codex 配置的 model = “agnes-2.0-flash” 但 CC Switch 用 DeepSeek 供应商去请求这个模型，DeepSeek 没有 Agnes 的模型。

解决： 确保 Codex 的 model 名称在 CC Switch 该供应商的模型列表中存在。如果用了聚合 API，模型名要以平台实际映射名称为准。

快速自查清单

如果报错不知道怎么排查，按这个顺序检查：

• CC Switch路由总开关 + Codex 路由开关是否开启

• 是否只开启了一个中转工具：CC Switch和 codex++ 不要同时运行，这里不是说用Codex++联动CC Swith，而且Codex++和CC Swith都开着，只用其中一个跑Codex本体。

没遇到上面这些报错时候可能会看不懂，遇到了可以帮你快速定位、快速修复。

手册里只写了我遇到的报错怎么解决，如果你遇到过其他的报错信息最后修好了，欢迎补充。

如果你身边也有在用Codex的朋友，遇到报错不知道怎么修的，请把这份手册转发给他，很可能对他有用。

我是平野先生，一个自学AI、喜爱折腾的职场中登。

关注我，让你的AI之路少踩坑。

搜索同名公众号不迷路。

如果你身边也有在折腾AI工具朋友，请把这篇文章随手转给他，能帮他少走点弯路。