`[Windows 10][Desktop app] Codex crash loop appears to leave DWM with ~33K handles, causing system-wide window-drag lag until session restart

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

• Version during the recorded crash loop: 26.707.9981.0 - Current version: 26.715.4045.0 - Distribution: Microsoft Store / packaged app (OpenAI.Codex_2p2nqsd0c76g0) - The current version was registered successfully on July 18, 2026 at 6:24:17 PM local time.

What subscription do you have?

pro

What platform is your computer?

• OS: Windows 10 Pro 22H2, x64 - OS build: 19045.5487 - CPU: Intel Core i7-14700K - RAM: 63.8 GB - GPU: NVIDIA GeForce RTX 5070 Ti, 16 GB - NVIDIA driver: 591.86 - Hardware-accelerated GPU scheduling: enabled (HwSchMode=2)

What issue are you seeing?

After using Codex Desktop for extended coding sessions, dragging any application window or File Explorer window becomes massively delayed and stuttery. The slowdown affects the Windows desktop compositor globally, not only the Codex window. Normal CPU, GPU, and memory totals do not explain it.

Restarting Windows clears the problem. On July 18, 2026, force-restarting only dwm.exe was tested and cleared the severe window-drag lag perfectly and immediately without requiring a logout or full OS restart. Closing Codex or restarting Explorer does not reliably clear the degraded compositor state.

During the affected Windows login session:

• Windows Error Reporting recorded a large Codex crash/relaunch storm from app version 26.707.9981.0.
• dwm.exe, the Desktop Window Manager responsible for compositing and moving windows, accumulated approximately 32,900 handles and about 512-515 MB of private memory.
• The DWM handle count remained at that elevated level while the machine was otherwise idle.
• Windows also recorded an NVIDIA kernel display-driver error during the crash period.

The correlation is strong, but the exact ownership of the leaked handles has not been proven. This may be a Codex renderer/AppX crash-cleanup issue, a DirectComposition resource-cleanup issue exposed by repeated Codex crashes, or an interaction with the NVIDIA Windows 10 driver stack.

What steps can reproduce the bug?

The issue is cumulative rather than immediate:

1. Start a fresh Windows login session.
2. Run Codex Desktop on Windows 10 for an extended coding session.
3. Execute multiple agent tasks involving shell commands, file operations, and long-running conversations.
4. If the app crashes or silently relaunches, continue using it after recovery.
5. After several hours or repeated crashes/relaunches, drag File Explorer, Task Manager, or another application's window rapidly across the desktop.
6. Observe that the window severely lags behind the pointer and may continue moving after the pointer stops.
7. Close Codex and retest. The desktop lag can remain.
8. Force-restart dwm.exe from an elevated PowerShell session and retest. In the confirmed test, the lag disappeared immediately while the rest of the desktop session remained usable.

While reproducing, monitor DWM with:

Get-Process dwm,codex -ErrorAction SilentlyContinue |
  Select-Object ProcessName, Id, Handles,
    @{Name='PrivateMB'; Expression={[math]::Round($_.PrivateMemorySize64 / 1MB, 1)}},
    StartTime

It would be useful to compare the DWM handle count immediately after sign-in, periodically during Codex use, and after any Codex crash/relaunch.

What is the expected behavior?

Codex Desktop should release renderer, DirectComposition, AppX, terminal, and child-process resources after tasks finish and when the app crashes or relaunches. Long Codex sessions and repeated app recoveries should not degrade DWM or the responsiveness of unrelated application windows.

Additional information

_No response_