Skip to content
CC Switch WikiUnofficial Community Wiki

Manually edited MCP configuration files are overwritten by cc-switch

Quick fix

Edit MCP settings in cc-switch and upgrade to v3.13.0+; use “Common Configuration” to share settings.json plugins/hooks across providers.

Symptom

Section titled “Symptom”
Error output
每次重新打开 cc-switch 或执行任何 MCP 操作时，我的修改都会被覆盖，配置恢复到 cc-switch 数据库中的旧版本。
English translation

Whenever I reopen cc-switch or perform any MCP operation, my changes are overwritten and the configuration reverts to the old version stored in the cc-switch database.

Cause

Section titled “Cause”

MCP synchronization in cc-switch is one-way (DB → live): import_from_*() runs only once when the database MCP table is empty (on first launch). After that, sync_all_enabled(), upsert_server(), and toggle_app() directly rewrite entire live files such as ~/.claude.json, ~/.codex/config.toml, and ~/.gemini/settings.json using the old database state, without first reading changes made outside cc-switch. Issue #2170 proposed adding backfill_from_live() for MCP, modeled on Prompts Backfill Protection (available since v3.7.0), but the issue was closed as stale after 60 days of inactivity and the mechanism was not implemented. #685 was also identified as the same design issue as #902. Therefore, there is currently no official protection against overwriting manually edited live files.

The same “full rewrite” mechanism has two variants. First, before v3.13.0, MCP had no per-app enable flags. Synchronizing MCP only for Claude Code could also leak it into configurations for OpenCode, Codex, and other applications. visibleApps.opencode=false controls only UI visibility; at startup, if the OpenCode configuration directory exists, it can still be imported and written back into ~/.codex/config.toml. This leakage was fixed in v3.13.0 with the enabled_claude/enabled_codex/enabled_gemini/enabled_opencode flags. Second, when switching providers, cc-switch writes the provider's entire settings_config back to ~/.claude/settings.json without reading and merging the current file. This silently clears enabledPlugins, hooks, enabledMcpjsonServers, and disabledMcpjsonServers managed by Claude Code. The maintainer marked #4322 as a duplicate of #3631. In #1594, the maintainer explained that full rewriting was retained as a design tradeoff after a merge approach was attempted in v3.11.0, and recommended using “Common Configuration” for shared settings such as plugins.

Fix

Section titled “Fix”

  1. Upgrade cc-switch to v3.13.0 or later. This version introduces separate enabled_claude / enabled_codex / enabled_gemini / enabled_opencode flags for each MCP server. Only servers with enabled_*=true are exported to each application's live file, fixing MCP leakage into unselected applications.

  2. Do not manually edit the MCP sections in ~/.claude.json, ~/.codex/config.toml, or ~/.gemini/settings.json. Add or modify them only in the cc-switch MCP management panel so the database and live files remain consistent and your changes are not overwritten by the old DB state on the next launch or provider switch.

  3. If enabledPlugins / hooks disappear from ~/.claude/settings.json after switching providers: edit the provider in cc-switch → open the “Common Configuration” panel → select “Extract from Current Provider,” and place shared settings such as plugins and hooks in the common configuration. When creating a provider, select “Write Common Configuration” so these fields persist across providers. The default provider created during your first import retains the complete original configuration.

  4. If MCP is still written to disabled applications after upgrading to v3.13.0+, or the full overwrite of settings.json still needs investigation, add your current version and reproduction steps to the original issues (#1486 / #3631 / #2170) and request that they be reopened. The merge/preservation fix for settings.json was tracked in #3631, but its final fixed version is not included in this corpus.

Affected Versions

Section titled “Affected Versions”
Toolcc-switch
Version3.9.1 - 3.16.1（受影响范围；其中 MCP 跨应用泄漏已在 v3.13.0 修复，settings.json 全量覆盖在 v3.16.1 仍可复现）
PlatformsWindowsmacOSLinux

Source Issues

Section titled “Source Issues”

This page is distilled from 5 real issues

FAQ

Section titled “FAQ”
I disabled OpenCode in the MCP panel—and even disabled OpenCode in visibleApps—so why is MCP still written to the OpenCode / Codex configuration?
This is a bug from before v3.13.0: visibleApps.opencode=false controls only UI visibility, while should_sync_opencode_mcp() checks only whether the OpenCode configuration directory exists during startup. MCP exports were also not filtered by application at that time. After upgrading to v3.13.0, only MCP entries with enabled_*=true are written to the corresponding application's live file.
Why did my plugin configuration disappear after switching providers?
Claude Code stores enabledPlugins in ~/.claude/settings.json, and cc-switch fully rewrites that file on every switch. The maintainer explained that this design was retained as a tradeoff after a merge approach was attempted in v3.11.0. Use “Common Configuration”: edit the provider → open the Common Configuration panel → select “Extract from Current Provider,” then select “Write Common Configuration” when creating a provider. By comparison, ~/.claude.json written by claude mcp add is not overwritten when switching.
Can cc-switch detect external configuration-file changes instead of overwriting them?
Issue #2170 proposed adding backfill_from_live() to MCP, modeled on Prompts Backfill Protection, so live content would be read back into the DB before synchronization. The issue was closed as stale after 60 days of inactivity, and according to this corpus the mechanism has not been implemented. The current workaround is to edit MCP only in the cc-switch panel.
Claude keeps editing ~/.claude.json, but it is overwritten every time. How can I make configuration debugging less difficult?
There is no official solution until a backfill mechanism is implemented. As a workaround, after making an external change, immediately open the cc-switch MCP panel and apply the same change to the database so it is not overwritten by the old state on the next launch or provider switch.
Does Skill configuration have the same leakage or overwrite issue?
The reporter of #1486 mentioned seeing a similar issue involving skill and suspected the same cause: application selection was not tied to the scope of background synchronization. This corpus does not include details of that issue, so this cannot be confirmed. Search the repository for related skill issues to verify.
Section titled “Related problems”
[DISCUSS] Support for pi coding agentThis is a feature request merged into tracking issue #1855; the original post provides no verifiable solution.1 issues mergedThe model cannot discover any tools - CodexUpgrade cc-switch past 3.16.1 and edit cc-switch-model-catalog.json to set supports_search_tool to false for the DeepSeek models.3 issues mergedcc-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 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.