CCSwitch 改了配置但 Codex 仍用旧模型怎么办？
很多人改完 CCSwitch 的 API 地址、Key 或默认模型后，发现 Codex 仍然像在调用旧配置。这个问题通常不是模型接口失效，而是保存位置、默认项、环境变量或客户端缓存没有统一。按顺序排查，比反复新增配置更可靠。
适用场景：配置变了，实际调用没变
你可能遇到这些表现：CCSwitch 界面里已经改成新模型，但 Codex 输出日志仍显示旧模型；换了 API Key 后仍然报旧 Key 的权限错误；删除一个配置后，某个终端窗口还能继续调用；在一个项目里正常，换到另一个项目又回到旧地址。遇到这些现象时，先不要继续堆配置，而是确认实际生效链路。
如果你还没有完成首次配置，先看 注册后如何配置 CCSwitch。本文讨论的是已经跑通过 AI API 接入，但修改配置后 Codex 接入仍不跟随变化的情况。
排查路线：从界面保存到进程重启
1. 确认你改的是当前默认项
CCSwitch 里可能同时存在多个模型、多个供应商或多个项目配置。先看当前默认项、当前激活项和 Codex 实际使用项是否一致。不要只看列表里是否有新模型，要确认“默认”“启用”“当前选中”三个状态。多人协作时，还要确认你没有改到个人配置，而 Codex 读取的是团队配置。
2. 检查环境变量是否覆盖了界面配置
部分工具会优先读取环境变量。运行下面的命令，看是否存在旧地址或旧模型名：
Get-ChildItem Env: | Where-Object { $_.Name -match 'OPENAI|AI|CODEX|MODEL|BASE' } | Sort-Object Name
$env:OPENAI_BASE_URL
$env:OPENAI_API_KEY
$env:MODEL如果环境变量里还有旧值，Codex 可能绕过 CCSwitch 的新设置。临时测试可以在新 PowerShell 中清理相关变量后再启动；长期处理则要去用户环境变量、系统环境变量、IDE 启动配置和项目脚本里统一修改。
3. 重启客户端和终端，而不是只刷新页面
配置文件保存后，已经运行的 Codex 进程可能仍持有旧配置。关闭 Codex、关闭终端、重新打开 CCSwitch，再启动 Codex 做一次最小测试。测试提示词只问模型名、当前时间或短句，不要一上来跑长任务。这样更容易从日志里看出到底调用了哪个模型。
常见问题：为什么我每次改完都像没生效
第一种原因是配置保存到了另一个目录。新电脑、便携版、管理员权限和普通用户权限可能让配置文件分散。第二种原因是 IDE 内置终端继承旧环境。第三种原因是多个工具都能设置模型，最后以启动顺序或环境变量优先级为准。第四种原因是你只改了模型显示名，没有改真实 model id。
可以按 CCSwitch 多模型配置自检 的方式建立一张配置表，把 API 地址、Key 来源、模型 ID、默认项和用途写清楚。需要确认状态码时，再结合 AI 模型接口报错排查清单 看 401、404、429 或超时对应的问题。
操作步骤：做一次可复现的生效验证
- 在 CCSwitch 里只保留一个测试默认项，记录模型 ID 和 API 地址。
- 关闭所有 Codex 进程、IDE 终端和旧 PowerShell。
- 新开 PowerShell，检查相关环境变量没有旧值。
- 启动 Codex，只运行一个短提示词，并查看日志中的模型名和请求地址。
- 再切换一次模型，重复启动和日志检查，确认变化能被复现。
如果你在多个项目之间切换，建议把项目级说明放进仓库文档，避免每次都靠记忆。Codex 可以帮你检查配置文件和启动脚本，但涉及 Key 的内容要注意脱敏。
检查清单和验收标准
- CCSwitch 当前默认项、Codex 日志模型名、实际 API 地址三者一致。
- PowerShell、IDE 终端、后台服务没有旧环境变量覆盖。
- 模型显示名和真实 model id 都经过核对。
- 改动后关闭旧进程并重启，结果仍然稳定复现。
- 配置表中记录用途、负责人、修改日期和回滚方式。
永沃云枢建议把这类问题当成模型调用管理问题，而不是单纯的软件界面问题。需要重新梳理完整接入路径时，可以回到 CCSwitch 下载配置与模型切换教程 和 Codex 接入从注册到 CCSwitch 逐项复核。
团队协作时的配置交接方式
如果一个团队多人使用 CCSwitch，配置交接最好不要只发截图。截图能说明界面状态，却不能说明优先级、环境变量和启动方式。更稳的做法是准备一份脱敏清单：配置名称、用途、真实模型 ID、是否默认、适用项目、最后修改人、需要重启哪些客户端。Key 本身不写入文档，只写来源和权限边界。
交接后让接手人独立做一次短请求验证，并把日志里的模型名和配置表核对。只有接手人能复现，才算配置真的交接完成。这个动作看似麻烦，但能减少后续“我这里正常、你那里不正常”的来回沟通。
每次切换后都保留一次短请求截图或日志片段，后续出现争议时，可以直接对照实际生效模型和配置表，而不是只看界面记忆。