Codex CreateProcessAsUserW Failed: 5? Check the PowerShell Path

If Codex on Windows reports CreateProcessAsUserW failed: 5 (Access is denied.), inspect the command path in ~\.codex\.sandbox\sandbox.log before changing permissions. When that path points into C:\Program Files\WindowsApps\Microsoft.PowerShell_...\pwsh.exe, install a non-packaged PowerShell build, put C:\Program Files\PowerShell\7 ahead of the Store build for Codex, restart the app, and repeat one read-only command. Do not run Codex as administrator, take ownership of WindowsApps, or disable the sandbox to hide the error.

This is a narrow fix for the packaged-PowerShell branch. Error 5 can also come from workspace ACLs, missing sandbox accounts, enterprise policy, ARM64 behavior, or another executable. The log path is the deciding evidence.

Prerequisites

Before changing anything:

1. Save open work and stop the failed Codex task.

2. Open a normal PowerShell window outside Codex.

3. Record the Codex version and Windows build.

4. Keep the current sandbox log. It distinguishes this branch from look-alike access failures.

5. Use one disposable or clean repository for the verification task.

The commands below only read command resolution and recent log lines:

Get-Command pwsh -All | Select-Object CommandType, Source
where.exe pwsh

$sandboxLog = Join-Path $HOME '.codex\.sandbox\sandbox.log'
Get-Content $sandboxLog -Tail 300 |
  Select-String 'runner start|CreateProcessAsUserW'

Expected result for this branch: pwsh.exe resolves to a path under C:\Program Files\WindowsApps\Microsoft.PowerShell_..., and a nearby log line ends with CreateProcessAsUserW failed: 5.

If the log names powershell.exe, cmd.exe, git.exe, an ARM64 binary, or a workspace file instead, stop here. Use the broader Codex Windows sandbox error guide and diagnose that boundary instead of forcing this fix.

Why the Store Path Matters

OpenAI Codex issue 35871 isolates the shell path on one Windows machine. The reporter ran 20 trials for each shell: the Microsoft Store or MSIX PowerShell path failed 20 of 20 times, while Windows PowerShell 5.1, cmd.exe, and Git Bash failed 0 of 20 times. The same codex exec test worked after the WindowsApps entries were removed from the PATH passed to Codex.

That is strong reproduction evidence, not a promise that every error 5 has the same cause. Earlier reports such as issue 10090 show the same WindowsApps PowerShell path in sandbox.log, while other reports identify different ACL and platform branches.

Windows uses CreateProcessAsUserW to create a process in another user's security context. Codex's Windows sandbox uses a restricted context. The observed failure occurs before PowerShell runs, so changing the PowerShell command or project file usually cannot fix this particular branch.

Step 1: Confirm the Packaged Shell, Not Just Error 5

Capture the resolved executables with their versions:

Get-Command pwsh -All |
  ForEach-Object {
    $item = Get-Item $_.Source -ErrorAction SilentlyContinue
    [pscustomobject]@{
      Source = $_.Source
      Version = $item.VersionInfo.FileVersion
    }
  }

Then match the latest runner and failure lines:

$sandboxLog = Join-Path $HOME '.codex\.sandbox\sandbox.log'

Select-String -Path $sandboxLog -Pattern 'runner start|CreateProcessAsUserW' |
  Select-Object -Last 20 |
  ForEach-Object Line

You have a match only when the failed runner start command names a PowerShell executable below C:\Program Files\WindowsApps.

Do not assume that the first item returned by Get-Command is what an already-running desktop app uses. The sandbox log records what Codex actually attempted.

Step 2: Install a Non-Packaged PowerShell Build

Use Microsoft's PowerShell installation guide. The supported options include the official MSI package and WinGet. For WinGet:

winget install --id Microsoft.PowerShell --source winget

If PowerShell is already installed through that package, WinGet may offer an upgrade instead. Close the terminal after installation and open a new one so it receives the updated PATH.

Verify the non-packaged executable directly:

$installedPwsh = Join-Path $env:ProgramFiles 'PowerShell\7\pwsh.exe'

Test-Path $installedPwsh
& $installedPwsh -NoProfile -Command '$PSVersionTable.PSVersion'

