Windows sandbox: CreateProcessAsUserW failed: 5 (Access is denied) — no command spawns under read-only or workspace-write #39276

What version of Codex is running?

codex-cli 0.147.0

Which model were you using?

gpt-5.6-sol (low reasoning effort)

What platform is your computer?

Windows 11 Enterprise 10.0.26200, x64

What steps can reproduce the bug?

Run any shell command with the sandbox enabled:

codex exec --sandbox read-only -c model_reasoning_effort=low "Run exactly this shell command: dotnet --version. Reply with its stdout, or the exact error if it failed."

What is the expected behavior?

The command runs. dotnet --version reads nothing outside the workspace and writes nothing, so it
should be allowed even under read-only.

What do you see instead?

The sandbox runner fails to spawn the child process, before the command itself runs:

ERROR codex_core::exec: exec error: windows sandbox: runner failed during SpawnChild:
CreateProcessAsUserW failed: 5 (Access is denied.)
| cwd=C:\Dev\CodexPlugins\plugins\plan-forge-flow
| cmd=C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command "try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
dotnet --version"
| env_u16_len=9281 | si_flags=256 | creation_flags=525312 (Windows error 5)

 exited -1 in 0ms

The turn ends with execution error: Io(Custom { kind: Other, error: "windows sandbox: runner failed during SpawnChild: ..." }) and Exit code: unavailable.

This is not specific to dotnet, and not specific to one policy — no command spawns at all:

It reaches the app server too, though I only have the agent's own account of it there: a turn/start carrying sandboxPolicy {"type":"workspaceWrite","writableRoots":[...],"networkAccess":true} left the agent reporting that every command came back access denied. The error text above is from codex exec, where it is visible directly.

Because danger-full-access works and every sandboxed mode does not, the practical effect on Windows is a choice between running unsandboxed and running with no shell access whatsoever. An agent in this state can still edit files through apply_patch, so it keeps working and simply cannot verify anything it wrote — in our case it produced code and reported that tests were unavailable.

Additional information

si_flags=256 (STARTF_USESHOWWINDOW), creation_flags=525312 (CREATE_UNICODE_ENVIRONMENT | EXTENDED_STARTUPINFO_PRESENT | CREATE_NO_WINDOW). The account is a standard (non-elevated) interactive user; running the same command from an elevated shell was not tested.