我用 CC Switch 处理这类配置，图的就是省心：供应商切换、密钥、模型目录和本地协议转换都放在一个地方。Codex 还是原来的 Codex，变的是它请求的上游。
这件事先要分清一件很容易踩坑的事：Codex 自定义提供商走的是 Responses API。如果第三方本身就提供 Responses 兼容接口，CC Switch 可以把它直接写入 Codex 配置；如果它只有 Chat Completions 接口，必须经由 CC Switch 的本地路由做协议转换。把 Chat Completions 地址直接填进 Codex，通常不会成功。
下面的界面名称和配置约定来自 CC Switch 用户手册与 OpenAI 的 Codex 配置参考，链接放在文末。版本更新会改变按钮位置，接口判断不会变。
开始前，先准备这几样
- 已安装 Codex CLI，并能在终端运行
codex。 - 已安装 CC Switch，并在其中启用 Codex。
- 第三方服务的 API Key、接口地址，以及准确的模型 ID。
- 确认服务商允许把它的接口用于你的场景，也确认自己愿意把提示词、代码片段和工具调用内容发给它。
最后一点并不多余。编码任务经常会把文件名、报错、配置片段甚至密钥附近的上下文带进请求。测试时先拿一个空仓库，别一上来就对公司的生产代码开火。
先判断：直连还是本地路由
别急着填地址。先问服务商一个具体问题：它到底支持哪个接口？
| 上游能力 | 在 CC Switch 里的做法 | 是否要保持本地代理运行 |
|---|---|---|
| 支持 OpenAI Responses API | 选择对应的 Codex 预设，或新建自定义供应商后直连 | 不需要 |
| 只支持 OpenAI Chat Completions，或模型名是 DeepSeek、Kimi、GLM 等 | 开启“需要本地路由映射”，并填写模型映射 | 需要 |
CC Switch 的手册明确说明：本地路由会把 Codex 发出的 Responses 请求转换成上游的 Chat Completions 请求，再把流式响应、推理内容和工具调用转换回来。它也会为映射的模型生成 Codex 的模型目录。因此，选择 DeepSeek、Kimi 一类内置预设时，通常已经替你把这个开关和映射表准备好了。
配置一个已有预设的服务商
能用预设就别手写 JSON。预设会带上端点、协议类型和常用模型设置，少掉很多“地址看起来对，但协议其实不对”的麻烦。
- 打开 CC Switch，切到 Codex。
- 点击右上角的 +，选择供应商预设。
- 填入 API Key；如果表单提供“获取模型”，可以让 CC Switch 调用上游的
/v1/models获取模型列表。 - 选择模型后保存，在供应商卡片上点击 启用。
- 关闭并重新打开终端，再运行
codex。
如果获取模型报 401 或 403，优先检查 Key；404 或 405 往往说明服务商没有实现 /v1/models，这时按服务商文档手填模型 ID 即可。模型 ID 不是展示名称，大小写和连字符都要照抄。
配置自定义 Responses 接口
当服务商没有预设、但明确宣称兼容 OpenAI Responses API 时，选择 自定义。填写服务商给出的基础地址、API Key 和模型 ID，然后保存并启用。
CC Switch 会管理 Codex 的 ~/.codex/auth.json 与 ~/.codex/config.toml：前者保存 API Key，后者指定 model_provider、base_url 和模型。OpenAI 的配置参考也说明了这几个自定义提供商字段，其中 wire_api 当前只支持 responses。因此，别把 /v1/chat/completions 当成直连地址塞进去；那不是 Codex 可直接使用的协议。
如果你要检查 CC Switch 是否真的接管了配置，可以只读查看 ~/.codex/config.toml。不要在切换供应商后再手工改这个文件，下一次启用或切换时 CC Switch 可能会把你的改动覆盖掉。
配置只有 Chat Completions 的第三方 API
这类接口最常见，也最容易误会。“OpenAI 兼容”经常只意味着它兼容 /v1/chat/completions，不代表 Codex 能直连。
- 在 Codex 的供应商面板添加对应预设；没有预设就新建自定义供应商，填入 API Key 和端点。
- 打开 需要本地路由映射。
- 在 模型映射 中填入上游真实的模型 ID；可选地补充显示名称和上下文窗口。
- 到 CC Switch 的代理服务中启动本地代理，并启用 Codex 接管。
- 保持 CC Switch 和本地代理运行，重新启动终端后再运行
codex。
启用接管后，CC Switch 会把 Codex 的 base_url 指到本机代理的 /v1 地址。默认监听在 127.0.0.1，这正是应该保持的状态：不要为了方便把它改到 0.0.0.0，除非你清楚局域网暴露这个代理意味着什么。
模型映射改完后也要重启 Codex。它在启动时读取模型目录，之后在 /model 中才能看到你添加的上游模型。
做一次小而完整的验证
第一次连接不要拿复杂任务试。用一个空目录，依次做下面几件事：
- 运行
codex，执行/model，确认当前模型或映射的模型出现在列表里。 - 发一个不含敏感内容的小请求，例如“创建一个只有
README.md的空项目，并说明会写入什么”。 - 在 CC Switch 的代理或用量页面检查请求是否到了预期供应商、模型和状态码是否成功。
能返回内容，还不能证明工具调用就没问题。再让它创建一个无关紧要的文本文件，确认流式输出、写文件和权限确认都能走通。走本地路由的供应商尤其要做这一步。
连接失败时，按这个顺序查
一开始就是 401/403。 API Key 不对、套餐没有该模型权限，或者第三方网关要求额外认证头。先在服务商控制台验证 Key，再回 CC Switch 更新，不要在终端里硬编码密钥。
模型列表拿不到，或 /model 里没有模型。 前者可能是上游没提供 /v1/models；后者常见于忘了填模型映射或没有重启 Codex。直接填写准确的模型 ID，重新启用供应商并重启终端。
直连可以，Chat 接口却报 404 或协议错误。 看“需要本地路由映射”是否开启，同时确认代理服务和 Codex 接管仍在运行。本地代理一旦停止，Codex 仍指向本机地址，请求自然会失败。
换了供应商却还是走旧接口。 关闭所有旧终端，新开一个再启动 Codex；如果系统环境变量里还留着 OPENAI_API_KEY，也检查一下。CC Switch 的 FAQ 专门提到环境变量可能覆盖它写入的供应商配置。
推理强度看起来没有作用。 这不一定是故障。一些上游只提供“开启/关闭推理”，不接受 low、medium、high 等等级。CC Switch 会按供应商、端点和模型名适配参数；用了中转域名或改写过的模型名时，识别也可能失效。
留一个回退方案
在 CC Switch 里保留 OpenAI 官方 登录预设。第三方服务维护、代理异常或模型表现不适合当前任务时，切回官方预设，关闭本地接管并重新开终端，就能把链路收回到官方服务。
我会把第三方供应商当成可替换的开发环境配置，不会把它当成长期绑定。Key 单独创建、设置限额、定期轮换。涉及私有仓库、客户数据或生产凭据时，先想清楚数据会经过谁的服务器。省下几步配置时间，不值得换来一次泄露。