CreateProcessAsUserW failed: 1920

Environment

• Platform: Windows
• Codex CLI: sandbox mode enabled
• Version: 0.142.0-alpha.6

Summary

Shell execution via the sandbox intermittently fails with:

CreateProcessAsUserW failed: 1920

The session does not crash and remains usable. Some shell commands succeed while others fail in the same session. Using require_escalated usually succeeds.

Observed behavior

1. 1920 is intermittent. Example from a single session:

• 07:08 — 1920
• 07:10 — probe succeeds (echo returns normally)
• 07:10 — another command → 1920 again

The sandbox is not completely broken; specific invocation instances hit the error while others succeed concurrently.

1. The session continues working. apply_patch still works, the tool router stays alive, and the conversation continues. Only shell_command via the normal sandbox path fails intermittently.

1. Starting a new session usually restores normal behavior. Restarting only the Codex UI (without killing the codex.exe app-server process) does not help — the 1920 error persisted until the app-server process was fully terminated and recreated.

1. require_escalated bypasses the failure. Commands that fail via the normal sandbox path succeed when escalated, confirming that two different execution paths exist and only the sandbox path is affected.

1. Numerous orphan codex-command-runner processes accumulate. On one occasion we observed:

• ~80 codex-command-runner-0.142.0-alpha.6.exe processes running simultaneously
• Of those, 27 were orphaned (parent processes had exited, some from 3-5 days earlier)
• The total count grows across sessions and is not cleaned up

Additional observations

Observed:

• Runner processes accumulate over time.
• Some become orphaned when their parent exits without cleaning them up.
• The number increases across sessions and persists after sessions end.

Hypothesis (not confirmed):

• Stale runner instances may remain in the runner pool.
• If task routing occasionally targets an unhealthy runner, CreateProcessAsUserW may fail while other runners continue working normally.
• This is only a hypothesis. We have no evidence that named pipes, ALPC, WNF, or other Windows kernel resources are the direct cause.

Reproduction

Unknown. The issue appears after long-running usage across multiple sessions. We have not found a deterministic reproduction path.

Logs

2026-07-02T07:12:58.299Z ERROR codex_core::exec
  → "exec error: windows sandbox: runner error: CreateProcessAsUserW failed: 1920"

2026-07-02T07:12:58.300Z ERROR codex_core::tools::router
  → "execution error: Io(Custom { kind: Other, error: \"windows sandbox: runner error: CreateProcessAsUserW failed: 1920\" })"

2026-07-04T07:08:18.783Z ERROR codex_core::exec
  → "exec error: windows sandbox: runner error: CreateProcessAsUserW failed: 1920"

The error propagates from codex_core::exec through codex_core::tools::router, wrapping the runner's CreateProcessAsUserW failure into an Io(Custom { ... }) error.

Summary of confidence levels

Confirmed:

• CreateProcessAsUserW failed: 1920 occurs intermittently in the Windows sandbox.
• Success and failure can coexist within the same session.
• The session does not crash; non-shell tools continue working.
• require_escalated bypasses the issue.
• codex-command-runner processes accumulate across sessions, many becoming orphaned.

Likely:

• The sandbox runner or sandbox runtime lifecycle management has a defect.

Hypothesis (unconfirmed):

• Orphaned runners are related to 1920.
• The scheduler may occasionally route to an unhealthy runner instance.