Error messages

CreateProcessAsUserW failed: 5 (Access is denied.)

CreateProcessAsUserW failed: 5 (Access is denied.)

On Windows, Codex runs the commands it wants to execute inside its own sandbox, and when that sandbox can't start a command you get one of two lines. Both are common: 108 issues in the openai/codex repo quote the first and 106 quote the second, as of September 25, 2026.

windows sandbox failed: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.)
windows sandbox failed: helper_unknown_error: setup refresh had errors

In the 0.157.0 source they're the same launch failing at two different steps, which we didn't expect from two such different-looking lines, so they share this page.

What the sandbox sets up

OpenAI's Windows docs describe two modes, picked with [windows] sandbox = "elevated" or "unelevated" in config.toml. Elevated, the preferred one, creates separate low-privilege Windows accounts (in the code they're CodexSandboxOffline and CodexSandboxOnline, in a group called CodexSandboxUsers) and needs an administrator to approve setup once. Unelevated runs commands under a restricted token made from your own account, and the docs call it the weaker fallback.

Either way, what a command may touch is controlled with ACLs. Each entry in one (an ACE) says which account may read or write that folder. Codex adds entries so the sandbox account can write to your workspace, and a deny entry on things it must not change.

Step one, the setup refresh

In elevated mode, every sandboxed command is preceded by a refresh. Codex runs its setup helper, which walks each folder the command is allowed to write to and adds the sandbox group's write entry wherever it's missing. The helper runs as you, without elevation (the source has a comment saying the refresh must never trigger the admin prompt).

That detail explains a lot of the reports. You can only change the permissions on a folder you're allowed to change them on. If a writable root is C:\, or a C:\tmp owned by Administrators, or C:\Users\Public, Windows refuses with error 5 and the helper records it. It doesn't stop at the first failure. It collects them, and at the end a single failed folder fails the whole refresh:

setup refresh completed with errors: ["write ACE failed on C:\\Users\\Public: SetNamedSecurityInfoW failed: 5"]

That's what surfaces as helper_unknown_error: setup refresh had errors, and your command never runs. One August report found C:\ itself saved as a writable root of a desktop-app project; every command in that project failed until it was gone.

Step two, starting the program

CreateProcessAsUserW is the Windows function that starts a program as a different user or under a different token. If the refresh passed, Codex logs on as the sandbox account and asks Windows to start your command with it. The number after the colon is the Windows error code:

• 5, Access is denied. Windows won't let the sandbox identity run that program. The best-documented case is PowerShell 7 from the Microsoft Store: a July report measured it failing every time pwsh resolved to C:\Program Files\WindowsApps\... in elevated mode, while the built-in Windows PowerShell 5.1, cmd.exe and Git Bash launched fine all twenty times.
• 1312, a logon session that doesn't exist. Codex treats this one as stale sandbox credentials, rotates the account's password and retries once. It skips the retry for programs under WindowsApps, because the source notes that Store apps can return 1312 with a healthy token.
• 2, The system cannot find the file specified. A September report on 0.154.0 kept getting it even for cmd.exe after a clean re-setup, in both modes. It was still open when we read it.

The full message carries cwd= and cmd=, which is the folder and command line Windows was handed. Read them before anything else.

What to try

Open the sandbox log at %USERPROFILE%\.codex\.sandbox\ (one file per day). For a refresh failure, the completed with errors line names the exact folder. Take that folder out of the project's writable roots, or open the project from a folder under your own user directory rather than a drive root. OpenAI's docs also say to remove "Everyone" write access from any folder Codex flags.

For error 5 at launch, run Get-Command pwsh in PowerShell. If the path contains WindowsApps, you're on the Store build. The reporter got commands running again by taking the WindowsApps entries out of PATH, so Codex fell back to Windows PowerShell 5.1. Switching to [windows] sandbox = "unelevated" also got that reporter past it, though they measured it as a real loss of isolation and went back.

OpenAI's troubleshooting list adds a code of its own: error 1385 means Windows is denying the sandbox accounts the right to log on, usually a company policy, and that's one for your IT department. Past that, the docs' advice is to restart Codex and let it run setup again. None of the issues we quote had an answer from OpenAI staff on September 25.

An MCP server that fails with Access is denied. (os error 5) on Windows can be caught by the same permissions; our page on MCP startup failures covers the rest of that message.