Windows: repeated display blackouts / kernel crashes during Codex sandbox command-runner activity across multiple app versions

What version of the Codex App are you using?

This has occurred across multiple Microsoft Store Codex desktop app versions:

• 26.730.8199.0
• 26.818.5345.0
• 26.818.8289.0
• 26.820.7780.0

Current installed version: OpenAI.Codex 26.820.7780.0

Platform

• Windows 11 x64
• Windows build family: 10.0.26200
• GPU: NVIDIA GeForce GTX 970
• NVIDIA driver during the latest incident: 582.66 (32.0.15.8266)

What issue are you seeing?

I have experienced four system-level display-loss incidents, and all four occurred while the Codex Windows desktop app was actively performing local work.

I have not observed the same blackout behavior during normal day-to-day PC use outside Codex work.

The incidents span several Codex app versions, so this does not appear to be limited to one specific release.

Incident 1 — 2026-08-06 ~23:32

Codex version: 26.730.8199.0

• Sudden loss of monitor output during Codex work
• Manual reset required
• No useful crash dump captured

Incident 2 — 2026-08-24 ~19:59

Codex version: 26.818.5345.0

• Monitor output disappeared during Codex work
• Windows bugcheck: 0x133 DPC_WATCHDOG_VIOLATION
• Minidump: 082426-6468-01.dmp

Incident 3 — 2026-08-26 ~02:03

Codex version: 26.818.8289.0

• Same monitor-output-loss symptom during Codex work
• Windows bugcheck: 0x133 DPC_WATCHDOG_VIOLATION
• Minidump: 082626-6500-01.dmp

Incident 4 — 2026-08-26 ~22:42

Codex version: 26.820.7780.0

• Monitor output suddenly disappeared while Codex was working
• The machine appeared to continue running after display output was lost
• Windows generated two graphics black-screen LiveKernelEvents at 22:42:59:
• 0x1A8 VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP
• 0x1B8 VIDEO_MINIPORT_BLACK_SCREEN_LIVEDUMP
• Live kernel dump: WATCHDOG4400-20260826-2242.dmp

The latest dump contains:

• nvlddmkm.sys
• dxgkrnl.sys
• dxgmms2.sys
• watchdog.sys
• TRGDDumpBlob
• NV_Blackscreen_Blackbox

I did not find explicit strings such as Graphics is hung, GPU timeout, or TDR, so I am not claiming that the NVIDIA driver or GPU is the root cause.

Codex-side timing for the latest incident

Local sandbox logs show Codex helper activity before Windows detected the display failure:

• 22:41:32 — pwsh.exe, sandbox setup, and codex-command-runner activity begins
• 22:42:41 — two PowerShell/helper processes start close together
• 22:42:48.692 — Windows WATCHDOG requests a Live Kernel Dump
• 22:42:52 — WATCHDOG dump activity
• 22:42:55 — kernel dump transmission completes
• 22:42:57 — additional Codex PowerShell/helper activity
• 22:42:58 — sandbox setup completes; C:\Users\Default access-denied messages are recorded
• 22:42:59 — Windows Error Reporting records 0x1B8 and 0x1A8

The sandbox setup itself reports completion and does not log a GPU or renderer crash.

This does not prove that Codex directly caused the graphics failure. However, because all four failures occurred during Codex work, I think the interaction between Codex's Windows sandbox / command-runner lifecycle and the Windows desktop / graphics stack is worth investigating.

GPU-disabled Codex test

For the fourth incident, Codex was deliberately launched with:

--disable-gpu
--disable-gpu-compositing
--disable-direct-composition

The flags were verified on the main app process command line before the incident.

The blackout still occurred.

I understand that these flags do not disable Windows DWM, DirectX, the NVIDIA kernel driver, or the physical GPU. So this does not rule out graphics hardware or the Windows graphics stack, but it makes a simple explanation based only on Chromium GPU acceleration less likely.

Workload during the latest incident

The latest incident did not occur during heavy browser rendering or a GPU workload. Codex was doing a minimal closeout task involving:

• read-only file inspection
• git status / git log / git diff
• Node validators
• node --check
• git diff --check
• text searches

There was no:

• Browser Development Host
• browser navigation / reload
• WebGL / Three.js workload
• OBS / viewer
• npm build
• apply_patch
• file write
• stress test

Sandbox observations

The latest Codex sandbox log also contains access-denied activity involving:

C:\Users\Default

This may be relevant to other Windows sandbox / command-runner reports.

Potentially related issues:

• #40119
• #37187
• #37364

I am not claiming this is the same root cause. My system differs in Windows build, GPU vendor, bugchecks, and failure path.

Expected behavior

Running local commands through the Codex Windows sandbox should not cause system-level display loss, graphics watchdog events, or Windows kernel crashes.

If the sandbox or isolated command runner encounters an internal failure, it should fail locally and recover without destabilizing the Windows display / desktop stack.

Additional information

I have intentionally stopped trying to reproduce this because repeated testing risks another system-level failure.

I can provide sanitized information from:

• Codex sandbox logs
• Windows Error Reporting events
• WinDbg output from the 0x133 minidumps
• analysis from the 0x1B8 WATCHDOG live dump
• AppX Codex version history

I am avoiding posting full dumps or full Codex session logs publicly because they may contain private system or project information.

At this point I cannot determine whether the root cause is:

• Codex sandbox / command-runner lifecycle
• an interaction between Codex and Windows desktop / graphics infrastructure
• NVIDIA / DirectX behavior exposed by Codex activity
• GPU hardware
• another Windows kernel component

The main reason for filing this report is the repeated correlation: four display-loss incidents, across multiple Codex versions, all while Codex was actively performing local work, with no equivalent failures observed during ordinary PC use.