[Windows Desktop 26.803.10989.0] codex-code-mode-host 0xc0000409 crash leaves concurrent exec calls stuck until restart

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.10989.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Codex Desktop for Windows, a crash of codex-code-mode-host.exe left six outstanding code-mode exec calls in unrelated tasks pending indefinitely. The affected tasks continued to appear “in progress” without an error or timeout until the whole Codex app was restarted.

I first observed this with six unrelated tasks using tools concurrently. All six stopped making progress at tool calls. Restarting Codex recovered the tasks. The same host crash fingerprint recurred later during the diagnostic session while a small read-only exec call was running. That call returned:

code-mode host closed its stdout

Windows recorded the same native crash fingerprint for both occurrences on the current app build:

Faulting application: codex-code-mode-host.exe
Faulting module:      ntdll.dll
Exception code:       0xc0000409
Fault offset:         0x000000000013a375
WER report bucket:    0f934d2d574646e44c274226f283d7dc

0xc0000409 is a Windows fail-fast exception. It does not by itself establish a stack-buffer-overflow root cause; Microsoft notes that applications also use this fail-fast code for other unrecoverable conditions: https://learn.microsoft.com/en-us/shows/inside/c0000409

Evidence connecting the unresolved task calls to the host exit:

• The six affected session transcripts each end at an outbound custom_tool_call named exec, with no matching custom_tool_call_output before the app restart.
• The nested operations span both shell_command and apply_patch in unrelated tasks, so this was not isolated to one command, workspace, or tool implementation.
• The first host crash was recorded at 2026-08-12 22:17:29.357 UTC+08:00 (14:17:29.357Z). The desktop app server answered requests at 22:46:56 while the six affected calls were still unresolved, shortly before the user restarted the app.
• During diagnosis, another host crash recurred at 2026-08-12 22:57:50 UTC+08:00 (14:57:50Z) while a small read-only exec was running. The outer call returned code-mode host closed its stdout, and Windows simultaneously recorded the identical application, module, exception code, fault offset, and WER bucket. The host process then restarted automatically about seven seconds later.
• No Windows System resource-exhaustion event was recorded between 22:00 and 23:00 local time.

The crash is therefore directly observed and recurrent on this machine. The exact native trigger is still unknown. I cannot attribute it to any one command: one call that began 227 ms before the first recorded crash still returned after the crash, while six unrelated outstanding calls remained unresolved.

What steps can reproduce the bug?

The native crash is intermittent; I do not yet have a deterministic minimal trigger. The observed sequence is:

1. Open several unrelated Codex Desktop tasks and let them run tool calls concurrently (six tasks were active in the original incident).
2. Continue normal work involving shell_command and apply_patch through code-mode exec.
3. When codex-code-mode-host.exe terminates, observe that the affected calls remain “running” indefinitely rather than failing.
4. Restart the entire Codex app. The orphaned tasks become usable again.
5. In the later diagnostic occurrence, the same host process terminated while a small read-only exec was running. The call surfaced code-mode host closed its stdout, and a replacement host started automatically about seven seconds later. In the original incident, however, the six unresolved calls did not leave the running state before the full app restart.

I found two minidumps for the current-build crashes in the Windows user CrashDumps directory. Session IDs, full transcripts, local paths, prompts, and dumps are intentionally omitted from this public report because they may contain private project data. I can provide redacted event records or arrange a private dump transfer if maintainers provide a secure channel.

What is the expected behavior?

When the code-mode host exits, the app should promptly reject all still-unresolved requests that can no longer receive a response from it and move the corresponding tasks out of the running state with an actionable error. It should then restart the host without requiring a full app restart.

For potentially side-effectful operations, the app should not silently replay an orphaned request. If completion cannot be determined, it should report that execution state is unknown so the user can reconcile filesystem or external effects before retrying.

Additional information

• Installed package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Windows Application log contains nine codex-code-mode-host.exe crashes in the last 30 days. Four share the exact ntdll.dll / 0xc0000409 / 0x13a375 signature, on 2026-08-06, 2026-08-08, and twice on 2026-08-12. This exact family spans at least app builds 26.730.8199.0, 26.803.5235.0, and 26.803.10989.0.
• Other historical host crashes on this machine used 0xc0000005 or 0xc0000374; I am not claiming that those have the same root cause without symbols or dump analysis.

Related reports reviewed before filing:

• #38190 reports an apply_patch hang on the same app build, but shell I/O remains healthy there and no matching WER host crash is reported.
• #37694 reports a code-mode host crash after extreme image-history memory growth, with a different 0x80000003 signature.
• #36096 records codex.exe as the faulting application and module.
• #37164 reports codex.exe fast-fails in earlier WER records and attributes newer Crashpad dumps to a likely Electron utility process. Neither report contains this codex-code-mode-host.exe fingerprint plus unresolved concurrent calls.

I did not find an existing report with this combination of a repeatable host crash fingerprint and failure to reject all outstanding requests after the host exits.