codex-cli 0.104.0 on Windows 10 exhibits unbounded memory commit growth when idle (reaches ~90GB, causes system OOM)

[slbidd]

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 bytes

Expected 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.

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.

[etraut-openai]

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.

[slbidd]

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.

[darlingm]

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.toml to 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.

[slbidd]

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 to see if it solves the issue:config.toml

[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.

[vincentkoc]

Possible related direction: #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.

[yassirusa]

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"