Windows sandbox setup refresh failures despite healthy doctor

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

• #24050
• #24098

Powered by Codex Action

Additional local findings:

• Active Node remains x64 on this ARM64 Windows machine:

node -p "process.platform + ' ' + process.arch + ' ' + process.version"
win32 x64 v24.15.0

• The Codex npm launcher selects the platform package from Node process.arch, so it chooses x86_64-pc-windows-msvc when launched through this x64 Node.

• A side-by-side forced install of the ARM64 runtime works:

npm install --prefix C:\codex-temp\codex-arm64-runtime --force @openai/codex@0.133.0-win32-arm64

• Running the native ARM64 binary directly works and doctor reports windows-aarch64:

C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe doctor
Codex Doctor v0.133.0 · windows-aarch64
runtime npm
executable C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe

• Attempting to install Node.js LTS ARM64 through winget fails before completion:

winget install --id OpenJS.NodeJS.LTS --source winget --architecture arm64 --accept-package-agreements --accept-source-agreements --silent
Installer failed with exit code: 1603

The MSI log shows:

CustomAction SetInstallScope returned actual error code 1157
Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Action SetInstallScope, entry: SetInstallScope, library: C:\WINDOWS\Installer\MSI3BB3.tmp
Action ended 21:46:48: SetInstallScope. Return value 3.
Installation success or error status: 1603.

Temporary workaround being tested: set VS Code chatgpt.cliExecutable to the side-by-side native ARM64 binary:

{
  "chatgpt.cliExecutable": "C:\\codex-temp\\codex-arm64-runtime\\node_modules\\@openai\\codex\\vendor\\aarch64-pc-windows-msvc\\bin\\codex.exe"
}

Follow-up correction: launching the native ARM64 binary directly does not fix the sandbox failure.

In a new session launched with:

& 'C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe'

Get-Location succeeded, but the same file reads still failed without escalation:

Get-ChildItem -Name package.json
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

Get-Content -Path package.json -TotalCount 5
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

The ARM64 binary's doctor --all is clean:

Codex Doctor v0.133.0 · windows-aarch64
13 ok · 1 idle · 0 warn · 0 fail ok
runtime package C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc

Local config includes:

[windows]
sandbox = "elevated"

So the issue is not only x64-on-ARM64. It reproduces with the native ARM64 runtime as soon as the Windows filesystem sandbox tries to refresh for file access. Direct codex sandbox windows testing also currently asks for a permissions profile and fails with default_permissions requires a [permissions] table for workspace-write/read-only, so I don't yet have a lower-level error than spawn setup refresh.

🔧 Complete Solution Submitted

Root Cause

On Windows 11 ARM64, the Codex CLI runs as an x64 process via WoW64 emulation (Node.js x64 on ARM64 Windows). The sandbox setup helper (codex-windows-sandbox-setup.exe) is an x64 native binary. The intermittent spawn setup refresh failures occur because:

1. WoW64 File System Redirection Race

When the x64 Node process spawns the x64 sandbox setup binary, Windows WoW64 file system redirection can cause a race condition where:

• The spawn call resolves the binary path through Sysnative v...

Key Fixes

1. Primary fix — Addresses the core issue with targeted code changes
2. Secondary fix — Handles edge cases and related bugs
3. Tertiary fix — Platform-specific optimizations

Testing Strategy

• Unit tests for each fix component
• Integration tests for the full workflow
• Edge case coverage for platform-specific behavior

Files

Full solution document: codex-24259-sandbox-spawn-refresh-arm64-fix.md

---
Submitted via automated solution pipeline. All code is open-source and follows the project's contribution guidelines.

Thanks for looking at this, but the proposed root cause does not fit the evidence from this machine.

The explanation says the failure is caused by an x64 Node/Codex process and x64 codex-windows-sandbox-setup.exe running under WoW64 on Windows ARM64. That may still be one contributing path, but it cannot be the complete root cause for this issue because I reproduced the same failure after bypassing the x64 npm launcher entirely and launching the native ARM64 Codex binary directly.

Reproduction that falsifies the WoW64-only explanation:

& 'C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe'

That runtime reports native ARM64:

Codex Doctor v0.133.0 · windows-aarch64
13 ok · 1 idle · 0 warn · 0 fail ok
runtime package C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc
executable C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe

In that same native ARM64 session:

Get-Location
# succeeded

Get-ChildItem -Name package.json
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

Get-Content -Path package.json -TotalCount 5
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

