codex.exe crashes with STATUS_STACK_BUFFER_OVERRUN (0xc0000409) on Windows 11

Start with the Windows Error Reporting archive and the crash details for codex.exe, then compare them with the session logs under ~/.codex/sessions/. Investigate the reported sandbox permission failure and the mismatched CLI, command runner, and runtime versions. Done means identifying the cause of the STATUS_STACK_BUFFER_OVERRUN and preventing the random crash.

Environment

• OS: Windows 11 Home China 22H2 (build 22621.4317)
• Hardware: HP Spectre, multi-monitor
• Install method: Windows Store (MSIX package)
• Store app version: 26.721.11231.0
• CLI version (version.json): 0.143.0
• Command runner version: 0.146.0-alpha.3.1
• Runtime package version: 26.723.12215
• Model: gpt-5.6-sol, reasoning effort: high
• Proxy: http://127.0.0.1:7890 (Clash-like proxy)

Note: Version components appear out of sync — partial/incomplete auto-update may contribute to instability.

Bug Description

codex.exe crashes randomly during agent sessions with exception code 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN) — a stack buffer overrun detected by Visual C++ /GS compiler security cookie check. The faulting module is codex.exe itself (not an external DLL), at offset 0xd3e12f1.

Today (2026-07-30) it crashed once so far, but Windows Error Reporting (WER) archives show ~254 total crashes of the same type:

• June 15: 2 crashes
• July 16: ~227 crashes — massive instability spike
• July 30: 1 crash (and counting)

The session logs under ~/.codex/sessions/ show "turn_aborted" with reason "interrupted" — the user is forced to manually abort after the CLI becomes unresponsive, not a clean exit.

Crash Details (from Windows Event Log)

Faulting application: codex.exe, version: 0.0.0.0, timestamp: 0x6a62a0c8
Faulting module: codex.exe, version: 0.0.0.0, timestamp: 0x6a62a0c8
Exception code: 0xc0000409
Fault offset: 0x000000000d3e12f1
Process ID: 0x9014

WER report archive: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\

Additional Observations

1. Sandbox permission error (also from today):

   SetFileAttributesW failed: 5 (Access denied) on C:\Users\Default
   

   The sandbox process appears to have partial permission failures.

2. Version mismatch: The stored version.json claims 0.143.0, but the actual command runner binary is 0.146.0-alpha.3.1 and runtime package is 26.723.12215 — suggesting component-level auto-updates are not fully synchronized.

Related

Likely related to the general pattern of random exits reported in #10511, but this issue provides concrete crash telemetry (WER event logs, dumps, exception codes) that may help pinpoint the root cause.