Codex Desktop startup rewrites config.toml and removes user-defined MCP servers on Windows

Open 💬 3 comments Opened May 27, 2026 by qizhao0123
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.11010.0 (logs during earlier occurrence also show client_version 26.519.81530)

What subscription do you have?

Not relevant to this local config persistence bug

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop overwrites %USERPROFILE%\.codex\config.toml during startup / bundled runtime or plugin initialization and removes a manually configured custom MCP server. As a result, an integration that was previously usable disappears after launching the desktop app and must be restored manually.

The secret environment variable remains configured; only the TOML MCP registration block is lost. The rewritten file retains desktop-generated entries such as [mcp_servers.node_repl] and bundled runtime/plugin settings while the existing [mcp_servers.<custom_http_server>] block is absent.

This is a blocking data-loss issue for users relying on custom MCP servers.

What steps can reproduce the bug?

  1. Configure an HTTP MCP server in %USERPROFILE%\.codex\config.toml using an environment-backed bearer token (server name and URL omitted here):
[mcp_servers.<custom_http_server>]
url = "<redacted>"
bearer_token_env_var = "<redacted_env_var_name>"
  1. Verify that the custom MCP block is present and works.
  2. Quit and relaunch Codex Desktop, allowing its startup runtime/plugin initialization to complete.
  3. Re-read config.toml. The custom MCP block has been removed, while desktop-managed node_repl / primary-runtime plugin entries remain.

Observed locally on 2026-05-27 (Asia/Shanghai, UTC+08:00):

  • The custom MCP block was present before the desktop rewrite.
  • The local structured log records app-server config/batchWrite requests at 09:06:58, 09:07:26, 09:08:56, 13:46:47, and 13:47:09.
  • At 13:58:07, config.toml was recreated again during this investigation without any manual or agent write; it still contained mcp_servers.node_repl and still omitted the custom MCP block.

No credentials, server URLs, or token values are included in this report.

What is the expected behavior?

Codex Desktop should preserve all user-defined [mcp_servers.*] sections when persisting desktop-managed runtime or plugin settings. Startup initialization must not remove unrelated custom configuration.

Additional information

Related to #24387, which identifies the desktop startup config/batchWrite path rewriting features.js_repl and mcp_servers.node_repl. This report covers a separate and more destructive impact of that path: removal of an unrelated user-defined MCP server.

Environment details:

  • Windows: Microsoft Windows NT 10.0.26200.0 x64
  • Codex Desktop installed package: 26.519.11010.0
  • Earlier overwrite logs on the same day report desktop client_version: 26.519.81530
  • Codex CLI/runtime version file: 0.133.0

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24387

Powered by Codex Action

Zhanghuaimin-233 · 20 days ago

I can reproduce this on a current Windows Codex Desktop build, and the affected block is now the Desktop/Computer Use node_repl MCP registration itself rather than a separate custom MCP server.

Environment

  • Codex Desktop Microsoft Store package: 26.803.5235.0
  • Desktop client version recorded in the app-server log: 26.803.41515
  • Windows x64
  • CUA/node_repl runtime present locally: runtime package 0.0.6 (20260723162306-088049353ddc)

Controlled reproduction

  1. Fully start Codex Desktop.
  2. Manually add a valid [mcp_servers.node_repl] registration to %USERPROFILE%\.codex\config.toml.
  3. Create a new task and initialize Computer Use.
  4. The runtime initializes successfully and can enumerate the current Windows applications/windows (Codex, File Explorer, VS Code, Edge, etc.). No click, input, or application launch was performed.
  5. Fully quit Codex Desktop.
  6. Fully quit cc-switch as well, to exclude it as a writer.
  7. Start Codex Desktop again.
  8. Re-read config.toml: the manually added mcp_servers.node_repl block has disappeared.

The same deletion reproduced with cc-switch completely exited, so it does not appear to be caused by cc-switch.

Write-path evidence

During the controlled restart on 2026-08-07, the Desktop/app-server log recorded a config/batchWrite request at approximately 19:45:03 local time. The config file was recreated at the same time with the node_repl block absent.

There was no corresponding node_repl configuration parse error or MCP startup error before the rewrite. The exact same registration works when inserted after Desktop has completed startup, which rules out an invalid executable or invalid TOML block as the immediate cause.

This looks like the Desktop startup configuration snapshot/round-trip omits mcp_servers.node_repl and then persists the incomplete snapshot through config/batchWrite.

This may also represent a regression or incomplete fix related to #26190, which was closed as completed: the current build still rewrites/removes node_repl configuration and breaks Computer Use persistence across restarts.

Expected behavior: Desktop startup/plugin synchronization should preserve a valid existing mcp_servers.node_repl registration, or regenerate an equivalent valid registration before writing the user config. It must not silently delete the only working Computer Use runtime registration.

DTALEX66 · 13 days ago

Additional manifestation of this Windows rewrite (reproduced 2026-08-14):

The rewrite also writes CRLF line endings and strips # comment prefixes from config.toml. On a machine where ~/.codex/config.toml carries a comment-marked managed block (e.g. # BEGIN <tool> MANAGED OVERLAY ... # END ...), a Codex Desktop re-login / startup rewrite changes the block to CRLF and removes the # prefix. Any tooling that hashes the managed block for drift detection then fails closed:

  • LF block hash c2e56fdf... (recorded state) vs CRLF block hash 50d589cb... → mismatch → BLOCK
  • The comment prefix # BEGIN ... becomes BEGIN ... → marker not found → BLOCK

Same root cause as this issue (Desktop rewrites config.toml on startup on Windows), but a third distinct symptom beyond removed MCP servers (#24718) and rewritten autonomy settings (#32763). Workaround on our side: normalize line endings before hashing and re-render the managed block, but the Desktop-side rewrite remains the underlying bug.