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

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

• #34872

Powered by Codex Action

Correction / refinement to the report above: there are two independent variables, not one. Further measurement shows the MSIX shell alone is not sufficient — the failure requires elevated mode AND an MSIX-packaged target. Changing either one fixes it.

Same machine, same MSIX pwsh target, 20 trials each:

| sandbox mode | failures |
|---|---|
| windows.sandbox=elevated (our config) | 20 / 20 |
| windows.sandbox=unelevated | 0 / 20 |

End-to-end with a real model turn:

codex exec -c windows.sandbox="unelevated" "git log -1 --oneline"   →  succeeded in 813 ms

So the accurate statement is: under elevated mode, the sandbox cannot launch an MSIX-packaged binary under its restricted token. Under unelevated, the same packaged shell launches fine.

This is worth knowing for triage, because it means affected users have two independent escapes — avoid the packaged shell, or switch the mode — and it may explain why some reporters see the failure and others with Store PowerShell do not: their mode differs.

Also: the "which commands fail" boundary is now precise

The earlier note about apparent intermittency resolves cleanly. In our runtime, simple readable operations are served internally and never reach SpawnChild; anything else attempts a real spawn and fails 100% of the time.

| command | failures |
|---|---|
| Get-Content <file> | 0 / 5 |
| Get-ChildItem | 0 / 5 |
| Get-Content <file> \| Measure-Object | 5 / 5 |
| $PSVersionTable.PSVersion | 5 / 5 |

A pipe, or any non-read command, is enough to cross into the failing path. This is almost certainly why the same broken setup produces contradictory reports from different users depending on which command they happened to try first.

Important caveat on the unelevated workaround I listed above — it is a degradation, not an equivalent fix. We measured what it costs before adopting it, and then rejected it. Posting the numbers so nobody takes it as a clean escape.

Two measured costs of running windows.sandbox=unelevated:

1. PowerShell drops to ConstrainedLanguage mode (verified twice, 5/5 each). Any .NET method call, Add-Type, or type cast fails inside an agent script.
2. The read-only sandbox tier is not available. The codex binary states it plainly: "Restricted read-only access requires the elevated Windows sandbox backend". If your workflow relies on read-only agents, unelevated silently weakens them — a deny-read on a sensitive file becomes a no-op. OpenAI's own documentation also notes the non-admin mode "carries greater risk if prompt injected".

There is also a footgun worth flagging on its own: codex app-server silently tolerates unknown -c keys (measured). A configuration-based workaround therefore fails silently if the key is ever renamed upstream — the failure comes back with no signal at all.

So the accurate framing is:

• avoiding the MSIX shell is a genuine fix (the sandbox backend is unchanged);
• switching to unelevated is a workaround that degrades the security backend, acceptable only if you don't depend on the read-only tier or on full-language PowerShell.

What we'd actually like from upstream: that the elevated backend be able to launch an MSIX-packaged binary, or — failing that — that it refuse the packaged shell explicitly and fall back to System32\WindowsPowerShell\v1.0\powershell.exe, with an error message naming the shell as the cause. Access is denied sends everyone hunting through account SIDs and permissions, which is where the seven existing reports went.

For the record, the fix we shipped on our side keeps elevated and removes the WindowsApps directories from the PATH of the child process we spawn — narrow, logged by name, and it leaves the sandbox backend intact.

Independent confirmation from Codex Desktop on Windows (sanitized; user authorized sharing).

Environment:

• Codex Desktop 26.721.4979.0
• Windows Microsoft Windows NT 10.0.26200.0
• command runner 0.146.0-alpha.3.1
• managed workspace-write session

Observed on 2026-07-29 while running a read-only rg verification:

runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access denied.)
| cmd=C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command "..."
| si_flags=256 | creation_flags=525312 (Windows error 5)

The command did not start. Retrying the same verification with the shell explicitly set to:

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

succeeded immediately (exit 0). This matches the packaged/WindowsApps PowerShell resolution condition described in this issue and provides a current Desktop-app reproduction. No credentials, customer data, or private workspace paths are included here.

Follow-up from the same sanitized Codex Desktop environment reported above (user authorized sharing).

During a longer implementation turn on 2026-07-29, the default command runner hit the same failure again on multiple independent calls, including:

• an rg ... | Select-Object read-only inspection;
• a simple Get-Date -Format ... call.

Both failed before command execution with:

windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access denied.)
cmd=C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command "..."
si_flags=256 | creation_flags=525312 (Windows error 5)

Immediately retrying through C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe succeeded (exit 0) in each case. This confirms that the failure persists across repeated tool calls in the same Desktop session and is not specific to one repository command or pipeline. No credentials, customer data, or private workspace paths are included.

Not a duplicate of #34872 — different failing mechanism.

