Windows desktop: node_repl MCP gets stuck with Transport closed after sandbox setup refresh failures
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_replcannot execute even a minimal JS snippet.- Chrome plugin cannot bootstrap browser-client.
- Computer Use cannot bootstrap
computer-use-client.mjsor callsky.list_apps(). - The user spent substantial time/tokens trying to diagnose and repair this from within Codex.
Reproduction / observed behavior
- Call
node_repl/jswith minimal code:
``js``
nodeRepl.write(JSON.stringify({ ok: true, cwd: nodeRepl.cwd }, null, 2));
- 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:
textnode_repl/js
tool call failed for ``
Caused by: Transport closed
- 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_replshould 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_repltransport 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
this is now fixed
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:
mcp__node_repl.jsbegan returningTransport closedconsistently.node_replMCP transport remained broken.node_replprocess could sometimes recover the extension runtime and getagent.browsers.get("extension")successfully.Important detail: the bootstrap shape mattered in this environment.
Working fresh-worker probe used the current browser runtime setup pattern with an explicit
elicitationDisplayNameandglobals: { nodeRepl }, then accessed the populatedagent.browserssurface. Older/stale snippets that call setup with no args, or assume the setup function returns the browser surface directly, failed.Local interpretation:
node_replMCP transport / browser backend registration for that session.node_replprocesses can clean process state, but it does not necessarily repair the current Codex session's MCP channel once it is already inTransport closed.node_replruntime, which is a practical workaround, but not a stable product-level recovery.Operational workaround that reduced damage:
Transport closedandBrowser is not available: extensionas terminal for thatnode_replruntime.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_replsession, or at least a diagnostic that distinguishes:node_replMCP transport closed/stale.Right now these collapse into similar user-visible failures, but their correct recovery actions are different.