Windows Codex Desktop: node_repl / Computer Use fails with "windows sandbox failed: spawn setup refresh"

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

• #25478
• #25419
• #25366
• #25226
• #25460

Powered by Codex Action

I can reproduce this on another Windows machine with the same Codex Desktop generation, and I have a few additional diagnostics that may help narrow the failure path.

Environment observed:

• Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex CLI helper: 0.135.0-alpha.1
• OS from codex doctor: Windows 11 Professional, 10.0.26220, x64
• Affected features: node_repl, Computer Use, and other Node-REPL-backed plugins

Minimal repro:

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

Observed result:

node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}

Additional diagnostics:

• codex-computer-use.exe itself is present and can start; turn-ended also returns the expected "missing turn-ended payload" error when called directly, so the Computer Use binary does not appear corrupted.
• A normal shell command under Codex can run through the elevated Windows sandbox path successfully.
• Sandbox logs show normal shell calls spawning the WindowsApps packaged setup helper successfully:

setup refresh: spawning C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe
setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed

• The failing node_repl path attempts to spawn the helper from the AppData helper cache instead, and Windows returns elevation error 740:

setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\7dea4a003bc76627\codex-windows-sandbox-setup.exe
setup refresh: failed to spawn ...: The requested operation requires elevation. (os error 740)

• The AppData helper and WindowsApps helper have matching SHA256 hashes, so this does not look like helper corruption.
• node_repl.exe --help exposes --disable-sandbox / DISABLE_SANDBOX, but adding this to config did not recover the Desktop-managed MCP path:

[mcp_servers.node_repl]
args = ["--disable-sandbox"]

[mcp_servers.node_repl.env]
DISABLE_SANDBOX = "true"

• Process inspection still showed Desktop launching node_repl.exe without the --disable-sandbox CLI arg. After stopping the old node_repl.exe, the current Desktop thread did not automatically reconnect the MCP transport without a full app/thread restart.

This makes it look like the issue is specific to the Desktop-managed node_repl startup path and how it invokes the elevated Windows sandbox setup refresh, rather than a general sandbox failure or a corrupted Computer Use binary.

Adding another Windows data point after the 2026-06-01 Codex Desktop update.

Environment

• Codex Desktop package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Desktop process path shape: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\Codex.exe
• Bundled Codex CLI: codex-cli 0.136.0-alpha.2
• CLI path shape: %LOCALAPPDATA%\OpenAI\Codex\bin\716dda49c14d31a0\codex.exe
• node_repl.exe path shape: %LOCALAPPDATA%\OpenAI\Codex\bin\34ab3e1324cc55b5\node_repl.exe
• Browser: Microsoft Edge with the Codex extension
• Platform: Windows x64

Impact

• Browser connection / Edge extension control is still unavailable.
• Minimal node_repl execution fails before any JS user code runs.
• Computer Use helper files are present, so this does not look like missing helper binaries.

Minimal failing test

nodeRepl.write('node-repl-ok')

Actual result

node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}

Lower-level sandbox results

• Direct sandbox smoke test from the current Codex tool context still fails with:

windows sandbox failed: CreateRestrictedToken failed: 87

• .codex/.sandbox/sandbox.2026-06-02.log shows normal shell/tool sandbox refreshes using the WindowsApps packaged helper path can process write roots successfully:

setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed

• The failing node_repl startup path instead tries the AppData helper path and Windows returns elevation error 740:

setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\716dda49c14d31a0\codex-windows-sandbox-setup.exe
setup refresh: failed to spawn ...: The requested operation requires elevation. (os error 740)

Additional diagnostics

• Running Codex Desktop as Administrator did not make the Desktop-managed node_repl path succeed.
• The current Codex tool shell still reports non-admin from [WindowsPrincipal].IsInRole(Administrator) even after an admin-style restart, so the Desktop/tool/node_repl child process may not be inheriting the expected token.
• %LOCALAPPDATA%\OpenAI\Codex\bin\716dda49c14d31a0\codex-windows-sandbox-setup.exe and the WindowsApps resource helper have matching SHA256 and length, so this does not look like helper corruption.
• node_repl.exe in %LOCALAPPDATA%\OpenAI\Codex\bin\34ab3e1324cc55b5\ matches the WindowsApps packaged resources\node_repl.exe by SHA256.
• computer-use\latest points to an existing package version and both codex-computer-use.exe plus helper_transport.js exist.

