Windows sandbox runner fails with CreateProcessAsUserW failed: 5 on Windows 11

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

• #26644
• #26186
• #25436

Powered by Codex Action

Additional information:

Get-Command pwsh -All returns:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.2.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\shend\AppData\Local\Microsoft\WindowsApps\pwsh.exe

PowerShell 7 is installed via WindowsApps/MSIX rather than MSI.

Windows PowerShell 5.1 is available at:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

This may be related to issue #25436 where reinstalling PowerShell via MSI resolved the same CreateProcessAsUserW failed: 5 error.

Update: I found a workaround.

The issue was caused by the Microsoft Store / MSIX version of PowerShell 7.

Originally:

• PowerShell 7.6.2 was installed via winget
• pwsh.exe resolved to:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.2.0_x64__8wekyb3d8bbwe\pwsh.exe

I removed the Store package:

Get-AppxPackage Microsoft.PowerShell | Remove-AppxPackage

Then installed the MSI version of PowerShell 7.6.2, which installs to:

C:\Program Files\PowerShell\7\pwsh.exe

After that, Codex sandbox execution started working normally.

Previously failing commands now succeed:

• git status
• Get-Location
• dir

This appears to match the behavior described in issue #25436.

i have posted the same issue here, no reply. https://github.com/openai/codex/issues/24291

I tried the workaround but for me it makes no difference

Adding a data point that isolates this as a version regression (0.145 → 0.146), reproducible and still present in 0.147.0.

Environment

• Windows 11 Pro, build 26200 (Dell laptop, Intel Lunar Lake)
• codex-cli installed via npm; [windows] sandbox = "unelevated" in config.toml
• pwsh 7 resolved via the Microsoft Store / WindowsApps shim (C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe)

Repro

codex sandbox -- pwsh -c "echo ok"

• 0.145.0 → ok (works, repeatedly, today)
• 0.146.0 → windows sandbox failed: CreateProcessAsUserW failed: 5 (Access is denied.)
• 0.147.0 → same failure: windows sandbox failed: CreateProcessAsUserW failed: 5 | si_flags=256 | creation_flags=525312

Same machine, same config.toml, same PowerShell install, nothing else changed between tests — only the codex version. npm install -g @openai/codex@0.145.0 immediately restores sandbox function; re-upgrading breaks it again. On 0.146 the sandbox log (~/.codex/.sandbox/sandbox.*.log) shows every START with no SUCCESS, whereas pre-0.146 logs show START/SUCCESS pairs.

Two observations that may help narrow it down

1. The MSIX-PowerShell workaround discussed above doesn't explain our case: our pwsh is the WindowsApps/MSIX shim and it works fine under 0.145. The failure is at CreateProcessAsUserW for the spawned process regardless of target executable, so it looks like the 0.146 sandbox architecture change (single codex.exe replacing .sandbox-bin) rather than the target binary's install type.
2. Practical impact in headless/exec use: every command falls back to an approval request that headless mode auto-denies, so codex exec workflows are fully blocked unless we pin 0.145.0.

Happy to run diagnostics or a patched build if that would help.

Update: fixed in 0.148.0 — same machine as my 2026-08-10 comment above.

Repro is the same one-liner as before: codex sandbox -- pwsh -c "echo ok"

| codex-cli | MSIX pwsh (WindowsApps shim) | MSI pwsh (Program Files) |
|---|---|---|
| 0.145.0 | OK | not installed at the time |
| 0.146.0 | CreateProcessAsUserW failed: 5 | not installed at the time |
| 0.147.0 | CreateProcessAsUserW failed: 5 | not installed at the time |
| 0.148.0 | OK | OK |

Environment otherwise unchanged: Windows 11 Pro build 26200, Dell laptop, codex-cli installed via npm, [windows] sandbox = "unelevated". That setting was already in place during the 0.146/0.147 failures, so it is not what fixed this.

Two caveats so this isn't over-read:

1. Between my 08-10 report and today I also installed the MSI build of PowerShell 7, so a bare pwsh now resolves to C:\Program Files\PowerShell\7\pwsh.exe instead of the WindowsApps shim. That is a second changed variable, so to keep them separated I ran 0.148.0 against both builds by absolute path — both succeed. The MSIX install type is therefore not the discriminator here.
2. I have not re-tested 0.146/0.147 against the MSI build. So the precise claim is: MSIX pwsh fails on 0.146/0.147 and works on both 0.145 and 0.148 — i.e. the discriminator is the codex version, not the PowerShell install type. This is consistent with, but narrower than, "MSIX is the cause".

Correction to my earlier comment. I previously offered the sandbox log as a diagnostic ("on 0.146 every START has no SUCCESS, whereas pre-0.146 logs show START/SUCCESS pairs"). Please don't rely on that signature. On 0.148.0 I have successful codex sandbox invocations — the command runs and prints its output — that log a START: line with no matching SUCCESS: line, and one invocation that logged nothing at all. So START-without-SUCCESS does not by itself indicate a broken sandbox. The version-vs-version repro above is the reliable signal; the log is not.

(For anyone looking: on this machine those entries are in ~/.codex/.sandbox/sandbox.<date>.log, a hidden directory — plain ls ~/.codex/ will not show it. The non-hidden ~/.codex/sandbox.<date>.log is a different, AUDIT:-only log.)

Sandbox denials still work on 0.148.0 — worth stating explicitly, since a fix to "sandbox won't start" could in principle have been a loosening. On 0.148.0 I confirmed all three of these are still blocked:

• writes to an absolute path outside the workspace
• .. relative-path escapes out of the workspace
• traversal through a junction inside the workspace pointing to a directory outside it

Verified by checking the target paths myself afterwards rather than trusting the agent's self-report; the junction case in particular indicates the check is done on the resolved real path, not the literal path.

@Mahkhmood9 — re your question from June ("is this still relevant"): for this specific failure mode, not on 0.148.0.