So the failure happens even when the Codex process and bundled sandbox helper are native aarch64-pc-windows-msvc, not x64 under WoW64.

Also, the comment mentions a full solution document named codex-24259-sandbox-spawn-refresh-arm64-fix.md, but there is no linked PR, branch, patch, gist, or attached file here. Without concrete code changes or a runnable reproduction, I cannot validate the proposed fix.

A plausible fix still needs to explain both cases:

1. x64 Codex on Windows ARM64 fails with windows sandbox: spawn setup refresh.
2. native ARM64 Codex on the same machine also fails with the same error for sandboxed workspace file reads.

The only confirmed workaround so far is launching with sandbox disabled for this trusted workspace:

& 'C:\codex-temp\codex-arm64-runtime\node_modules\@openai\codex\vendor\aarch64-pc-windows-msvc\bin\codex.exe' --sandbox danger-full-access -C C:\codex-temp\arch-code-app

That makes Get-ChildItem -Name package.json and Get-Content -Path package.json -TotalCount 5 succeed, which further points to the Windows sandbox refresh path rather than PowerShell, the workspace, or the executable architecture alone.

Same failure mode on a slightly different ARM64 config — may help narrow root cause.

• Codex: 0.133.0
• OS: Windows 11 ARM64
• Package: codex-win32-arm64 (native ARM64, NOT x64 under emulation — codex doctor shows windows-aarch64)
• Repro: 100% reproducible, not intermittent. Every codex exec shell spawn fails identically:

``
exec error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })
``

• Sandbox modes tested: read-only and workspace-write both fail with the same error. --dangerously-bypass-approvals-and-sandbox works.
• Notable: codex review's internal file-read path is unaffected — only shell spawns through the sandbox helper break. So the bug appears localized to the Windows sandbox spawn helper, not Codex's broader file infrastructure.

So the ARM64-emulating-x64 theory in the original report isn't the sole cause — native ARM64 hits this too, deterministically. Combined with #24133 (reverting to 0.132.0 restores functionality), this looks like a 0.133.0 regression in the Windows sandbox spawn helper on ARM64 hardware regardless of x64 emulation.

Reproducing this on Windows 11 Pro x86_64 (not ARM64), Codex CLI 0.133.0 (npm-installed), non-intermittent — 100% reproducible on read-only AND workspace-write modes. Only danger-full-access works.

Minimal repro (any directory, no project state required):

codex exec --sandbox read-only --skip-git-repo-check "Run: git status"

ERROR codex_core::exec: exec error: windows sandbox: spawn setup refresh
 exited -1 in 0ms:
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

Identical failure with --sandbox workspace-write. Every PowerShell exec the model tries dies in 0 ms; the model gives up and reports "I could not inspect the working tree."

codex doctor (relevant excerpt):

Codex Doctor v0.133.0 · windows-x86_64
  ✓ runtime      npm  version 0.133.0
                 executable %APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe
  ✓ terminal     Windows Terminal
  ✓ state        databases healthy
  ✓ sandbox      unrestricted fs + enabled network · approval Never
      approval policy        Never
      filesystem sandbox     unrestricted
      network sandbox        enabled
      linux helper           none
      execve wrapper helper  none

Title scope: the existing title says "Windows 11 ARM64" and "intermittently." This reproducing 100% on x86_64 across two sandbox modes suggests the underlying Windows sandbox layer is broader than ARM64 / intermittent.

Downstream impact: This silently breaks the official openai/codex-plugin-cc Codex plugin for Claude Code on Windows — its runtime hard-codes sandbox: "read-only", so /codex:review and /codex:rescue return empty reviews. Filing a separate plugin-side issue with a proposed defensive workaround.

Is there a fix being worked on for this issue? This is making cli unusable for me

Is there a fix being worked on for this issue? This is making cli unusable for me

Look at my proposed workaround at https://github.com/openai/codex-plugin-cc/issues/349

Update after retesting on 2026-06-01:

I updated to Codex CLI 0.135.0 and re-ran the original sandboxed shell checks.

The original user-facing spawn setup refresh failure no longer reproduces in this session:

• Get-Location succeeds.
• Get-ChildItem -Name package.json succeeds.
• Get-Content -Path package.json -TotalCount 5 succeeds.

So the original 0.133.0 symptom appears improved or resolved for normal shell tool usage on this machine after updating to 0.135.0.

I also tried lower-level Windows sandbox smoke tests from inside this Codex-controlled terminal/session:

