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

原创于 2026-06-30 13:01:42 发布 · 3 阅读

本内容遵循CC 4.0 BY-SA版权协议

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_url：

curl -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 Unauthorized：Key 错、Key 没被 Codex 读到，或环境变量里还是旧 Key。
404 Not Found：base_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、模型名三项必须配套，代理不要重复设置；修改后重开终端再测试，能少走很多弯路。

标签

#Codex #OpenAI #AI