Skip to content
CC Switch WikiUnofficial Community Wiki

Switching Codex providers overwrites config.toml

Quick fix

Upgrade cc-switch to v3.17.0+ and sync the MCP and other settings you want to keep into “General Configuration”; if an old snapshot still writes them back…

Symptom

Section titled “Symptom”
Error output
`config.toml` 被重写后，Codex Desktop 相关配置丢失或被还原。
English translation

After `config.toml` is rewritten, Codex Desktop-related settings are lost or reverted.

Cause

Section titled “Cause”

The common issue is that Codex stores MCP, plugin, features, desktop/windows preferences, and model/provider settings in `~/.codex/config.toml`, while cc-switch also rewrites this file when switching providers, taking over local routing after restart, or syncing from the database. Older versions rewrote the entire `config.toml` or provider snapshot (`providers.settings_config`), the `mcp_servers` table, and General Configuration together. As a result, only fields such as model/provider/base_url might remain, or deleted/changed `[mcp_servers.*]`, `[plugins.*]`, `[features]`, `[windows]`, and `[desktop]` sections might be restored. Issues #5149/#5049 involved lost plugins and desktop settings; #4697/#4699/#4856/#956 involved MCP entries revived from an old snapshot or MCP table; and #2844/#4713 involved session history and reconnection or login problems after the provider name or auth/config was rewritten.

The fixes vary by issue. Maintainers confirmed that General Configuration merging was unreliable and that nested table loss was fixed in v3.17.0 with a structured backend merge using `toml_edit`. In v3.17.0, live `[mcp_servers]` entries contaminating snapshots when switching away were also stripped, and already contaminated snapshots can self-heal the next time you switch away. However, maintainers said this only covers the provider-switching path: restarting without switching does not immediately self-heal, and proxy takeover or backup merging may still retain orphaned MCP entries. Issue #6344 still reported in 3.19.2 that the MCP panel toggle imports entries but does not write them. Some settings that appear ineffective are not caused by incorrect cc-switch writes: in #3548, maintainers confirmed `base_url` belongs under `[model_providers.<name>]`, not `openai_base_url`; #2614 showed that Codex reads the context window from the model catalog's `context_window`, not top-level `model_context_window`; and #4970/#4971/#3668 involved the desktop selector failing to render because of the model catalog, `models` array, or `openai_chat` format.

Fix

