›_ Codex Issues
Codex Issues / #29882

Windows Codex Desktop may trigger full system freeze after Modern Standby resume; prior LiveKernelEvent 193 dxgkrnl watchdog

Open 💬 3 comments Opened Jun 24, 2026 by solankydev

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.616.10790.0

PackageFullName: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

  • OS: Microsoft Windows NT 10.0.26200 x64
  • Device: Dell Latitude 5420
  • BIOS: Dell 1.54.1, release date 2026-04-23
  • GPU: Intel(R) Iris(R) Xe Graphics
  • GPU driver: 32.0.101.7084, driver date 2026-01-15
  • Intel Wi-Fi: Intel(R) Wi-Fi 6 AX201 160MHz, driver 24.20.0.4, driver date 2026-01-06
  • Intel Dynamic Tuning / DPTF: 8.7.10802.26924, driver date 2022-04-11
  • RAM: 32 GB

What issue are you seeing?

The laptop has fully frozen twice while Codex Desktop was open, requiring a forced power-button restart. In the latest incident, Codex Desktop was the only foreground application open. A Go API server and Vite dev server were running in the background, but no other major apps were active.

This does not look like a normal Codex UI hang only. Windows became unresponsive enough that I had to hold the power button. After reboot, Windows recorded Kernel-Power 41 and EventLog 6008 for an unexpected shutdown, but did not capture a normal bugcheck.

The strongest pattern is that the freeze occurred after Modern Standby resume, and a prior related incident has Windows graphics-kernel watchdog evidence.

Latest incident, 2026-06-24 IST:

  • 21:11:18 - System entered Modern Standby due to idle timeout.
  • 21:35:49 - System exited Modern Standby, reason: keyboard input.
  • Around 21:41 - Laptop appeared frozen/hung.
  • Around 22:04:40 - Previous shutdown later recorded as unexpected.
  • 22:12:24 - OS started again after forced power-button restart.
  • 22:12:27 - Kernel-Power 41: system rebooted without clean shutdown.
  • 22:12:40 - EventLog 6008: previous shutdown was unexpected.

I checked System/Application logs around the freeze. I did not find clear disk/NVMe/NTFS/WHEA/display-reset evidence at the exact freeze time. After the system became unhealthy, Windows logged UWP/app hang noise such as Microsoft To Do and Phone Link DCOM/WER events, but those look more like symptoms after the system was already stuck.

Earlier related evidence:

  • 2026-06-20 23:29-23:32 - Windows Error Reporting recorded LiveKernelEvent with:
  • P1: 193
  • P2: 810
  • bucket: LKD_0x193_DxgkrnlLiveDump:810__dxgkrnl!ProcessDeadlockThread
  • dump path: C:\WINDOWS\LiveKernelReports\WATCHDOG\WATCHDOG-20260620-2329.dmp

There was also another forced restart in the recent logs:

  • 2026-06-21 08:42:04 - Kernel-Power 41
  • 2026-06-21 08:42:17 - EventLog 6008, previous shutdown at 03:35:33 was unexpected

Codex-specific WER history on this machine also includes:

  • 2026-06-19 12:12:01 - RADAR_PRE_LEAK_64 for Codex.exe
  • 2026-06-19 21:58:18 - AppHangTransient for Codex.exe

What steps can reproduce the bug?

I cannot reproduce this on demand yet. Observed pattern:

  1. Open Codex Desktop for Windows.
  2. Have a local development setup running in the background, for example Go API server and Vite dev server.
  3. Let the laptop enter Modern Standby / idle sleep.
  4. Resume with keyboard input.
  5. Continue using or leave Codex Desktop open.
  6. Laptop may fully freeze and require holding the power button.

What is the expected behavior?

Codex Desktop should not be able to contribute to a full Windows system freeze after Modern Standby resume. If the Electron renderer/GPU process, app-server, sandbox, or runtime enters a bad state after resume, Codex should recover, fail visibly, or restart its own processes without causing system-wide unresponsiveness.

Additional information

This may be related to existing Windows Desktop stability/performance issues, but this report adds a specific Modern Standby + graphics watchdog signal:

  • #20544
  • #27581
  • #28855
  • #25951
  • #29133

