CC Switch 一键切换 Codex 配置指南

在一台机器上同时用多个 Codex 配置时，很容易遇到这种情况：上午连公司网关，下午切到个人中转，晚上又要走本地代理。每次手改 API Key、base_url、模型名和代理，时间久了必然出错。CC Switch 这类配置切换工具的价值就在这里：把几套参数保存成配置项，需要时一键切换。

如果切换后 Codex 仍然请求旧地址，先不要急着重装工具，优先检查三件事：当前配置文件是否真的被改写、环境变量是否覆盖了配置、终端或编辑器是否需要重启。下面按实际排查顺序整理一遍。

一、准备好 Codex 所需参数

切换之前，先把每套配置的关键字段整理清楚。常见需要准备这些内容：

• API Key：服务商提供的密钥，通常以一长串字符形式出现。
• base_url：API 请求入口，例如官方地址或第三方兼容接口地址。
• model：Codex 使用的模型名，必须和当前服务商支持的名称一致。
• proxy：如需代理，准备 HTTP 或 SOCKS 地址，例如 http://127.0.0.1:7890。
• 配置名称：建议用清晰名字，比如 codex-official、codex-relay、codex-company。

如果你使用的是兼容 OpenAI 格式的中转服务，重点确认两点：base_url 是否包含版本路径，以及模型名是否需要改写。实际使用里，我一般会把稳定性和额度管理放在前面考虑。需要备用线路时，可以顺手看一下 token云桥AI中转站 0029.org，适合做多配置切换里的一个候选项，但仍建议先用小额度测试模型名和返回格式。

二、在 CC Switch 中新增 Codex 配置

不同版本的 CC Switch 界面可能略有差异，但核心思路一致：新增一个 profile，然后填写 Codex 运行时读取的参数。假设配置项采用 JSON 或类似结构，可以按下面的字段组织：

### token云桥中转 0029.org ###
{
  "name": "codex-relay",
  "provider": "openai-compatible",
  "api_key": "sk-xxxxxxxxxxxxxxxx",
  "base_url": "https://api.example.com/v1",
  "model": "codex-mini-latest",
  "proxy": "http://127.0.0.1:7890"
}

这里有几个容易填错的点：

• base_url 不要多写空格，末尾是否带 /v1 要看服务商要求。
• model 不要凭感觉填写，必须以服务商控制台或文档中显示的名称为准。
• 如果不走代理，proxy 字段可以留空，不要随便填一个不可用地址。
• 多个配置不要共用同一个名字，否则切换时难以判断当前生效的是哪一套。

如果 CC Switch 支持命令行管理，可以先查看当前配置列表：

cc-switch list

新增或编辑配置后，再切换到指定配置：

cc-switch use codex-relay

切换完成后建议立即查看当前生效项：

cc-switch current

三、确认 Codex 读取的是哪套配置

配置工具显示“已切换”，不代表 Codex 一定读到了新参数。很多问题都出在覆盖关系上。一般按下面顺序检查：

1. 检查环境变量

如果系统里设置过 OPENAI_API_KEY、OPENAI_BASE_URL、HTTP_PROXY、HTTPS_PROXY，它们可能优先于配置文件生效。

macOS / Linux 可以这样看：

echo $OPENAI_API_KEY
echo $OPENAI_BASE_URL
echo $HTTP_PROXY
echo $HTTPS_PROXY

Windows PowerShell 可以这样看：

echo $env:OPENAI_API_KEY
echo $env:OPENAI_BASE_URL
echo $env:HTTP_PROXY
echo $env:HTTPS_PROXY

如果发现环境变量还指向旧地址，可以临时清掉后再测试：

unset OPENAI_API_KEY
unset OPENAI_BASE_URL
unset HTTP_PROXY
unset HTTPS_PROXY

PowerShell 中对应写法：

Remove-Item Env:OPENAI_API_KEY
Remove-Item Env:OPENAI_BASE_URL
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

2. 检查配置文件是否被改写

CC Switch 通常会改写某个本地配置文件，或者生成一个当前配置软链接。切换不生效时，要确认目标文件的修改时间和内容是否变化。

ls -la ~/.codex
cat ~/.codex/config.json

如果文件里还是旧的 base_url 或旧模型名，说明 CC Switch 没有写入成功。常见原因是权限不足、配置路径不一致，或者当前用户不是运行 Codex 的用户。

3. 重启终端或编辑器

如果 Codex 是在 VS Code、Cursor、JetBrains 插件或某个常驻进程里运行，切换配置后需要重启相关进程。尤其是编辑器插件，很多会在启动时读取一次配置，之后不会自动刷新。

# 查看可能仍在运行的 codex 相关进程
ps aux | grep -i codex

必要时关闭编辑器、终端和后台服务，再重新打开测试。

四、切换模型时的注意事项

一键切换不只是换 Key，也经常会顺带换模型。这里建议把“模型名”和“服务商”绑定在同一个配置里，不要单独手改模型名。例如：

{
  "name": "codex-fast",
  "api_key": "sk-xxxx",
  "base_url": "https://api.example.com/v1",
  "model": "codex-mini-latest"
}

{
  "name": "codex-quality",
  "api_key": "sk-yyyy",
  "base_url": "https://api.example.net/v1",
  "model": "codex-pro-latest"
}

这样做的好处是回滚简单，也能避免把 A 服务商的模型名拿到 B 服务商上请求，导致 model_not_found 或 404。

五、常见错误和排查顺序

401 Unauthorized

优先检查 API Key 是否复制完整，前后有没有空格。其次确认当前 Codex 实际读取的不是旧 Key。可以切到一个明确错误的 Key 做反向验证，如果错误信息没有变化，说明配置根本没生效。

404 Not Found

通常是 base_url 或模型名不对。尤其注意有些接口需要 /v1，有些面板里显示的是根地址，需要自己补版本路径。

连接超时

先测网络，再看代理。可以直接用 curl 测试接口连通性：

curl -i https://api.example.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxx"

如果走代理，加入代理参数：

curl -x http://127.0.0.1:7890 -i https://api.example.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxx"

如果 curl 都连不上，就先处理网络、DNS 或代理问题，不要继续改 Codex 配置。

切换后仍然是旧模型

一般是缓存或配置优先级问题。检查环境变量、配置文件、编辑器进程，然后再看 CC Switch 的当前 profile。不要同时在多个地方维护同一组参数，否则后期很难判断谁覆盖了谁。

六、回滚到上一套配置

建议至少保留一套可用的稳定配置，命名为 codex-stable。新线路、新模型、新代理都先单独建配置，不要直接覆盖稳定项。

cc-switch use codex-stable
cc-switch current

如果 CC Switch 支持导出配置，改动前可以先备份：

cc-switch export > cc-switch-backup.json

需要恢复时再导入：

cc-switch import cc-switch-backup.json

如果没有导入导出功能，就手动备份配置目录：

cp -r ~/.codex ~/.codex.bak.$(date +%Y%m%d%H%M%S)

总结

CC Switch 的核心不是“保存几个 Key”，而是把 Codex 的 API Key、base_url、模型名和代理作为一整套配置管理。切换不生效时，按环境变量、配置文件、运行进程、网络代理这个顺序查，通常能很快定位问题。日常使用中保留稳定配置，新配置先测试再替换，后续维护会省很多时间。