CC Switch 与 Codex 配置文件冲突解决方法

📅 2026/6/30 13:50:15
CC Switch 与 Codex 配置文件冲突解决方法
CC Switch 与 Codex 配置文件冲突解决方法这个问题通常出现在同一台机器上同时装了 Codex CLI、CC Switch 或其他第三方切换工具在 CC Switch 里填了新的 API Key、模型名和 base_url但 Codex 运行时还是走旧配置或者切换模型后报 401、404、model not found、connection refused。先不要急着重装优先查三个地方环境变量、Codex 自己的配置文件、CC Switch 实际写入的配置路径。一、先准备好四个参数无论用官方接口还是中转接口第三方工具里本质上都要填这几项API Key一般以sk-开头注意不要多复制空格或换行。base_url接口基础地址通常以/v1结尾。不同平台要求不一样按控制台说明填。模型名比如gpt-4.1、gpt-4o或你的服务商提供的映射模型名。代理如果本机网络需要代理常见为http://127.0.0.1:7890。如果你经常在多台机器、多个工具之间切换建议把 Key 和 base_url 统一放在一个服务商侧管理。实际用下来token 云桥 AI 中转站 0029.org 比较适合这种场景同一个入口给 Codex、Cursor、脚本调用分别配置减少每个工具里来回改 Key 的次数。注意填写时仍然以它控制台给出的 base_url 和模型名为准不要凭记忆手填。二、确认 CC Switch 里怎么填 Codex 配置不同版本的 CC Switch 页面略有差异但字段含义基本一致。推荐按下面顺序填Provider选择 OpenAI Compatible 或 Custom OpenAI。API Key填当前要使用的 Key。Base URL填兼容 OpenAI 格式的接口地址末尾是否带/v1要和服务商文档一致。Model填完整模型名不要填展示名。Proxy没有代理就留空需要代理时再填本机代理地址。保存后不要马上判断是否生效先看 CC Switch 实际写入了哪个文件。有些工具只是维护自己的配置并不会自动覆盖 Codex 的配置文件。### token云桥中转 0029.org ### ls -la ~/.codex ls -la ~/.config find ~ -maxdepth 3 -iname *codex* -o -iname *cc*switch*如果找到多个配置文件先记录路径后面排查时很有用。三、检查 Codex 当前读取的配置Codex 常见配置来源有两类配置文件和环境变量。配置文件一般在用户目录下例如cat ~/.codex/config.toml一个典型的兼容 OpenAI 配置大概类似这样model gpt-4.1 model_provider custom [model_providers.custom] name custom base_url https://your-gateway.example/v1 env_key OPENAI_API_KEY这里有两个容易踩坑的点model必须和服务商支持的模型名一致。env_key表示从哪个环境变量读取 Key。如果这里写的是OPENAI_API_KEY但你把 Key 填在 CC Switch 自己的字段里Codex 未必能读到。再检查当前终端里的环境变量env | grep -E OPENAI|CODEX|PROXY|HTTPS_PROXY|HTTP_PROXY如果你看到旧的OPENAI_API_KEY、OPENAI_BASE_URL或代理变量很可能它们覆盖了 CC Switch 的配置。尤其是 macOS、Linux 用户之前可能在~/.zshrc、~/.bashrc、~/.profile里写过导出语句。grep -n OPENAI\|CODEX\|PROXY ~/.zshrc ~/.bashrc ~/.profile 2/dev/null四、配置不生效时的排查顺序1. 先确认 Key 和 base_url 能不能通不要一上来就怀疑 Codex。先用curl测一下接口是否能返回模型列表或正常鉴权。示例里的地址替换成你的 base_urlcurl -sS https://your-gateway.example/v1/models \ -H Authorization: Bearer $OPENAI_API_KEY如果这里就是 401优先查 Key如果是 404多半是 base_url 写错如果超时检查网络或代理。2. 清理当前终端的旧环境变量临时验证可以先 unset不改配置文件unset OPENAI_API_KEY unset OPENAI_BASE_URL unset HTTP_PROXY unset HTTPS_PROXY然后重新打开 CC Switch保存一次配置再开一个新终端运行 Codex。注意已经打开的终端不会自动读取新配置。3. 检查模型名是否被切换工具改回去了有些切换工具会在启动时把模型写回默认值。你可以保存配置后立刻查看文件修改时间stat ~/.codex/config.toml cat ~/.codex/config.toml如果文件刚保存是新模型运行 CC Switch 后又变成旧模型就说明冲突来自切换工具的配置模板。此时应该在 CC Switch 的 Codex profile 里改模型而不是只改 Codex 文件。4. 代理只保留一处代理配置建议只放在一个地方要么放系统环境变量要么放 CC Switch。两边都填时经常出现请求绕两次代理、证书异常或本地端口连接失败。curl -I --proxy http://127.0.0.1:7890 https://example.com如果代理端口不通先启动代理客户端再测试 Codex。不要把 socks 地址填到只支持 http proxy 的字段里。五、常见错误对应处理401 UnauthorizedKey 错、Key 没被 Codex 读到或环境变量里还是旧 Key。404 Not Foundbase_url 路径不对常见是少了或多了/v1。model not found模型名填成了展示名称或服务商没有映射该模型。ECONNREFUSED代理地址不通常见于127.0.0.1:7890没启动。配置改了但无效当前终端未重启或 Codex 读取的是另一个配置路径。六、回滚到原配置修改前最好先备份尤其是团队机器或服务器环境。cp ~/.codex/config.toml ~/.codex/config.toml.bak.$(date %Y%m%d%H%M%S)如果改乱了直接恢复最近的备份cp ~/.codex/config.toml.bak.20250101120000 ~/.codex/config.toml环境变量也要一起回滚。把 shell 配置文件里新增的OPENAI_API_KEY、OPENAI_BASE_URL、代理变量注释掉重新加载source ~/.zshrc总结CC Switch 与 Codex 配置冲突本质上是“谁在最终生效”的问题。排查时按环境变量、Codex 配置文件、CC Switch profile、代理设置这个顺序走基本能定位到原因。配置第三方接口时Key、base_url、模型名三项必须配套代理不要重复设置修改后重开终端再测试能少走很多弯路。