如果你的目标是在 Codex 的 ChatGPT 订阅和 DeepSeek API 之间来回切换，CC Switch 的价值不只是提供一个配置界面，更重要的是替你保存和恢复不同提供方的配置快照。

但这条路径有一个很容易误判的现象：CC Switch 升级以后，界面看起来已经是新版本，DeepSeek 供应商却仍然显示需要本地路由，Codex 也继续按旧的 Chat 协议请求。原因往往不是升级失败，而是旧供应商记录仍然保存着旧配置。需要用新预设重新创建供应商，不能只升级应用本身。

本文按附件中的 CC Switch v3.19.1 实测流程整理。第三方工具的版本和界面会变化，使用前应以当前发布说明和本机实际配置为准。

1. 什么时候适合使用 CC Switch

三种接入方式可以先按工作习惯选择：

只使用 DeepSeek，不需要频繁切换：官方脚本或手动配置更直接。
经常在 ChatGPT 订阅和 DeepSeek 之间切换：CC Switch 更方便。
主要使用桌面端，并需要额外的桌面插件入口：再考虑 Codex++。

CC Switch 管理的是本机配置，不会自动解决模型协议不兼容。DeepSeek 当前 Codex 接入仍然要使用官方支持的模型和 Responses 协议，先确认上游边界，再配置切换工具。

OpenAI 的 Codex 配置参考说明，用户级配置位于 ~/.codex/config.toml，而模型提供方属于机器级配置，不能依赖项目仓库里的本地配置覆盖。可以先阅读 Codex config.toml 官方文档，理解 CC Switch 实际会管理哪些文件。

2. 第一个坑：升级应用不等于升级旧供应商

按照附件中的实测，CC Switch v3.19.1 及更新版本将 DeepSeek 预设从旧的 Chat 格式和本地路由模式，调整为原生 Responses 直连。这里有一个关键区别：

新版本预设：使用新的地址、模型和 Responses 配置。
旧供应商记录：仍可能保留升级前的 Chat 配置和路由标记。

所以“升级了 CC Switch 但仍然需要路由”的第一排查方向，不是继续打开本地代理，而是查看当前供应商是不是旧记录。如果是，使用新 DeepSeek 预设重建供应商。

版本号只是附件测试时的参考。当前界面可能更换名称，预设字段也可能发生变化；不要把 v3.19.1 当成永远有效的最低版本，先在设置或关于页面核对当前发布版本和更新说明。

3. 升级前先保护原配置

CC Switch 需要操作 Codex 的用户级配置和认证文件。开始前先做一份独立备份：

~/.codex/config.toml
~/.codex/auth.json（如果当前环境使用文件认证）
~/.codex/models.json
~/.codex 下的 MCP、profile 和备份目录

不要把备份放进公开 Git 仓库，也不要把 API Key、OAuth 凭据或完整 auth.json 发到聊天工具。备份的作用是恢复本机配置，不是制作一个可以共享的配置包。

同时关闭 Codex 桌面端和 CLI 会话。多个程序同时写同一份 config.toml 时，切换工具刚写入的字段可能被另一个进程覆盖，最终表现为“点了启用但 Codex 没变化”。

4. 用新预设重新创建 DeepSeek 供应商

按照当前 CC Switch 界面中的对应入口执行：

1. 升级 CC Switch，并在“设置 / 关于”中确认版本。
2. 打开应用，切到 Codex 配置页。
3. 点击添加供应商。
4. 选择 DeepSeek 官方预设，不要先选自定义配置。
5. 填入 API Key，保存并启用。
6. 检查卡片是否仍显示“需要路由”。
7. 如果仍显示，删除旧供应商后用新预设重建。
8. 完全退出并重启 Codex，而不是只关闭窗口。

预设的价值是减少手工遗漏：它通常会同时写入 API 地址、模型菜单、Responses 协议和推理参数。自定义配置适合已经明确知道每个字段含义的人；第一次迁移时，先用预设建立一份能运行的基线，再逐项定制。

不要手动把模型改成当前文档没有声明支持 Codex 的其他型号。模型菜单能显示某个名称，不代表这个型号的 Responses、工具调用和模型目录都已经兼容。

5. CC Switch 到底替你保存了什么

Codex 的用户级认证和配置文件本质上是单槽位的。你从 ChatGPT 订阅切到 DeepSeek 时，如果直接覆盖 config.toml 和认证文件，就可能丢失当前登录方式或需要重新登录。

CC Switch 的切换思路通常是：

切出当前供应商：快照配置和认证文件。
写入目标供应商：恢复目标配置和认证文件。
重新启动或刷新 Codex：让客户端读取新的配置快照。

这使“订阅 -> DeepSeek -> 订阅”的切换不必每次重新手工编辑文件。但它也带来一个限制：切换工具保存的是本机敏感配置快照。你在文件中手工改过的字段，可能在下一次切换时被旧快照覆盖。

因此每次切换后都要检查：

当前 model 和 model_provider 是否正确。
base_url 和 Responses 协议是否匹配。
认证方式是否是当前供应商需要的方式。
MCP、profile、信任设置和其他本机配置是否仍在。
是否出现旧路由字段或过期模型元数据。

6. 如果通过兼容网关接入

如果使用 4SAPI 这类聚合入口，CC Switch 的官方 DeepSeek 预设可能不会自动适配这条路径。需要单独核对网关的 Base URL、模型映射、Responses 支持、流式事件、工具调用和错误返回；不要因为卡片能保存配置，就把网关路径当成直连路径。

尤其要注意模型目录。第三方工具可能只对官方 deepseek.com 域名下的地址自动镜像能力声明，换成中转地址后，模型元数据、推理档位和工具格式可能需要人工确认。这里的结论取决于当前 CC Switch 版本和实际代码路径，不能当成所有版本都一样。

7. 切换完成后的验证

验证一：不要只看卡片状态

“已启用”只能说明 CC Switch 写入了目标配置。启动 Codex 后，应进一步查看：

模型显示名称或自定义标签是否符合预期。
Codex 是否不再要求启动本地路由。
请求日志或上游用量记录是否出现真实请求。

桌面端可能将自定义模型统一显示为“自定义”，这不是单独的失败信号。更可靠的证据是上游用量、请求日志和一个安全测试任务。

验证二：先做只读任务

只读取当前项目，列出入口文件、测试命令和最近提交影响的模块。
不要修改、删除、发布或发送任何内容。

先确认模型能读文件、调用只读工具和返回结果，再进入写操作。

验证三：再做可回滚的小任务

在一个测试仓库中，先找到测试命令，再给 README 增加一行说明。
修改前说明计划，完成后运行相关检查，不要改动其他文件。

观察工具调用是否连贯、补丁是否可应用、测试结果是否能回传。不要用“你好”或“你是什么模型”验证 Agent 接入。

8. 常见问题速查

现象	可能原因	处理方式
升级后仍提示需要路由	使用了旧 DeepSeek 供应商	删除旧记录，用新预设重建
配置保存但 Codex 不变	Codex 进程仍打开或读取了另一用户目录	完全退出并确认用户级路径
切回订阅后要求重新登录	认证快照不完整或被手工覆盖	检查备份和当前认证存储方式
404 或流式异常	旧 Chat 协议、模型不支持或地址重复拼接	对照官方模型和 Responses 配置
模型显示“自定义”	客户端统一显示自定义提供方	用请求日志或上游用量确认
改动被切换后覆盖	CC Switch 恢复了旧配置快照	把变更写入正确的供应商配置并重新备份

9. 一份可复制的切换前检查 Prompt

请先不要修改 Codex 配置，帮我检查从当前供应商切换到 DeepSeek 前的风险。

输出以下内容：
1. 当前 Codex 用户级 config.toml、models.json 和认证文件的位置；
2. 当前 model、model_provider、base_url、wire_api 和认证方式；
3. 切换工具可能覆盖的字段，以及需要先备份的文件；
4. DeepSeek 预设是否使用 Responses，是否仍显示需要本地路由；
5. 一个只读验证任务和一个可回滚小修改；
6. 切回原供应商后的检查项；
7. 任何未确认的版本、字段或第三方工具行为。

不要输出完整 API Key，不要删除旧配置，不要直接执行供应商切换。

10. 两种真实切换场景

场景一：订阅切到 DeepSeek

切换前先结束正在运行的高风险任务。一个正在写文件、发送消息或调用外部系统的会话，不应该在配置切换过程中继续执行。

1. 等待或停止当前 Codex 任务。
2. 记录当前会话需要恢复的项目路径和未完成事项。
3. 在 CC Switch 中启用新的 DeepSeek 供应商。
4. 完全退出并重新启动 Codex。
5. 用只读任务验证模型和工具调用。
6. 再开始低风险的可回滚修改。

