[Windows] Codex exhausts commit memory, freezes the OS, and repeatedly crashes with 0xc0000409

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

Microsoft Store package OpenAI.Codex 26.810.4967.0 (ChatGPT.exe file version 151.0.7922.137). The same codex.exe crash signature also occurred on package versions 26.803.10989.0, 26.803.8161.0, 26.803.5235.0, and 26.730.8199.0.

What subscription do you have?

ChatGPT Pro (local authentication reports plan type: prolite)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop progressively consumes commit/virtual memory until Windows records a low-virtual-memory condition. The entire PC then lags or locks up: mouse/input and window operations stall, the ChatGPT shell hangs, codex.exe crashes, and the machine can require a forced reboot.

This is not only a subjective UI slowdown. Windows Resource Exhaustion Detector event ID 2004 directly attributed the largest allocations to Codex:

• 2026-08-14 15:59: codex.exe used 6,067,736,576 bytes and ChatGPT.exe used 3,387,764,736 bytes.
• 2026-08-14 16:08: codex.exe used 5,698,453,504 bytes and ChatGPT.exe used 3,132,710,912 bytes.
• 2026-08-14 09:31: ChatGPT.exe used 5,355,786,240 bytes and codex.exe used 5,184,335,872 bytes.
• 2026-08-14 11:28: ChatGPT.exe used 2,735,767,552 bytes, codex.exe used 2,617,253,888 bytes, and a Codex-started Python workload used 1,604,128,768 bytes.

Windows also recorded repeated Application Error event ID 1000 failures for codex.exe:

• Exception code: 0xc0000409
• Exception data: 7
• Faulting module: codex.exe
• On package 26.803.10989.0 the repeated fault offset was 0x000000000ccfa321 and the WER bucket was identical across incidents.
• The same exception family repeated across multiple earlier app builds, with a build-specific offset.

Separately, Windows recorded Application Hang event ID 1002 for ChatGPT.exe at 2026-08-14 16:12 and 2026-08-15 09:28. The severe incidents were followed by Kernel-Power 41 / EventLog 6008 unexpected-shutdown records. No display-driver reset, WHEA hardware error, or storage-timeout event was found in the same diagnostic window.

Fully exiting Codex restores responsiveness when the system is still responsive enough to close it. During a fresh post-relaunch sample the Codex process tree returned to a much smaller baseline, showing that the multi-gigabyte state is accumulated rather than the normal startup footprint.

What steps can reproduce the bug?

1. Start Windows and launch the Microsoft Store Codex Desktop app using the native Windows/PowerShell agent.
2. Open or continue normal local Codex work, particularly long-running threads and multiple threads that use shell/tool activity. Browser, Computer Use, document, PDF, spreadsheet, presentation, and visualization plugins are installed; the configured node_repl MCP is also active.
3. Continue using Codex for an extended session. The problem is progressive and reproduces faster with larger/longer sessions and concurrent local work.
4. Observe increasing system-wide input/UI latency. Eventually Windows becomes severely unresponsive even though the hardware is otherwise capable.
5. Check Event Viewer under Windows Logs > System for Resource Exhaustion Detector event ID 2004. In reproduced incidents, codex.exe and ChatGPT.exe are the leading virtual-memory consumers at roughly 2.5-6.1 GB each.
6. Check Windows Logs > Application. codex.exe repeatedly terminates with event ID 1000 / 0xc0000409; the desktop shell also records event ID 1002 hangs.
7. Fully terminate the Codex/ChatGPT process tree if Windows still responds. Responsiveness improves after the process tree exits. In the worst cases a forced reboot is required.

The failure is not tied to one repository or language. The Windows events show the Codex backend and desktop shell as the principal resource consumers. A Java/JVM process was not running during the diagnostic snapshot, despite Java initially appearing implicated in Task Manager.

What is the expected behavior?

Codex Desktop should keep backend, renderer, helper-process, handle, and commit-memory usage bounded during long-running and multi-threaded work.

Completed or inactive work should release resources. Local logs and rollout/session data should be rotated or compacted without loading multi-gigabyte state into memory. The app should remain responsive, should not interfere with Windows input/UI responsiveness, and should never drive the host into low-virtual-memory conditions or an unclean reboot.

If an individual task or helper fails, Codex should terminate/reap it and surface a recoverable error instead of crashing codex.exe with 0xc0000409.

Additional information

Hardware and commit configuration

• CPU: Intel Core i5-10400F, 6 cores / 12 logical processors
• GPU: NVIDIA GeForce RTX 3060 Ti, driver 32.0.15.9186
• RAM: 15.85 GB
• System volume: 464.79 GB total, 66.75 GB free during diagnostics
• Page file: fixed 10,000 MB; total Windows commit limit approximately 25.61 GB; automatic page-file management is disabled

The fixed page file can make a leak reach the commit limit sooner, but Codex/ChatGPT consuming several gigabytes each is still abnormal, and related reports reproduce the system-wide stutter on machines with substantially more RAM.

Codex local-state findings

• %USERPROFILE%\.codex\logs_2.sqlite is 1,184,866,304 bytes.
• It contains about 158,225 retained rows, but SQLite reports 289,274 pages with 225,264 pages on the freelist (about 880 MiB of unused pages inside the file).
• Retained log bodies total about 143.7 MB and estimated log bytes total about 158.2 MB, so the physical database is heavily bloated.
• Individual HTTP transport TRACE records reached 7,260,118 bytes.
• Persisted rollout/session JSONL files include one over 1.0 GB and several around 799 MB. Loading or reconstructing large sessions may be relevant to the memory growth.
• Codex crash dumps exist for the 2026-08-11 and 2026-08-14 failures. Sanitized dump metadata or private artifacts can be provided if maintainers request them.

Raw SQLite databases, session files, and dumps are not attached publicly because they can contain prompts, source code, local paths, and credentials.

Potentially related reports:

• https://github.com/openai/codex/issues/38723
• https://github.com/openai/codex/issues/38750
• https://github.com/openai/codex/issues/38546
• https://github.com/openai/codex/issues/33368
• https://github.com/openai/codex/issues/29436
• https://github.com/openai/codex/issues/28855

This report adds OS-confirmed low-virtual-memory attribution, a repeated deterministic codex.exe crash signature, unexpected-reboot correlation, and detailed SQLite/session-size evidence.

Start by examining the %USERPROFILE%\.codex\logs_2.sqlite findings and persisted rollout/session JSONL files, then correlate their sizes with Windows Resource Exhaustion event 2004 and the repeated codex.exe event 1000 crashes. Crash dumps from 2026-08-11 and 2026-08-14 may provide further evidence if maintainers request them. Done means long-running and multi-threaded work keeps memory bounded, releases inactive state, and avoids hangs or 0xc0000409 crashes.