Codex Desktop overwrites user config.toml and removes registered MCP servers

Summary

Codex Desktop can overwrite the user-level config.toml and remove an unrelated
user-registered MCP server. In my case, a CloudMind Streamable HTTP MCP server was
successfully registered and usable, then disappeared from config.toml after later
Codex Desktop configuration activity. The server and credentials remained healthy.

Environment

• OS: Windows
• Codex CLI: 0.146.0
• Codex Desktop: Windows Desktop app using the bundled app-server
• User config: C:\Users\<user>\.codex\config.toml
• MCP transport: Streamable HTTP
• The same CODEX_HOME is used by Codex Desktop and the CLI

Reproduction / observed timeline

1. Start Codex Desktop with an existing user-level config.toml.
2. While Desktop is running, register a user-level MCP server from the CLI:

``powershell
codex mcp add cloudmind --url https://cloudmind.chaosyn.com/mcp --bearer-token-env-var CLOUDMIND_BEARER_TOKEN
``

1. Restart Desktop and open a new task. The server is available and its tools are

callable. A read-only MCP handshake returned protocol 2025-03-26 and 20 tools,
including the expected memory tools.

1. Later, open/trust another project and use normal Desktop project/plugin/settings

flows. The user config is rewritten atomically.

1. The unrelated [mcp_servers.cloudmind] table is gone. A new task no longer

exposes any mcp__cloudmind__* tools, and the CLI reports:

``text
No MCP server named 'cloudmind' found
``

The exact Desktop action that performs the first destructive rewrite is still being
narrowed down, but the loss occurs after Desktop configuration writes and is
repeatable across separate registration/restart cycles.

Actual result

• The entire MCP registration table disappears from the user config.
• The MCP server is absent from codex mcp get cloudmind --json.
• The current task has no CloudMind tool namespace.
• The bearer-token environment variable remains present and the upstream MCP

endpoint continues to respond to an authenticated read-only handshake.

Expected result

Updating project trust, plugin state, marketplace metadata, or another unrelated
Desktop setting should preserve all existing user-level config tables, including
MCP servers that were added by the CLI.

Requested fix

• Make config writes use a current read-modify-write transaction or a serialized

config writer, rather than an older in-memory snapshot.

• Preserve unknown/unrelated TOML tables during Desktop writes.
• Detect config-version conflicts, refetch, and retry the targeted write.
• Add a regression test proving that project/plugin/settings writes preserve a

manually registered user-level MCP server.

• After an external config change, reliably reload MCP configuration for loaded

tasks or clearly require a full Desktop restart.

Related issues

• #24515: Claude settings migration clobbers user-level config.toml
• #24065: Desktop settings writes conflict with plugin/marketplace refreshes
• #10499: Desktop MCP inventory and per-task tool injection can diverge

No credentials or token values are included in this report.