一、先把这两个隐藏机制弄清楚，配置才不会白费力气

用 CC Switch 把国产大模型接入 Codex 桌面版，真正绊倒人的往往不是填错 API 密钥，而是两个藏在底层的机制：

  1. Codex 桌面应用会基于登录身份对模型选择器做门控，一旦检测不到 OpenAI 官方登录态，就会把自定义模型全部隐藏。
  2. DeepSeek、Kimi、MiniMax 等国内厂商暴露的是 Chat Completions 协议，而新版 Codex 用的是 Responses API 接口——请求体和流式结构完全不同，直连就会出现 404 或者解析错误。

CC Switch（GitHub 121k+ stars，MIT 许可）用两个开关解决了这些问题：

  • 「Codex 应用增强 → 切换第三方时保留官方登录」会让 auth.json 继续保存 OpenAI 的 Access Token，只把第三方参数写进 config.toml，骗过桌面端的门控逻辑。
  • 「本地路由」在 127.0.0.1:15721 起一个协议转换层，把 Codex 发出的 Responses 请求改写成 Chat Completions 再转发给上游，响应回来时再反向转换。

完整流程可以归纳为六步：先切回 OpenAI Official 完成登录 → 打开应用增强开关 → 用内置预设添加国产供应商并填 Key → 开启本地路由并允许接管 Codex → 启用供应商 → 完全退出并重启 Codex。

坑一：桌面端的模型展示门控

典型表现是，在 CC Switch 里切换到 DeepSeek 之后：

  • Codex 桌面应用的模型下拉框中看不到任何自定义模型，只剩下官方默认的那几个，推理等级也会回落；
  • 而命令行 codex 中 /model 一切正常。

官方文档明确说了，这不是 CC Switch 的 bug，而是 Codex 桌面客户端的上游闭源行为：桌面应用会根据当前登录身份过滤模型列表，一旦发现不到 ChatGPT/Codex 的登录态，就把配置文件里的自定义模型藏起来，强制回退到官方默认模型。
由于上游已经把这个问题的修复标记为“暂不规划”，所以无法从 GUI 层面根治，只能通过保留有效登录态来绕过去。

坑二：接口协议不匹配

协议 使用方 接口路径
Responses API 新版 Codex CLI / 桌面端 /responses
Chat Completions DeepSeek、Kimi、MiniMax、GLM 等 /chat/completions

两种协议的请求体、流式事件与返回结构完全不同。直接把 Chat 格式的地址填进 Codex 配置，轻则模型列表异常，重则 404 或 400，甚至流式数据无法被正确解析。

CC Switch 的做法是加入一层本地的协议转换层：

Codex 发出的 Responses 请求
          ↓
CC Switch 本地路由 (127.0.0.1:15721)
          ↓
上游 Chat Completions API
          ↓
转换回 Codex 认可的 Responses 格式

二、动手前的准备工作

根据官方建议，你需要准备好：

  • CC Switch v3.16.1 或更新版本（应用增强开关在 v3.16.1 起才做成显式开关，当前最新为 v3.18.0）；
  • 已安装并能成功启动的 Codex，建议同时保留桌面应用与 CLI；
  • 一个可以登录 Codex 的 OpenAI/ChatGPT 账号，Free 订阅即可（它只负责提供登录身份，不产生第三方流量费用）；
  • 至少一个国产模型的 API Key（DeepSeek、Kimi、GLM、MiniMax 任选其一）。

⚠️ 官方特别提醒：不要手动复制、分享 ~/.codex/auth.json 的内容，里面存有 OpenAI 的登录票据和 Access Token，属于敏感信息。

三、六步配置详解

第 1 步：先切回 OpenAI Official，完成官方登录

打开 CC Switch 的 Codex 面板，把供应商选为 OpenAI Official 并启用（如果列表里没有，可以从预设供应商中重新添加）。
接着启动 Codex（推荐用 CLI），按照正常流程登录一次 ChatGPT/Codex 账号。Free 订阅就足够——这里只是为了让桌面端感知到官方身份，实际的模型计费不会走这条路。

登录完成后，~/.codex/auth.json 就会保存一份有效的官方身份。后续操作的关键就在于不能让第三方供应商的切换覆盖这份官方缓存。

第 2 步：开启 Codex 应用增强

