codex-cli 0.104.0 on Windows 10 exhibits unbounded memory commit growth when idle (reaches ~90GB, causes system OOM)
What version of Codex CLI is running?
codex-cli 0.104.0
What subscription do you have?
ChatGPT Team
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Command Prompt (cmd.exe)
What issue are you seeing?
Description
Running codex natively on Windows 10 Pro 64-bit results in persistent and unbounded virtual memory growth, even when no input or interaction occurs.
Over several hours, the codex.exe process continuously increases its committed memory usage until system commit limits are exhausted (approximately 90GB+). This leads to system-wide resource exhaustion and eventual system hang.
The behavior occurs with the Windows sandbox explicitly disabled:
experimental_windows_sandbox = false
No prompts, tasks, or indexing operations were performed. The CLI was left idle.
This strongly suggests a memory leak or unbounded allocation loop occurring while idle.
Environment
- OS: Windows 10 Pro 64-bit (10.0.19045.0)
- CLI: 0.104.0
- Model: gpt-5.3-codex
- Sandbox: disabled
- Shell: cmd.exe
- RAM: 32GB
Steps to Reproduce
Install Codex CLI 0.104.0 on Windows
Configure with sandbox disabled:
experimental_windows_sandbox = false
Run codex in CMD
Do not interact
Leave system idle for several hours
Actual Result
codex.exe committed memory grows continuously
Eventually reaches ~90GB+
Windows reports virtual memory exhaustion
System services begin failing:
Windows Error Reporting stops
Event Log service stops
DHCP services terminate
TLS fatal error 10013 appears
Pagefile too small error reported
System becomes unresponsive (black screen)
Forced power-off required
Kernel-Power unexpected shutdown logged on reboot
Windows diagnostic message:
Windows successfully diagnosed a low virtual memory condition.
The following programs consumed most of the virtual memory:
codex.exe (...) used 99570417664 bytesExpected Behavior
When idle, Codex CLI should maintain a stable memory footprint.
Memory usage should not grow continuously without interaction, and should never exhaust system commit limits or cause system instability.
Additional Context
Windows sandbox was explicitly disabled.
No heavy scanning, indexing, or long-running operations were executed.
CLI remained idle the entire time.
The issue appears consistent with a memory leak or unbounded resource allocation.
The scale of commit growth (~90GB) caused full system resource exhaustion.
<img width="1532" height="1141" alt="Image" src="https://github.com/user-attachments/assets/76b871b0-2864-4783-8f8f-6b42384b83de" />
<img width="2560" height="1390" alt="Image" src="https://github.com/user-attachments/assets/c149391e-c6ea-492e-91d5-e62e1ad93710" />
What steps can reproduce the bug?
Install codex-cli 0.104.0 on Windows 10 (10.0.19045.0 x64).
Configure experimental_windows_sandbox = false.
Open Windows Command Prompt (cmd.exe).
Run codex.
Do not execute any prompts or commands.
Leave the process idle for several hours.
Result: codex.exe committed memory grows continuously until it exhausts system commit limits (~90GB), leading to system instability and forced reboot.
What is the expected behavior?
When idle, codex-cli should maintain a stable memory footprint.
Memory usage should not grow continuously without user interaction, and it should never exhaust system commit limits or cause system-wide instability.
Additional information
Windows sandbox was explicitly disabled.
No indexing, scanning, or long-running operations were executed.
The CLI remained completely idle.
Memory growth occurred in commit size, not just working set.
The issue led to system-level resource exhaustion (TLS errors, pagefile exhaustion, service termination).
codex.exe reached approximately 99GB committed memory before failure.
The issue occurs even when codex is left completely idle without any prompt execution.
8 Comments
Thanks for the bug report. You mentioned 0.104.0 multiple times in your report. Do you suspect that this is a regression in the latest build? We haven't received any previous reports of this behavior in the CLI. If you are able to repro this consistently with 0.104.0, could you see if you can likewise repro it with the previous version? If we have a clear indication that it's a regression, that would increase the priority to fix it.
Thank you for the response.
I will attempt to reproduce the issue in a controlled manner and compare the behavior between 0.104.0 and the previous version.
If I can reproduce it consistently and confirm whether this is a regression, I will report back here with detailed findings.
This is a bit of a shot in the dark since it's cross platform, and v0.104.0 is less severe than a few versions ago, but it's easy to try and check! Try adding this to your
config.tomlto see if it solves the issue:[tui]
animations = false
When you say "Do not execute any prompts or commands," I don't know if you mean during the idle period or if your problem happens with a fresh Codex instance before your first prompt. If the latter, you may not have animations on the screen and then this wouldn't do anything.
Codex animations, running in Linux with tmux, currently have a memory leak problem. A few versions ago, a single blinking dot on the screen was eating up 20GB per Codex instance over 2-3 days. See #11877 and #11857. A Codex update happened to shut down the blinking dot bug and left the current memory leak less severe at about 10 KB/s while animations are running. But, I figure it's easy for you to see if animations are the cause of your issue too.
Codex currently redraws an extreme amount of characters around animations that don't need to be. If the terminal or its scrollback captures all of this, it can eat up a lot of memory.
In that issue, I link to a branch of mine that has 5 commits that increasingly make the animation output more efficient. The first commit completely solves the memory exhaustion bug for me, again on Linux with tmux.
Thank you for the suggestion.
Here is some additional context about the incident:
At the time the issue occurred, I had opened a fresh Codex interface and did not enter any prompts or execute any commands. The next morning, I noticed other applications had run out of memory. When I opened Task Manager and took a screenshot, the system quickly became unresponsive and required a forced reboot.
The system had been running continuously for approximately three to four days, and this was not the first time Codex had been started during that uptime. Although the visible interface was new and idle, it is possible that some background state or subprocess from earlier activity was still present.
According to the Windows Resource-Exhaustion-Detector event logs, the majority of committed memory (~90GB+) was attributed to codex.exe, not cmd.exe or any terminal process. This makes it unlikely that the issue was caused by terminal scrollback or animation output alone.
I attempted to reproduce the issue after a fresh system restart but have not been able to trigger it immediately. The original incident appears to have occurred in a longer-running system state, so it may depend on extended uptime or prior Codex activity.
I will try disabling TUI animations as suggested and continue testing under conditions closer to the original environment. If I can reproduce the behavior consistently or determine whether animations are related, I will report back with detailed findings.
Possible related direction: https://github.com/openai/codex/pull/12505
That draft targets retained app-server thread/listener memory and archive-state teardown paths (feature-gated, default off), which may overlap with some long-running memory growth reports.
When will this be worked on. Codex-5.3 and codex-5.3-spark are completely useless and they keep churning tokens without editing any code until they "run out of room"
Are you saying this only happens with gpt-5.3-codex and gpt-5.3-codex-spark? Does it not happen with gpt-5.4?
To be clear, I'm a regular user, but my opinion on your question is probably not anytime soon. It just doesn't seem to be affecting enough people, and niche issues like that often sit for a very long time, even if they make Codex unusable for the people unaffected.
In fairness, the Codex team did say it was looking for if this is a regression that can be shown was introduced in some version and didn't always happen. No one has gone back and ran previous versions to show this yet. Unless it triggers often for someone, it could be hard to determine. This makes it a lot harder to investigate for both users and the Codex team.
Realistically, your best option may be to
git cloneCodex, and ask Codex to use the latest released version (or the most recent commit if you want to live more dangerously) and diagnose and patch the problem locally, then ask it to merge those changes with future releases. Another option would be to try PR #12505 and see if it fixes it for you. I don't run the released Codex anymore. I run a locally built one with changes and fixes that I want. I think a ton of people have to do this now.Unfortunately, if #12505 fixes it or if you make your own fix, it's unlikely to wind up in Codex. The team has said that reviewing outside PRs took longer than just fixing issues internally, so they no longer accept outside PRs and just close them without review.
I say this as someone who genuinely loves Codex. I'm not trying to slam it. I get the scaling issues they're having. I'm just trying to set realistic expectations for you.
Hello, I am persistently seeing a similar issue. My "committed memory" consistently climbs to ~100 GB (near its maximum amount) despite codex only using ~500 MB. Asking codex itself to diagnose the issue it says: