Windows sandbox: restricted token cannot enumerate or execute under the user profile, so pwsh/python/gh silently "do not exist"

What version of Codex CLI is running? codex-cli 0.146.1 (@openai/codex 0.146.1, codex-win32-x64)

What subscription do you have? ChatGPT (auth_mode = chatgpt)

Which model were you using? gpt-5.6-sol

What platform is your computer? Microsoft Windows NT 10.0.26200.9168 x64

What terminal emulator? Reproduced from Git Bash (MSYS2) and cmd.exe; not terminal-specific.

Codex doctor report: 17 ok · 1 idle · 1 notes · 0 warn · 0 fail — auth, connectivity and model access are all healthy. The failure is entirely in the sandbox command runner.

What issue are you seeing?

On this machine the Windows sandbox's restricted token can stat paths under C:\Users\<user>\ but cannot enumerate directories or execute binaries there. Sandboxed codex exec is consequently unable to run any tool installed under the user profile — which on a normal Windows dev box is most of them.

It surfaces as two unrelated-looking symptoms with one cause.

Symptom 1 — total CreateProcessAsUserW failed: 5 when pwsh is an MSIX App Execution Alias

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

The cmd= path is under the user profile. …\AppData\Local\Microsoft\WindowsApps\pwsh.exe is an App Execution Alias — a reparse point into C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe — and the sandbox token cannot execute it. Every command fails before it runs, under both -s read-only and -s workspace-write.

This is a common configuration rather than an exotic one: winget install --id Microsoft.PowerShell installs the msix variant, and that is the only installer in the manifest.

> winget show --id Microsoft.PowerShell --exact
Version: 7.6.4.0
  Installer Type: msix
  Installer Url: .../PowerShell-7.6.4.msixbundle

So anyone who installed PowerShell 7 via winget and never separately ran the MSI has pwsh on PATH as an alias only, with C:\Program Files\PowerShell\7\pwsh.exe absent. winget install --installer-type msi --force cannot help — it returns No applicable installer found, because the manifest has no MSI.

Workaround for this half: remove WindowsApps from the PATH the codex process itself sees. Shell discovery then falls through its candidate list (pwsh → pwsh.exe → powershell → powershell.exe) to Windows PowerShell 5.1 at C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, which is machine-wide, and commands spawn correctly.

Symptom 2 — with a machine-wide shell, every user-profile tool reports "not recognized"

After that workaround the sandbox runs commands, but only machine-wide ones. git (at C:\Program Files\Git) works; python and gh do not:

gh : The term 'gh' is not recognized as the name of a cmdlet, function, script file, or operable program.
python : The term 'python' is not recognized as the name of a cmdlet, function, script file, or operable program.

This is not a PATH problem. I initially assumed it was and was wrong. Dumping $env:PATH from inside the sandbox shows the inherited PATH arrives intact, including both directories:

C:\Users\<user>\.codex\tmp\arg0\codex-arg0CGD0Ky
C:\Users\<user>\AppData\Roaming\npm\...\codex-win32-x64\vendor\...\codex-path
C:\Program Files\Git\mingw64\bin
...
C:\Users\<user>\AppData\Local\Programs\Python\Python312     <-- present
...
C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links        <-- present

shell_environment_policy also works correctly — arbitrary variables set via -c shell_environment_policy.set.FOO=bar arrive in the child exactly as configured. Neither mechanism is at fault.

The actual cause, probed directly

Run inside the sandbox (-s workspace-write, machine-wide PowerShell):

$p = "C:\Users\<user>\AppData\Local\Programs\Python\Python312\python.exe"
$g = "C:\Program Files\Git\cmd\git.exe"
Test-Path -LiteralPath $p                       # -> True
Test-Path -LiteralPath $g                       # -> True
Get-ChildItem -LiteralPath (Split-Path $p)      # -> UnauthorizedAccessException
& $p -c "print(42)"                             # -> ApplicationFailedException

The token can stat the user-profile executable, but cannot enumerate its directory and cannot execute it. The machine-wide binary is fine. That single fact produces both symptoms: pwsh fails to spawn because the alias is in the profile, and python/gh are "not found" because PowerShell's command discovery cannot enumerate the PATH directories holding them.

Writes to the workspace itself succeed under -s workspace-write even though the workspace is also under C:\Users\<user>\, so this is not a blanket profile denial — execute and enumerate are denied where write is allowed.

-s danger-full-access is unaffected, since it does not use the sandbox runner:

> codex exec -s danger-full-access 'run: git rev-parse --short HEAD; gh --version; python -c "print(1+1)"'
90756b1
gh version 2.95.0 (2026-06-17)
2

What steps can reproduce the bug?

1. Windows 11. Install PowerShell 7 with winget install --id Microsoft.PowerShell (yields msix). Confirm C:\Program Files\PowerShell\7\pwsh.exe does not exist and where pwsh returns the WindowsApps path.
2. Install any tool into the user profile — e.g. winget install GitHub.cli, or python.org's per-user Python.
3. codex exec -s read-only 'run: git rev-parse --short HEAD' → every command fails with CreateProcessAsUserW failed: 5, cmd= pointing at the WindowsApps alias.
4. Re-run with WindowsApps removed from the PATH the codex process sees → commands now spawn via powershell.exe, and git works.
5. codex exec -s workspace-write 'run: gh --version' → not recognized, despite WinGet\Links being present in the sandbox's $env:PATH.
6. Run the Test-Path / Get-ChildItem / full-path-execute probe above → True, UnauthorizedAccessException, ApplicationFailedException.

What is the expected behavior?

1. The sandbox should be able to execute the user's toolchain. Per-user installs are the norm on Windows — winget package links, python.org per-user installs, npm globals, pipx, rustup, Store apps. If the token cannot execute anything under C:\Users\<user>\, sandboxed mode cannot run most real projects, and -s danger-full-access becomes the only usable setting, which defeats the point of having a sandbox.
2. If this denial is deliberate isolation, it needs to say so. Right now a denied execute is reported as CommandNotFoundException — "the term 'python' is not recognized" — which sends you looking for a PATH bug. I spent a long time ruling out PATH, shell_environment_policy.inherit, set.PATH, and profile files before probing the ACL. An explicit "sandbox denied execute on <path>" would have made it a one-minute diagnosis, and the docs should state that user-profile executables are unavailable in sandboxed mode.
3. Shell discovery should not select an executable the sandbox's own token cannot start. Skipping WindowsApps alias stubs, or probing the machine-wide C:\Program Files\PowerShell\7\pwsh.exe (already referenced in the binary) before the PATH lookup, would fix symptom 1 outright.

Relationship to existing issues

#26186, #37592, #30024, #35958 and #36614 all report CreateProcessAsUserW failures, the first two with error 5. I am not claiming those share this cause. #37592's follow-up describes an intermittent failure where some commands succeed, correlated with SetFileAttributesW on C:\Users\Default; this one is total, deterministic, and fully explained by the token's inability to execute under the user profile. Filing separately rather than assuming — if a maintainer confirms a shared root cause, please close this as a duplicate.

Found while trying to run a code review with codex exec on an ordinary developer machine; nothing here is specific to the project under review. Paths redacted per the template.

Start with the Windows sandbox command runner and shell-discovery path around CreateProcessAsUserW. Reproduce with the listed Test-Path, Get-ChildItem, and full-path execution probes, then verify that sandboxed commands either execute supported user-profile tools or report an explicit denial instead of treating them as missing.