[Windows][26.721.11231.0] RADAR_PRE_LEAK_64 and AppHang before sleep; resume leaves app headless and system unresponsive
Summary
On Windows, Codex Desktop became severely unresponsive after resuming from a long sleep. The app's ChatGPT.exe processes remained present, but no application window appeared, and attempts to terminate the process tree from Task Manager did not complete normally.
Windows Error Reporting shows that the application was already unhealthy before the machine entered sleep: it recorded a suspected memory-leak event for ChatGPT.exe, followed later by an application hang. The system entered sleep approximately two minutes after the hang event. After an approximately eleven-hour sleep, resuming the machine exposed the headless/unresponsive state and severe system slowdown.
A normal reboot restored usability.
Environment
- Codex Windows package:
OpenAI.Codex 26.721.11231.0 - Architecture: x64
- Windows build:
10.0.26200 - Physical memory: approximately 16 GB
- Executable recorded by Windows:
ChatGPT.exe - Executable version in the relevant WER records:
150.0.7871.128 - Subscription: not included because the failure occurs at the local desktop-process / OS-resume layer
Observed timeline
Exact local timestamps are intentionally omitted; the relative sequence is preserved.
- Windows Error Reporting Event ID 1001 recorded:
- Event name:
RADAR_PRE_LEAK_64 - Process:
ChatGPT.exe
- Approximately 8 hours 43 minutes later, Application Hang Event ID 1002 reported that
ChatGPT.exehad stopped interacting with Windows. - Approximately two minutes later, Kernel-Power Event ID 42 recorded entry into sleep.
- After approximately 11 hours 8 minutes, Kernel-Power Event ID 107 and Power-Troubleshooter Event ID 1 recorded resume from the low-power state.
- After resume:
- overall system responsiveness was severely degraded;
- memory use appeared abnormally high;
ChatGPT.exeprocesses were still visible;- the Codex window never appeared;
- ending the process from Task Manager did not complete normally.
- A normal OS restart recovered the machine.
Negative evidence / checks
The relevant Windows logs did not show:
- Resource-Exhaustion-Detector Event ID 2004;
- an unexpected shutdown or Kernel-Power Event ID 41;
- a blue-screen event;
- a display-driver reset Event ID 4101;
- disk-reset or disk-failure events around the incident.
There was an Intel wireless-adapter power-transition failure at resume. This may have contributed to resume latency, but it does not explain the earlier RADAR_PRE_LEAK_64 and Application Hang 1002 events for ChatGPT.exe.
Steps to reproduce
The failure has been observed once and is not yet deterministic:
- Launch Codex Desktop on Windows and use it normally for several hours.
- Leave the application running.
- Allow the machine to enter sleep without fully quitting Codex.
- Leave the machine asleep for an extended period (approximately eleven hours in this incident).
- Resume Windows.
- Observe whether the system becomes severely unresponsive while
ChatGPT.exeremains in the process list without a visible Codex window.
Expected behavior
- Codex memory usage should remain bounded during extended use.
- The desktop app should survive sleep/resume with a usable window.
- If a renderer or background process cannot be restored, Codex should recover it or present a clear error.
- The application process tree should remain terminable through normal Windows process-management tools.
Actual behavior
The application was flagged for a suspected memory leak, later stopped interacting with Windows, entered sleep in that state, and resumed as a headless process group while the system was severely degraded.
Related issues
- #34305 reports Windows memory spikes,
RADAR_PRE_LEAK_64, andMoAppHang. - #35963 reports Windows memory-leak and hang events.
- #25575 reports background processes remaining present with no GUI window.
This report differs by documenting the sequence on package 26.721.11231.0: suspected leak -> application hang -> sleep -> long-duration resume -> headless process group and failed normal termination.
Privacy and diagnostic artifacts
No raw Event Viewer exports, WER files, minidumps, application databases, screenshots, or full process listings are attached. Those artifacts may contain usernames, local paths, conversation identifiers, project information, or process memory.
This report intentionally excludes:
- email/account information;
- Windows username and private filesystem paths;
- machine name, IP addresses, and device identifiers;
- conversation, task, thread, and project contents;
- private repository names;
- WER report GUIDs and temporary-file paths;
- unrelated installed applications and processes.
A minimal redacted event summary can be provided privately if maintainers request additional evidence.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional confirmation from a separate Windows machine: this is reproducible on a newer Codex build.
Environment
26.727.6591.0(x64)26200Reproduction pattern
This has happened more than once:
Diagnostics captured before the latest restart
A process inspection found:
codex.exeusing approximately 1.8 GB working set;node.exehelpers from the Codexcua_noderuntime, totaling approximately 1.3 GB working set;kernel.js --session-id <redacted> --working-dir <redacted>;codex-command-runner-0.146.0-alpha.9.2.exeprocesses;Manually terminating those orphaned helper trees and old SSH/shell processes freed memory, but did not restore smooth UI behavior. A full Windows reboot was still required.
Expected behavior
Codex should remain responsive across extended idle/sleep periods, and stale helper trees should be reaped or safely restarted on resume. If renderer or helper recovery fails, the app should recover itself without degrading the entire desktop session.
All local usernames, repository paths, session IDs, and project details are intentionally redacted. If useful, I can capture a minimal Event Viewer timeline and another redacted process snapshot on the next occurrence.