Windows Desktop: Computer Use fails because node_repl kernel exits with `windows sandbox failed: spawn setup refresh`
Open 💬 2 comments Opened Jun 4, 2026 by test-leek
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
On Codex Desktop for Windows, Computer Use is unavailable because the node_repl kernel exits before Computer Use can initialize. The failure happens even with a minimal node_repl script, so this appears to be in the Windows sandbox / Node REPL startup path rather than the Computer Use plugin itself.
Environment
- OS: Windows
- Codex Desktop package observed in logs:
OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0 - Computer Use plugin cache version:
openai-bundled/computer-use/26.601.21317 - Node REPL path from config:
.../OpenAI/Codex/bin/34ab3e1324cc55b5/node_repl.exe - Node version from bundled runtime:
v24.14.0
Steps to reproduce
- Enable the bundled Computer Use plugin on Windows.
- Start a Codex Desktop thread.
- Try a minimal Node REPL call, before any Computer Use automation:
nodeRepl.write(JSON.stringify({ cwd: nodeRepl.cwd, homeDir: nodeRepl.homeDir, tmpDir: nodeRepl.tmpDir }, null, 2));
- Try Computer Use bootstrap /
sky.list_apps():
if (!globalThis.sky) {
const { setupComputerUseRuntime } = await import("<computer-use plugin root>/scripts/computer-use-client.mjs");
await setupComputerUseRuntime({ globals: globalThis });
}
globalThis.apps = await sky.list_apps();
Expected behavior
node_replstarts successfully.- Computer Use can initialize and list Windows apps.
Actual behavior
The minimal node_repl call fails before Computer Use logic runs:
node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_pid":19564,"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}
Earlier attempts produced the same core error with different kernel PIDs:
windows sandbox failed: spawn setup refresh
One shell command during diagnosis also surfaced:
windows sandbox: CreateProcessWithLogonW failed: 1056
Additional observations
- Google Drive / Google Calendar plugins were enabled successfully and their tools load, so this does not appear to be a general plugin installation problem.
- The Computer Use plugin files exist, including
scripts/computer-use-client.mjs. - Attempted workaround: setting
node_replargs to['--disable-sandbox']inconfig.toml. This temporarily wrote successfully, but after restarting Codex / rebooting Windows, Codex rewrote the section back toargs = [], so the workaround did not persist.
Relevant config section after restart:
[mcp_servers.node_repl]
args = []
command = '.../OpenAI/Codex/bin/34ab3e1324cc55b5/node_repl.exe'
startup_timeout_sec = 120
Impact
Computer Use is unusable on this Windows installation because the dependency runtime fails before any app-control call can run.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Disclosure: I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery
This report is useful because the minimal
node_replcall fails before Computer Use code runs, so the first thing to validate is the local bridge/sandbox runtime rather than repeatedly reinstalling the Computer Use plugin itself.WinBridge checks the active
node_repl/Codex helper paths and their generation against the installed package, together with the bundled plugin/runtime state and active config. That can catch mixed-version or stale local helper references left by Desktop updates, and it backs up before rebuilding a recoverable user-local layer.It does not make
--disable-sandboxa persistent workaround or try to bypass the Windows sandbox. If the expected local helpers/config are coherent and the official sandbox setup path still fails withCreateProcessWithLogonW/setup-refresh errors, the remaining failure belongs upstream.If anyone with this exact
windows sandbox failed: spawn setup refresh→node_replexit tries WinBridge, please leave ✅ / 🟡 / ❌ feedback at https://github.com/zemeng5208/winbridge-recovery/issues/4. Even a no-change report would help define the tool's boundary.