#34872 is about Node canonicalizing absolute paths at startup and hitting EPERM on lstat of workspace ancestors: a path-traversal / directory-access problem, where the fix is about which directories the sandbox grants.

This issue is about process creation: under windows.sandbox=elevated, CreateProcessAsUserW returns error 5 when the target binary is MSIX-packaged, before any command runs. It reproduces on a target that lives inside the workspace, with no ancestor traversal involved, and it disappears by changing either the mode or the binary — neither of which is a path-permission change.

Same platform and same subsystem, but the failing step and the fix differ. Keeping this one open.

---

@ffonsecabc — thank you for the independent confirmation, and for the second follow-up. Two details from your reports are worth pinning down for triage:

• the failing target is the WindowsApps alias pwsh.exe (an MSIX execution alias), and the immediate retry through the inbox System32\WindowsPowerShell\v1.0\powershell.exe succeeds — which matches the packaged-vs-unpackaged boundary measured above;
• it recurs across independent calls in one session, including trivially read-only ones (Get-Date), so it is not workload-dependent.

That is a second environment, on a different Codex build, showing the same boundary.

Additional Codex Desktop reproduction on Windows.

Environment

• Codex Desktop version: 26.721.41059
• Workspace: trivial empty folder at C:\temp\codextest
• Workspace sandbox permission: Read only
• Tested with both:
• [windows] sandbox = "elevated"
• [windows] sandbox = "unelevated"

Direct invocation failures

Direct PowerShell commands such as:

Get-Location
git --version

both fail with:

CreateProcessAsUserW failed: 5 (Access is denied.)

This reproduces under both elevated and unelevated; changing the sandbox setting did not alter the result.

Control cases that succeed

cmd.exe /c git --version

returns:

git version 2.54.0.windows.1

and:

cmd.exe /c powershell -NoProfile -Command "Get-Location"

returns:

Path
----
C:\temp\codextest

So on this machine:

• PowerShell itself is executable inside the Codex security context.
• cmd.exe works.
• cmd.exe can successfully launch PowerShell.
• Only Codex Desktop's direct PowerShell spawn path fails with CreateProcessAsUserW error 5.
• The problem is not specific to the repository or workspace ACLs.

This may be the same packaged-shell resolution defect described here, but the unelevated workaround does not resolve it in Codex Desktop version 26.721.41059. A practical current workaround is to retry commands through cmd.exe /c, including cmd.exe /c powershell -NoProfile -Command "...", rather than treating the direct PowerShell failure as complete shell unavailability.

Follow-up from the same Codex Desktop reproduction:

cmd.exe /c where pwsh

returns:

C:\Users\antho\AppData\Local\Microsoft\WindowsApps\pwsh.exe

while:

cmd.exe /c where powershell

returns:

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

The Codex-injected PATH includes C:\Users\antho\AppData\Local\Microsoft\WindowsApps, after the Windows PowerShell 5.1 directory. The direct runner nevertheless appears to resolve pwsh, which lands on the WindowsApps alias, while the explicit workaround cmd.exe /c powershell -NoProfile -Command "Get-Location" succeeds through PowerShell 5.1.

This strongly aligns the Desktop case with the packaged/MSIX pwsh resolution cause described in this issue. One nuance: [windows] sandbox = "unelevated" still did not fix direct invocation in Codex Desktop 26.721.41059.

I traced the default Windows shell-selection path on current main. get_shell_path() accepts the which::which("pwsh") result before consulting the existing unpackaged PowerShell fallbacks. This means a WindowsApps/App Execution Alias can win even when C:\Program Files\PowerShell\7\pwsh.exe or Windows PowerShell 5.1 is available.
That appears consistent with the reproductions here. I would not assume the correct fix layer yet, though: shell detection is shared, whereas the incompatibility appears specific to the Windows sandbox spawn path. Would you prefer rejecting packaged candidates during default shell selection, or validating them at the elevated sandbox boundary so non-sandboxed Store PowerShell remains unaffected?
If you would like this addressed as an external contribution, please explicitly invite me to submit the focused fix and regression coverage.

Independent confirmation from Codex Desktop on Windows x64.

Environment

• Codex Desktop: 26.730.61639 (MSIX package 26.730.8199.0)
• bundled codex runtime: 0.147.0-alpha.1.2
• Windows 11: 10.0.26200
• sandbox: [windows] sandbox = "elevated"
• PowerShell: 7.6.4

Reproduction

With the Microsoft Store/MSIX build of PowerShell 7 installed, the shell selected by Codex was the user-scoped app execution alias:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

PowerShell itself resolved to the packaged binary:

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

Every sandboxed shell command failed before command execution:

windows sandbox: runner failed during SpawnChild:
CreateProcessAsUserW failed: 5 (Access is denied.)

The following were verified and did not resolve it:

• CodexSandboxOffline and CodexSandboxOnline existed and were enabled.
• Sandbox setup completed and the copied codex-command-runner launched.
• No domain or local computer GPO was applied.
• Trusting the Desktop executables and copied command runner in endpoint protection did not change the result.
• The same PowerShell command succeeded outside the Codex sandbox.

A/B confirmation

Installing the machine-wide MSI/WinGet build of the same PowerShell version changed resolution to:

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

After restarting Codex, the same command immediately succeeded inside the elevated sandbox:

CODEX_SANDBOX_OK
PowerShell=7.6.4
Executable=C:\Program Files\PowerShell\7\pwsh.exe
exit=0

This strongly confirms that Codex should detect and skip a user-scoped/MSIX pwsh.exe when using the Windows sandbox, fall back to a machine-wide shell, and surface an actionable error instead of generic Win32 error 5.

Reproduced a matching failure in Codex Desktop on Windows (2026-08-06): spawned subagents consistently fail before any command executes with CreateProcessAsUserW failed: 5 (Access is denied.), including Get-Location, Get-Content, and rg. The root agent in the same workspace can run the same commands normally.

The agent failure attempted the MSIX/WindowsApps pwsh.exe path. This is therefore a strong duplicate/corroborating report for the restricted-token packaged-shell cause described here.

I originally opened #37259 before finding this issue; closing it as duplicate.

I can reproduce this issue in Codex Desktop on Windows, and I have some additional diagnostics that may help.

Environment:

• Codex Desktop AppX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• PowerShell 7.6.4 installed from Microsoft Store / MSIX
• sandbox_mode = "workspace-write"
• approval_policy = "on-request"
• approvals_reviewer = "auto_review"
• Auto-review enabled
• Full Access disabled

Failure:
Every agent shell command inside the workspace fails before the command itself starts with:

CreateProcessAsUserW failed: 5 (Access is denied.)

Minimal reproducer:

Get-Content .\package.json -TotalCount 1

The sandbox log shows that the actual launcher is:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

This is the App Execution Alias / reparse point for the Store-installed PowerShell.

Additional findings:

• CodexSandboxOffline and CodexSandboxOnline exist and are enabled.
• Sandbox setup refresh completes successfully.
• codex-command-runner.exe and codex-windows-sandbox-setup.exe are present.
• Controlled Folder Access is disabled.
• I found no clear AppLocker / Code Integrity block.
• The failure happens during child-process creation, before the requested command runs.

I tested both:

[windows]
sandbox = "elevated"

and:

[windows]
sandbox = "unelevated"

Result in both cases:
0/8 basic read-only commands succeeded.

The agent runtime continued to launch:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

and failed with the same CreateProcessAsUserW error 5.

I also changed the Codex Desktop integrated terminal shell from PowerShell to Command Prompt. This had no effect on the agent sandbox launcher; it continued to use the WindowsApps pwsh.exe alias.

The 8-command test included:

• reading package.json
• reading src/App.tsx
• git status
• git diff
• git rev-parse
• rg searches

Because every sandboxed shell invocation fails, routine read-only work requires repeated escalation/approval. In one larger read-only audit this resulted in 41 approval requests.

This appears consistent with the packaged/MSIX PowerShell issue described here, but in Codex Desktop the agent appears to explicitly use:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

I could not find a supported configuration option for changing the agent sandbox shell executable.

A possible fix would be for the agent shell resolver to avoid App Execution Alias / packaged PowerShell executables for sandboxed execution and fall back to a non-packaged shell such as:

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

Full Access only bypasses the failing sandbox and does not fix the underlying issue.

Reproduced this on Codex Desktop on Windows and can confirm the PATH-based workaround works end-to-end, with one nuance worth flagging.

Environment:

• PowerShell 7.6.4 Store/MSIX installed
• PowerShell 7.6.4 MSI also installed side-by-side at C:\Program Files\PowerShell\7\pwsh.exe
• [windows] sandbox = "elevated" in config.toml

Initial datapoint (before the fix worked): with where.exe pwsh in my own interactive PowerShell session resolving the real MSIX binary (C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe) ahead of the per-user alias, Codex Desktop's sandbox log still explicitly showed:

START: C:\Users\chase\AppData\Local\Microsoft\WindowsApps\pwsh.exe -Command ...

followed by CreateProcessAsUserW failed: 5 (Access is denied.). This looked like Codex was ignoring PATH order entirely and hard-resolving the per-user alias. Turned out that was an artifact of my own interactive shell (itself launched via the MSIX pwsh, which self-prepends its own directory to PATH) — not representative of the environment Codex's own process actually inherited.