进入 设置 → 通用 → Codex 应用增强 → 切换第三方时保留官方登录，把这个开关键拨到启用状态。
这个开关默认是关闭的，所以绝大多数人第一次切换供应商时就已经把官方登录态弄丢了。
开启之后，切换到第三方供应商时 CC Switch 只会写入 config.toml，auth.json 保持原样不动，这样就保留了桌面端识别所需要的登录依据。

第 3 步：用内置预设添加国产供应商

回到 Codex 管理面板，点击右上角加号。强烈建议优先使用内置预设，因为预设已经填好了 base URL、默认模型、模型映射表以及 thinking/reasoning 参数，而且会自动勾选“需要本地路由映射”。

以下是四个国产供应商的预设信息（依据 CC Switch 官方指南与厂商文档）：

供应商 预设名 base URL 默认模型 协议
DeepSeek DeepSeek https://api.deepseek.com DeepSeek V4 Flash Chat（需路由）
Kimi 开放平台 Kimi https://api.moonshot.cn/v1 kimi-k2.7-code Chat（需路由）
Kimi For Coding Kimi For Coding https://api.kimi.com/coding/v1 kimi-for-coding Chat（需路由）
GLM GLM 智谱 Anthropic 兼容或 Coding Plan 地址 GLM-5.2 视预设而定
MiniMax MiniMax 见预设 见预设 Chat（需路由）

重点区分一下 Kimi 的两个预设：

  • Kimi 用的是 platform.kimi.com 开放平台的 Key，按 token 用量计费。
  • Kimi For Coding 是 Kimi 会员在 kimi.com/code 中生成的权益 Key，模型固定为 kimi-for-coding。

选择对应预设后，只要填入 API Key 并保存即可。

第 4 步：启动本地路由并接管 Codex

进入 设置 → 路由 → 本地路由，完成两个操作：

  1. 打开 路由总开关，启动监听 127.0.0.1:15721 的本地服务；
  2. 在 路由启用 中把 Codex 打开（如果只让 Codex 走路由，Claude、Gemini 的开关可以保持关闭）。

对于使用 Chat Completions 协议的供应商（DeepSeek、Kimi、MiniMax 等），这一步是必须的，否则会收到 404 或流式解析错误。
启用接管后，CC Switch 会把 Codex 的动态配置指向本地路由，你的真实 API Key 依然安全地保存在供应商配置中，由路由在转发时动态注入。

第 5 步：启用供应商

回到 Codex 供应商列表，点击目标供应商旁边的“启用”。如果看到 “需要路由” 标记，说明该供应商必须在路由服务运行期间才能使用；若路由未启动，CC Switch 会主动提示“需要路由服务才能正常使用”。

第 6 步：完全退出并重启 Codex

这里不是关闭窗口，而是彻底退出 Codex 进程，再重新启动。
原因有两点：

  • Codex 只在启动时读取 config.toml；
  • /model 菜单需要重启后才会重新加载 model_catalog_json。

四、配置成功后的样子

验证清单：

检查项 预期表现
Codex App 显示的账号信息 仍然显示 OpenAI 官方账号（这是正常现象）
CC Switch 当前供应商 显示为你选择的第三方供应商
路由请求日志 可以看到 Codex 请求从本地路由经过
第三方供应商后台用量记录 出现实际的模型调用记录
Codex /model 菜单 可以看到预设的国产模型，如 DeepSeek V4 Flash

开启应用增强后，~/.codex/config.toml 中会写入类似下面的配置片段：

model_provider = "custom"

[model_providers.custom]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
wire_api = "responses"
experimental_bearer_token = "sk-..."

而 auth.json 始终保留着官方登录缓存。桌面端看到的是 auth.json 里的身份，因此放行了模型选择器；实际请求则按照 config.toml 和路由的指引走向第三方厂商。

五、三个不能忽视的副作用

1. 看到官方账号 ≠ 配置没生效

这是最容易让人误会的现象。开启应用增强后，Codex 桌面端读的是 auth.json，所以会一直显示 OpenAI 账号信息。但这并不代表流量还在走 OpenAI——实际的计费、请求路径一切以 CC Switch 当前供应商和路由日志为准。

2. 不要用 Codex 里的账户信息来判断谁在扣费

切换到 DeepSeek 之后，界面仍然显示官方账号，但扣费、配额限制、错误码和数据隐私策略都已经切换到第三方。你可以通过 CC Switch 的用量面板查看具体的请求记录。

3. 官方登录态会过期

如果你连续好几天没有使用过官方 OpenAI 服务，Token 失效后模型选择器可能再次变空——这时候重新登录一次官方账号就能恢复。

