›_ Codex Issues
Codex Issues / #37592

Windows sandbox inconsistently fails to start PowerShell with CreateProcessAsUserW error 5

Open 💬 3 comments Opened Aug 8, 2026 by teknovaltda-prog
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.803.41515

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

REPORTE_PUBLICO_GITHUB_CODEX_WINDOWS.md

What steps can reproduce the bug?

The Codex Windows app intermittently fails to launch PowerShell commands inside its workspace-write sandbox.

The exact error is:

windows sandbox: CreateProcessAsUserW failed: 5 (Acceso denegado.)

The affected PowerShell executable is resolved through:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

The same Windows account, Codex app version, configuration, and local environment can work correctly in one task but fail in another task. When the failure occurs, even simple read-only PowerShell commands cannot start because the process is rejected before the command executes.

This prevents Codex from inspecting, editing, testing, or validating the workspace and therefore prevents normal use of the paid service. Repeated attempts made while diagnosing this Codex sandbox failure have also consumed paid usage.

The relevant configuration is:

sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

No personal filesystem paths, account identifiers, session identifiers, or credentials are included in this public report.

What is the expected behavior?

  1. Open Codex App version 26.803.41515 on Windows x64.
  2. Open a local project using workspace-write mode with the Windows sandbox set to unelevated.
  3. Start a task and ask Codex to execute a simple read-only PowerShell command such as Get-Location.
  4. Codex attempts to launch pwsh.exe through the WindowsApps alias.
  5. The process can fail before the command executes with: windows sandbox: CreateProcessAsUserW failed: 5 (Acceso denegado.)
  6. Open another Codex task or project using the same Windows account and configuration.
  7. The same command may work there, demonstrating inconsistent sandbox process-launch behavior between tasks.

Additional information

A sanitized public diagnostic report is attached to this issue.

The in-app slash menu did not show a feedback or problem-reporting option in this installation, so this issue is being submitted through the official Codex GitHub repository.

Please investigate the Windows sandbox permission state and the inconsistent CreateProcessAsUserW behavior. Please also advise the appropriate channel for an account-level review of paid usage consumed by repeated failed attempts caused by this app error, and restore that usage if applicable.

The failure was reproduced again on 08-08-2026 when Codex attempted to run a simple local read-only PowerShell command. The command never started and returned the same CreateProcessAsUserW error 5.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 19 days ago

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

  • #37259
  • #36508

Powered by Codex Action

yasuyuki · 18 days ago

Additional follow-up testing on the same Windows environment (2026-08-10):

  • A fresh empty test workspace was used under C:\CodexWork. No user-profile ACL changes were made and no real data was moved.
  • CreateProcessAsUserW failed: 5 was reproduced during normal sandbox PowerShell process startup with both windows.sandbox = "elevated" and unelevated.
  • In the latest unelevated test, Get-ChildItem and apply_patch succeeded, while New-Item, Get-Content, Copy-Item, Move-Item, Rename-Item, and Remove-Item failed at sandbox process start, before the command executed.
  • The sandbox log reports workspace setup completing with processed 2 write roots ... errors=[]; the command runner then repeatedly reports error 5 while attempting to hide C:\Users\Default via SetFileAttributesW. This is a correlated log observation, not a confirmed root cause.
  • Persistent rules contain allow entries for Get-ChildItem, Get-Date, and Get-Location; therefore those successful commands are not clean evidence that the sandbox is functioning. No broad allow rule for the tested file cmdlets, and no approval_policy = "never", full-access, or yolo setting, was found.
  • Restarting Codex and switching between elevated and unelevated did not resolve the issue.

The root cause remains unknown. Please advise what diagnostic data is needed and provide a safe, supported remediation. We are deliberately avoiding ACL changes, changes to protected profile attributes, and moving real data until the cause is understood.

jrgoralski · 15 days ago

Pointer, not a duplicate claim: I hit CreateProcessAsUserW failed: 5 on the same OS build (10.0.26200) and traced it to a specific cause, filed as #38222 with a direct probe.

Short version: on my machine the sandbox's restricted token can Test-Path an executable under C:\Users\<user>\ but gets UnauthorizedAccessException enumerating its directory and ApplicationFailedException executing it, while a machine-wide binary under C:\Program Files\ runs fine. That single fact explained both the spawn failure (my pwsh was only a WindowsApps App Execution Alias, which lives in the profile) and a second symptom where python and gh came back "not recognized" even though their directories were present in the sandbox's $env:PATH.

I do not think this is your bug. Yours is intermittent, with Get-ChildItem and apply_patch succeeding while other commands fail, and you correlate it with SetFileAttributesW on C:\Users\Default. Mine is total and deterministic. Posting only because the probe is cheap and might be worth running on your setup to rule the ACL angle in or out:

$p = "C:\Users\<you>\AppData\Local\Programs\Python\Python312\python.exe"   # any user-profile exe
Test-Path -LiteralPath $p
Get-ChildItem -LiteralPath (Split-Path $p)
& $p --version

If you get True / UnauthorizedAccessException / ApplicationFailedException, it is likely the same underlying thing and #38222 can be folded into this one.