This looks specific to the Desktop-managed node_repl / browser bridge sandbox setup-refresh path after the update, not to the Edge extension itself or missing local helper files.

Additional Edge-extension click evidence from the same Windows machine:

When clicking the Codex extension in Microsoft Edge, Windows shows an Electron launch dialog like:

Error launching app
Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\...\google-chrome
Cannot find module 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\...\google-chrome'

This looks like the extension/native-host click path is passing google-chrome as an Electron app path/argument incorrectly.

Native host read-only checks:

• Edge registry key exists:

HKCU\Software\Microsoft\Edge\NativeMessagingHosts\com.openai.codexextension
Default = %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

• The manifest exists and points to the bundled extension host:

{
  "name": "com.openai.codexextension",
  "path": "%USERPROFILE%\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe",
  "type": "stdio",
  "allowed_origins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"]
}

• However, extension-host-config.json is not present next to extension-host.exe in the current chrome/latest/extension-host/windows/x64 directory. The 26.527.30818 installManifest.mjs appears to be designed to write this file next to extension-host.exe.
• Running scripts/check-native-host-manifest.js --json with bundled Node reports Chrome registry missing because it checks HKCU\Software\Google\Chrome\NativeMessagingHosts\...; this machine is using Edge and the Edge registry key is present.

So there may be two related failure paths here:

1. Browser-control/node_repl setup refresh fails with os error 740 / windows sandbox failed: spawn setup refresh.
2. Clicking the Edge extension launches Electron with google-chrome interpreted as an app/module path, possibly due to missing or stale native host config / browser channel handling.

Adding a confirmed workaround data point for Computer Use on Windows.

Environment:

• Codex Desktop package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Bundled Codex CLI: codex-cli 0.136.0-alpha.2
• Computer Use plugin: computer-use@openai-bundled, package 26.527.60818
• Platform: Windows x64

Initial failure:

node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof","stream_error":null}

Local sandbox log showed the failing node_repl / Computer Use path trying to spawn the AppData helper and getting elevation error 740:

setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\716dda49c14d31a0\codex-windows-sandbox-setup.exe
setup refresh: failed to spawn ...: The requested operation requires elevation. (os error 740)

Normal shell tool calls in the same Codex Desktop session were still able to use the WindowsApps packaged sandbox helper successfully, so this looked specific to the Desktop-managed node_repl / Computer Use path.

Workaround that fixed Computer Use for this machine:

[windows]
sandbox = "unelevated"

Steps:

1. Changed C:\Users\<user>\.codex\config.toml from sandbox = "elevated" to sandbox = "unelevated" under [windows].
2. Fully restarted Codex Desktop.
3. Retested node_repl with a minimal JS call; it succeeded.
4. Retested Computer Use through the plugin runtime.

Post-restart verification:

• sky.list_apps() returned 40 apps/windows.
• Targeted Notepad explicitly.
• Computer Use activated the Notepad window.
• get_window_state(... include_text: true) read the document text successfully.
• type_text(...) inserted a new line.
• A second text snapshot read the inserted line back successfully.

So on this machine, switching Windows sandbox mode from elevated to unelevated plus a full Codex Desktop restart restored Computer Use. This appears to be a practical workaround for the elevated sandbox setup-refresh failure, not a fix to the underlying issue.

This looks worth separating into three layers before changing more config:

1. whether the failure happens before any Computer Use/browser code runs, by testing a minimal node_repl call;
2. whether codex-windows-sandbox-setup.exe is being launched unelevated and failing with error 740 / setup refresh;
3. whether Codex Desktop is regenerating the node_repl MCP config and discarding local args such as --disable-sandbox.

If a redacted sandbox log tail and the regenerated [mcp_servers.node_repl] config are available, it should help distinguish a local Windows sandbox setup issue from a Computer Use plugin issue.

this is now fixed