AgentFixFind a fix
CodexOpen issueUpdated Aug 20, 2026

Codex times out waiting for runner spawn_ready

Diagnose the open Codex Windows sandbox error timed out after 15000ms waiting for runner spawn_ready without confusing it with later pipe or token failures.

Exact error

Match the message before using the fix

windows sandbox: timed out after 15000ms waiting for runner spawn_ready

Quick answer

Start here

There is no confirmed permanent fix yet. Match `waiting for runner spawn_ready` exactly, because pipe-input, `CreateProcessAsUserW`, and token errors occur at different phases. Confirm the versioned command-runner file exists, retry a harmless command in a fresh local session, and use broader execution permissions only as a one-command diagnostic if you knowingly accept the risk—not as the permanent setup.

Diagnosis

Why it happens

  • The sandbox setup reached the phase where Codex waits for its runner process, but the runner did not signal readiness within 15 seconds.
  • The source report confirms the version-matched runner binary was present, so a missing helper is not the only possible cause.
  • No maintainer-confirmed root cause or fixed version was available when this page was checked.

Safest first

Fixes, in order

01

Match the timeout phase exactly

Applies when: Before following any Windows sandbox workaround

Similar-looking errors after runner startup need different diagnosis.

  1. Copy the complete sandbox error.
  2. Confirm it says `waiting for runner spawn_ready` and `15000ms`.
  3. If it instead mentions pipe input, `CreateProcessAsUserW`, `SetTokenInformation`, or a missing helper, use the matching error page.
  4. Record Codex CLI/app version and Windows build.

Expected: The failure is identified as the runner-readiness phase, not a different sandbox error family.

02

Check the versioned runner without deleting sandbox files

Applies when: The exact spawn_ready timeout on a local Windows session

The upstream reproduction found the runner present; checking it distinguishes this issue from a packaging failure without destructive cleanup.

  1. Close stale Codex sessions and open a fresh local PowerShell window.
  2. Inspect `%USERPROFILE%\.codex\.sandbox-bin` for a `codex-command-runner` executable matching the installed Codex version.
  3. Do not download a runner from an unofficial source or delete the sandbox directory.
  4. Retry one harmless read-only command with the normal sandbox enabled.

Expected: You know whether the runner is present and whether the timeout reproduces in a clean local session.

03

Use broader execution only as a controlled diagnostic

Applies when: Optional test when you understand the command and can accept the loss of sandbox protection

The reporter observed that danger-full-access bypassed the failure. That isolates the Windows sandbox path but does not repair it.

  1. Choose a harmless command that reads no secrets and makes no changes.
  2. Run that one command outside the sandbox only if your Codex client presents and you accept the permission escalation.
  3. Return to normal sandbox settings immediately afterward.
  4. Report whether normal mode times out while the controlled diagnostic runs.

Expected: The comparison identifies the Windows sandbox runner as the failing boundary without treating unrestricted execution as the fix.

Verification

Prove the fix worked

  1. A real fix is verified only when a new local session runs the harmless command with the normal sandbox enabled.
  2. Repeat once after closing and reopening Codex.
  3. Confirm the result does not depend on danger-full-access or another permanent permission reduction.

Escalation

If it still fails

  • Keep the exact phase string, Codex version, Windows build, shell, local versus SSH/RDP context, and runner filename.
  • Check Windows security or event logs for a blocked child process without changing exclusions broadly.
  • Track the open upstream issue for maintainer diagnosis and a fixed version.

Scope

Environment and version notes

  • The source report used Codex CLI 0.147.0 on Windows 11 Home in both PowerShell and Git Bash.
  • The report remained open with no confirmed permanent fix when checked.
  • Sources rechecked August 20, 2026.

Evidence

Sources

Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.