›_ Codex Issues
Codex Issues / #28481

[Bug] mcp__node_repl__js unavailable in Codex Desktop 26.609.9530.0 (app-server 0.140.0-alpha.2) — Client-side feature gate not user-configurable

Open 💬 5 comments Opened Jun 16, 2026 by esccq
💡 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)?

Codex Desktop 26.609.9530.0 (app-server 0.140.0-alpha.2)

What subscription do you have?

CODEX

What platform is your computer?

_No response_

What issue are you seeing?

Summary

On Codex Desktop 26.609.9530.0 (Windows, UWP), the mcp__node_repl__js tool
is never registered in the tool list for any new chat thread, even though the
node_repl MCP server is configured and the underlying runtime is downloaded
and version-OK.

This makes the @browser, @computer-use, and the Node REPL workflows
unavailable to the model.

Environment

  • Codex Desktop: 26.609.9530.0 (Microsoft Store / WindowsApps)
  • App-server CLI: 0.140.0-alpha.2
  • Platform: Windows 11 64-bit (UWP package)
  • Sandbox: unelevated

config.toml excerpt

[mcp_servers.node_repl]
command = '"C:\Users\Administrator\AppData\Local\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b\bin\node_repl.exe"'
...
[mcp_servers.node_repl.env]
NODE_REPL_NATIVE_PIPE = "C:\\Users\\Administrator\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\789504f803e82e2b\\run\\node_repl.pipe"
NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS = "10000"

[features]
js_repl = false   # <-- appears to be a client-side gate; user edits are ignored

Setting [features] js_repl = true and restarting Codex has no effect —
the value is re-emitted as false on the next launch, and the tool remains
absent from the tool list.
What the model sees
The system prompt for the model contains no mention of js_repl or
node_repl. The tool list returned to the model does not include
mcp__node_repl__js. Calling it produces:

output = "unsupported call: mcp__node_repl__js"

Evidence from logs
app-server log (codex-desktop-*.log, ~/.codex):[BrowserUseThreadConfig] browser_use_runtime_paths_selected reports
nodeReplPath = ...\runtimes\cua_node\789504f803e82e2b\bin\node_repl.exe,
nodeReplPathSource = bundled-or-dev,
nodeVersionStatus = ok, nodeVersionValue = v24.14.0
No subsequent MCP server connected, tool registered, or
stdio_transport_spawned event for node_repl.exe
enabledFeatures does not include js_repl

Sandbox log (~/.codex/.sandbox/sandbox.2026-06-16.log):No EBUSY, no os error 740, no denied, no spawn failed
Setup refresh: processed 3 write roots errors=[] (clean)

Network ruled out: the mcp__node_repl__js tool is registered over a
local stdio pipe; no outbound traffic is involved.
Elevation ruled out: changing [windows] sandbox from elevated to
unelevated has no effect on tool registration.
Repro steps
Install Codex Desktop 26.609.9530.0 from Microsoft Store.
Configure a model provider (OpenAI or any wire_api = "responses"-
compatible endpoint).
Start Codex Desktop, open a new chat, send:

Use mcp__node_repl__js to run `nodeRepl.write("ok")`.

Observe: model emits the tool call, Codex returns
unsupported call: mcp__node_repl__js, and the model receives no
registration handshake for that tool.
Expected
Either [features] js_repl = true should enable mcp__node_repl__js
registration, or the gate should be exposed via a documented
configuration key.
node_repl should appear in the model-visible tool list when enabled.
Actual
node_repl is silently skipped at startup; no error is reported; the
model has no way to discover or recover the capability.
Impact
@browser and @computer-use plugins are completely unusable
(they depend on setupBrowserRuntime / setupComputerUseRuntime
run via mcp__node_repl__js).
All Node-REPL-based debugging and skill loading is impossible.
Suggested fix
Honor [features] js_repl in app-server 0.140.x alpha, or
Expose node_repl registration as a separately configurable
mcp_servers.node_repl.enabled flag independent of the
experimental js_repl feature, or
At minimum, log a warning when mcp_servers.node_repl is configured
but skipped due to a closed feature gate, so users can diagnose.

What steps can reproduce the bug?

Out of the box, on a clean install with no config changes, repeated calls all fail. There's nothing to reproduce on my end.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27178
  • #27907

Powered by Codex Action

srda85 · 2 months ago

I am seeing the same issue on Windows.

Environment:

  • Codex Desktop package: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0
  • Session metadata: cli_version: 0.140.0-alpha.19
  • Computer Use plugin: computer-use@openai-bundled
  • Computer Use plugin version: 26.611.62324
  • Platform: Microsoft Windows NT 10.0.26200.0 x64

Same symptoms:

  • @Computer / @Ordinateur loads the Computer Use skill
  • mcp__node_repl__js / node_repl/js / js are not exposed
  • Codex falls back to shell commands instead of visual Computer Use
  • restarting, reinstalling/reactivating the plugin did not fix it
c40205193-lgtm · 2 months ago

I can reproduce a closely related failure on a newer Windows Desktop build, so I am adding evidence here instead of opening a duplicate.

Environment observed locally on 2026-06-23 (Asia/Shanghai):

  • Codex Desktop package path from running process: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0\app\Codex.exe
  • codex-cli 0.142.0-alpha.6
  • Windows desktop process set includes both Codex.exe and bundled codex.exe
  • node_repl.exe exists at %LOCALAPPDATA%\OpenAI\Codex\bin\node_repl.exe and is 13,513,728 bytes, last modified 2026-06-17 15:03:12

Current CLI/config state says node_repl is configured and enabled:

> codex mcp get node_repl
node_repl
  enabled: true
  transport: stdio
  command: C:\Users\Laptop\AppData\Local\OpenAI\Codex\bin\node_repl.exe
  args: -
  cwd: -
  env: -
  startup_timeout_sec: 30
  tool_timeout_sec: 300