Section titled “Fix”

  1. Back up `~/.codex/config.toml`, `~/.codex/auth.json`, and `~/.cc-switch/`, then upgrade cc-switch to v3.17.0 or later. Do not stay on 3.12.0/3.12.1, which clear configuration and show a database mismatch warning if you roll back. For session history or provider name issues, upgrade to at least v3.16.2.

  2. Put Codex changes you need to keep in cc-switch’s “General Configuration” or the relevant provider template, rather than editing only the live `config.toml`. This includes `[mcp_servers.*]`, plugin and desktop preferences, and manual entries such as `web_search = "live"` that provider templates may overwrite.

  3. If a deleted MCP entry reappears after saving, delete the matching entry in cc-switch’s “MCP Management” at the upper right and check whether old `[mcp_servers.*]` entries remain in each Codex provider configuration. Deleting only `~/.codex/config.toml` is not enough because the database or snapshots can write the entry back.

  4. If you suspect an old provider snapshot is contaminated, on v3.17.0+ switch to another provider and then switch back to trigger self-healing that strips `[mcp_servers]` when switching away. If you only restarted cc-switch without switching, perform this switch manually.

  5. If Codex Desktop plugins, Computer Use/Browser/Chrome, or `[desktop]`/`[windows]`/`[features]` settings were restored, add those sections to General Configuration before switching. The temporary workaround in #5049 was to import General Configuration manually; Claude already read it automatically, while Codex automation required a later version.

  6. If `/model` or the desktop model dropdown is empty, confirm the provider apiFormat is `openai_responses`. With `openai_chat` and local routing, the catalog was generated but not displayed in Codex Desktop in #4970/#4971. As a temporary workaround, follow #3668 to manually add the `model` field and the provider’s `models` array, and sync `models_cache.json`.

    ~/.codex/config.toml
    [model_providers.deepseek]
    name = "deepseek"
    base_url = "http://127.0.0.1:15721/v1"
    wire_api = "responses"
    requires_openai_auth = true
    models = [
      { model = "deepseek-v4-pro", display_name = "DeepSeek V4 Pro" },
      { model = "deepseek-v4-flash", display_name = "DeepSeek V4 Flash" },
    ]
    model_catalog_json = "cc-switch-model-catalog.json"

  7. If enabling “1M context” still shows 258k, do not rely only on top-level `model_context_window = 1000000`. Following #2614, use a custom catalog to set that model's `context_window` to 1000000; the default `effective_context_window_percent` of 95 will show about 950k.

    ~/.codex/config.toml
    model = "deepseek-v4-pro"
    model_provider = "custom"
    model_catalog_json = "/Users/luca/.codex/custom-models.json"
    model_auto_compact_token_limit = 900000

  8. If the MCP panel toggle still does not write to `~/.codex/config.toml` in 3.19.2 (#6344 is open), the temporary options are to maintain `[mcp_servers]` manually or use a bridging script to merge and write `enabled_codex=1`, while keeping entries not managed by cc-switch. Follow the issue for an official fix.

Affected Versions

Section titled “Affected Versions”
ToolCodex（Desktop App / CLI；少量报告同时涉及 Claude Code）
Version受影响报告横跨 3.12.0–3.19.2；v3.16.0/v3.16.2 修复历史分桶与接管，v3.17.0 修复通用配置合并和切换快照主路径，#6344 在 3.19.2 仍打开
PlatformsWindowsmacOS

Source Issues

Section titled “Source Issues”

This page is distilled from 21 real issues

FAQ

Section titled “FAQ”
Does it matter whether “Write to General Configuration” is checked? What if only base_url remains either way?
In #1440, a maintainer asked about this. The user confirmed that only base_url remained whether the option was checked or not, and that 3.12.0/3.12.1 could not even write General Configuration comments. This was an older-version write/clear issue. Upgrade to a fixed version, confirm General Configuration contains the intended settings, and do not roll back to an old version that reports a database mismatch.
Where can I import settings into General Configuration manually? Is it under skills and MCP management?
The answer in #5049 was to put new plugins and other configuration items into “General Configuration” manually so they enter the cc-switch database and persist across switches and restarts. New plugins on the Claude side were already read into General Configuration automatically; Codex automation was expected to be extended in a later version.
Is base_url written to the wrong place? Doesn’t Codex recognize openai_base_url?
#3548 was closed with no code change: cc-switch writes `base_url` under `[model_providers.<name>]` for Codex, which is the standard field for Codex model_providers. `openai_base_url` is not a field that cc-switch writes.
Why does an MCP entry I deleted reappear after I save or switch providers?
The common cause in #4856/#4697/#4699 is that copies remain outside the live configuration: the `providers.settings_config` snapshot, the `mcp_servers` table, or MCP Management may still contain the old entry. Delete it from MCP Management and the provider configuration in cc-switch, then switch away and back once on v3.17.0+ to self-heal contaminated snapshots.
After switching back to OpenAI Official, why does it stay at “Reconnecting...” or ask me to log in again? Did preserveCodexOfficialAuthOnSwitch not help?
#4713 reported that even with `preserveCodexOfficialAuthOnSwitch = true`, `config.toml` or `auth.json` could still be rewritten. The temporary options were to log in again or edit the configuration manually, but the issue could recur on the next switch. The issue is stale, and this path is still not fully resolved.
Why is the desktop model selector still empty when the catalog file was generated and the proxy forwards requests normally?
#4970/#4971 found that with `openai_chat` and local routing, the catalog was generated but Codex Desktop did not render it; only `openai_responses` worked. #3668 also listed three separate issues: a catalog entry missing the `model` field, a missing `models` array in `[model_providers]`, and an out-of-sync `models_cache.json`.
Section titled “Related problems”
Provider API Key Overwritten: After Codex Restart or SwitchUpgrade to cc-switch v4.0.0 or later to prevent provider keys from overwriting each other and restore the official login state.6 issues mergedInvalid schema for function — CodexUpgrade CC Switch to a version including the v3.18.0 fix for `parameters.type:null`; track the original issues for other `null` schema variants.13 issues mergedCodex desktop cannot see modelsSign in to official ChatGPT, enable “Keep official login when switching to third parties,” and enable local routing. Restart Codex.6 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.