What actually fixed it: removing C:\Users\chase\AppData\Local\Microsoft\WindowsApps from PATH did work — but it had to be removed from both User and Machine scope (it was present, oddly, in both — Machine PATH had a duplicate of the per-user alias folder baked in alongside the expected systemprofile WindowsApps entry), and Codex Desktop had to be fully quit (all ChatGPT.exe/codex.exe processes terminated, not just the window closed) before reopening, since PATH is only read at process start. A partial restart (window closed but background processes still alive) silently kept using the old, unfixed environment and still failed identically.

After a genuinely clean restart with both WindowsApps PATH entries removed, whoami succeeded and returned the correct principal.

Suggested addition to the fix: since this environment variable is process-inherited, any documentation or auto-detection logic should account for the fact that closing/reopening a chat window inside the Desktop app does not necessarily restart the underlying codex.exe/ChatGPT.exe process tree — a full app quit is required for a PATH change to take effect.

Separately (unrelated to this issue but hit along the way): also had to repair a corrupted deny_read_acl_state.json (0-byte/NUL-filled) and grant a narrowly-scoped WriteAttributes ACE on C:\Users\Default for the sandbox's dedicated CodexSandboxOffline/Online accounts — those were separate, unrelated pre-existing issues on this machine, now resolved, mentioned here only in case anyone else hits multiple stacked sandbox issues at once and needs to rule them out independently.

Independent reproduction from Codex Desktop on Windows, reported with user authorization.

Environment:

• Codex Desktop AppX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Codex CLI on PATH: 0.144.1
• OS registry: ProductName Windows 10 Pro, DisplayVersion 25H2, build 26200.9168, x64
• [windows] sandbox = "elevated"
• Microsoft Store/MSIX PowerShell 7.6.4

Observed repeatedly during ordinary read-only repository work:

windows sandbox: runner failed during SpawnChild:
CreateProcessAsUserW failed: 5 (Access is denied.)
cmd=C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command "..."

The requested Git/PowerShell command did not begin. Retrying through the approved escalated path completed the same read-only command, so this is below the repository or project harness layer.

Shell resolution evidence:

where.exe pwsh
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

Get-Command pwsh
Path: C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe

C:\Program Files\PowerShell\7\pwsh.exe: absent
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe: present

The failure appears intermittent only because some simple reads can complete without reaching the failing SpawnChild path; multiple independent child-start attempts failed before execution. Setting login:false did not reliably change the outcome.

The documented diagnostic path %USERPROFILE%\.codex\.sandbox\sandbox.log is absent on this installation, and no other sandbox.log exists under %USERPROFILE%\.codex.

This matches the packaged/MSIX PowerShell boundary described in this issue. The safest user-side remedy appears to be installing machine-wide PowerShell so C:\Program Files\PowerShell\7\pwsh.exe is selected, then fully quitting and restarting Codex. Switching to unelevated is not an equivalent fix because it weakens the sandbox and has not worked consistently for Desktop reports.

Please make sandbox shell selection reject the WindowsApps/App Execution Alias target and fall back to a machine-wide PowerShell or the inbox Windows PowerShell, with an actionable error when only a packaged target is available.

Independent confirmation on current builds (user authorized public sharing; user/workspace paths omitted).

Environment

• Codex Desktop AppX: 26.820.9563.0
• codex-cli 0.150.1
• Windows x64, managed workspace-write sandbox
• PowerShell 7.6.5 installed side-by-side:
• Store/MSIX: Microsoft.PowerShell_7.6.5.0_x64__8wekyb3d8bbwe
• MSI: C:\Program Files\PowerShell\7\pwsh.exe

Reproduction

The Codex process PATH resolves pwsh in this order:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.5.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Program Files\PowerShell\7\pwsh.exe

Direct/default PowerShell shell startup fails before command execution with:

CreateProcessAsUserW failed: 5 (Access is denied.)

The controls are deterministic in the same sandbox:

pwsh -NoLogo -NoProfile -Version
-> Access is denied (exit 1)

C:\Program Files\PowerShell\7\pwsh.exe -NoLogo -NoProfile -Version
-> PowerShell 7.6.5 (exit 0)

Additional finding: disabling the App Execution Alias is insufficient

I disabled the Store PowerShell pwsh.exe entry under Windows App execution aliases, confirmed that the per-user alias file no longer exists, fully rebooted Windows, and restarted Codex. The failure persists because Codex's process PATH still contains the Store package's direct install directory ahead of the MSI directory.

A process-local A/B test that removes only that direct Store package directory from PATH immediately succeeds:

where pwsh
-> C:\Program Files\PowerShell\7\pwsh.exe

pwsh -NoLogo -NoProfile -Version
-> PowerShell 7.6.5 (exit 0)

This matches the rust-v0.150.1 resolver behavior: which("pwsh") wins before the hard-coded MSI fallback is considered. It would help if Windows sandbox shell resolution rejected an inaccessible WindowsApps result and continued to the existing MSI fallback (C:\Program Files\PowerShell\7\pwsh.exe) before falling back to Windows PowerShell 5.1.