如果你已经在用 Codex 写代码、改文件、跑命令，想把默认模型换成 DeepSeek V4，最省事的做法通常不是自己手改 ~/.codex/config.toml，而是直接交给 CC Switch 来管。
这样做的好处很实际：
- 不用自己反复改配置文件
- 不容易把接口地址和协议格式配混
- 出问题时更容易判断是供应商问题，还是路由没开
这篇只讲一件事：怎么把 DeepSeek V4 接进 Codex，并确认它真的已经跑通。
开始前先准备
先确认下面三样都已经有了：
- 你已经安装好了
Codex - 你已经安装并打开了
CC Switch，如果还没装，可以先去下载 CC Switch - 你手里有可用的
DeepSeek API Key
还有一点最好提前做：先把 Codex 至少运行过一次。
原因很简单。Codex 第一次启动时，通常会先生成自己的本地配置目录。如果你一次都没开过，后面 CC Switch 接管配置时，排查起来会更绕一点。
为什么 Codex 接 DeepSeek 要管本地路由
这个点和 Claude Code 不太一样，最好一开始就讲清楚。
现在的 Codex 主要走的是 OpenAI Responses API 这一套；但 DeepSeek 这类上游，常见提供的是 OpenAI Chat Completions 兼容格式。两边虽然都属于 OpenAI 风格接口，但请求体、流式返回和接口路径并不是一回事。
所以如果你把 DeepSeek 的 Chat 接口直接塞给 Codex，常见结果通常是：
- 模型列表不对
- 请求直接报
404或400 - 流式输出格式不兼容，Codex 读不出来
这时候真正起作用的就是 CC Switch 的本地路由。你也可以顺手看看 CC Switch 的更多教程，很多高级用法都会围着这层路由展开。
简单理解就是：
Codex继续按自己熟悉的 Responses 格式发请求CC Switch在本地把请求转成 DeepSeek 能收的 Chat Completions- 上游返回之后，再转回 Codex 能识别的格式
所以对 Codex 接 DeepSeek 这件事来说，本地路由通常不是可选项，而是关键环节。
切到 Codex 面板
打开 CC Switch 之后，在左侧应用切换器里选 Codex。
如果你没看到这个入口，先去：
设置 → 通用 → 应用可见性
确认 Codex 没有被隐藏。
添加 DeepSeek 供应商
进入 Codex 面板之后，点击右上角的 + 按钮添加供应商。
第一次配置时，优先直接选 DeepSeek 预设。原因也很简单：这条预设通常已经把接口基址、默认模型、模型菜单和需要本地路由这几个关键项帮你带上了，少走很多弯路。
最常见的流程就是：
- 选择
DeepSeek预设 - 填入你的
DeepSeek API Key - 确认默认模型
- 保存供应商
如果你只是想先接通，默认模型优先选下面两个之一就够了：
deepseek-v4-flashdeepseek-v4-pro
日常高频使用优先 Flash，复杂任务再换 Pro，这套顺序通常最稳。
把本地路由开起来
这一步很重要，最好不要跳。
去设置里的路由页面，找到本地路由，然后确认两件事都打开了：
- 本地路由主开关已经开启
Routing Enabled里面的Codex也已经开启
常见路径是：
设置 → 路由 → 本地路由
路由开起来之后，CC Switch 会让 Codex 不再直接打到 DeepSeek，而是先走本地地址，默认一般是：
http://127.0.0.1:15721/v1
真正的 DeepSeek API Key 仍然保存在 CC Switch 里，由本地路由转发时再注入。也就是说，你不需要把真实 Key 直接暴露在 Codex 当前运行配置里。
启用供应商，然后重开 Codex
回到 Codex 供应商列表，在刚添加的 DeepSeek 卡片上点一次：
启用
如果卡片上带有类似 Needs Routing 这类提示，也不用奇怪，意思就是这条供应商必须配合本地路由一起用。
这里和 Claude Code 最大的区别也在这儿：Codex 更适合在切换后直接重开当前终端会话。
原因通常有两个：
- Codex 进程可能已经读过旧的
config.toml - 模型目录或模型菜单刷新，往往也需要一个新进程
所以最稳妥的习惯就是：启用供应商之后，直接重新开一次 Codex。
先检查模型，再做一个小测试
重新进入 Codex 之后，先别急着拿大项目试。
先做两个很小的确认：
- 用
/model看一下当前模型是不是已经切到 DeepSeek - 发一个很轻的请求，看它能不能稳定返回
测试任务可以很简单，比如：
- 让它解释一小段代码
- 让它整理一个短需求
- 让它总结一个小文件
这一步主要是确认三件事：
- Codex 现在确实已经走到 DeepSeek 了
- 模型名是你刚才设的那个
- 返回没有出现认证、模型名或协议格式错误
什么情况优先怀疑是路由问题
如果你遇到下面这些情况，先不要急着改模型名，优先往路由这边查：
- 请求报
404，尤其是和/responses相关 - 模型已经启用，但 Codex 还是像没切过去
/model里看不到你刚配的 DeepSeek 模型- 返回是格式错误，或者流式输出明显不对
这类问题很常见，很多时候不是 DeepSeek 本身有问题，而是下面三项里有一项没对上：
- Codex 面板当前启用的供应商不是 DeepSeek
- 本地路由服务没有运行
Routing Enabled里的Codex没有打开
只要这三项有一项不对，链路就可能看起来像“已经接了，但就是不好使”。
配置文件一般写到哪里
如果你后面要排查，最值得知道的路径通常就是：
~/.codex/config.toml
路由接管开启后，这里常见会被写成指向本地路由，而不是直接写上游地址。
如果你看到配置里指向的不是本地地址，而是你手动填进去的 DeepSeek 接口，那就要警惕一件事：你可能把本该交给 CC Switch 处理的转换链路，自己绕开了。
常见问题
为什么我已经加了 DeepSeek，Codex 还是报 404
先检查是不是把 DeepSeek 的 Chat 接口直接写进了 Codex，而没有经过 CC Switch 本地路由。
对 Codex 来说，这往往就是问题根源。因为它默认期待的是 Responses API，不是直接吃 Chat Completions。
为什么 /model 里没看到 DeepSeek
先重开一次 Codex。
很多时候供应商本身没问题，只是当前进程没有刷新模型目录。对 Codex 来说，这比 Claude Code 更常见。
本地路由开了，为什么请求还是走错地方
优先对一下这三件事：
- Codex 当前启用的供应商是不是 DeepSeek
- 本地路由服务是不是还在运行
Routing Enabled里的Codex开关是不是打开
这三项要同时成立，链路才是完整的。
