›_ Codex Issues
Codex Issues / #27655

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
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26304
  • #27313
  • #26530
  • #27287
  • #27178

Powered by Codex Action

guohao117 · 2 months ago

I don't think this is a duplicate of the MCP/Chrome sandbox issues listed above.

We found that adding --disable-sandbox to the MCP args can work around the Computer Use and Chrome failures themselves. The bug being reported here is different: in the Codex Windows app, the MCP args/config setting is not persisted correctly.

Specifically, after setting the args in the UI, the UI can still show the expected value, but after restarting the app config.toml gets reset/overwritten and no longer matches the UI state. That means the workaround cannot be saved reliably across app restarts.

So the issue is about the Windows app settings persistence/sync behavior for MCP args, not about whether --disable-sandbox fixes the underlying Chrome/Computer Use launch problem.

<img width="1422" height="498" alt="Image" src="https://github.com/user-attachments/assets/38d71ad6-35d8-4686-8466-499e31ba326c" />

<img width="986" height="162" alt="Image" src="https://github.com/user-attachments/assets/928020e3-228d-474d-b702-883ce57dc608" />

guohao117 · 2 months ago

Additional observation from further testing on Windows:

Codex Desktop appears to reprovision the bundled cua_node runtime during app startup using a staging / replacement flow. I observed runtime directories being removed and temporary .stage... directories being created near:

C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\

This also explains why runtime-level workarounds do not persist. For example, replacing the bundled:

...\bin\node_repl.exe

with a shim that calls the original binary with --disable-sandbox is reverted on the next Codex Desktop startup. The backup file created next to it, such as:

...\bin\node_repl.real.exe

also disappears because the runtime directory is replaced.

The same reset / non-application behavior is reproducible for custom MCP settings:

  • custom args for Node_repl are reset or not passed to the spawned process
  • custom env entries such as DISABLE_SANDBOX=true are reset or do not appear under [mcp_servers.node_repl.env] after restart
  • custom command values, such as pointing Node_repl to a wrapper script, are also reset back to the bundled runtime command

So the issue seems broader than only args not being persisted in config.toml: on Windows startup, Codex Desktop appears to regenerate both the bundled runtime and the generated MCP config from defaults. As a result, user changes to command, args, and custom env for Node_repl are discarded or not applied to the spawned MCP process, even when the Settings UI still shows them.

guohao117 · 2 months ago

I’m going to close this issue and replace it with a clearer report.

The original wording here focused too much on --disable-sandbox / args being reset. After reading the MCP config behavior more carefully, the more precise issue is that bundled/plugin MCP servers are managed/generated definitions, but the Settings UI still presents command, args, and env as if they were effective persistent user overrides.

I’ll open a new issue focused on that UI / effective-config mismatch, and link back here so the history remains discoverable.