[Windows][26.810.7004.0] Codex run drives node.exe to ~55 GB virtual memory and crashes/reboots Windows
What version of the Codex App are you using?
- Codex Desktop:
26.810.7004.0 - Bundled Codex CLI:
0.148.0-alpha.9 - Platform: Windows 11 x64
- Subscription: ChatGPT Pro 200
Summary
Codex Desktop is reproducibly triggering severe system-wide instability on my Windows machine. The strongest incident was captured by Windows Event Viewer: a Codex-started node.exe process grew from ~33.9 GB to ~55.0 GB of virtual memory in about one minute, Windows logged Resource Exhaustion Detector events, and the machine then automatically rebooted after a bugcheck.
This is not a generic unstable-PC issue in my testing: I worked on the same machine for a full day with Codex/ChatGPT Desktop closed and had no instability. The next morning I launched Codex, started two runs, and within ~5 minutes the same failure chain returned.
Reproduction / observed failure chain
- Use the machine normally for a full day with Codex/ChatGPT Desktop closed.
- Result: no freezes, black screens, desktop corruption, or reboot.
- Launch Codex Desktop.
- Start normal Codex work.
- Within minutes, the failure escalates:
- Chrome becomes unresponsive / dark;
- Codex becomes unresponsive / dark;
- the Windows desktop background disappears;
- Windows eventually reboots automatically.
Windows Event Viewer evidence from 2026-08-16
Resource Exhaustion Detector — Event ID 2004
At 11:27:40:
node.exePID10308:33,896,910,848bytes virtual memory- another
node.exePID25312:3,266,023,424bytes explorer.exe:2,889,867,264bytes
At 11:28:40, one minute later:
- the same
node.exePID10308:55,018,573,824bytes virtual memory explorer.exe:2,921,197,568bytescodex.exe:529,600,512bytes
So one node.exe increased from ~33.9 GB to ~55.0 GB in roughly one minute immediately before the system crash/reboot.
System crash / reboot
At 11:30:41:
Kernel-PowerEvent ID41: system restarted without a clean shutdown.
At 11:30:52:
Microsoft-Windows-WER-SystemErrorReportingEvent ID1001- Bugcheck:
0x0000010d - Parameters:
(0x0000000000000005, 0x0000667840b50648, 0x000000000000100a, 0xffff9987baf11c40) - A minidump was written under
C:\WINDOWS\Minidump\...
At 11:30:53:
- Event ID
6008: previous shutdown was unexpected.
Controlled reproduction after restart
I then reproduced the runaway behavior more carefully.
Before starting a run:
- Codex was open and idle;
- no
node.exeornode_repl.exeprocess was present initially; - Browser, Chrome, and Computer Use plugins were disabled;
- the machine was responsive.
After opening the existing run screen (without starting/resuming it), node.exe and node_repl.exe appeared at a small baseline.
After starting one normal Codex run:
node.exePID9132reached about1064 MBprivate memory;- approximately 11 seconds later the same PID was at about
1816.5 MBprivate memory; - multiple
node_replprocesses were also visible; - the run became difficult/impossible to stop from the UI;
- I force-terminated Codex/ChatGPT through Task Manager before Windows reached the same ~55 GB state again.
This happened with only one controlled run and with Browser/Chrome/Computer Use disabled.
Current config/runtime observations
The user config contains one bundled Node REPL MCP entry pointing to Codex's own runtime:
[mcp_servers.node_repl]
command = '...\\OpenAI\\Codex\\runtimes\\cua_node\\...\\bin\\node_repl.exe'
startup_timeout_sec = 120
and its environment points to Codex's bundled node.exe.
A manual enabled = false added under [mcp_servers.node_repl] did not persist: Codex Desktop removed that line again after restart.
codex doctor --summary on the bundled CLI reports:
- 16 OK
- 0 failures
- state databases healthy
- auth/config/network healthy
- 452 active rollout files
- 55.86 GB of active rollout data on disk
Possible amplifier: very large image-heavy rollouts
I am not claiming this is the sole root cause, but the profile also contains extremely large Codex rollout files.
The largest active rollout is 5.64 GB. A read-only scan of that one rollout found:
data:image:1504base64:1607"type":"compacted":75
Several other active rollouts are 3–4.7 GB.
That looks potentially related to #34863 (large image-heavy rollouts / repeated inline PNG data retained across compaction), and may amplify the memory problem when old sessions are opened or resumed.
Expected behavior
- One normal Codex run should not cause a bundled Node process to allocate tens of gigabytes of virtual memory.
- Helper/MCP/runtime processes should have bounded memory and be reaped or reused correctly.
- Disabling Browser/Chrome/Computer Use should not still allow an uncontrolled Node/Node REPL memory explosion during an ordinary coding run.
- Large local rollouts should be loaded/compacted safely without making the entire Windows session unstable.
- A Codex failure should remain recoverable at the application level and must not take down Windows or force an automatic reboot.
Related issues
This looks closely related to:
- #38825 — Windows Codex creates/retains hundreds of duplicate Node/MCP processes during one task
- #38765 — Windows Codex exhausts commit memory, freezes OS, and crashes
- #38754 — stdio MCP servers repeatedly spawned and not reaped within one task
- #38714 —
node_replworkers remain after Code Mode work and correlate with system-wide stalls - #37672 — Windows code-mode host / Node helper explosion;
enabled = falsecan be ineffective - #34863 — oversized image-heavy rollouts and compaction amplification
- #38820 — Windows
26.810.7004.0system-wide performance regression
Additional information / diagnostics available
I can provide sanitized additional diagnostics if maintainers want them, including:
- the Windows minidump metadata;
- additional Event Viewer output;
- process/memory screenshots from the controlled reproduction;
- sanitized config excerpts;
- rollout-size statistics without exposing private conversation contents.
I am intentionally not attaching raw rollout files, databases, local project paths, conversation content, or authentication data because they contain private material.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
The runtime memory explosion is upstream of what
codex-rescuecan fix, but your local state profile (55.86 GB active rollouts, multi-GB image-heavy sessions, repeated compactions) is a valuable stress test for its persisted-session diagnostics.I’m field-testing the tool as experimental, local-first, and source-rollout read-only. If you’re willing, please test only the bounded diagnostic path first:
A clean result is useful too: the tool should not claim local corruption merely because the Desktop runtime is leaking memory. Please avoid salvage on the largest rollout unless you actually need recovery and
doctorcompletes successfully.Sanitized output + versions/timing/exit code only; no raw rollouts/DBs, images/base64, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue
Maintainer escalation request — actionable status needed
This report is now part of a broader, reproducible Desktop/app-server lifecycle failure family across #38825, #38754, #38765 and related reports. On this Windows machine the impact is not just degraded performance: a Codex-started
node.exereached ~55 GB virtual memory immediately before Resource Exhaustion events and a Windows bugcheck/reboot.The strongest current evidence now points to repeated MCP/runtime generations being created and retained rather than reused/reaped. #38754 also has a focused, tested external lifecycle-cleanup patch available for maintainer review, including bounded reuse and cleanup validation.
At this point more duplicate reproduction data is probably less useful than a maintainer decision. Could someone from the Codex team please provide one of the following:
I am happy to run a short, controlled Windows qualification test against a named candidate build and report process counts, commit usage and Event Viewer results. Until then I cannot safely use Codex Desktop for normal local development because the reproduced failure can take down the OS.