›_ Codex Issues
Codex Issues / #38665

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

Open 💬 4 comments Opened Aug 14, 2026 by 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:

  • #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.

View original on GitHub ↗

4 Comments

MilkyWay008 · 13 days ago

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

jdcodes1 · 10 days ago

The protocol placement of this timeout narrows the failure considerably (traced on main @ 1f41cc5d92):

What has already succeeded when this fires. The client creates the runner process and completes the pipe handshake before ever waiting for spawn_ready (windows-sandbox-rs/src/elevated/runner_client.rs#L380-L420) — so the runner launched, connected both named pipes, and received the spawn request. And on the runner side, spawn_ready is only sent after spawn_ipc_process returns — i.e. after the sandboxed child has actually been created (restricted token, job object, ConPTY, redirected handles):

https://github.com/openai/codex/blob/1f41cc5d92722748e45cae9cecc6d883a4e7cbb1/codex-rs/windows-sandbox-rs/src/bin/command_runner/win.rs#L580-L612

Crucially, a failing spawn_ipc_process sends an Error frame (ErrorStage::SpawnChild), which the client reports as "expected spawn_ready from runner, got …" — a different message than yours. A bare 15,000 ms timeout therefore means the runner sent nothing: spawn_ipc_process is hanging, not erroring. On a machine where this happens for every command, something is deterministically blocking restricted-token/ConPTY child creation — the classic profile being security software (AV/EDR) interposing on CreateProcessAsUser-style calls with restricted tokens, which also explains why danger-full-access (no runner, plain spawn) works.

Diagnostics that would pin it on your machine:

  • the sandbox log directory %USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log plus the runner's per-spawn log dir — whatever the last logged stage is before silence identifies the hung step;
  • toggling [windows] sandbox = "elevated" vs "unelevated" in config bisects which spawn path is affected;
  • temporarily disabling third-party AV/EDR (or adding codex-command-runner.exe to its exclusions) is the fastest confirmation of the interposition theory.

Fix shapes for the repo:

  1. Runner-side stage watchdog: spawn_ipc_process already has stage granularity (ErrorStage), but only on the error path. Emitting a progress frame per stage — or converting a stage that exceeds its own sub-deadline into an Error frame before the client's 15 s expires — turns "timed out waiting for spawn_ready" into "hung creating ConPTY / duplicating token / assigning job object", which is actionable.
  2. Client-side harvest on timeout: before terminating the runner, capture its stderr/log tail into the error message rather than discarding the only evidence of where it hung.
  3. Error attribution for the agent: your 9-retry observation is the same misattribution family as #38992 — apply_patch surfacing "Failed to write file" when the sandbox infrastructure failed invites the model to retry or misdiagnose. A distinct sandbox-infrastructure error class (non-retryable within the turn, surfaced to the user) would stop the retry burn for every failure of this kind.
256952365 · 9 days ago

Additional reproducible variant on Codex Desktop for Windows: the cold tool call eventually succeeds, but consistently consumes ~28.5–29.5 seconds before the command itself starts; immediately subsequent calls are fast.

Environment

  • Codex Desktop MSIX: 26.814.5167.0 x64
  • Bundled command runner: codex-command-runner-0.148.0-alpha.15.exe
  • Windows 11: 10.0.26200.8973
  • Local desktop session, workspace-write sandbox
  • Trivial local command: Get-Date (no network)

Measurements

After a full Codex Desktop restart:

| Run | End-to-end tool-call wall time | Inner command wait |
|---|---:|---:|
| Cold #1 | 28.624 s | 0.064 s |
| Warm #2 | 0.280 s | 0.058 s |
| Warm #3 | 0.282 s | 0.060 s |

The same cold pattern was reproduced multiple times in the same task after the tool/code-mode host had gone cold:

  • 29.488 s total / 0.253 s command
  • 28.916 s total / 0.253 s command
  • 28.492 s total / 0.246 s command

Earlier attempts also failed with the exact error:

Failed to create unified exec process: timed out after 15000ms waiting for runner spawn_ready

Two consecutive failures returned after 15.119 s and 15.126 s.

Controls

  1. Changed:
[windows]
sandbox = "elevated"

to:

[windows]
sandbox = "unelevated"

Then fully exited/restarted Codex Desktop and confirmed the new app/code-mode-host process start time. The cold call was still 28.624 s, so this variant is not eliminated by the elevated/unelevated switch.

  1. The actual PowerShell command consistently takes only ~0.06–0.25 s.
  1. A non-shell patch/tool operation also showed the same ~28.2–28.4 s cold delay, suggesting the delay may be in the desktop code-mode/tool-host lifecycle or shared runner transport rather than in PowerShell itself.

Observed pattern

This is not necessarily only the first tool call ever in a conversation. It appears on the first call of a newly cold/recycled tool-host lifecycle; multiple operations issued continuously afterward are fast.

The stable ~28.6 s delay looks compatible with two ~15 s runner/pipe readiness windows or a timeout followed by a successful fallback/retry. Expected behavior is for the first harmless local tool call to complete in roughly the same sub-second range as warm calls, or to fail fast with a phase-specific diagnostic.

naipi11 · 9 days ago

If 0.147.0 Windows sandbox times out on spawn_ready while danger-full-access works, treat it as a runner-start stall, not a bad command.

Method:

  1. Pin CLI to 0.146.1 (the timeout is 0.147.0-specific) and retry the same workspace-write command.
  2. If you must stay on 0.147.0, exclude %USERPROFILE%\.codex\.sandbox-bin from Defender / AV real-time scanning, then retry.
  3. Read today's %USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log to see whether setup finished and which phase hung.
  4. Use danger-full-access only as a temporary bypass, not as the fix.

Evidence: the timeout fires after the client has already created the runner. 0.146.x users report a complete setup + pwd success; 0.147.0 local sessions hang before spawn_ready.

Independent community workaround; not an official OpenAI fix.