Windows sandbox: CreateProcessAsUserW fails with error 5 when the resolved shell is the MSIX (Store) build of pwsh

The report names the Windows sandbox SpawnChild path and CreateProcessAsUserW, but no repository files or tests. Start by tracing shell resolution into SpawnChild and reproduce the failure with a Store/MSIX pwsh on Windows. Done means packaged shells are skipped or rejected with a clear fallback or error, verified against the listed shell behaviors.

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 (openai/codex#26803, openai/codex#25436, openai/codex#26186, #10090, openai/codex#9062, and likely openai/codex#30047 / openai/codex#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).

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

1. Ensure a non-packaged pwsh precedes the Store one in PATH, or remove WindowsApps from the PATH handed to codex.
2. [windows] sandbox = "unelevated" in ~/.codex/config.toml (documented fallback; not needed once the shell is non-packaged).