Expected result: Test-Path returns True, and the second command prints a PowerShell 7 version. Microsoft documents $Env:ProgramFiles\PowerShell\7 as the default MSI installation directory.

Step 3: Verify PATH Order Without Deleting WindowsApps

Open a new normal PowerShell window:

Get-Command pwsh | Select-Object -ExpandProperty Source
where.exe pwsh

Expected result: the first path is C:\Program Files\PowerShell\7\pwsh.exe, not a path under C:\Program Files\WindowsApps.

If the Store build still comes first, inspect the user PATH without changing it:

[Environment]::GetEnvironmentVariable('Path', 'User') -split ';'

Use System Properties > Environment Variables to move C:\Program Files\PowerShell\7 before the relevant WindowsApps entry. Do not delete WindowsApps from the machine-wide PATH; other app execution aliases can depend on it.

For a temporary current-terminal check, prepend only the MSI directory:

$env:Path = "C:\Program Files\PowerShell\7;$env:Path"
Get-Command pwsh | Select-Object -ExpandProperty Source

This proves command resolution in that terminal only. Codex Desktop must be fully restarted after the persistent PATH order is corrected.

Step 4: Restart Codex and Run One Read-Only Test

Fully quit Codex, including its system-tray process, then reopen it. In a clean repository, ask:

Run one read-only command that prints the current directory, report the result, and stop

After the task completes, recheck the log:

$sandboxLog = Join-Path $HOME '.codex\.sandbox\sandbox.log'

Select-String -Path $sandboxLog -Pattern 'runner start|CreateProcessAsUserW' |
  Select-Object -Last 20 |
  ForEach-Object Line

Success means all three conditions hold:

• the latest runner uses C:\Program Files\PowerShell\7\pwsh.exe or another non-packaged shell;

• the read-only command returns its expected directory; and

• no new CreateProcessAsUserW failed: 5 line appears for that run.

Do not use a file edit as the first test. A read-only command isolates process creation from separate workspace write-permission failures.

If the Error Persists

Use the evidence to choose the next branch:

The existing Codex Windows sandbox guide covers these broader branches. If you need stronger isolation for agent work while the desktop issue is unresolved, compare a Docker sandbox workflow in a disposable repository.

Common Failure Modes

Why This Sequence Works

The sequence changes one boundary at a time. The sandbox log identifies the exact executable Codex tried to spawn. The official PowerShell installer supplies a normal executable outside the Store package directory. PATH verification ensures Codex selects that executable, and the one-command control proves process creation before write permissions enter the test.

This applies the useful structure behind Aident's Ollama networking guide: match exact terminology, answer early, use reproducible checks, state the expected result, and separate adjacent failures instead of guessing from one symptom.

Verify the Evidence Through Aident Loadout

Follow https://aident.ai/SETUP.md

With Codex Desktop closed, use the installed public aident CLI to confirm authentication and discover a current read-only GitHub issue-search Action:

aident account auth status
aident vault vault --action status
aident capabilities search --queries 'Search GitHub issues for an exact Windows error' --types action --targetEnv staging --output json --limit 5

Ask Aident Loadout to inspect the returned Action schema, preflight a bounded query for repo:openai/codex is:issue "CreateProcessAsUserW failed: 5", and execute it only after the preflight is accepted. Success is one current result set, no provider credential copied into the prompt, and no repository change.

Use Aident Loadout to verify that one hosted read-only Action while the local desktop sandbox remains closed.

Sources

• Windows sandbox failure when the resolved shell is the Store build of PowerShell, OpenAI Codex issue, opened July 29, 2026

• Elevated Windows sandbox commands fail with no output, OpenAI Codex issue, opened January 28, 2026

• Codex resolves an unusable PowerShell alias on Windows, OpenAI Codex issue, opened April 22, 2026

• Install PowerShell on Windows, Microsoft Learn, accessed August 3, 2026

• CreateProcessAsUserW function, Microsoft Learn, accessed August 3, 2026

Refresh this guide when Codex changes Windows shell resolution, sandbox user creation, PATH handling, the default sandbox mode, or the Store and MSI PowerShell compatibility behavior.