The local evidence makes Codex Desktop a plausible trigger, while the actual hard freeze appears to involve the Windows graphics / Modern Standby stack. The previous dxgkrnl!ProcessDeadlockThread / WATCHDOG dump is the strongest low-level clue.

I have not attached raw dumps, .codex databases, local sessions, screenshots, or unsanitized logs publicly because they may contain private paths or data. I can provide sanitized event summaries or specific command outputs if maintainers need them.

View original on GitHub ↗

3 Comments

Yassycodes · 2 months ago

Thanks for the mention here. I am still unable to use codex app on my windows system due to the performance issue I reported and I first noticed the issue on June 12th. My Github has been hanging for over a week now and the app is literally unusable for me right now.

Fingers crossed they fix this soon.

solankydev · 2 months ago

Additional recurrence today, 2026-06-25 IST.

The same hard-freeze pattern happened again around 09:38 IST. I had to force restart with the power button.

Relevant Windows event markers from the reboot/session:

  • 09:25:07 - Kernel-Power 506: system entered Modern Standby, reason Idle Timeout.
  • 09:32:32 - Kernel-Power 507: system exited Modern Standby, reason Input Keyboard.
  • Around 09:38 - laptop appeared frozen/unresponsive.
  • 09:40:51 - DCOM timeout for Phone Link/YourPhone, likely symptom while the system was already unhealthy.
  • 09:42:41 - OS started again after forced restart.
  • 09:42:44 - Kernel-Power 41: system rebooted without cleanly shutting down first.
  • 09:42:58 - EventLog 6008: previous system shutdown was unexpected. The event message says previous shutdown at 09:28:52 AM.

Checks after reboot:

  • No fresh LiveKernelEvent, WATCHDOG, dxgkrnl, Codex.exe, AppHang, or RADAR record found in the Application/WER log for 09:20-10:05.
  • No new clear disk/NVMe/NTFS/WHEA error around the freeze. WHEA entries after reboot are informational initialization/event-log entries.
  • System log again shows the same Modern Standby resume shortly before the hard freeze.

This makes the recurrence stronger: at least two consecutive incidents now show Modern Standby -> keyboard resume -> hard system freeze -> forced restart, with Codex Desktop open.

jeremy157695 · 12 days ago

I can reproduce a closely related, less severe variant: after Modern Standby resume, Codex Desktop's main ChatGPT.exe process enters a persistent high-CPU state and causes system-wide mouse/input stutter. Fully quitting and restarting Codex clears it immediately.

Environment

  • Codex Desktop: OpenAI.Codex 26.810.6296.0
  • Windows 11 Pro Insider build 26300
  • Device: Dell Latitude 5285
  • CPU: Intel Core i7-7600U
  • RAM: 16 GB
  • GPU: Intel HD Graphics 620
  • GPU driver: 31.0.101.2141

Correlated timeline (local time, Asia/Taipei)

  • 2026-08-15 23:19:18: Kernel-Power event 506 — entered Modern Standby
  • 2026-08-16 05:19:55: Kernel-Power event 507 — exited Modern Standby
  • After resume, the main ChatGPT.exe process remained at about 31.41% total host CPU and approximately 862 MB working set, with system-wide mouse stutter.
  • A full Codex exit/restart replaced the main process; an equivalent sample then averaged 0.67% total host CPU with approximately 303 MB working set, and the stutter stopped immediately.

A separate recurrence also began after a Modern Standby exit (event 507 at approximately 2026-08-15 20:47), with the main process sustaining roughly 28–31% total CPU.

Additional observations:

  • The problematic sample did not show a persistent high disk-read loop, so this appears different from the I/O-heavy behavior in #38518.
  • Windows reported an effective CPU speed limit of 100%, so there was no evidence of active CPU throttling during the test.
  • Intel graphics was updated before the latest reproduction, but the issue recurred.
  • Disabling Codex analytics did not prevent recurrence.
  • Codex diagnostics contained repeated Electron powerMonitor.speed-limit-change breadcrumbs around the affected period.

This strengthens the Modern Standby/resume correlation. In this case the system did not hard-freeze, but Codex's main Electron process appeared to remain in a runaway post-resume CPU loop until the entire app was restarted.