Codex Desktop app-server repeatedly crashes during plugin/list with bogus 372 GiB allocation and heap corruption

Resolved 💬 2 comments Opened Jul 11, 2026 by dingjianhui123-create Closed Jul 11, 2026

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:

  1. Launch Codex Desktop.
  2. Open or resume an existing long-running task.
  3. The bundled app-server initializes plugins, Apps/MCP resources, thread state, model/WebSocket warmup, and remote-control recovery.
  4. Within seconds or minutes, the app-server reports a fatal allocation error or crashes with heap corruption.
  5. 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_apps resource 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+0xcc24cf1 offset and same failure hash.
  • The unexpected heap exception is detected in RtlFreeHeap, with the remaining stack returning into codex.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

  1. Symbolicate the dumps for this exact build, especially codex+0xcc24cf1 and codex+0x962b40.
  2. Audit length/capacity conversion and allocation bounds in plugin/App/MCP catalog parsing.
  3. Audit resource pagination and manifest serialization/deserialization.
  4. Audit ownership and cancellation during app-server restart and thread/resume recovery.
  5. Check concurrency between plugin/list, app/list, thread/resume, MCP initialization, and remote-control reconnect.
  6. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