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

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.