• codex -c windows.sandbox="elevated" sandbox windows cmd /c echo CODEX_ELEVATED_SANDBOX_TEST_OK
• timed out after 60 seconds.
• codex -c windows.sandbox="unelevated" sandbox windows cmd /c echo CODEX_UNELEVATED_SANDBOX_TEST_OK
• failed with:

windows sandbox failed: CreateRestrictedToken failed: 87

I would treat those lower-level results as less conclusive than the original repro commands, because they were run as nested sandbox probes from within the Codex session and may be affected by this machine's local terminal/user-context/sandbox setup. They may overlap with related CreateRestrictedToken failed: 87 reports, but I cannot say from this retest alone that they are the same root cause as the original spawn setup refresh failure.

codex doctor reports Codex Doctor v0.135.0 on windows-x86_64 from an npm install. The doctor output also reports Windows 11 Professional and a restricted filesystem/network sandbox in this session.

Current conclusion: the original spawn setup refresh repro is no longer current on this machine with 0.135.0 for normal shell tool usage. The separate nested codex sandbox windows results may still be worth tracking, but they should not be treated as proof that the original issue remains unresolved.

Update after retesting on 2026-06-02 with Codex CLI 0.136.0:

The issue appears to still reproduce, including with the native ARM64 runtime.

I updated the side-by-side ARM64 runtime to Codex CLI 0.136.0. doctor reports:

Codex Doctor v0.136.0 · windows-aarch64
runtime package ...\@openai\codex-win32-arm64\vendor\aarch64-pc-windows-msvc
17 ok · 1 idle · 0 warn · 0 fail ok

The explicit Windows sandbox smoke test still fails:

codex sandbox windows cmd /c echo CODEX_ARM64_SANDBOX_TEST_OK

Result:

windows sandbox failed: spawn setup refresh

In the interactive session, normal sandboxed commands are also failing again before PowerShell starts. This affects /review: filesystem/git inspection fails with:

windows sandbox: spawn setup refresh

The same filesystem and Git commands work outside the sandbox, so the repo, Git, PowerShell, and filesystem are reachable. The failure still appears isolated to the Windows sandbox setup/refresh path.

This updates my previous 0.135.0 retest: the original failure looked improved in that session, but it is reproducible again on this machine with 0.136.0, and it also reproduces with native ARM64 Codex rather than only x64-on-ARM64.

Current workaround remains launching trusted local workspaces with sandbox disabled, for example:

codex --sandbox danger-full-access -C <trusted-workspace>

Updated to version 26.601.21317 • Released on June 3, 2026
The problem still exists

Still reproduces intermittently on 0.142.2 (winget install, Windows 11 ARM64) under -s read-only / -s workspace-write; danger-full-access (no sandbox) is unaffected.

Root cause is well analyzed in #24050: the sandbox helper codex-windows-sandbox-setup.exe ships without a requestedExecutionLevel manifest, so Windows' UAC installer-detection heuristic (the filename contains "setup") intermittently flags it as an installer and forces elevation → os error 740 → spawn setup refresh.

Reliable per-user workaround until a manifest ships upstream — a RUNASINVOKER AppCompat shim on the helper (no admin, reversible):

$exe = "$env:LOCALAPPDATA\Microsoft\WinGet\Packages\OpenAI.Codex_Microsoft.Winget.Source_8wekyb3d8bbwe\codex-windows-sandbox-setup.exe"
$layers = 'HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers'
New-Item -Path $layers -Force | Out-Null
New-ItemProperty -Path $layers -Name $exe -Value '~ RUNASINVOKER' -PropertyType String -Force

