Windows ChatGPT/Codex process consumes 50+ GB and crashes
What version of the Codex App are you using (From “About Codex” dialog)?
26.818.41509
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Windows ChatGPT desktop app’s bundled codex.exe process rapidly consumes memory during ordinary local project use. Memory is not released, the application becomes unresponsive, and Windows eventually reports resource exhaustion or the application crashes.
Observed memory usage:
codex.exe starts at approximately 100 MB.
It then grows into multiple gigabytes.
On the current updated build, it reached approximately 15.1 GB.
On the previous build, Windows recorded approximately 52.4 GB, 53.3 GB, and 55.0 GB of virtual-memory consumption by codex.exe immediately before hangs or crashes.
Crash information:
Exception code: 0xc0000409
Fault offset: 0x000000000cec59e1
Windows Error Reporting event type: MoBEX
Two separate crashes had the same exception code and fault offset.
What steps can reproduce the bug?
Feedback ID: 01a02642-f04f-7450-bebc-f2fc9838fffb
What is the expected behavior?
codex.exe memory usage should remain within a reasonable, stable range during normal project work. Memory used for completed operations or conversation processing should be released or reused.
The desktop app should remain responsive and should not consume tens of gigabytes of memory, exhaust Windows resources, or crash. Long-running conversations and large local projects should not cause unbounded memory growth.
Additional information
Affected builds:
Previous package: OpenAI.Codex 26.818.4152.0
Current updated package: OpenAI.Codex 26.818.5229.0
Current ChatGPT.exe file version: 151.0.7922.170
Events recorded on 22 August 2026, Pacific/Auckland time:
Windows Resource Exhaustion Detector events at approximately 09:00:38, 09:21:39, and 09:39:54.
Application crashes at approximately 09:21:39 and 09:39:59.
An application hang occurred at approximately 09:33.
Windows Error Reporting IDs:
Crash: 3d0b3add-e434-4fc4-a9eb-8908a821ba59
Crash: 88162fd9-23b7-435a-bb00-fa8ef220f8b3
Hang: 7b434295-f9f8-4748-8578-b3b94bd89e24
vmmemWSL was using approximately 4–5 GB during the resource-exhaustion events, but codex.exe was recorded as using approximately 52–55 GB and was the dominant consumer.
I can provide a controlled memory-growth trace or relevant Windows Error Reporting files if required. I have not attached a raw process dump because it contains sensitive project or conversation data.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Controlled reproduction on 23 August 2026:
No prompt or command was submitted in the affected conversation. Merely opening the conversation triggered continuous memory growth.
The affected conversation was then closed to prevent system failure. The original codex.exe process, PID 1920, ended and was replaced by PID 17740. The replacement process remained stable at approximately 85–87 MB, with system available memory recovering to approximately 10.8–11.2 GB.
This demonstrates that loading the specific stored conversation is sufficient to trigger the runaway allocation. No Azure, Docker, build, test, or terminal operation was performed in that conversation during the reproduction.
Saw the 52GB peak and 0xc0000409 crash, I've been through a similar runaway on Windows and the fail-fast is usually the process hitting the memory ceiling rather than a logic bug. The 407MB -> 19.5GB growth from just opening one stored conversation points at that specific session's state being rebuilt in memory, so dont reopen that conversation, archive or delete it, and fresh sessions should stay around 85MB. Newer builds already halved your peak, so retest on the newest one, and if it still blows up, grab the WER payload from C:\ProgramData\Microsoft\Windows\WER\ReportArchive plus the CrashDumps folder, that gives maintainers the stack without a huge raw dump. There are also two dupes already flagged (#38765, #39670), worth checking if yours is the same regression.
Thanks—this is directionally consistent with what I observed. One technical qualification: 0xc0000409 is a Windows fail-fast exception and does not, by itself, establish that the process hit the memory ceiling. The Windows Resource Exhaustion Detector events and the 52–55 GB readings confirm that severe memory exhaustion occurred, but the fail-fast subcode or a dump would be needed to establish the immediate crash cause.
I have now found an apparent mitigation. Before archiving, a controlled check went from approximately 407 MB to 19.5 GB simply by opening the related stored conversation. I then archived that long conversation, restarted Codex, and continued in a fresh task. The runaway growth has not recurred so far.
That makes loading or resuming the long conversation a strong trigger, but I do not yet consider it the confirmed root cause or a permanent fix. I will keep the conversation archived rather than delete it or manually alter .codex state, so the evidence remains available.
The lower peak on build 26.818.5229.0 is encouraging, but 19.5 GB is still abnormal and the comparison does not prove that the newer build fixed or halved the problem.
#38765 appears closely related and has the same 0xc0000409 crash family. #39670 is another similar report, although GitHub does not currently show either as a formal duplicate of this issue.
Additional confirmation on a newer Codex Desktop build (26.818.8289.0):
The approximately 105.2 GiB-to-157.8 MiB reset is consistent with unbounded retained state rather than a fixed startup cost. This is a critical normal-use blocker and can exhaust system commit. Please add task/session-level memory attribution and a protective ceiling that stops one runaway task before Windows-wide exhaustion.
I intentionally omitted prompts, source code, account identifiers, session IDs, and full local paths. Additional redacted event data can be provided if useful.