Codex provider writeback resets live UI settings from config.toml - cc-switch
Quick fix
Upgrade to cc-switch v4.0 or later. Provider switching updates only key fields and preserves the rest of ~/.codex/config.toml.
Symptom
Section titled “Symptom”provider routing 本身切换成功,但不属于 provider 的 Codex live settings 会被旧的 provider snapshot 覆盖。典型会丢的内容包括:personality、[desktop] 里的主题、accent color 等桌面偏好、[mcp_servers] 这类 context entriesProvider routing switches successfully, but Codex live settings that are not part of the provider are overwritten by an older provider snapshot. Commonly lost settings include: personality, desktop preferences such as the theme and accent color in [desktop], and context entries such as [mcp_servers].
In v3.x, cc-switch treated the provider snapshot first imported or last saved in its database as the single source of truth (SSOT). When switching or enabling a provider, write_codex_live_config_atomic / write_live_with_common_config replaced the entire ~/.codex/config.toml file through an atomic rename (Full Replacement). The live file was only a projection of the snapshot. As a result, fields absent from the provider snapshot—including personality later changed in the Codex UI, [desktop] (such as mac-menu-bar-enabled = false), [mcp_servers], [hooks.state] trusted_hash, [projects.*], and [permissions.*]—were erased on writeback. When switching to an empty official template, config.toml could even be reset to a zero-byte empty file. Common Config could mitigate this, but it was opt-in per provider (meta.commonConfigEnabled); third-party and built-in official providers often had it disabled, causing application-level settings such as [desktop] to be lost in either direction. Also, the “Extract from edited content” button in the common configuration dialog (useCodexCommonConfig.ts’s handleExtract) immediately persisted via setCommonConfigSnippet and unconditionally triggered sync_current_provider_for_app. Simply clicking “Extract” could silently overwrite the live file on disk. Another variant of the same root cause was manual edits being reset: one user changed wire_api to "chat", but it was rebuilt as "responses". The maintainers said that v3.x overwriting manual changes through SSOT was intended behavior; the MiMo case was resolved by reworking the preset in v3.16.4.
Upgrade to cc-switch v4.0 or later. Version 4.0 rewrote configuration writes: switching providers, toggling routes, or restarting CC Switch now replaces only the key fields—address, Key, model, and protocol—and preserves everything else, including plugins, themes, [projects], MCP, and comments. It no longer replaces the whole configuration file using an old snapshot or backup. The “Extract from edited content” button was removed; saving a common configuration snippet now writes only to the database and no longer overwrites ~/.codex/config.toml.
If configuration was lost after upgrading, retrieve the original configuration from the default provider card imported when cc-switch was first launched. Then manually merge erased fields from an old local backup, if available, such as an earlier copy of ~/.codex/config.toml. Examples include [desktop] mac-menu-bar-enabled = false and [hooks.state].
If you cannot upgrade yet and are still on v3.x, put settings that must persist across providers in the “Shared configuration snippet” (Edit provider → Shared Configuration panel → Extract from current provider), and confirm that commonConfigEnabled is enabled for every provider. This may not preserve [hooks.state] or fields added in later Codex upgrades. Avoid clicking “Extract from edited content” in the common configuration dialog; in 3.20.0, that button silently overwrites the live file.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 7 real issues
- #3695Codex provider 写回会重置 live UI settings from config.toml
- #3700Codex provider 写回会重置 live UI settings from config.toml
- #4332mimo模型适配问题,peizhi
- #5770Codex config.toml is fully overwritten when switching providers, causing hooks.state trust data to be lost
- #6400bug(codex): provider switch drops [desktop] mac-menu-bar-enabled = false
- #6875[Bug] 切换/启用 Codex Provider 时全量覆盖 config.toml 与 auth.json,导致外部新增配置与 Token 丢失且无物理文件备份
- #6879[Bug] Codex/Claude/Gemini 在通用配置弹窗中点击「从编辑内容提取」会直接持久化并静默覆写本地 live 配置文件
- After switching providers, Codex repeatedly asks me to trust hooks again because trusted_hash is missing. What should I do?
- In v3.x, rebuilding config.toml erased Codex’s own [hooks.state]. Upgrade to v4.0: switching then replaces only key fields, preserving [hooks.state] and preventing repeated trust prompts.
- I manually changed config.toml (for example, wire_api = "chat"). Why was it reset?
- In v3.x, cc-switch rebuilt config.toml from its single data source, overwriting manual changes by design. Adjust the relevant fields through the provider settings in the app. For the MiMo case, starting in v3.16.4 the preset uses the /responses endpoint natively, so wire_api = "responses" is the expected and supported configuration. Starting in v4.0, manual changes to non-key fields are no longer overwritten.
- Is the “Extract from edited content” button safe? Why did clicking it change my configuration?
- In version 3.20.0 and earlier, clicking this button immediately persisted via setCommonConfigSnippet and triggered sync_current_provider_for_app, silently overwriting the entire ~/.codex/config.toml file. It was not just a frontend preview. The button was removed in v4.0; saving a snippet now writes only to the database and no longer touches the live file on disk.
- The Codex desktop “Show in menu bar” setting (mac-menu-bar-enabled = false) turns back on after switching providers. How can I prevent this?
- The provider snapshot overwrote the [desktop] table. Shared configuration snippets were opt-in per provider, and third-party and official providers often had them disabled, causing settings to be lost in either direction. Upgrade to v4.0: switching changes only key fields and preserves application-level settings such as [desktop].
Related problems
Section titled “Related problems”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.