codex mcp list also includes:

node_repl  C:\Users\Laptop\AppData\Local\OpenAI\Codex\bin\node_repl.exe  enabled

And the current %USERPROFILE%\.codex\config.toml contains:

config.toml:47:[mcp_servers.node_repl]
config.toml:48:command = 'C:\Users\Laptop\AppData\Local\OpenAI\Codex\bin\node_repl.exe'

However, in the active Codex Desktop thread, tool_search cannot discover the required tool:

tool_search query: mcp__node_repl__js
result: Found 0 tools

So the user-visible configuration and CLI both say the MCP server exists, but the active model/tool inventory still does not expose mcp__node_repl__js.

There is also a persistence/config-writeback symptom that may be related. I ran a local repair script that waited until all Codex.exe / codex.exe processes exited, then checked and added the MCP server. The log shows:

[2026-06-23 18:58:56] no Codex processes found; applying MCP config
[2026-06-23 18:58:56] pre-add get exit=1 output=Error: No MCP server named 'node_repl' found.
[2026-06-23 18:58:56] add exit=0 output=Added global MCP server 'node_repl'.
[2026-06-23 18:58:57] verify get exit=0 output=node_repl | enabled: true | transport: stdio | command: C:\Users\Laptop\AppData\Local\OpenAI\Codex\bin\node_repl.exe
[2026-06-23 18:58:57] config matches=C:\Users\Laptop\.codex\config.toml:113:[mcp_servers.node_repl] | C:\Users\Laptop\.codex\config.toml:114:command = 'C:\Users\Laptop\AppData\Local\OpenAI\Codex\bin\node_repl.exe'

After restarting Codex Desktop, the CLI/config can again show node_repl, but the active thread still does not get the mcp__node_repl__js tool. That suggests at least the tool-exposure layer is not consistent with the persisted MCP config. It may also overlap with the config writeback behavior discussed in #24718.

Expected behavior:

  • If [mcp_servers.node_repl] is present and codex mcp get node_repl reports it as enabled, mcp__node_repl__js should either be directly available or discoverable through tool_search in new Desktop threads.
  • If Desktop intentionally skips this MCP server because of a feature gate or runtime condition, the UI/logs should report that reason instead of leaving the CLI/config and active tool inventory inconsistent.

No credentials or tokens are included in this report.

bigZ-again · 2 months ago

Version 26.616.9593.0 update: tool now registered, but action field leaks through namespace routing

The tool registration issue reported for 26.609 is partially resolved in 26.616 — mcp__node_repl now appears in the model-visible tool list. However, the tool still cannot be called successfully due to a new routing-layer defect.

Behavior observed on 26.616.9593.0 (Windows, Microsoft Store)

| js_repl | Call parameters | Result |
|---|---|---|
| false | action="js" + code | unsupported call: js |
| false | code only (no action) | unsupported call: js |
| true | action="js" + code | MCP error: -32602: unknown field 'action', expected 'title','code','timeout_ms' |
| true | code only (no action) | unsupported call: js |

Key finding

With js_repl = true, the call reaches the node_repl.exe MCP server (returning a JSON-RPC error, not an "unsupported call" rejection). The node_repl MCP server's js tool expects {title, code, timeout_ms}. The Codex namespace-tool routing layer adds action: "js" for sub-tool dispatch but does not strip it before forwarding — so the server rejects it as an unknown field.

With js_repl = false, calls are rejected at the Codex routing layer before reaching the MCP server, and the tool remains registered.

Environment

  • Codex: 26.616.9593.0
  • Node REPL: node_repl-20260619.1, Node v24.14.0
  • config.toml: js_repl persists as true after manual edit (unlike 26.609 where it was overwritten on restart)
  • Provider: external (issue is provider-independent; tool dispatch is client-side)
knightrobin · 1 month ago

+1 from another Windows user. Confirming the bug still reproduces on a newer build than the ones already reported, and that the impact is broader than just node_repl.

My environment

  • Codex Desktop: 26.623.81905 (Microsoft Store, Windows 11 x64, MSIX package OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0)
  • App-server / CLI: bundled (0.142.x family)
  • Custom model provider via base_url with wire_api = "responses" (so the non-OpenAI path) - same requires_openai_auth = true shape
  • Sandbox: unelevated

What I see

  • [mcp_servers.node_repl] is registered in ~/.codex/config.toml, the bundled node_repl.exe exists, nodeReplPathSource = bundled-or-dev, nodeVersionStatus = ok
  • [features] js_repl = true is set in the same file
  • After every Codex Desktop restart, the value is re-emitted as false in the on-disk config.toml (file mtime matches the launch)
  • mcp__node_repl__js is absent from the model-visible tool list
  • /mcp in chat shows zero servers, even with three correctly-registered [mcp_servers.*] blocks (custom servers) in config
  • Calling mcp__node_repl__js from the model returns unsupported call: mcp__node_repl__js

Broader impact worth flagging

The gate does not only block node_repl - it appears to suppress all custom [mcp_servers.*] blocks from being loaded. The MCP server processes themselves are fine (I can spawn them directly with the bundled node and they handshake/serve tools over stdio correctly), but Codex never tries to load them. So list_mcp_resources returns empty even though the config has the entries. This affects anyone who added a custom MCP server expecting it to show up in the tool list.

Suggested fix (echoing the OP)

Either honor [features] js_repl on Windows, or expose node_repl registration as a separate [mcp_servers.node_repl].enabled flag independent of the experimental feature. At minimum, log a warning when an [mcp_servers.*] block is configured but skipped due to a closed feature gate, so users can diagnose the issue without having to dig through sqlite and logs.