Skip to content
CC Switch WikiUnofficial Community Wiki

Provider card and config.toml out of sync Codex

Quick fix

Most related issues remain unresolved. Upgrade CC Switch from affected 3.20.4 and retry switching; if it persists, retain logs and configuration evidence.

Symptom

Section titled “Symptom”
Error output
the provider row/card can contain the new snapshot while `~/.codex/config.toml` still contains the previous snapshot.

Cause

Section titled “Cause”

In CC Switch 3.20.4, the update path for the current Codex Provider may save card data before writing the live `config.toml`. If the live write fails, the saved card may not roll back, so the Provider card, live Codex configuration, and current Provider marker may differ.

Later review stated that the main branch write engine includes rollback and pending recovery operations. After a partial publish, it recovers forward on the next startup or use rather than simply restoring the old snapshot. Some Windows 4.0.x observations that switching did not take effect were later confirmed to involve direct/routing modes and UI formatting limits, so they are not a confirmed reproduction of the same transaction desynchronization.

Fix

Section titled “Fix”

  1. Confirm that you are using CC Switch 3.20.4. If so, upgrade to the current version and retest Provider editing or switching.

  2. If the card and `config.toml` still differ after upgrading, record the Provider marker before and after the action, `live-state.json`, `~/.codex/config.toml`, `auth.json`, and complete CC Switch logs, then submit a new reproduction report.

  3. Check whether a Provider that supports routing only was selected in direct mode. This shows a routing-required prompt and does not by itself indicate that the save transaction failed.

Affected Versions

Section titled “Affected Versions”
ToolCodex
Version3.20.4 (affected)
PlatformsmacOS

Source Issues

Section titled “Source Issues”

This page is distilled from 1 real issues

FAQ

Section titled “FAQ”
What evidence is needed if it still reproduces after upgrading?
Provide about 50 complete lines of `cc-switch.log` before and after the action, `live-state.json` from both times, and state whether the Codex aggregate proxy/takeover switch is enabled and whether Codex Desktop is running at the same time.
Why does switching not occur after clicking a third-party Provider?
If the Provider's `apiFormat` is `openai_chat`, clicking it in direct mode shows a routing-required prompt. After routing starts, the current Provider in routing mode and direct mode are different concepts.
Does an unchanged `config.toml` in routing mode mean desynchronization?
Not necessarily. In routing mode, Codex configuration can continue pointing to the local proxy `127.0.0.1:15721`; switching primarily changes proxy routing. Check both the current mode and `proxy_route`.
Section titled “Related problems”
cc-switch Usage Statistics Differ from DeepSeek Official Site / Stop UpdatingUpgrade to v3.19.2 or later, then run “Rebuild Codex Usage” once on the “Usage Statistics” page to correct historical overcounts or missing records.22 issues mergedsettings.json configuration lost after switching providers (cc-switch)Extract shared fields into “Common Configuration” and enable writing them for each provider; v3.12.2 fixes the proxy-related BUG.29 issues mergedThe proxy takeover claude switch cannot be ticked in Claude Desktop modeIn claude-desktop mode, the takeover section hard-codes the Claude Code (claude) switch instead of the Claude Desktop one, so clicking does nothing.2 issues merged

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.