Repository navigation
[Windows 11][26.810.4967.0] Active thread causes system-wide lag and pointer flicker with sustained GPU/DWM load #38710
Description
What version of the Codex App are you using?
- Windows MSIX package:
26.810.4967.0(x64) - Embedded Chromium/ProductVersion:
151.0.7922.137 - Previous package:
26.803.10989.0
Windows AppX deployment Event ID 855 confirms that 26.803.10989.0 was updated to 26.810.4967.0 at 2026-08-14 19:05:19 UTC+7. The regression began with this update.
What platform is your computer?
- Windows 11 Pro 25H2,
10.0.26200, x64 - AMD Ryzen 9 3950X, 16 cores / 32 logical processors
- 32 GB RAM
- NVIDIA GeForce RTX 3060
- NVIDIA driver
32.0.15.9621(596.21), dated 2026-04-13 - Hardware-accelerated GPU scheduling already disabled (
HwSchMode=1) - Multiplane Overlay already disabled (
OverlayTestMode=5)
What issue are you seeing?
Starting work in any Codex Desktop thread causes severe system-wide degradation:
- mouse-pointer movement flickers/stutters
- window movement and the rest of the Windows desktop become slow and glitchy
- the symptom is not confined to the Codex window
- it reproduces with Codex Desktop as the only user application under test
- fully terminating Codex, including its background process tree, restores normal Windows responsiveness immediately.
Codex CLI, Codex running through Pi, and Claude Code do not reproduce the problem on the same machine. This isolates the regression to the Windows desktop application rather than the model workload, repository, or machine capacity.
Steps to reproduce
- Fully terminate all Codex Desktop processes.
- Launch Codex Desktop
26.810.4967.0. - Open a thread and start a session.
- Move the pointer and interact with other Windows surfaces.
- Observe system-wide pointer flicker, lag, and visual glitches.
- Fully quit Codex, including its background processes.
- Observe that Windows responsiveness returns immediately.
The trigger is starting a thread session. Merely running comparable terminal-based agents does not trigger it.
Expected behavior
An active Codex thread should not degrade pointer movement, Desktop Window Manager composition, or responsiveness outside the application.
Measured evidence during an affected active thread
GPU Engine 3D counters
A 10-sample, one-second-interval Windows Performance Counter capture showed:
| Process / engine | Average 3D utilization | Maximum |
|---|---|---|
Codex ChatGPT.exe GPU process |
9.97% | 10.49% |
dwm.exe |
8.89% | 10.20% |
Only the Codex GPU process and DWM showed sustained 3D activity in the capture. This is notable because the visible symptom is system-wide composition/input degradation despite low aggregate resource pressure.
CPU, memory, and I/O
A separate 10-second process sample during the incident measured:
- Electron main process: 14.98 CPU-seconds in 10 seconds, equivalent to 1.50 logical cores or about 4.7% of this 32-thread machine.
- Background
codex.exeservice: approximately 0.12% of total-machine CPU in the same sampling period. - Codex process-family working set: approximately 2.64 GB.
- Electron main process: 872 MB
- largest renderer: 618 MB
- GPU process: 198 MB
- Electron main-process read/write transfer delta during a 10-second follow-up sample: 0 MB / 0 MB.
- Task Manager during the original incident: approximately 12% total CPU, 49% memory, and 4% disk.
This is not conventional CPU, RAM, or disk saturation. The desktop application can nevertheless make the entire machine difficult to use.
Windows event and application-log checks
From the package update time through 2026-08-15 13:18 UTC+7:
- Display /
nvlddmkm/ DxgKrnl / WHEA GPU-reset or hardware events: 0 - Codex/ChatGPT Application Error or Application Hang events: 0
Current Codex Desktop logs were also checked for warning loops associated with similar reports. Counts across the current session logs were:
chrome_native_host_cache_reconcile_failed: 0Failed to collect child process snapshot: 0ResizeObserver loop: 0- D3D / ANGLE / DirectComposition error strings: 0
This capture therefore does not match the Chrome native-host retry loop in #38510 or the WMI child-process snapshot failure in #34158.
Assessment
The measurements establish correlation, not a proven root cause. They point to a desktop main-process/rendering regression involving Chromium GPU composition and DWM:
- exact onset after the package update;
- deterministic thread-session trigger;
- immediate recovery when the Desktop process tree exits;
- sustained Codex GPU-process and DWM 3D activity;
- significant Electron main-process CPU without system resource saturation;
- no display-driver reset, hardware error, crash, native-host retry loop, or WMI snapshot warning;
- terminal Codex clients remain unaffected.
Related reports
- [Windows][26.810.4967.0] This update makes the entire PC stutter — fully exiting Codex fixes it immediately #38554 : same package update and system-wide stutter
- Codex Windows 26.810.4967 idle main-process CPU busy loop in Chrome plugin app-server hashing #38547 : same package, Electron main-process busy loop
- Windows Codex app causes mouse stutter during startup and task switching without CPU/Disk saturation #33074 : Windows mouse stutter during task startup/switching
- [Windows 11][26.813.12317] ChatGPT/Codex causes persistent system-wide mouse lag and ~10% CPU while idle #38583 : similar system-wide mouse lag on the subsequent Windows build
This report adds an independent reproduction on Ryzen 9 / RTX 3060 hardware, precise AppX update provenance, per-process GPU/DWM counters, process CPU and working-set measurements, and negative evidence for the known retry-loop and driver-reset signatures.
Privacy and retained evidence
Process IDs, usernames, account information, local paths, task/thread identifiers, and conversation contents are intentionally omitted. Raw Desktop logs are not attached publicly because they contain local paths and task metadata. Narrowly scoped additional measurements or sanitized log excerpts can be provided if maintainers specify what is needed.
Activity
github-actions commentedon Aug 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rpaddict commentedon Aug 29, 2026
Adding this for reference even though the issue is closed: I reproduced a related long-session pattern where desktop-wide lag persisted without overall CPU, RAM, disk, or GPU exhaustion and cleared when DWM was restarted.
I published the monitoring and recovery utility here:
https://github.com/rpaddict/CodexWatchdog
It tracks Codex-owned processes and DWM history, cleans only verified orphan helpers by default, and exposes user-confirmed Codex and DWM restart controls. It is an unofficial diagnostic/workaround tool, not an upstream fix, and is not affiliated with OpenAI.