⚠️ 官方明确反对的操作：在本地路由已接管 Codex 的情况下，把供应商切回 OpenAI Official。CC Switch 会尽量阻止这种操作，因为用代理方式访问官方 API 可能引发账号风险。建议官方登录仅用于保活 auth.json，实际模型调用全部通过第三方供应商完成。

六、常见问题排查

Q：已经开了增强开关，桌面端还是看不到自定义模型？

按照官方建议的顺序排查：

  1. 确认开关确实开启了——默认关闭，很多人第一次切供应商时就把官方登录态覆盖了。
  2. 官方登录态可能已过期，重新登录一次即可。
  3. 用 CLI 兜底诊断：运行 codex debug models，只要 CLI 端能列出模型，就说明配置本身没有问题（CLI 不受门控影响）。

Q：上游返回 404？

如果用的是内置预设，先检查当前供应商是否确实来自预设，并且路由已经正常运行。只有自定义供应商才需要手动核对 base URL——它应当是服务根地址，而不是包含 /chat/completions 的完整路径。

Q：/model 菜单里看不到国产模型？

保存供应商之后务必重启 Codex。CC Switch 会生成 cc-switch-model-catalog.json 并写入 model_catalog_json，但运行中的 Codex 进程一般不会热加载模型目录。

Q：为什么桌面端好像只能用第一个模型？

目前 Codex 桌面应用还不支持在 GUI 里切换多个模型，它会默认使用配置中的第一个模型。需要频繁切换时，建议通过 CLI 来操作。

Q：能同时并行使用多个模型吗？

不能。Codex CLI 在任意时刻只读取当前激活的那一套配置，CC Switch 做的是决定“哪一套生效”，而不是让多套配置同时运行。如果想并行使用不同模型，需要分别启动多个终端并搭配不同的 ~/.codex/ 配置目录。

Q：预设里没有我的供应商怎么办？

选择自定义配置，按供应商文档填入 API Key、base URL 和模型名称，并在高级选项中将“上游格式”设置为 Chat Completions（需开启路由）。

七、如何选择合适的模型

模型 适合场景 计费方式
DeepSeek V4 日常编程、大批量调用、对成本敏感的场合 按 token 用量
Kimi K2.7 Code 需要超长上下文的编码任务 按 token 用量
Kimi For Coding 已购买 Kimi 会员 Code 权益的用户 订阅制
GLM-5.2 Coding Plan 下支持 200k 上下文，跨文件重构 订阅制/按量
MiniMax 多模态与长文本场景 按 token 用量

一条实践经验：先用 DeepSeek 或 GLM Coding Plan 把整套流程跑通，确认路由、门控都没问题之后，再去折腾其他供应商——排查问题时，变量越少越好。

模型层抽象的价值。 把模型供应商从本地工具配置中解耦出来，好处远不止节约成本。上个月 Anthropic 就曾因出口管制对部分地区临时禁用了部分旗舰模型，那些把单一模型硬编码进生产链路的团队立刻受到影响。
除了通过 CC Switch 在本地做协议转换以外，也可以选择 API 网关层面的统一入口，比如非线智能API。它提供完全兼容 OpenAI SDK 的接口，目前已经上架 485 个模型，覆盖文本、代码、多模态等场景，国内可直接访问，切换模型时无需修改本地任何配置，大幅降低了环境切换和维护的复杂度。将模型调用从本地路由提升到平台层，也意味着更好的稳定性和更灵活的资源调配能力。

八、总结

Codex 桌面端接入国产模型的坑，本质上就两个：桌面应用按登录身份控模型列表，以及国产厂商用的是 Chat Completions 而不是 Responses 协议。理解这两点之后，配置就退化成一套机械的六步流程。

再强调三个最容易出错的点：

  • 应用增强开关默认关闭，必须手动打开；
  • 使用 Chat Completions 协议的供应商必须开启本地路由；
  • 改完配置必须完全退出再重启 Codex。

根据 CC Switch 官方仓库（GitHub 121557 stars，MIT 许可，最新版 v3.18.0 发布于 2026-07-21）和配置指南来看，这套方案目前还在活跃维护中。以上内容以 2026 年 7 月 27 日的官方文档为基础整理，各厂商 API 地址和模型名称可能会有调整，实际操作时建议以 CC Switch 内置预设和厂商最新文档为准。

延伸资源