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

[CheckPickerUpper]

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:

• Windows SSH session: sandbox/unified exec runner times out on pipe-in, while local/RDP works #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.
• Windows sandbox runner fails to start with 0xc0000022 / pipe-in timeout #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.
• Windows sandbox runner fails with CreateProcessAsUserW 1312 after successful setup refresh #32060, Windows sandbox runner fails to spawn any local command with CreateProcessAsUserW failed: 1312 on Windows 11 24H2 #31768, Windows sandbox command runner fails with CreateProcessAsUserW failed: 1312 #30024, Windows sandbox runner fails with CreateProcessAsUserW failed: 5 on Windows 11 #26803, Windows sandbox runner fails with CreateProcessAsUserW failed: 5 on Codex 26.609.4994.0 #28339, Win: After upgrading Codex, I'm getting "windows sandbox: runner error: CreateProcessAsUserW failed: 1920" #20570, Codex Extension for VS Code: Windows sandbox runner fails before PowerShell starts with CreateProcessAsUserW failed: 1920 #30219 — all fail at CreateProcessAsUserW with a specific Win32 error code. This one never reports a CreateProcessAsUserW failure at all.
• Windows sandbox spawn fails with SetTokenInformation(TokenDefaultDacl) error 1344 when workdir is the home directory (and 1920 via per-user WindowsApps pwsh) #36328, Windows browser sandbox fails to initialize: SetTokenInformation(TokenDefaultDacl) failed: 1344 #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.

[MilkyWay008]

Seen this one on Windows before, the runner exe is right there but spawn_ready never fires, so it's not a missing binary. First thing I'd try: exclude ~/.codex/.sandbox-bin\ from Defender/AV real-time scanning, that alone can eat the whole 15s window on first launch. If it still stalls, run with codex exec --debug or RUST_LOG=codex_core=trace to see which phase hangs, and probe from a non-home workdir, the 1344 family in #36328 behaves like that. Oh, btw, in case it might help that, I built a portable Hermes OTG repo, check it, imo it may be able to help you diagnose and figure out the fix in no time. https://github.com/MilkyWay008/Hermes-OTG