Skip to content

Windows sandbox inconsistently fails to start PowerShell with CreateProcessAsUserW error 5 #37592

Open
Open
Windows sandbox inconsistently fails to start PowerShell with CreateProcessAsUserW error 5#37592
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@teknovaltda-prog
teknovaltda-prog
opened on Aug 8, 2026

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.

Activity

  1. teknovaltda-prog
    added
    appIssues related to the Codex desktop app
    on Aug 8, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Aug 8, 2026

  3. github-actions commented on Aug 8, 2026

    @github-actions
    github-actionsBot
    on Aug 8, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. yasuyuki commented on Aug 10, 2026

    @yasuyuki
    yasuyuki
    on Aug 10, 2026 – with ChatGPT Codex Connector

    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.

  5. jrgoralski commented on Aug 12, 2026

    @jrgoralski
    jrgoralski
    on Aug 12, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions