Windows app: MCP settings UI shows Node_repl args that are not written to config.toml after restart

Resolved 💬 4 comments Opened Jun 11, 2026 by guohao117 Closed Jun 15, 2026

Summary

On Codex Desktop for Windows, the MCP settings UI for Node_repl can show an argument as configured, but the generated MCP config does not match the UI state after restart.

In this case, the UI shows this argument for Node_repl:

--disable-sandbox

But after restarting Codex Desktop, the generated config is reset to:

[mcp_servers.node_repl]
args = []

The UI still displays --disable-sandbox as configured, so the settings UI and the generated config.toml disagree.

This is primarily a Windows app settings persistence / UI sync bug. It is not primarily a report about the underlying Chrome or Computer Use sandbox failure.

Why this matters

For some Windows users, node_repl fails when launched through the default sandbox runner:

node_repl kernel exited unexpectedly
windows sandbox failed: runner error: CreateProcessAsUserW failed: 5

Adding --disable-sandbox to the Node_repl MCP args can work around that failure and allows node_repl-backed workflows such as the Chrome plugin to run.

However, because the settings UI value is not reliably written into the generated MCP config, this workaround cannot be persisted across app restarts.

Environment

  • OS: Windows
  • Codex Desktop versions observed in local logs/config: 26.608.12217 / 26.608.1337
  • Node runtime path pattern:
C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258\bin\node_repl.exe
  • Windows sandbox config:
[windows]
sandbox = "elevated"

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Open MCP settings for Node_repl.
  3. Add this argument in the settings UI:
--disable-sandbox
  1. Save/update the MCP config.
  2. Restart Codex Desktop.
  3. Observe that the settings UI still shows --disable-sandbox for Node_repl.
  4. Inspect the generated config:
C:\Users\<user>\.codex\config.toml
  1. Inspect the launched node_repl.exe command line.

Expected behavior

The generated config should match the settings UI:

[mcp_servers.node_repl]
args = ["--disable-sandbox"]

The launched process should include the configured argument:

node_repl.exe --disable-sandbox

Actual behavior

The settings UI still shows --disable-sandbox, but the generated config is reset to:

[mcp_servers.node_repl]
args = []

The launched process command line is only:

node_repl.exe

In one observed flow, saving/updating the UI once did not update config.toml; saving/updating again cleared the args in the generated config.

Workaround note

For users hitting the Windows Chrome / node_repl sandbox launch failure, --disable-sandbox appears to be a useful workaround for the Chrome plugin path when it is actually passed to node_repl.exe.

The bug here is that Codex Desktop's Windows MCP settings UI can show the workaround as configured while the generated config and launched MCP process do not receive it.

Additional diagnostic notes

Directly running the bundled Node runtime outside the failing MCP path works:

node.exe --version
v24.14.0

node_repl.exe --help also works and documents the relevant option:

--disable-sandbox  Start the Node kernel directly even when CODEX_CLI_PATH is set

This suggests the runtime itself is present and executable; the key issue in this report is the mismatch between MCP settings UI state and generated config.toml / process args.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