Summary
On Windows, the sandbox fails with CreateProcessAsUserW failed: 5 (Access is denied.) whenever the resolved shell is the MSIX (Microsoft Store) build of PowerShell 7. Windows refuses to launch a packaged (MSIX) binary under the restricted token the sandbox creates.
This appears to be the underlying cause behind several open reports (#26803, #25436, #26186, #10090, #9062, and likely #30047 / #26896 where accounts were also involved). None of them identify the packaged-shell condition, which is why the failure looks environment-specific and unreproducible: it depends solely on whether pwsh resolves to C:\Program Files\WindowsApps\....
Measurement
Same machine, same session, 20 trials per shell. Counted on the presence of CreateProcessAsUserW in the output, not on the exit code (cmd.exe legitimately returns non-zero, which is misleading).
| shell launched by the sandbox |
failures |
pwsh.exe — Store/MSIX (C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe) |
20 / 20 |
powershell.exe 5.1 (C:\Windows\System32\WindowsPowerShell\v1.0\) |
0 / 20 |
cmd.exe |
0 / 20 |
| git bash |
0 / 20 |
End-to-end confirmation: codex exec with the normal PATH resolves the MSIX pwsh and fails. The same codex exec with the WindowsApps entries removed from PATH falls back to PowerShell 5.1 and returns normally (exit 0, ~720 ms).
Error payload
windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.)
| cwd=C:\Users\<user>\<workspace>
| cmd="C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe" -NoProfile -Command "..."
| env_u16_len=6928 | si_flags=256 | creation_flags=525312 (Windows error 5)
creation_flags=525312 = 0x80400 = CREATE_UNICODE_ENVIRONMENT | EXTENDED_STARTUPINFO_PRESENT.
Two red herrings we eliminated, in case they save someone time
- Environment block size.
env_u16_len=6928 is constant across all 20 failures, and it is ~5× below the documented 32,767 limit. An oversized block would also raise ERROR_INVALID_PARAMETER (87), not 5. Not the cause.
- "Intermittent" behaviour. It looks intermittent but is deterministic per command: in our environment
echo hello failed 20/20 while Get-Content <path> succeeded 20/20 — file reads evidently take a path that never reaches SpawnChild. Observers who tested different commands drew opposite conclusions from the same broken setup.
Also ruled out on this machine: the CodexSandboxOffline / CodexSandboxOnline accounts both exist and are enabled, so this is not the missing-account variant.
Environment
- Windows 11 Pro, 10.0.26200
codex-cli 0.144.3~/.codex/config.toml: [windows] sandbox = "elevated"
Suggested fix
When resolving the shell, skip binaries under %ProgramFiles%\WindowsApps (or any MSIX-packaged executable) and fall back to System32\WindowsPowerShell\v1.0\powershell.exe. A packaged binary cannot be started under a restricted token, so it can never work on the sandbox path.
A clear error message would help too — Access is denied gives no hint that the shell is the problem.
Workarounds for anyone hitting this now
- Ensure a non-packaged
pwsh precedes the Store one in PATH, or remove WindowsApps from the PATH handed to codex.
[windows] sandbox = "unelevated" in ~/.codex/config.toml (documented fallback; not needed once the shell is non-packaged).
Summary
On Windows, the sandbox fails with
CreateProcessAsUserW failed: 5 (Access is denied.)whenever the resolved shell is the MSIX (Microsoft Store) build of PowerShell 7. Windows refuses to launch a packaged (MSIX) binary under the restricted token the sandbox creates.This appears to be the underlying cause behind several open reports (#26803, #25436, #26186, #10090, #9062, and likely #30047 / #26896 where accounts were also involved). None of them identify the packaged-shell condition, which is why the failure looks environment-specific and unreproducible: it depends solely on whether
pwshresolves toC:\Program Files\WindowsApps\....Measurement
Same machine, same session, 20 trials per shell. Counted on the presence of
CreateProcessAsUserWin the output, not on the exit code (cmd.exelegitimately returns non-zero, which is misleading).pwsh.exe— Store/MSIX (C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe)powershell.exe5.1 (C:\Windows\System32\WindowsPowerShell\v1.0\)cmd.exeEnd-to-end confirmation:
codex execwith the normalPATHresolves the MSIXpwshand fails. The samecodex execwith theWindowsAppsentries removed fromPATHfalls back to PowerShell 5.1 and returns normally (exit 0, ~720 ms).Error payload
creation_flags=525312=0x80400=CREATE_UNICODE_ENVIRONMENT | EXTENDED_STARTUPINFO_PRESENT.Two red herrings we eliminated, in case they save someone time
env_u16_len=6928is constant across all 20 failures, and it is ~5× below the documented 32,767 limit. An oversized block would also raiseERROR_INVALID_PARAMETER(87), not 5. Not the cause.echo hellofailed 20/20 whileGet-Content <path>succeeded 20/20 — file reads evidently take a path that never reachesSpawnChild. Observers who tested different commands drew opposite conclusions from the same broken setup.Also ruled out on this machine: the
CodexSandboxOffline/CodexSandboxOnlineaccounts both exist and are enabled, so this is not the missing-account variant.Environment
codex-cli0.144.3~/.codex/config.toml:[windows] sandbox = "elevated"Suggested fix
When resolving the shell, skip binaries under
%ProgramFiles%\WindowsApps(or any MSIX-packaged executable) and fall back toSystem32\WindowsPowerShell\v1.0\powershell.exe. A packaged binary cannot be started under a restricted token, so it can never work on the sandbox path.A clear error message would help too —
Access is deniedgives no hint that the shell is the problem.Workarounds for anyone hitting this now
pwshprecedes the Store one inPATH, or removeWindowsAppsfrom thePATHhanded to codex.[windows] sandbox = "unelevated"in~/.codex/config.toml(documented fallback; not needed once the shell is non-packaged).