Codex Desktop app-server repeatedly crashes during plugin/list with bogus 372 GiB allocation and heap corruption
What happened?
Codex Desktop for Windows repeatedly crashes and restarts its bundled codex.exe app-server 0.144.0-alpha.4, sometimes followed by termination of the entire Desktop/AppX container.
The most actionable failure logged by Desktop is:
Codex CLI process exited classifiedAsExpected=false code=3221226505
Most recent error: memory allocation of 399431958765 bytes failed
3221226505 is 0xC0000409. The requested allocation is about 372 GiB, while the dump shows an actual process commit peak of only 689 MB. This is not normal physical-memory exhaustion.
The same fatal-exit signature reproduced again at 15:29 local time with the exact same:
- fault offset:
codex+0xcc24cf1 - bucket:
FAIL_FAST_FATAL_APP_EXIT_c0000409_codex.exe!Unknown - failure hash:
{de980cc6-e79f-2a5a-de3a-58ef8955356d} - commit peak: 689 MB
A separate app-server crash at 15:11 was detected by the Windows heap manager in RtlFreeHeap:
- exception:
0xC0000409 - fast-fail:
FAST_FAIL_UNEXPECTED_HEAP_EXCEPTION - bucket:
FAIL_FAST_UNEXPECTED_HEAP_EXCEPTION_c0000409_codex.exe!Unknown - commit peak: 737 MB
- process uptime: 12 seconds
There are also multiple Desktop/AppX container exits with no Application Error, WER report, Crashpad dump, or exit code.
Environment
- Codex Windows package:
OpenAI.Codex 26.707.3748.0, X64 - Bundled app-server:
0.144.0-alpha.4 - Desktop client version reported in app-server requests:
26.707.31428 - Chromium/Crashpad annotation:
150.0.7871.101 - Windows 11 Pro 25H2, build
26200.8737, 64-bit - CPU: Intel Core i9-14900KF
- RAM: 31.8 GiB visible
- 12 configured plugins are enabled, all from OpenAI bundled, curated, or primary-runtime packages
What steps can reproduce the bug?
The issue is intermittent but currently very frequent:
- Launch Codex Desktop.
- Open or resume an existing long-running task.
- The bundled app-server initializes plugins, Apps/MCP resources, thread state, model/WebSocket warmup, and remote-control recovery.
- Within seconds or minutes, the app-server reports a fatal allocation error or crashes with heap corruption.
- Desktop attempts to restart the app-server. It may enter an error/restart loop or the entire AppX container may terminate.
Parallel agents and tool-heavy activity increase the trigger rate, but the same issue also reproduces after sub-agents are stopped.
Relevant crash timeline
| Local time (UTC+8) | Component | Result |
|---|---|---|
| 12:08:56 | codex-code-mode-host.exe | 0xC0000005, invalid pointer write to 0x48 |
| 12:14:44 | Desktop UI | Application Hang 1002, top-level window idle |
| 12:28:00 | codex.exe app-server | 0xC0000374, heap corruption; auto-restarted |
| 13:03:11 | Desktop/AppX | Silent container termination |
| 13:35:10 | Desktop/AppX | Silent container termination |
| 13:48:07 | Desktop/AppX | Silent container termination after sub-agents were stopped |
| 13:57:45 | Desktop/AppX | Silent container termination |
| 14:53:02-03 | codex.exe app-server | Bogus ~372 GiB allocation, 0xC0000409, dump created |
| 14:53:08 | Desktop/AppX | Container terminated after app-server restart |
| 15:11:45 | codex.exe app-server | FAST_FAIL_UNEXPECTED_HEAP_EXCEPTION, dump created |
| 15:27:52 | Desktop/AppX | Silent container termination |
| 15:29:38-39 | codex.exe app-server | Exact recurrence of the 14:53 fatal-exit offset/bucket/hash, dump created |
Activity immediately before the crashes
For the 14:53 fatal allocation failure:
- process uptime: 29 seconds
- last incomplete Desktop request:
plugin/list - structured logs are concentrated in
plugin/list,app/list, plugin manifest/marketplace loading, and bundled browser/chrome content
For the exact 15:29 recurrence:
- process uptime: 34 seconds
- last active request:
plugin/list - 1,002 structured-log rows were written in 23 seconds
- plugin/App/resource/manifest initialization was active
For the 15:11 unexpected heap exception:
thread/resume- MCP/Apps initialization
- paginated
codex_appsresource enumeration (cursor offset 86) - model/Responses WebSocket warmup
- remote-control reconnect attempts
- repeated
409 Remote app server already online - one Responses WebSocket TLS handshake EOF
The network errors are context, not a sufficient explanation for heap corruption.
What did you expect to happen?
- Plugin/App/MCP or remote-control failures should return bounded errors and leave Desktop usable.
- Invalid external, cached, manifest, or pagination lengths should be rejected before allocation.
- Restart recovery should cancel previous initialization work and must not corrupt or double-free shared state.
- An app-server failure should not silently terminate the Desktop/AppX container.
Diagnostic findings
- This is not normal out-of-memory behavior: the three newest dumps have commit peaks of 689, 737, and 689 MB.
- The fatal allocation signature reproduced with the same
codex+0xcc24cf1offset and same failure hash. - The unexpected heap exception is detected in
RtlFreeHeap, with the remaining stack returning intocodex.exe. - OpenAI package binaries have valid Authenticode signatures.
- SQLite integrity checks were healthy.
- No aligned WHEA, GPU/display, disk/NTFS, bugcheck, or Kernel-Power event was present in the incident windows.
- Proxy/backend access was not persistently unavailable; many relevant requests completed with HTTP 200.
- No single plugin has been proven faulty. The shared trigger context is app-server plugin/App/MCP catalog initialization and thread-resume recovery.
- OpenAI private symbols are not available locally, so the minidumps identify detection points and trigger context but not the original corrupting source line.
Dump metadata
Raw dumps are not attached publicly because they may contain process memory, local paths, task text, and plugin data. I can provide them through a secure OpenAI support channel if requested.
| File | Size | SHA-256 |
|---|---:|---|
| codex.exe.30456.dmp | 4,216,786 | 43AFAEDAEF29E5C0F6DB6056F1FF1CDFE2E8EE0F91559DA9CABA6012A5E165FB |
| codex.exe.24868.dmp | 4,210,876 | 1DD24515A7A672DD7BA0B9F7B8860CF497E69AB99666EA163607FE15A4A01687 |
| codex.exe.29976.dmp | 4,745,017 | 911776C4DB298F480432E287E0199F2956663A08C0D852F5E43CCA23876A022A |
| codex.exe.644.dmp | 4,495,110 | FED0741F40200A6D85076D1695B5609CC2E245F9ADA57A570D000CD62E1DFAC4 |
| codex-code-mode-host.exe.26108.dmp | 1,169,938 | FD11F7EC7C31F71F0E1CD731BFABA7EEB54344A8F3141120BFC6A2FDBF2F7B6E |
Suggested engineering checks
- Symbolicate the dumps for this exact build, especially
codex+0xcc24cf1andcodex+0x962b40. - Audit length/capacity conversion and allocation bounds in plugin/App/MCP catalog parsing.
- Audit resource pagination and manifest serialization/deserialization.
- Audit ownership and cancellation during app-server restart and
thread/resumerecovery. - Check concurrency between
plugin/list,app/list,thread/resume, MCP initialization, and remote-control reconnect. - Preserve an actionable exit status or dump for silent Desktop/AppX termination.
No plugins, caches, proxy settings, or system configuration were modified while collecting this report.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