›_ Codex Issues
Codex Issues / #36096

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

Open 💬 2 comments Opened Jul 30, 2026 by zyl423
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

  1. 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 29 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35179

Powered by Codex Action

zyl423 · 29 days ago

Thank you for flagging #35179. I've reviewed it and while it's the same crash (codex.exe, exception 0xc0000409, Store version 26.721), I believe this report adds complementary diagnostic data worth keeping separate:

What #35179 contributes

  • Strong evidence that excessive memory consumption (17.2 GB observed when restoring a thread with ~100 PNG files) can trigger the stack buffer overrun
  • Confirmation it also affects Remote SSH setups since late July

What this report (#36096) adds

  • Long-term WER crash history: ~254 crashes logged in Windows Error Reporting since June, with a massive spike of ~227 on July 16 alone. This shows the bug is not isolated to heavy image threads — it happens during routine agent sessions too.
  • Version component mismatch: version.json reports 0.143.0, command runner is 0.146.0-alpha.3.1, runtime is 26.723.12215. Partial auto-update desync may be a contributing factor.
  • Sandbox permission errors: SetFileAttributesW failed on C:\Users\Default observed alongside the crashes.

Hypothesis

The 0xc0000409 stack buffer overrun likely occurs when Codex hits an internal memory allocation failure path. In #35179 it's triggered by 17 GB of image data; here it's happening under normal agent workloads. The version mismatch might be exacerbating memory management bugs already present in 26.721.

Happy to close or merge if the maintainers prefer — just want to make sure the WER telemetry and version inconsistency data aren't lost.