[Windows][26.721.11231.0] RADAR_PRE_LEAK_64 and AppHang before sleep; resume leaves app headless and system unresponsive

[cavintank]

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.

1. Windows Error Reporting Event ID 1001 recorded:
   • Event name: RADAR_PRE_LEAK_64
   • Process: ChatGPT.exe
2. Approximately 8 hours 43 minutes later, Application Hang Event ID 1002 reported that ChatGPT.exe had stopped interacting with Windows.
3. Approximately two minutes later, Kernel-Power Event ID 42 recorded entry into sleep.
4. After approximately 11 hours 8 minutes, Kernel-Power Event ID 107 and Power-Troubleshooter Event ID 1 recorded resume from the low-power state.
5. After resume:
   • overall system responsiveness was severely degraded;
   • memory use appeared abnormally high;
   • ChatGPT.exe processes were still visible;
   • the Codex window never appeared;
   • ending the process from Task Manager did not complete normally.
6. 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:

1. Launch Codex Desktop on Windows and use it normally for several hours.
2. Leave the application running.
3. Allow the machine to enter sleep without fully quitting Codex.
4. Leave the machine asleep for an extended period (approximately eleven hours in this incident).
5. Resume Windows.
6. Observe whether the system becomes severely unresponsive while ChatGPT.exe remains 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

• Windows Desktop 26.715.4045 repeatedly becomes unresponsive (MoAppHang) after memory spikes #34305 reports Windows memory spikes, RADAR_PRE_LEAK_64, and MoAppHang.
• Windows desktop app exits unexpectedly after memory-leak and hang events #35963 reports Windows memory-leak and hang events.
• Windows app won't open after update, background process exists but no GUI window #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.

[github-actions]

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

• Windows desktop app exits unexpectedly after memory-leak and hang events #35963

Powered by Codex Action

[ZALIPON]

Additional confirmation from a separate Windows machine: this is reproducible on a newer Codex build.

Environment

• Codex Windows package: 26.727.6591.0 (x64)
• Windows 11 Pro, build 26200
• Physical memory: approximately 125.7 GB

Reproduction pattern

This has happened more than once:

1. Use Codex normally for a long session.
2. Leave Codex running overnight.
3. Manually power off the monitor and allow the PC to enter its normal idle/sleep state.
4. Wake the PC the next day.
5. The whole Windows UI becomes extremely sluggish and stutters badly.
6. Restarting Windows restores normal performance.

Diagnostics captured before the latest restart

A process inspection found:

• codex.exe using approximately 1.8 GB working set;
• 11 lingering bundled node.exe helpers from the Codex cua_node runtime, totaling approximately 1.3 GB working set;
• their command lines were kernel.js --session-id <redacted> --working-dir <redacted>;
• 11 corresponding codex-command-runner-0.146.0-alpha.9.2.exe processes;
• the command runners' own recorded parent processes were no longer present.

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.