升级后仍能复现时，需要提供哪些证据？

提供操作前后约 50 行完整 `cc-switch.log`、两个时间点的 `live-state.json`，并说明 Codex 的聚合代理/接管开关及 Codex Desktop 是否同时运行。

为什么点击第三方 Provider 后没有切换？

如果该 Provider 的 `apiFormat` 是 `openai_chat`，在直连模式点击时会出现“需要路由”提示；选择开始路由后，路由模式与直连模式的当前 Provider 是不同概念。

不一定。路由模式下 Codex 配置可持续指向本地代理 `127.0.0.1:15721`，切换主要改变代理路由；应同时检查当前模式和 `proxy_route`。

Quick fix

多数相关 issue 仍未解决；将 CC Switch 从受影响的 3.20.4 升级到当前版本后重试切换；若仍复现，请保留日志和配置证据重新报告。

报错原文

the provider row/card can contain the new snapshot while `~/.codex/config.toml` still contains the previous snapshot.

在 CC Switch 3.20.4 中，当前 Codex Provider 的更新路径可能先保存卡片数据，再写入实时 `config.toml`。若实时写入失败，已保存的卡片不一定回滚，因此 Provider 卡片、Codex 实时配置和当前 Provider 标记可能不一致。

后续核查称主分支的写入引擎已加入回滚和待恢复操作；其语义是部分发布后在下次启动或使用时前滚恢复，而不是简单恢复旧快照。该 issue 中 Windows 4.0.x 的部分“切换未生效”观察后来被确认与直连/路由模式和 UI 的格式限制有关，不能作为同一事务失步的确定复现。

确认当前使用的是 CC Switch 3.20.4；如是，升级到当前版本后重新测试 Provider 编辑或切换。
若升级后仍出现卡片与 `config.toml` 不一致，记录操作前后的 Provider 标记、`live-state.json`、`~/.codex/config.toml`、`auth.json` 及完整 CC Switch 日志，并提交新的复现报告。
检查是否在直连模式中选择了仅支持路由的 Provider；该场景会显示需要路由的提示，不能据此判断为保存事务失败。

ToolCodex

Version3.20.4 (affected)

PlatformsmacOS

本页汇总自 1 个真实 issue

升级后仍能复现时，需要提供哪些证据？: 提供操作前后约 50 行完整 `cc-switch.log`、两个时间点的 `live-state.json`，并说明 Codex 的聚合代理/接管开关及 Codex Desktop 是否同时运行。
为什么点击第三方 Provider 后没有切换？: 如果该 Provider 的 `apiFormat` 是 `openai_chat`，在直连模式点击时会出现“需要路由”提示；选择开始路由后，路由模式与直连模式的当前 Provider 是不同概念。
路由模式下 `config.toml` 不变是否代表失步？: 不一定。路由模式下 Codex 配置可持续指向本地代理 `127.0.0.1:15721`，切换主要改变代理路由；应同时检查当前模式和 `proxy_route`。