Exact error
Match the message before using the fix
windows sandbox: runner error: CreateProcessAsUserW failed: 5windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.)execution error: Io(Custom { kind: Other, error: "windows sandbox: runner failed during SpawnChild" })Quick answer
Start here
This error occurs before your command runs, so changing the command usually does not help. Update Codex, start a new session, and capture the full `cwd` and `cmd` lines beneath `SpawnChild`. If every sandboxed mode fails but the same harmless command runs outside the sandbox, you have isolated a Windows sandbox process-creation failure. There is no confirmed universal repair; do not reset broad Windows permissions or run permanently unsandboxed as a fix.
Diagnosis
Why it happens
- Windows denies child-process creation under the restricted sandbox token before PowerShell, dotnet, git, or the requested command executes.
- One current report resolves the shell through the Microsoft Store `WindowsApps` alias, while another uses elevated sandbox mode; the shared error does not prove one universal underlying cause.
- Security policy, executable identity, token permissions, and version-specific sandbox state can converge on Win32 error 5.
Safest first
Fixes, in order
Prove the failure is at sandbox spawn
Applies when: When every simple command fails immediately
The nested `SpawnChild` log is more diagnostic than the final generic execution error.
- Start a new Codex session on the current official version.
- Run a harmless command such as `Get-Location` or `dotnet --version` in read-only mode.
- Record the full error, including `cwd`, resolved `cmd`, and whether exit time is 0 ms.
- For diagnosis only, compare the same harmless command outside the sandbox if your security policy permits it.
Expected: The evidence shows the command works normally but no sandboxed child process is created.
Check the resolved shell executable
Applies when: When the nested log points to a WindowsApps alias or an unexpected PowerShell path
An alias path is a useful branch signal, not a proven universal cause.
- In a normal PowerShell window, list every resolved `pwsh` executable.
- Compare the real executable paths with the `cmd=` path in the Codex error.
- If you already have an official non-alias PowerShell installation, configure Codex to use that stable executable through supported settings.
- Do not copy executables or modify WindowsApps ACLs.
Get-Command pwsh -All | Format-List SourceExpected: Codex resolves the intended official shell path, or the alias branch is ruled out without changing system permissions.
Use unsandboxed execution only as a bounded diagnostic bypass
Applies when: When work is blocked and the exact command is safe, understood, and approved
The reports show danger-full-access can bypass this failure, but it removes the protection that failed.
- Review the exact command and working directory before approving it.
- Use the bypass only for the minimum diagnostic or verification step.
- Return to a sandboxed policy afterward.
- Attach the sandbox log and version to the upstream issue rather than treating the bypass as repaired state.
Expected: The bounded command runs, while the unresolved sandbox defect remains clearly documented.
Verification
Prove the fix worked
- Run a harmless command in read-only or workspace-write mode.
- Confirm it returns output and no longer exits at 0 ms with Win32 error 5.
- Verify that the successful run used a sandboxed policy rather than danger-full-access.
Escalation
If it still fails
- Record Codex app/CLI version, Windows build, sandbox policy, `cwd`, full `cmd`, and shell installation source.
- Do not apply broad ACL resets, disable endpoint security, or delete sandbox users based on this error alone.
- Treat danger-full-access as a security tradeoff and temporary bypass, not a permanent repair.
Scope
Environment and version notes
- Public reproductions include Codex Desktop 26.602 with CLI 0.137 alpha and Codex CLI 0.147.0 on Windows 11.
- Both primary issues remained open on August 20, 2026; npm reported Codex CLI 0.148.0 as current.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.
Desktop elevated-sandbox reproduction where every command fails before spawn.
Current CLI reproduction across read-only and workspace-write with the resolved WindowsApps shell path.
Related Windows process-creation error report showing the wider error cluster.