›_ Codex Issues
Codex Issues / #38765

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

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

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:

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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38048
  • #38059
  • #38544
  • #38542

Powered by Codex Action

shleder · 11 days ago

The multi-GB local state in this report is useful as a codex-rescue scale/control case. Rescue won’t fix Desktop commit-memory exhaustion; I’m field-testing whether its rollout discovery and diagnosis stay bounded on the same very large histories without loading/replaying the whole session into an app runtime.

If the large Codex home is still available, could you start with:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

Please stop at diagnosis for the biggest rollout unless you actually need recovery. I’m interested in runtime, exit code, selected session, and whether the source rollout remains unchanged. A healthy result is valid evidence too.

Please share sanitized output only—no raw rollout/log/SQLite files, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

xyl-lyx · 5 days ago

I can reproduce the same failure family on a newer Windows Codex Desktop build.

Environment

  • Microsoft Store package: OpenAI.Codex 26.818.5229.0
  • Bundled CLI: codex-cli 0.149.0-alpha.4.1
  • OS: Windows 11 x64, 10.0.26200
  • Memory: 32 GB installed; Windows currently reports about 27.69 GiB usable
  • Page file: 12,288 MB currently allocated

Repeated crash signature on 2026-08-23

Windows recorded three codex.exe crashes at 11:04:45, 12:23:42, and 13:23:31 local time. All three have the same signature on this build:

  • Application Error event ID 1000
  • Windows Error Reporting event ID 1001 / event name MoBEX
  • Faulting module: codex.exe
  • Exception code: 0xc0000409
  • Exception data / P10: 0000000000000007
  • Fault offset / P8: 000000000cec59e1
  • WER bucket hash: e1b752faaa126945df8ca61c9f9199b9

Windows Resource Exhaustion Detector event ID 2004 directly attributed most committed virtual memory to Codex before two of the crashes:

  • 11:04:41: codex.exe used 33,183,801,344 bytes (about 30.9 GiB)
  • 12:23:43: codex.exe used 30,744,879,104 bytes (about 28.6 GiB)

After restarting the app, the current Codex app-server returned to a baseline of about 0.48 GiB private memory / 0.55 GiB working set. This strongly suggests accumulated memory growth rather than a normal startup footprint.

Large image-heavy rollout evidence

The active local session store currently contains 105 rollout JSONL files totaling about 68.43 GiB.

  • Largest rollout: 39,902,898,277 bytes (37.16 GiB), created by a long-running image-heavy thread.
  • Second-largest rollout: about 14.43 GiB and also image-heavy.

I inspected these with fixed-size sampling only and did not parse or expose any private message content:

  • For the 37.16 GiB rollout, 12 of 16 evenly spaced 4 MiB samples contained no newline, indicating records larger than 4 MiB.
  • 14 of 16 samples contained data:image / base64 markers; 44 data:image markers were observed in the sampled regions.
  • For the 14.43 GiB rollout, all 16 samples contained data:image / base64 markers, and 9 samples contained no newline.

This looks closely related to #34863, where repeated inline PNG data survives compaction and an oversized rollout can require several times its on-disk size when resumed.

Local log database bloat

logs_2.sqlite is currently 1,675,284,480 bytes (about 1.56 GiB):

  • SQLite page size: 4,096 bytes
  • Page count: 409,005
  • Freelist pages: 376,213
  • Freelist bytes: 1,540,968,448 (about 92% of the database)
  • Retained log rows: 104,951
  • Sum of retained estimated_bytes: 79,495,369 bytes

This resembles the local-state bloat reported in this issue.

Trigger and impact

Opening or resuming the oversized image-heavy thread is the clearest observed trigger. During affected sessions, Codex progressively consumes commit memory, the UI becomes unreliable, and codex.exe terminates. The shell can then fall back to a login-looking screen even though restarting the desktop app restores the existing login.

Raw session files, SQLite databases, minidumps, and screenshots are not attached publicly because they may contain prompts, private images, local paths, source data, and credentials. Sanitized WER metadata or privately shared artifacts can be provided if an OpenAI maintainer requests a secure upload channel.

Can maintainers confirm whether the image-compaction behavior from #34863 is expected to be fixed in the Windows app-server, and whether any fix is present after 26.818.5229.0?

Related: https://github.com/openai/codex/issues/34863