Windows desktop: node_repl MCP gets stuck with Transport closed after sandbox setup refresh failures

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

Summary

On Windows Codex desktop, node_repl MCP repeatedly becomes unusable. Calls to node_repl/js either fail with Transport closed or the kernel exits with windows sandbox failed: spawn setup refresh / stdout_eof. This blocks Chrome plugin and Computer Use plugin because both require node_repl bootstrap.

Environment

  • OS: Windows
  • Codex desktop package path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__...
  • Workspace path: redacted local Windows workspace
  • Plugins involved: node_repl, chrome@openai-bundled, computer-use@openai-bundled

Impact

  • node_repl cannot execute even a minimal JS snippet.
  • Chrome plugin cannot bootstrap browser-client.
  • Computer Use cannot bootstrap computer-use-client.mjs or call sky.list_apps().
  • The user spent substantial time/tokens trying to diagnose and repair this from within Codex.

Reproduction / observed behavior

  1. Call node_repl/js with minimal code:

``js
nodeRepl.write(JSON.stringify({ ok: true, cwd: nodeRepl.cwd }, null, 2));
``

  1. Observed failure modes:

``text
node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof"}
`
or:
`text
tool call failed for
node_repl/js
Caused by: Transport closed
``

  1. Computer Use bootstrap fails immediately because it also runs through node_repl:

``js
const { setupComputerUseRuntime } = await import(".../computer-use-client.mjs");
await setupComputerUseRuntime({ globals: globalThis });
globalThis.apps = await sky.list_apps();
``

Local diagnostics

Sandbox log repeatedly shows AppData helper requiring elevation:

setup refresh: failed to spawn C:\Users\<redacted>\AppData\Local\OpenAI\Codex\bin\716dda49c14d31a0\codex-windows-sandbox-setup.exe: requested operation requires elevation (os error 740)

When using the WindowsApps bundled helper, sandbox setup entries appear to complete, but the current MCP transport remains closed and does not recover in the same thread.

Related Chrome issue that was also observed

A Chrome launch error showed Electron trying to launch ...\resources\google-chrome as an app/module. Chrome itself was installed at:

C:\Program Files\Google\Chrome\Application\chrome.exe

After creating/confirming the Chrome profile and native host, Chrome dry-run correctly resolved to chrome.exe, extension installed/enabled, native host manifest correct. However node_repl remained broken, still blocking Chrome/Computer Use plugin automation.

Expected behavior

  • node_repl should recover or respawn cleanly after config/path corrections or after its child process exits.
  • Sandbox setup should not use a helper path that requires UAC elevation in normal desktop plugin operation.
  • Chrome and Computer Use plugins should surface a clearer actionable error if node_repl transport is dead.

Request

Please investigate the Windows desktop node_repl MCP lifecycle and sandbox setup helper path selection. This failure consumes user tokens/time because plugin recovery attempts cannot proceed once the transport is closed.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25460
  • #25366
  • #25419
  • #25488
  • #25511

Powered by Codex Action

iceweasel-oai contributor · 2 months ago

this is now fixed

angelrancelantigravity · 1 month ago

Additional field data from a Windows Codex Desktop environment showing the same failure mode, with a useful separation between installation/profile health and the Codex node_repl/extension runtime.

Observed symptoms:

  • The coordinator session's mcp__node_repl.js began returning Transport closed consistently.
  • Chrome itself was recoverable and healthy after a clean restart with a dedicated profile already authenticated.
  • The official Codex Chrome extension was installed and enabled, the native host manifest was present, and the extension host process existed.
  • Despite that, the original node_repl MCP transport remained broken.
  • A fresh worker/subagent with a newly created node_repl process could sometimes recover the extension runtime and get agent.browsers.get("extension") successfully.
  • A separate fresh worker timed out during browser runtime setup and reset its kernel, so the recovery is not deterministic.

Important detail: the bootstrap shape mattered in this environment.

Working fresh-worker probe used the current browser runtime setup pattern with an explicit elicitationDisplayName and globals: { nodeRepl }, then accessed the populated agent.browsers surface. Older/stale snippets that call setup with no args, or assume the setup function returns the browser surface directly, failed.

Local interpretation:

  • This does not look like a Chrome profile, login, extension-install, or native-host-manifest problem once those checks pass.
  • The failure domain appears to be the Codex Desktop node_repl MCP transport / browser backend registration for that session.
  • Killing/recycling stale node_repl processes can clean process state, but it does not necessarily repair the current Codex session's MCP channel once it is already in Transport closed.
  • Starting a fresh worker/subagent can create a usable node_repl runtime, which is a practical workaround, but not a stable product-level recovery.

Operational workaround that reduced damage:

  • Treat Transport closed and Browser is not available: extension as terminal for that node_repl runtime.
  • Do not retry live browser sends in the same runtime.
  • Reconstruct from a known-good browser state, then use a fresh worker/runtime for a short probe.
  • If the coordinator runtime still reports Transport closed, continue via fresh worker or restart Codex Desktop as a last resort.

Request/suggestion:

It would help if Codex exposed a supported, documented way to reset/rebind the extension browser backend for the current node_repl session, or at least a diagnostic that distinguishes:

  1. Chrome extension not installed/enabled.
  2. Native host missing or disconnected.
  3. Extension host alive but no browser backend registered.
  4. node_repl MCP transport closed/stale.
  5. ChatGPT/Chrome page itself heavy or unresponsive.

Right now these collapse into similar user-visible failures, but their correct recovery actions are different.