CC Switch 修改不生效，最常见原因不是“它没有保存”，而是用户查看的文件、正在运行的客户端和 CC Switch 写入的 live config 不是同一份。不要先删除配置；先找出当前真正生效的配置来源。
先分清三类配置
- CC Switch 自身数据：Provider、同步、备份与管理记录。
- 目标工具 live config：Claude Code、Codex 等实际启动时读取的配置。
- 项目级配置：某个仓库专用的 MCP、环境变量或说明文件，优先级可能高于用户级配置。
CC Switch 的目标是写入或回填目标工具的 live config，但不同工具、不同系统和不同版本的实际路径可能变化。因此不要照抄网络上某个固定目录；优先在 CC Switch 当前选中的工具页查看它正在管理的对象，并用目标 CLI 的设置输出或日志交叉验证。
修改后仍不生效的排查顺序
- 在 CC Switch 确认当前 Provider、MCP 或 Skill 已保存，且切换的是正确工作区。
- 完全退出目标 CLI 和所有相关终端，再重新启动。许多 CLI 不会热加载 Provider 配置。
- 检查项目目录是否有覆盖用户级设置的配置文件或环境变量。
- 查看 MCP 服务本身日志，确认不是“配置已加载但服务启动失败”。
- 若开了云同步，确认另一台设备没有把旧版本回写。
不要直接手改再让同步覆盖
排障时可以备份后对比配置，但避免同时在 CC Switch、文本编辑器和同步盘里改同一份内容。更稳的做法是：暂停同步，导出或备份当前配置，做一次最小改动，重启并验证后再恢复同步。
API key、MCP 命令和本地路径都可能是敏感信息，发截图或日志前应先遮盖。关于 CC Switch 的 Provider、云同步与备份能力，可回看 CC Switch 使用教程。如果问题是 MCP 调用返回错误，则按 MCP 工具调用失败排查继续定位。
总结
CC Switch 修改不生效时，依次确认“写到哪里、谁在覆盖、进程是否重启、服务是否启动”。先做最小验证，比全量重装或删除配置更安全。
先做配置来源清单
排错前把所有可能影响结果的来源列出来：CC Switch 当前配置、目标客户端用户级配置、项目目录配置、终端环境变量、系统环境变量和云同步副本。不要假设“最后编辑的文件就是最后生效的文件”；很多 CLI 会在启动时读取环境变量，而项目配置又可能覆盖用户级值。
可以记录如下信息，避免排错过程中丢失上下文：
| 项目 | 记录内容 |
|---|---|
| 当前客户端 | 名称、版本、启动方式 |
| 当前工作区 | 仓库根目录、是否受信任 |
| Provider | Base URL、模型别名，不记录完整密钥 |
| MCP | server 名称、命令、启动日志位置 |
| 同步 | 是否开启、最后同步的设备 |
Provider 没切换时怎么查
先用目标客户端的请求日志或服务端日志确认它实际访问的 endpoint。若 endpoint 还是旧地址，问题在配置写入、覆盖或进程未重启；若 endpoint 已是新地址但返回失败，则继续检查新 Provider 的 key、模型名与服务状态。把这两类问题分开，能避免在错误层面反复修改。
还要注意多个终端窗口：已经运行的 shell 可能保留旧环境变量，即使 CC Switch 已更新系统配置也不会自动刷新。关闭旧终端、重新打开一个干净窗口，并使用最小请求测试。
MCP 修改不生效时怎么查
MCP 有“客户端是否读取配置”和“server 能否启动”两道门。先确认工具列表中能否看到该 server；看不到说明配置未被读取或格式无效。看得到但调用失败，则查看 server 的启动命令、工作目录、依赖、端口和 stderr 日志。
路径含空格、引号嵌套、Node/Python 解释器不是同一个环境，都是 Windows 上常见的失败原因。不要把一长串 shell 命令直接塞进配置；先在同一终端独立运行，成功后再交给 MCP。
如何安全恢复
如果配置已经混乱，先导出或复制当前可读版本，再暂停云同步。然后删除“你确认由 CC Switch 管理的测试项”，不动无关工具配置；建立一个新 Provider 或一个简单 MCP server，验证写入、重启和调用的完整链路。只有基线正常，才逐步导入旧内容。
FAQ：能不能直接删除所有配置目录？
不建议。这样会丢失密钥引用、MCP 设置、会话和无法重建的项目偏好。先备份、确定配置归属，再做范围最小的恢复。
FAQ：为什么不同电脑切换结果不一样？
优先检查同步版本、客户端版本和系统环境变量。同步只保证文件复制，不保证两台设备都有相同的本地模型、路径、可执行程序和权限。