Windows Codex Node REPL MCP fails with `windows sandbox failed: spawn setup refresh`, breaking spreadsheet artifact runtime
Open 💬 2 comments Opened Jun 4, 2026 by graemeh
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
On Windows Codex Desktop, the Node REPL MCP server is exposed but fails even on a minimal smoke test. This prevents spreadsheet artifact workflows that expect the Node REPL / @oai/artifact-tool path from working, and forces fallback to local Python workbook generation.
Environment
- Platform: Windows / PowerShell
- Codex Desktop version observed:
OpenAI.Codex_26.601.2237.0_x64 - Codex command runner observed:
codex-command-runner-0.136.0-alpha.2.exe - Node REPL executable configured under
%LOCALAPPDATA%\OpenAI\Codex\bin\...\node_repl.exe - Node configured for Node REPL under
%LOCALAPPDATA%\OpenAI\Codex\bin\...\node.exe - Primary-runtime Spreadsheets plugin enabled
- Curated remote Data Analytics, Investment Banking, and Public Equity Investing skills also installed/enabled in the cache
Relevant config shape:
[features]
memories = true
js_repl = false
[mcp_servers.node_repl]
args = []
command = '<LOCALAPPDATA>\\OpenAI\\Codex\\bin\\<hash>\\node_repl.exe'
startup_timeout_sec = 120
[mcp_servers.node_repl.env]
NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS = "1000"
NODE_REPL_NODE_MODULE_DIRS = ""
NODE_REPL_NODE_PATH = '<LOCALAPPDATA>\\OpenAI\\Codex\\bin\\<hash>\\node.exe'
NODE_REPL_TRUSTED_CODE_PATHS = '<CODEX_HOME>'
CODEX_HOME = '<CODEX_HOME>'
Reproduction
- Start a Codex session on Windows.
- Use/discover the Node REPL MCP tools.
- Run
js_reset. - Run a minimal JS smoke test:
nodeRepl.write(JSON.stringify({ cwd: nodeRepl.cwd, tmpDir: nodeRepl.tmpDir }));
Actual result
The Node REPL kernel exits unexpectedly:
node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_pid":18780,"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}
Attempting an import has the same failure:
try {
var mod = await import('@oai/artifact-tool');
nodeRepl.write(JSON.stringify({available:true, keys:Object.keys(mod).slice(0,10)}));
} catch (e) {
nodeRepl.write(JSON.stringify({available:false, error:String(e)}));
}
Result:
node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_pid":39180,"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}
After stopping a stale node_repl.exe process, js_reset failed with:
tool call error: tool call failed for `node_repl/js_reset`
Caused by:
Transport closed
Expected result
The minimal smoke test should execute and return JSON. Spreadsheet artifact workflows should be able to use the documented Node REPL / @oai/artifact-tool workflow, or the runtime dependency path should be exposed clearly.
Additional observations
- The primary-runtime Spreadsheets plugin exists but appears to contain skills/assets only, not an obvious
node_modulesdirectory or@oai/artifact-toolpackage. NODE_REPL_NODE_MODULE_DIRSis empty in the Node REPL MCP environment.- A separate Data Analytics spreadsheets skill exists in the curated remote plugin cache.
- Investment Banking and Public Equity Investing plugins include workbook-related scripts/templates. These may add routing ambiguity, but the Node REPL crash appears independent because even the minimal smoke test fails.
- Local memory/history in this environment showed the same
windows sandbox failed: spawn setup refreshfailure before the current workbook task, suggesting this is not caused solely by the newest skills.
User impact
- Documented spreadsheet artifact runtime cannot be used.
- Spreadsheet tasks fall back to ad hoc Python/local package workflows.
- One workaround attempt produced a hand-built XLSX package that Excel refused to open as corrupt.
- A valid workbook was later generated only after installing
openpyxllocally into the workspace.
Questions / suggested investigation
- Why does Node REPL fail on a minimal smoke test with
windows sandbox failed: spawn setup refresh? - Why does killing a stale
node_repl.exeleave the MCP transport closed rather than respawning cleanly? - Should
[features].js_repl = falsecoexist with an exposednode_replMCP server/tool? - Should
NODE_REPL_NODE_MODULE_DIRSbe empty when spreadsheet skills instruct agents to use@oai/artifact-tool? - Should
@oai/artifact-toolbe present in the primary-runtime plugin cache, or resolved through another dependency loader that is not currently exposed? - Could multiple spreadsheet/workbook-oriented skills from primary-runtime, Data Analytics, Investment Banking, and Public Equity Investing create routing ambiguity for workbook tasks?
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Update with a tested workaround, based on the observation from @eliotcougar in #26530 that Codex CLI 0.137.0 ships a
codex-windows-sandbox-setup.exehelper containing anasInvokermanifest while the Windows Desktop App cached/bundled helper did not.On the affected Windows Desktop App install, I verified:
@openai/codex@0.137.0installed via npm reportscodex-cli 0.137.0.asInvoker.asInvoker.codex-windows-sandbox-setup.exewith the npm CLI 0.137.0 helper, the originalwindows sandbox failed: spawn setup refreshfailure no longer appeared.There was one additional failure after that first helper swap:
node_replthen failed with anEPERMwhile trying tolstatthe user AppData directory through the Desktop App cached Node path. PointingNODE_REPL_NODE_PATHat a normal installed Node executable outside the Desktop AppData cache resolved that second failure.After applying both changes, actual
node_replJavaScript execution worked again. After adding the primary runtimenode_modulesdirectory toNODE_REPL_NODE_MODULE_DIRS, both of these imports also worked:The important caveat: the workaround did not persist across a Codex Desktop restart. After restart, Desktop regenerated/reverted:
CODEX_CLI_PATHback to the Desktop AppData cachedcodex.exeNODE_REPL_NODE_PATHback to the Desktop AppData cachednode.exeNODE_REPL_NODE_MODULE_DIRSback to emptycodex-windows-sandbox-setup.exeback to the non-asInvokerhelperReapplying the workaround after restart restored
node_repland the artifact-tool imports again.Sanitized workaround shape:
codex-windows-sandbox-setup.exehelper in place of the Desktop App cached helper.CODEX_CLI_PATHto the npm CLI 0.137.0codex.exe.NODE_REPL_NODE_PATHto a regular installed Node executable outside the Desktop AppData runtime cache.NODE_REPL_NODE_MODULE_DIRSto the primary runtime dependencynode_modulesdirectory.This makes me think the CLI-side fix is real, but the Windows Desktop App still needs to bundle/regenerate the updated helper and preserve/generate a working
node_replenv after restart.