Windows sandbox times out waiting for runner spawn_ready on a local session (0.147.0), while danger-full-access works

What version of Codex CLI is running?

0.147.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4-codex (default)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 — Windows 11 Home

What terminal emulator and version are you using (if applicable)?

Local session. Reproduced from Git Bash and from PowerShell 7 directly on the machine — no SSH, no RDP, no remote session of any kind.

Steps to reproduce

Every command routed through the Windows sandbox times out before the runner reports ready. One trivial command is enough:

codex exec --skip-git-repo-check -s workspace-write -c approval_policy='"never"' "Run the shell command: pwd"

Actual result

ERROR codex_core::exec: exec error: windows sandbox: timed out after 15000ms waiting for runner spawn_ready
ERROR codex_core::tools::router: error=execution error: Io(Custom { kind: Other, error: "windows sandbox: timed out after 15000ms waiting for runner spawn_ready" })
 exited -1 in 0ms

A single pwd prompt produced 9 of these in one run, as the agent retried. The same failure hits apply_patch, so no file edit can complete either — the model reports Failed to write file <path> and cannot tell that the cause was the sandbox rather than a rejected edit.

Expected result

The command runs, as it does with the sandbox disabled.

Control

Identical prompt, identical directory, same session, only the sandbox mode changed:

codex exec --skip-git-repo-check -s danger-full-access -c approval_policy='"never"' "Run the shell command: pwd"

 succeeded in 2200ms

Zero occurrences of spawn_ready. So the failure is specific to the sandboxed runner path, not to the command, the directory, or the model.

The matching runner binary is present

This does not appear to be a missing-runner problem. ~/.codex/.sandbox-bin/ carries a runner whose version matches the CLI exactly, written at the same time as codex.exe:

298668336  Aug 14 04:26  codex.exe
  1300272  Aug 14 04:27  codex-command-runner-0.147.0.exe
  1301296  Aug 11 19:13  codex-command-runner-0.147.0-alpha.6.6.exe
  1301296  Aug  8 12:08  codex-command-runner-0.147.0-alpha.6.5.exe
  1302320  Aug  5 09:59  codex-command-runner-0.147.0-alpha.1.2.exe
  1302320  Aug  2 02:41  codex-command-runner-0.146.0-alpha.9.2.exe
  1302320  Jul 28 20:18  codex-command-runner-0.146.0-alpha.3.1.exe
  1271600  Jul 13 14:32  codex-command-runner-0.144.2.exe
  1271600  Jul 10 02:55  codex-command-runner-0.144.0-alpha.4.exe
  1293104  Jul  5 18:15  codex-command-runner-0.142.5.exe
  1211184  Jun 16 00:20  codex-command-runner-0.140.0-alpha.2.exe

No Windows Application Error dialog appears, and the runner produces no output of its own — it simply never reaches spawn_ready inside 15000 ms.

Relationship to existing issues

This is the same 15000 ms runner-startup family as several open reports, but at a different phase and under different conditions, so it did not look covered by any of them:

• #30839 — timed out after 15000ms connecting runner pipe-in, but only over SSH; the reporter states local and RDP sessions work. This one is a purely local session.
• #22834 — timed out after 15000ms connecting runner pipe-in on 0.130.0, accompanied by a 0xc0000022 Application Error dialog. No dialog here, and no event-log entry.
• #32060, #31768, #30024, #26803, #28339, #20570, #30219 — all fail at CreateProcessAsUserW with a specific Win32 error code. This one never reports a CreateProcessAsUserW failure at all.
• #36328, #37648 — SetTokenInformation(TokenDefaultDacl) failed: 1344.

Searching the tracker for spawn_ready returns nothing, open or closed, so the wait-for-spawn_ready phase appears to be unreported.

Impact

With the sandbox on, the agent cannot run any command or edit any file, and each attempt costs 15 seconds before failing. Worse for tooling built on top: a PreToolUse hook that legitimately refuses an edit and a sandbox that failed to start are indistinguishable from the transcript — both surface as Failed to write file <path>. That makes an unenforced session look identical to a blocked one.

Start with the Windows sandbox runner startup path used by codex exec, focusing on the wait for spawn_ready and the matching binary in ~/.codex/.sandbox-bin/. Reproduce the workspace-write command locally and compare it with danger-full-access; done means the runner reaches ready and both pwd and file edits work without the timeout or misleading failure.