[Windows][26.810.7004.0] Codex run drives node.exe to ~55 GB virtual memory and crashes/reboots Windows

Open 💬 3 comments Opened Aug 16, 2026 by tapperwijn89
💡 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?

  • 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

  1. Use the machine normally for a full day with Codex/ChatGPT Desktop closed.
  • Result: no freezes, black screens, desktop corruption, or reboot.
  1. Launch Codex Desktop.
  2. Start normal Codex work.
  3. 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.exe PID 10308: 33,896,910,848 bytes virtual memory
  • another node.exe PID 25312: 3,266,023,424 bytes
  • explorer.exe: 2,889,867,264 bytes

At 11:28:40, one minute later:

  • the same node.exe PID 10308: 55,018,573,824 bytes virtual memory
  • explorer.exe: 2,921,197,568 bytes
  • codex.exe: 529,600,512 bytes

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-Power Event ID 41: system restarted without a clean shutdown.

At 11:30:52:

  • Microsoft-Windows-WER-SystemErrorReporting Event ID 1001
  • 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.exe or node_repl.exe process 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.exe PID 9132 reached about 1064 MB private memory;
  • approximately 11 seconds later the same PID was at about 1816.5 MB private memory;
  • multiple node_repl processes 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: 1504
  • base64: 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_repl workers remain after Code Mode work and correlate with system-wide stalls
  • #37672 — Windows code-mode host / Node helper explosion; enabled = false can be ineffective
  • #34863 — oversized image-heavy rollouts and compaction amplification
  • #38820 — Windows 26.810.7004.0 system-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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 11 days ago

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

  • #38825

Powered by Codex Action

shleder · 11 days ago

The runtime memory explosion is upstream of what codex-rescue can 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:

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

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 doctor completes 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

tapperwijn89 · 10 days ago

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.exe reached ~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:

  1. confirmation that this failure family is actively being investigated;
  2. the issue/PR that should be treated as the canonical fix path;
  3. whether the lifecycle-cleanup patch linked in #38754 overlaps the intended fix and is worth inviting as a PR; or
  4. a candidate Desktop/CLI build that affected users can safely qualify against this reproduction.

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.