先说个真实的场景你高高兴兴把 DeepSeek 接进 Codex跑了半天发现效果不错然后某一天想切回 OpenAI 官方模型结果codex启动之后模型列表里只剩 DeepSeek或者直接给你抛一个unexpected status 401 unauthorized再看一眼配置发现model_provider不知道什么时候被改掉了。这时候绝大多数人的第一反应是重装 Codex其实不用问题基本都出在 CC Switch 对本地配置的接管方式上。这篇文章我按自己排障的完整思路来写从原理、体检、恢复到各种报错怎么查一套流程走完保证你能把官方模型找回来顺便把这个工具的用法彻底搞明白。1. 官方模型消失的真正原因CC Switch 的代理机制与 Codex 的模型发现逻辑很多人以为 CC Switch 是给 Codex 装了一个新模型其实不是。它的工作方式更像是一个本地代理和配置文件改写器你选中某个 Provider 之后它会去修改 Codex 的配置文件把请求的出口指向本地代理再由本地代理把请求转发给真正的服务商。问题就出在这一步——它改的是配置不是 Codex 的模型库一旦配置被覆盖成 DeepSeek 的 Provider官方模型自然就不在视线里了。1.1 CC Switch 到底改了你的什么文件Codex CLI 在 macOS 上的配置集中在两个文件~/.codex/config.toml主配置里面定义了模型、Provider、API 地址等。~/.codex/auth.json认证信息存放登录 token。CC Switch 切换 Provider 时核心动作是改写config.toml里的model_provider字段把它的值从openai改成类似deepseek这样的自定义 Provider 名称同时会往[model_providers.deepseek]段里写入base_url和env_key。听起来没什么问题但风险在于它写入的不只是新增一段有时会直接改写默认选择。等你再手动改回model_provider openai时如果对应的[model_providers.openai]段已经被删掉、或者配置残留了base_url指向本地代理Codex 启动时仍然会把你的请求送到 CC Switch 的本地端口而 CC Switch 当前激活的 Provider 如果还是 DeepSeek那结果就是你嘴上说要用官方模型实际请求还是进了 DeepSeek表现自然就是官方模型不见了。1.2 Codex 是如何决定用哪个模型的Codex 启动时会做这几件事读config.toml拿到model_provider的值。根据这个值去找[model_providers.xxx]段取出base_url和env_key。向base_url发起鉴权和模型列表请求拿到可用的模型列表。从[[models]]定义里匹配你指定的model如果匹配不到就报类似model: gpt-6-astra; cause: 配置错误的错误。所以最核心的一点是只要model_provider被指向了非官方地址Codex 眼中的世界就完全变了它会认为世界上只有 DeepSeek 或者当前代理才能提供的模型OpenAI 官方模型自然不在列表里。这个机制很像电视机的输入源切换屏幕还是那块屏幕但信号源变了频道列表就全变了。CC Switch 做的就是把 HDMI 输入从官方信号切换到了第三方信号而你的遥控器模型列表显示的当然是第三方频道的节目。2. 动手恢复前先给当前配置做一次体检我不建议你上来就直接删配置或者重装 Codex那样容易把还能救的登录态弄丢。正确顺序是先搞清楚当前配置坏在哪再决定用哪种方式恢复。2.1 配置文件在哪、怎么快速定位问题打开终端按顺序执行这几条命令# 查看当前主配置 cat ~/.codex/config.toml # 查看认证状态 ls -l ~/.codex/auth.json cat ~/.codex/auth.json | head -c 200第一眼要确认几个关键位置model_provider当前值是什么。是不是存在[model_providers.deepseek]或类似的自定义 Provider 段。[model_providers.openai]段还在不在base_url有没有被改成localhost或127.0.0.1之类的本地地址。[[models]]列表里是否还能看到gpt-6-astra这样的官方模型条目。我看过不少翻车案例最常见的是这三种状态配置文件状态现象大致根因model_provider被改为deepseekCodex 界面只显示 DeepSeek 系列模型CC Switch 切换 Provider 时直接改写默认值model_provider还是openai但base_url指向本地端口启动后请求走本地代理报 401 或 404手动改过 Provider但 base_url 残留[model_providers.openai]整个段不存在报缺少 base_url 配置手动编辑时误删了官方配置块2.2 一个判断原则先看官方配置还剩多少恢复默认配置这个说法很容易让人误解为把 CC Switch 删干净就行其实不对。CC Switch 只是一个外部工具真正决定 Codex 怎么工作的还是config.toml。只要这个文件里的官方 Provider 配置完整哪怕没有 CC Switch你也可以正常使用官方模型。所以我在体检时会做一个简单评估config.toml里的官方配置还剩多少如果[model_providers.openai]还在只是model_provider被改了那恢复成本很低。如果这个段被删了那就需要手动补全或者干脆让 Codex 重建默认配置。如果auth.json里的 token 已经失效那就必须重新codex login这一步逃不掉。先去~/.codex目录看一眼有没有自动备份很多版本在更新配置时会生成.bak或.old后缀的同名文件如果有恢复起来最省事。3. 恢复默认配置的完整操作从备份还原到重建验证体检做完下面直接上恢复流程。我按有没有备份分两种路线第三种情况是给你验证是否恢复成功的方法三条一起看。3.1 路线 A有备份直接还原如果你之前在切换前备份过config.toml或者 CC Switch 在修改配置时留下了备份文件那恢复是最简单的# 先备份当前被改乱的配置留个后路 cp ~/.codex/config.toml ~/.codex/config.toml.hand-fix.bak # 用备份文件覆盖回去改成你自己的实际备份文件名 cp ~/.codex/config.toml.bak ~/.codex/config.toml然后确认一下备份里的关键字段grep -n model_provider ~/.codex/config.toml grep -n base_url ~/.codex/config.tomlmodel_provider应该等于openai[model_providers.openai]段的base_url要么不存在、要么指向https://api.openai.com/v1。如果这两处都不对说明备份本身也不是干净的请直接看路线 B。3.2 路线 B没有备份让 Codex 重建默认配置没有备份也不用慌。Codex CLI 的默认配置完全可以重新生成你只需要把被污染的配置文件暂时移走然后触发一次重新登录# 把现有配置移走不要直接删方便后面找回自定义内容 mv ~/.codex/config.toml ~/.codex/config.toml.cc-switch-corrupted # 重新登录这步会重新生成默认配置和刷新 token codex login执行完登录后Codex 会在~/.codex下生成一份全新的config.toml和auth.json。这时候你直接运行codex官方模型就应该回来了。如果codex login因为认证问题卡住也可以先手动清掉旧认证codex logout rm -f ~/.codex/auth.json codex login登录成功后再把你之前需要的自定义配置比如模型温度、model选择一行一行加回去千万别整段复制旧的 provider 配置不然又把错误带回来了。3.3 验证是否恢复成功的三个检查点配置恢复完不是看一眼就觉得行了建议按下面三个步骤验证# 1. 查看可用的模型列表应该能看到官方模型 codex models # 2. 跑一次最简对话确认请求真正到达 OpenAI codex exec say hi, just a connectivity test # 3. 再检查一遍配置里的关键字段 grep -E model_provider|base_url ~/.codex/config.toml如果codex models能看到gpt-6-astra之类的官方条目、codex exec能正常返回内容、base_url不是本地地址基本就恢复成功了。这时候再打开 CC Switch你会发现它依然在但没有真正接管你的 Codex——这是正常状态说明你把控制权拿回来了。4. 从 401 到 503逐个拆解恢复过程中的异常报错恢复过程中最常见的卡点其实不是配置本身而是一堆让人摸不着头脑的 HTTP 状态码。我把热词里反复出现的几个报错整理一下按看到这个错先往哪个方向查的逻辑来讲。4.1 401 Unauthorizedtoken 问题还是代理转发问题这个报错出现频率极高表现形式通常是unexpected status 401 unauthorized: cc switch local proxy failed while handling第一反应别去怪 CC Switch先判断请求到底发给了谁。你可以临时改一下base_url指向官方地址再跑一次请求如果正常说明问题出在 CC Switch 的代理层也就是代理转发时没有携带有效凭证如果不正常那说明你的auth.json已经过期需要重新codex login。还有一个很容易忽略的点当你通过 CC Switch 接入 DeepSeek 时凭证用的是 DeepSeek API Key而不是 OpenAI token。如果你切回官方模型时 CC Switch 还挂在激活状态本地代理会把 OpenAI 官方请求也转发到 DeepSeek 的鉴权逻辑里自然就 401 了。恢复时记得在 CC Switch 里把 Provider 切到 OpenAI 官方或者退出 CC Switch 的本地代理进程。4.2 404、502、503本地代理状态和转发目标不匹配这三个状态码放在一起看因为它们多半是一家人unexpected status 404 not found: cc switch local proxy failed while handling unexpected status 502 bad gateway: cc switch local proxy failed while handling unexpected status 503 service unavailable: cc switch local proxy failed while handling404本地代理活着但把请求转发给了一个不认这个接口的服务。比如 DeepSeek 某些接口不支持/responses这个 endpoint代理解析不了就回 404。502本地代理活着但它背后要转发的上游服务连不上通常是 API Key 配错或网络不通。503本地代理本身没起来或者 Caddy 服务没监听端口请求直接无处可去。排查顺序建议是先看 CC Switch 的本地代理进程是否在跑再看它的日志输出最后确认你当前选中的 Provider 和 Codex 的base_url是否一致。# 查看本地代理进程是否存在 ps aux | grep -i cc-switch # 查看监听端口找到 CC Switch 的代理端口 lsof -iTCP -sTCP:LISTEN | grep -iE cc-switch|caddy如果你确认配置已经恢复成官方默认但 CC Switch 的本地进程还占着端口直接把它退掉Codex 就会直连官方 API不再经过代理。4.3 配置语义错误缺少 base_url 和工具调用相关报错有时候不是 HTTP 状态码的问题而是配置语义不对最常见的是配置错误: codex provider 缺少 base_url 配置这句话的意思是model_provider指定的那个 Provider 名字在config.toml里找不到对应的[model_providers.xxx]段或者找到了但里面没有base_url。说白了就是model_provider deepseek但[model_providers.deepseek]段被你删了或者名字拼写不一致。修复方式很简单要么删掉model_provider这一行让 Codex 用默认值要么把对应的 Provider 段补齐。二选一不要两个都做一半。还有一个和 DeepSeek 模型本身强相关的报错deepseek messages tool calls need immediate results这个不是配置问题是 DeepSeek 推理模型不支持 Codex 所需的某些工具调用模式。Codex 在运行时会要求某些工具调用立即返回结果而 DeepSeek 推理模型做不到就会报这个错。解决方法是换用 DeepSeek 的对话模型而不是推理模型或者避免在任务中触发工具调用。换句话说有些模型能力边界是天生的不是配置能扭转的。5. 以后想长期混用 DeepSeek 和官方模型正确配置姿势在这走到这一步你已经把官方模型找回来了。但我知道很多人其实是想要两个都要用日常用 DeepSeek 省成本需要高难度代码生成时切回官方模型。这个需求很合理关键是别再让配置乱掉。5.1 推荐的 config.toml 结构官方和第三方分开维护正确的思路是官方 Provider 配置完全保留DeepSeek 作为独立追加的 Provider而不是替代。下面是一个经过了验证的参考结构# 主选择需要官方模型时保持 openai model_provider openai # 官方 Provider 保持默认不写 base_url或者显式写官方地址 [model_providers.openai] name openai # DeepSeek 作为独立的第三个 Provider 追加不影响 openai [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY切换时只需要改model_provider的值不需要删任何 Provider。CC Switch 如果动配置你也知道它动的是哪一行自己手动改回来就能恢复。5.2 日常使用 CC Switch 的几个建议我用 CC Switch 也踩过不少次坑最后总结了几条习惯现在分享出来切换 Provider 前先备份config.toml。一条命令的事别偷懒。CC Switch 本身不会帮你备份真出问题只能靠自己。不要手动删[model_providers.openai]段。无论你多想给 DeepSeek 腾位置都不要删。官方 Provider 和第三方 Provider 完全可以共存。CC Switch 有更新时先看更新日志再升级。部分旧版本的配置改写逻辑有 bug会在切换时把其他 Provider 的base_url一并改掉这种问题升级版本后基本就没了。DeepSeek 接入时优先用 Chat Completions 兼容接口。Codex 对/responses接口的支持和 DeepSeek 的实现存在差异如果因为接口不兼容导致反复报错不要试图绕过换一个模型或者换一种接入方式更省时间。注意模型服务商的使用规范。DeepSeek 这类模型有自己的内容安全策略不要尝试通过特殊方式突破模型限制或破解安全机制这不仅违反平台规则也可能导致 API 被限制得不偿失。我个人现在的用法是config.toml里把openai和deepseek两个 Provider 都写清楚CC Switch 只负责管理和切换 API Key不再让它碰核心配置。切模型时就改一行model_provider切完顺手codex models验证一下整套流程十分钟之内能跑完再也没有出现过官方模型失踪这种事了。如果你现在正好卡在某个报错上按第 4 节的顺序从 401 逐步排查到配置语义错误基本都能定位到根因。实在还没解决的话把config.toml恢复到默认再重新登录是永远有效的保底方案——这次别忘了先备份。