Skip to content

[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 #28481

Open

Description

@esccq

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

Activity

  1. added
    appIssues related to the Codex desktop app
    on Jun 16, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    app-serverIssues involving app server protocol or interfaces
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 16, 2026
  3. github-actions commented on Jun 16, 2026

    @github-actions
    Contributor
  4. srda85 commented on Jun 17, 2026

    @srda85

    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
  5. c40205193-lgtm commented on Jun 23, 2026

    @c40205193-lgtm

    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.

  6. bigZ-again commented on Jun 23, 2026

    @bigZ-again

    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)
  7. knightrobin commented on Jul 2, 2026

    @knightrobin

    +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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updatesmcpIssues related to the use of model context protocol (MCP) serverswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions