›_ Codex Issues
Codex Issues / #28320

Bundled MCP command/args/env appear editable in Settings UI but are overwritten by managed plugin definitions

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

Summary

Bundled/plugin MCP servers such as node_repl appear editable in the Codex Desktop MCP Settings UI. The UI allows users to edit fields such as command, args, and env, but those edits are not effective persistent overrides for managed bundled MCP definitions.

After restarting Codex Desktop, the generated MCP config is rebuilt from the bundled/plugin MCP definition, so user edits are overwritten or ignored. The UI may still show the edited values, which makes the effective MCP configuration misleading.

Expected behavior

Codex Desktop should do one of the following:

  1. Allow real user overrides for bundled MCP command, args, and env, persist them, and launch the MCP server with those effective values.

or:

  1. Mark those fields as managed/read-only in the Settings UI for bundled MCP servers, and clearly explain that users need to create a separate external MCP server if they want custom command, args, or env.

Actual behavior

The Settings UI presents bundled MCP command / args / env as editable, but the effective config is regenerated from the bundled/plugin definition after restart.

For example, for the bundled node_repl, adding this argument in the Settings UI:

--disable-sandbox

can leave the UI showing the arg, while the generated/effective config after restart returns to:

[mcp_servers.node_repl]
args = []

The launched node_repl.exe process also does not receive the user-edited arg.

Why this matters

This makes the Settings UI misleading: it exposes controls that look editable, but for bundled/managed MCP servers those edits are not reliable effective overrides.

This is especially confusing when users are trying to diagnose MCP launch failures, because the UI can suggest that an arg/env override is configured while the launched process is still using the managed bundled definition.

Environment

Observed on Windows Codex Desktop builds around:

26.608.x / 26.609.x

Example bundled runtime path shape:

C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe

Related

This supersedes and clarifies #27655. That earlier issue focused on node_repl args being reset, but the more precise issue is the mismatch between editable UI controls and managed/generated bundled MCP definitions.

View original on GitHub ↗

2 Comments

guohao117 · 2 months ago

Chrome workaround for affected Windows users

For users hitting Windows node_repl sandbox launch failures, a working workaround is to avoid editing the bundled/plugin node_repl entry.

Instead, create a separate external MCP server for node_repl, pass --disable-sandbox there, and disable the bundled/plugin node_repl.

Example PowerShell setup

Copy the current bundled cua_node runtime to a stable external MCP location. Copy the whole bin directory, not just node_repl.exe, because the runtime also depends on its bundled Node and node_modules.

$src = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node" -Directory |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

$dst = "$HOME\.codex\external-mcp\node_repl"
Remove-Item $dst -Recurse -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force $dst | Out-Null
Copy-Item "$($src.FullName)\bin" $dst -Recurse -Force

Find the current bundled Chrome client and compute its trust hash:

$chromePlugin = Get-ChildItem "$HOME\.codex\plugins\cache\openai-bundled\chrome" -Directory |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

$chromeClient = Join-Path $chromePlugin.FullName "scripts\browser-client.mjs"
$chromeHash = (Get-FileHash $chromeClient -Algorithm SHA256).Hash.ToLowerInvariant()
$externalBin = "$HOME\.codex\external-mcp\node_repl\bin"

Register it as a normal external MCP server. These env values are the important Chrome-related pieces to carry over from the bundled MCP definition:

codex mcp add node_repl_external `
  --env BROWSER_USE_AVAILABLE_BACKENDS=chrome,iab `
  --env BROWSER_USE_CODEX_APP_BUILD_FLAVOR=prod `
  --env BROWSER_USE_CODEX_APP_VERSION=$($chromePlugin.Name) `
  --env CODEX_HOME="$HOME\.codex" `
  --env NODE_REPL_NODE_PATH="$externalBin\node.exe" `
  --env NODE_REPL_NODE_MODULE_DIRS="$externalBin\node_modules" `
  --env NODE_REPL_TRUSTED_CODE_PATHS="$HOME\.codex" `
  --env NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S=$chromeHash `
  -- "$externalBin\node_repl.exe" --disable-sandbox

Then disable the bundled/plugin node_repl in Codex Desktop.

The important part is that the external MCP server launches:

node_repl.exe --disable-sandbox

This avoids the managed bundled MCP config reset path described in this issue.

In local testing, this restored Chrome control: the external node_repl could initialize the bundled Chrome client and access the Chrome extension backend.

What not to copy for the Chrome workaround

Do not statically copy SKY_CUA_NATIVE_PIPE or SKY_CUA_NATIVE_PIPE_DIRECTORY for this Chrome workaround. Those are for Computer Use, and the pipe name is session-specific and changes after Codex restarts.

Important: this is only a workaround for affected Windows machines. It does not fix the Settings UI / effective-config mismatch described in this issue.

github-actions[bot] contributor · 2 months ago

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

  • #27655

Powered by Codex Action