不要在一个任务中途切换模型。即使会话表面上还能继续，新的模型目录、系统指令和推理档位也可能已经不同，继续执行会让一次任务包含两套不可比较的运行条件。

场景二：DeepSeek 切回订阅

切回时除了验证模型名称，还要检查原来的认证方式和工具配置。尤其是使用 OAuth 或多个 profile 的环境，不能只看 model 字段。

原提供方是否恢复。
原认证方式是否恢复，是否不必要地要求重新登录。
原有 MCP、profile、信任设置和审批策略是否仍在。
Codex 是否读取了当前用户的配置，而不是另一个用户目录。
切回后是否完成了一次只读任务和一次原项目测试。

11. 供应商快照的安全边界

CC Switch 为了实现快速切换，需要保存供应商相关的配置快照。快照里可能包含 API Key、OAuth 凭据、模型目录、Base URL 和其他本机设置。它应该被视为敏感数据，而不是普通的应用配置。

建议建立以下边界：

快照目录只允许当前用户读取。
快照不进入 Git、云盘同步目录和团队共享目录。
导出诊断信息时先过滤 token、cookie、Key 和授权头。
删除供应商前先确认是否还需要恢复其中的认证信息。
轮换 Key 后清理旧快照，避免旧凭据继续留在本机。

如果切换后发现手工修改被覆盖，不要直接继续改同一个文件。先确定哪一份是当前供应商的源配置，修改后重新保存快照，再通过重启验证它是否真的被恢复。

12. 用配置差异定位“为什么没生效”

当 CC Switch 显示已启用、Codex 却没有变化时，把三个时间点的配置拿出来比较：

A：启用前的配置。
B：点击启用后、尚未启动 Codex 的配置。
C：Codex 启动后实际读取的配置或启动日志。

比较以下字段即可，不要把完整凭据放进差异文件：

model、model_provider、base_url、wire_api
model_catalog_json、推理档位和认证方式
MCP、profile、审批和信任相关字段

A 与 B 没有变化，说明切换工具没有写到预期文件；B 有变化、C 又恢复，说明某个启动进程或其他工具覆盖了配置；C 正确但请求仍失败，则继续查上游协议、模型映射和网络。

13. 切换回归清单

测试	订阅状态	DeepSeek 状态	预期
只读项目分析	可用	可用	两种供应商都能完成
小型补丁	可回滚	可回滚	补丁和测试结果可追踪
MCP 只读查询	若环境启用	若环境启用	工具清单和调用结果可见
配置重启	恢复后仍在	恢复后仍在	重启不丢失提供方和认证状态
切回操作	恢复原配置	恢复目标配置	不需要删除整个 .codex

每次只改一个变量。不要在切换供应商的同时升级 Codex、重写 Prompt、替换 MCP 和修改项目权限，否则即使结果变好，也无法知道是哪一项变化造成的。

14. 结论与限制

CC Switch 适合需要在多个 Codex 供应商之间切换的人，但它的核心不是“点一下就兼容所有模型”，而是保存和恢复本机配置。升级应用后，旧供应商仍可能保留旧协议，必须用新预设重建并通过实际请求验证。

第三方切换工具的版本、预设和文件快照行为会变化。使用时要保留备份、保护认证文件、关闭并重启 Codex，最后用只读任务和可回滚修改确认真实路由。出现异常时，先恢复已知可用配置，不要继续叠加新的手工字段。

关于 API 接入的补充说明
本文第 6 节提到的兼容网关路径，是 CC Switch 的官方 DeepSeek 预设之外的一种可选配置方式。如果你已经通过 4SAPI 等中转站统一管理多个模型的 API 调用，并将其作为自定义模型提供方配置到 CC Switch 中，需要单独验证网关的 Base URL、模型映射、Responses 协议支持、流式结束事件、工具调用格式和错误返回。这类网关不参与 CC Switch 的配置切换逻辑本身，是否采用取决于你的 API 管理习惯和成本控制需求，不属于 CC Switch 官方预设的必要环节。官方预设直连 DeepSeek 成功，不代表网关路径同样兼容，建议保留独立请求日志以便区分问题来源。

资料与说明

• DeepSeek：Codex 接入文档：核对 DeepSeek 的模型和 Responses 接入边界。
• OpenAI：Codex config.toml 官方文档：核对用户级配置和模型提供方字段。