我的 Codex CLI 在 Windows 上用起来最大的问题不是不会装而是装好之后不知道把请求往哪里发。后来在 CC Switch 里把 DeepSeek API 接进去顺便解决了切换模型和保存 API Key 的麻烦。这篇文章不是为了复述官方 README而是把我实际在 Windows 11 上把 Codex CLI、CC Switch 和 DeepSeek API 串联起来并且稳定跑了半个月的配置过程、踩坑经历和排查方法整理出来。如果你也想在 Windows 终端里用 Codex CLI 驱动 DeepSeek这篇文章应该能帮你省掉至少一个晚上的 debug 时间。1. 把三样东西串起来之前先搞懂它们的分工1.1 Codex CLI 的模型来源并不只有官方Codex CLI 是 OpenAI 开源的终端编程助手很多人默认它只能连 OpenAI 官方模型其实并不对。它从设计上就留了自定义模型提供方的入口你可以通过model_providers字段注册任意兼容接口然后指定model和model_provider让它把请求发到第三方服务上。官方文档管这个叫 bring your own model本质上就是允许你在~/.codex/config.toml里配置一个 base URL、一个鉴权方式、一个请求协议然后按你自己的模型名去跑。这个机制给国内用户最直接的用途就是把 Codex CLI 接到 DeepSeek API 上。DeepSeek 的接口和 OpenAI 高度兼容只需要注意协议差异后面我会重点讲。就算你没有 CC Switch手动改config.toml也能接上但问题是日常使用中你不可能只用一个模型。今天想用 DeepSeek 写代码明天想切回官方账号每次手动改文件、改环境变量不仅容易出错还会把官方登录状态搞乱。这才是我觉得 CC Switch 有价值的原因它把“切换供应商”这件事做成了界面上的一个按钮或一次点击。1.2 CC Switch 到底管了什么CC Switch 是一个第三方配置切换工具最早很多人在 Claude Code 场景下用它切换不同的服务商后面也支持了 Codex CLI。它在 Windows 上主要有两种工作方式。第一种是直接改写配置文件也就是替你编辑~/.codex/config.toml把当前选中的模型提供方写进去。这种方式简单直观缺点是你每切一次配置文件就变一次如果中途又手工改过配置容易互相覆盖。第二种是“本地网关”模式也就是你在错误日志里常看到的那句 local proxy。CC Switch 会在本机启动一个监听端口的服务比如127.0.0.1:15739然后固定把这个地址写成 Codex CLI 的 base URL。Codex CLI 发出的所有请求先到本地网关再由网关按照你当前选中的供应商配置转发到 DeepSeek 或其它目标。我推荐理解第二种方式因为你在 windows 上遇到的所谓 unexpected status 401、404、502、503绝大多数都是在本地网关这一环出的问题。比如 CC Switch 进程没起来、端口被占用、网关拿到的 API Key 是空的或者网关把请求转发到了不对的路径。理解了本地网关的位置排查范围一下就缩小了。另外网关模式下切换模型不需要反复改 Codex 的配置文件Codex 一直在和本地网关说话网关再去背后调不同的上游。1.3 DeepSeek API 的兼容层与两个必须记牢的端点差异DeepSeek API 提供的是 OpenAI 兼容接口这一点意味着很大的便利你不需要给 Codex CLI 装额外的 SDK只要把 base URL 指过去再用一个 Bearer Token 做鉴权它就能认出请求结构。但兼容不等于 100% 相同最大的差异在端点上。OpenAI 官方的 Codex CLI 默认走的是 Responses API也就是请求会发到/responses。而 DeepSeek 公开的兼容接口走的是 Chat Completions也就是/chat/completions。这两个端点虽然都能实现多轮对话但请求体格式存在差异。如果没有在 Codex 配置里指定wire_api它默认会按 Responses 协议去发DeepSeek 那边自然返回 404 或者直接让本地网关报 local proxy failed。所以在配置里的关键动作就是把wire_api设为chat并确保 base URL 拼接出来的最终路径能正确打到 DeepSeek 的/chat/completions上。这一点记住之后后面所有报错都会好理解很多。DeepSeek 平台目前主推的模型名是deepseek-chat和deepseek-reasoner前者适合日常代码生成后者适合复杂推理。两者都走同一个兼容端点只是模型名不同。2. Windows 端的安装与准备2.1 安装 Node.js 与 Codex CLICodex CLI 官方以 npm 包分发Windows 上第一步是先装 Node.js。我建议装 LTS 版本不要追最新因为一些 npm 原生模块的预编译二进制在最新版 Node 上可能还没跟上。安装时选默认设置记得确认Add to PATH被打勾。装完后打开新的 PowerShell执行node -v和npm -v能正常输出版本号就说明环境没问题。然后全局安装 Codex CLI命令很简单npm install -g openai/codex装完后执行codex --version。如果提示找不到命令先执行npm config get prefix返回的目录就是 npm 全局可执行文件的安装目录。一般 Windows 下是C:\Users\你的用户名\AppData\Roaming\npm你需要把它加到当前用户的环境变量 PATH 里。这步绕过去就会出现搜索热词里那个unable to locate the codex cli binary or required runtime components。这不是 Codex 本身坏了通常是系统没有找到codex.exe的位置。加完 PATH 后重新开一个终端窗口再试。如果你所在网络环境拉 npm 包很慢可以先把 npm 源切到国内镜像npm config set registry https://registry.npmmirror.com这只是让下载更快不影响后续 Codex CLI 登录或请求路径因为这个镜像只干预 npm 包下载和 Codex 运行时请求无关。2.2 装 CC Switch安装版还是便携版CC Switch 在 Windows 上有安装版和便携版两种。安装版会写入系统级的配置可能在启动时弹 UAC适合希望开机自启的人。便携版是解压后直接运行.exe不写注册表升级时直接替换文件夹适合像我这种喜欢保留一份绿色工具的人。第一次尝试建议用便携版因为遇到问题要回退版本直接删文件夹就行不会留残余。我自己的习惯是放到D:\Tools\CCSwitch不让它躺在系统盘里。运行后会有一个主界面左侧列出支持的应用比如 Codex、Claude Code 等。第一次打开时 Windows Defender 有概率弹出风险提示。原因很简单这类工具要读写用户目录下的配置文件运行行为容易被安全软件误判。只要你是从 GitHub Releases 官方渠道下载的校验过大小时就可以放心用。实在不放心可以单独做一次杀毒扫描或者加白名单不建议跑到不知名下载站找所谓“绿色版”。2.3 准备 DeepSeek API Key 并用 curl 验证上游在 DeepSeek 开放平台创建 API Key复制以sk-开头的那串字符串。第一次使用 DeepSeek 的 API 一般需要先在账户里充值因为 API 调用是按 token 计费的。虽然代码生成量不大时费用很低但余额为零的时候调用会直接失败这也是一会儿排查报错时要先确认的项。拿到 Key 后最好先绕过 Codex CLI 和 CC Switch直接验证 DeepSeek 上游是否正常。在 PowerShell 里执行curl.exe -X POST https://api.deepseek.com/chat/completions -H Content-Type: application/json -H Authorization: Bearer sk-你的APIKey -d {\model\:\deepseek-chat\,\messages\:[{\role\:\user\,\content\:\hi\}],\max_tokens\:20}注意这里要用curl.exe而不是 PowerShell 里默认的curl别名否则参数解析方式不一样。如果上游正常会返回一段 JSON里面有choices、usage这些字段。万一这里就报 401说明 Key 本身有问题或者账户状态异常赶紧先去控制台核对不要继续折腾后面的配置。这一步非常重要它能帮你把问题牢牢锁定在“上游”还是“本地配置”后面排查 401 时可以节省非常多时间。3. 配置阶段让 Codex CLI 的请求真正抵达 DeepSeek3.1 在 CC Switch 里添加 DeepSeek 并开启本地网关打开 CC Switch 主界面找到 Codex 应用相关的设置项进入供应商或模型管理。新建一个供应商配置名称可以叫 DeepSeekBase URL 填https://api.deepseek.comAPI Key 填刚才复制的密钥。有些版本里还需要你填一个默认模型名这里填deepseek-chat就好。接下来是重点把当前 Codex 使用的供应商切到 DeepSeek并开启本地网关模式。不同版本的 CC Switch 按钮位置不太一样有的叫“开启本地代理”有的叫“使用 Local Proxy”但核心表现是一致的CC Switch 会告诉你一个本地监听地址通常是127.0.0.1:15739。开启后CC Switch 会在后台启动一个 HTTP 服务Codex 的请求会先到这个地址。这里有必要提醒一下 Windows 防火墙。第一次网关启动时防火墙通常弹窗问要不要允许node.exe或 CC Switch 进程对外监听。如果你点了取消后面本地网关端口处于半死不活的状态请求就会失败。保险起见可以先去防火墙里把 TCP 入站规则中对应端口或程序放行。这一步做完再继续下面的配置文件修正。3.2 config.toml 手工修正model_provider、base_url、wire_api 的含义虽然 CC Switch 会尝试自动改写 Codex 配置但为了排查稳定我建议手动打开%USERPROFILE%\.codex\config.toml检查一遍。没有这个文件的话可以先创建一个注意.codex这个目录默认是隐藏的在资源管理器地址栏直接输入路径最省事。一个能跑通的配置长这样model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url http://127.0.0.1:15739/v1 env_key DEEPSEEK_API_KEY wire_api chat逐行解释一下。model就是当前会话使用的模型名deepseek-chat已经够用如果要用深度推理可以临时改成deepseek-reasoner。model_provider必须和下方[model_providers.deepseek]里的键名一致Codex 就是通过这个关联关系知道该去哪找配置。base_url这一项最容易被误解。如果你不通过 CC Switch可以直接写https://api.deepseek.com/v1但如果你已经在 CC Switch 里开了本地网关就应该写http://127.0.0.1:15739/v1。注意是/v1不是裸域名因为 Codex CLI 会根据wire_api在 base URL 后面拼接路径。当wire_api chat时最终请求会是http://127.0.0.1:15739/v1/chat/completions。DeepSeek 官方地址兼容这个路径格式。env_key是告诉 Codex读取环境变量DEEPSEEK_API_KEY作为鉴权凭证。这样 API Key 不会直接明文写在配置文件里减少误操作提交到公开仓库的风险。wire_api chat是整条链路上最关键的字段它把协议切到 Chat Completions避开 OpenAI Responses API 的不兼容问题。设置环境变量的方法在 PowerShell 里执行setx DEEPSEEK_API_KEY sk-你的APIKeysetx写入的是用户级环境变量之后新开的终端窗口自动生效。已经打开的 PowerShell 窗口不会自动刷新要重新打开一个。3.3 端到端验证与常见检查命令配置完之后先不要急着跑 Codex验证本地网关是否正常。最直接的办法是请求网关的模型列表看看 CC Switch 有没有把 DeepSeek 的模型暴露出来curl.exe http://127.0.0.1:15739/v1/models如果网关正常会返回一个包含deepseek-chat的 JSON 列表。如果这里就连接失败先回到第 2 章检查防火墙和端口监听。如果这里返回列表但 Codex 依然报错再往后走。然后运行一次最简单的 Codex 指令codex exec 用 Python 写一个快速排序第一次调用会读取配置和环境变量然后向网关发请求。能正常返回结果说明整条链路已经通了。如果没有就进入下面的排查章节。4. 高频报错排查从 401 到 502每一条都对应一个真实坑4.1 本地网关没起来端口占用与二进制找不到很多人看到cc switch local proxy failed while handling codex endpoint /responses就直接以为是 Codex 或 CC Switch 的 bug。实际上这个报错的前半段已经告诉我们消息到本地网关这一步了但网关注入失败或转发失败。所以先确认网关到底有没有在监听。检查端口netstat -ano | findstr 15739如果有输出说明有进程监听记录下 PID然后用tasklist | findstr 你的PID看看是不是 CC Switch 或它调用的 node 进程。如果没有输出多半是 CC Switch 的本地网关没有成功启动。重新启动 CC Switch切换到 DeepSeek 供应商一次再执行netstat看端口有没有起来。端口被占用的情况我也遇到过。之前电脑上有一个别的工具占用了15739CC Switch 起不来。解决方法是进入 CC Switch 设置里改一个端口比如改成15740然后同步修改config.toml里base_url的端口号。很多人只改了 CC Switch 的设置忘了改 Codex 配置结果 Codex 还在往旧端口发请求报错依然存在。如果你遇到的是unable to locate the codex cli binary or required runtime components那和网关无关是 Codex CLI 自身安装不完整或不在 PATH。重新执行一次npm install -g openai/codex然后确认npm config get prefix目录在环境变量里。两个问题别混在一起看能减少不少弯路。4.2 401 鉴权失败密钥注入链路unexpected status 401 unauthorized看起来是鉴权失败但你得先分清楚这 401 是从哪里返回的。我见过两种情况。第一种上游 DeepSeek 返回 401。这种最好定位直接用第 2.3 节的 curl 命令测上游如果也返回 401就是 Key 不对、账户欠费或者平台侧的权限异常。去控制台重新创建 Key确认账户有余额再测试。第二种本地网关返回 401。这种情况直接 curl 上游可能正常但 CC Switch 网关转发时没有正确注入鉴权头。检查 CC Switch 里的 DeepSeek 配置看 API Key 字段是否真的保存了有些版本在切换供应商时会丢失 Key 内容。还要检查config.toml里的env_key是否和你 PowerShell 里设置的环境变量名字完全一致大小写也要一致。Codex CLI 读取环境变量的逻辑很严格变量名写错一个字母都会导致空凭证。之前我遇到一个很隐蔽的问题我先用setx设置了DEEPSEEK_API_KEY但环境变量里还残留了一个空的同名变量优先级把正确值覆盖了。排查时清掉系统里的旧变量重新打开终端才正常。建议在 PowerShell 里执行echo $env:DEEPSEEK_API_KEY确认当前终端的变量值是否包含sk-前缀。4.3 404 与 /responses 端点不兼容wire_api 才是关键搜索热词里频繁出现cc switch local proxy failed while handling codex endpoint /responses这基本就是 wire_api 设置不对。默认情况下 Codex CLI 倾向于使用/responses端点而 DeepSeek 并没有提供这个端点于是本地网关把请求转给 DeepSeek 时上游返回 404网关再把 404 包成自己的错误。解决方式就是打开config.toml确认已经写入wire_api chat改完之后重启 Codex CLI而不是只关掉对话框。因为 Codex 进程一旦启动配置可能已经被进程加载到内存旧请求还是会打到/responses。我建议改完配置后把终端窗口也一并关闭重开确保干净。另一种 404 是模型名写错。比如在model里填了gpt-4o一类 OpenAI 模型名DeepSeek 平台不认这个模型也会返回 404。一定要用 DeepSeek 平台实际的模型名如deepseek-chat或deepseek-reasoner。这个字段在 CC Switch 里配置时也要保持一致因为本地网关会按模型名做路由。4.4 502/503 网关报错与对话闪跳的处理502 Bad Gateway和503 Service Unavailable都是网关层面的错误。502 通常表示本地网关已经收到了 Codex 的请求但向上游 DeepSeek 请求时失败比如上游连接超时、返回了不可解析的内容或者 DeepSeek 接口临时抖动。503 则更像是上游明确拒绝服务通常是限流或服务过载。碰到这两类问题我建议先做个快速拆解直接 curl DeepSeek 的/chat/completions看上游本身是否可用。如果上游也异常那就不是你的配置问题等平台恢复即可。如果上游正常但通过网关就 502试着在 CC Switch 里关闭网关再重新开启有时候是网关内部的长连接缓存坏了重启能解决。“切换模型后原对话不停跳闪”这个现象我在 Windows 上遇到过很让人烦躁。原因是 Codex CLI 的会话上下文还保留着旧模型的请求记录而 CC Switch 切换供应商后旧会话里的消息可能仍在尝试访问旧的 endpoint导致 Codex 不断重试、状态反复刷新。遇到这种情况不要继续在旧会话里挣扎直接退出 Codex删除对应的会话记录再开一个全新会话。Codex 的会话文件一般在%USERPROFILE%\.codex\sessions目录下按时间戳存放。删除前先确认没有重要内容或者把整个 sessions 目录复制一份备份再操作。5. 长期使用经验备份、更新、切换官方账号的注意事项5.1 CC Switch 与官方账号其实不冲突但配置会互相覆盖很多人在用 CC Switch 接第三方 API 时会担心会不会和官方登录账号冲突我自己的体验是它们不直接冲突但配置文件确实会被互相覆盖。Codex CLI 的官方账号登录信息存在auth.json用于和 OpenAI 的服务鉴权而 CC Switch 主要改的是config.toml也就是模型提供方的配置。正常情况下两者各管各的。但当你切换回 OpenAI 官方模型时CC Switch 会改model_provider和model字段而 Codex 官方登录需要auth.json里有可用的 token。如果你从未登录过官方账号即使 CC Switch 切到 OpenAI 名称Codex 依然会提示需要登录让你误以为冲突了。我的建议是在动 CC Switch 之前先把config.toml和整个.codex目录备份一次。每次切换到新的供应商配置后如果发现 Codex 行为异常直接对照备份恢复而不是在界面上反复猜测。CC Switch 作为一个频繁读写配置的工具出现覆盖乱序的概率虽然不高但备份一下心里踏实。5.2 Codex CLI 更新与 CC Switch 配置刷新Codex CLI 更新频率不算低。Windows 下更新很简单npm update -g openai/codex更新之后建议先跑一次codex --version确认版本号变了。如果更新后之前能用的 DeepSeek 配置突然报错优先检查~/.codex/config.toml是否被安装脚本重置。npm 全局包的安装脚本一般不会动用户配置文件但保险起见还是要看一眼。CC Switch 这边如果你用的是便携版更新时直接替换整个程序目录配置文件如果存在程序目录下替换前先拷贝出来。如果存在系统用户目录下通常不受影响。更新后模型配置列表有时候不刷新可以退出 CC Switch 重新打开或者点击界面里的刷新按钮。Windows 上偶尔会有“界面已经切换了模型但config.toml没有同步”的情况这时候你手动保存一次 provider 配置再切换到别的 provider 再切回来基本就能触发重写。5.3 换模型后清掉旧会话别让状态残留最后一个我特别想强调的经验是在 Windows 上长期使用 Codex CLI 接 DeepSeek一定要养成换模型后开新会话的习惯。Codex CLI 的会话状态是基于历史消息和当前模型配置的如果你在同一个终端里切了模型旧历史里的消息工具调用和 token 统计可能和新模型对不上轻则重复请求重则界面闪跳。我现在的工作模式是日常代码任务用deepseek-chat需要深度分析复杂逻辑时写一个简短指令用codex exec直接执行一次拿到结果再回到主会话。每次切换模型前先退出当前会话进程再从 CC Switch 切换供应商最后重新进入 Codex。这套流程虽然多两个动作但换来的是稳定不抽风值得。API Key 也不要长期直接暴露在环境变量里尤其当你的终端会记录历史命令时强烈建议把 Key 只填在 CC Switch 里由它统一管理。实在需要环境变量给变量权限设置好只限定当前用户。总之工具链越简单越好CC Switch 和 Codex CLI 的组合现在已经成了我在 Windows 上接 DeepSeek 的标准姿势希望这份记录能让你一次跑通。