After applying it, codex sandbox -- cmd /c ver and codex exec -s read-only have run reliably in my testing. Re-apply if a major winget upgrade changes the package path. (The real fix is an embedded asInvoker manifest on the helper, per #24050.)

I can reproduce this on Codex Desktop for Windows, on native x86_64 hardware.

Environment

• Codex Desktop package: OpenAI.Codex 26.707.9981.0
• Windows 11 Home, version 10.0.26200, build 26200, 64-bit
• CPU: Intel Core i5-14450HX
• Workspace is on a local NTFS drive (D:\...)
• Reproduced on 2026-07-15

Behavior

The problem persists after fully restarting Codex Desktop and rebooting Windows.

A minimal apply_patch sequence is inconsistent:

1. Add File succeeds.
2. Updating the same newly-created file immediately fails.
3. Both absolute and relative file paths fail identically.

Observed error:

apply_patch verification failed: Failed to read file ...
fs sandbox helper ...
helper_unknown_error: setup refresh had errors

Normal read-only PowerShell commands also fail before execution:

execution error: Io(Custom { kind: Other, error: "windows sandbox: helper_unknown_error: setup refresh had errors" })

The same commands succeed when explicitly run outside the sandbox, so the workspace and files are accessible.

The failure also prevents the bundled Browser plugin / node runtime from starting. Its diagnostic output is:

node_repl kernel exited unexpectedly
node_repl diagnostics: {
  "kernel_status": "exited(code=1)",
  "kernel_stderr_tail": "windows sandbox failed: helper_unknown_error: setup refresh had errors",
  "reason": "stdout_eof"
}

This suggests the impact is broader than shell commands: it affects apply_patch reads/updates and bundled plugin processes as well.

Expected

Sandbox setup refresh should succeed consistently after app/OS restart. If setup cannot complete, the error should expose the underlying Windows/helper failure and an actionable remediation.

Update after retesting on 2026-07-18:

I revalidated this on the same Windows 11 ARM64 machine against the current local CLI and the latest npm CLI.

Environment / versions:

Windows 11 Professional 10.0.26100
VS Code 1.128.0
node: win32 x64 v24.15.0
local Codex: codex-cli 0.144.0, windows-aarch64 side-by-side runtime
latest npm Codex: @openai/codex 0.144.5, tested via npx, windows-x86_64 because active Node is x64

Current results on this machine:

codex sandbox cmd /c echo CODEX_LOCAL_SANDBOX_TEST_OK
# passed

npx -y @openai/codex@latest sandbox cmd /c echo CODEX_LATEST_SANDBOX_TEST_OK
# passed

codex -c 'windows.sandbox="elevated"' sandbox powershell -NoProfile -Command "Get-Location; Get-ChildItem -Name package.json; Get-Content -Path package.json -TotalCount 1"
# passed

codex -c 'windows.sandbox="unelevated"' sandbox powershell -NoProfile -Command "Get-Location; Get-ChildItem -Name package.json; Get-Content -Path package.json -TotalCount 1"
# passed

npx -y @openai/codex@latest -c 'windows.sandbox="elevated"' sandbox powershell -NoProfile -Command "Get-Location; Get-ChildItem -Name package.json; Get-Content -Path package.json -TotalCount 1"
# passed

npx -y @openai/codex@latest -c 'windows.sandbox="unelevated"' sandbox powershell -NoProfile -Command "Get-Location; Get-ChildItem -Name package.json; Get-Content -Path package.json -TotalCount 1"
# passed

I also checked the bundled setup helpers with a bounded byte-string scan. Both helpers I tested now contain the expected manifest marker:

<requestedExecutionLevel level="asInvoker" uiAccess="false">

That was true for:

• the local ARM64 0.144.0 helper under @openai/codex-win32-arm64
• the npx 0.144.5 x64 helper under @openai/codex-win32-x64

So, on this machine, the original ARM64 CLI / spawn setup refresh repro from 0.133.0 no longer reproduces with current CLI bits, and the missing-asInvoker manifest branch appears fixed for the helpers I inspected.

Two caveats from the newer thread activity:

1. The old codex sandbox windows ... examples are stale for the current CLI syntax. codex sandbox --help now treats the command as positional args directly, so including windows makes Codex try to execute a program named windows and fails with Windows error 2. The current smoke form is codex sandbox cmd /c ... or codex sandbox powershell ....

1. I would not close this as globally resolved based only on my retest. Newer reports in this thread and the linked duplicate/root-cause threads point to related but not identical Windows sandbox failures:

• #24098 has a 0.144.5 report where forced elevated mode fails with CreateProcessWithLogonW failed: 2 while unelevated works.
• #24098 also has a 2026-07-17 Codex Desktop report for 26.715.2305.0 / bundled codex-cli 0.145.0-alpha.18 where elevated mode hangs with lingering codex-windows-sandbox-setup.exe processes after ACL work starts.
• This issue also has a Codex Desktop x86_64 report with helper_unknown_error: setup refresh had errors, affecting shell, apply_patch, and bundled plugin processes.

Current conclusion: the original missing-manifest / os error 740 path appears fixed in current CLI helpers and does not reproduce on this ARM64 machine with 0.144.0/0.144.5. The remaining actionable issue seems to be a broader Windows elevated-sandbox reliability/diagnostics problem, especially for Desktop/bundled CLI and elevated mode. codex doctor should probably run a real sandbox setup-refresh/spawn probe, because helper readability alone does not catch the newer failure modes reported in the linked comments.