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.exe service: 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
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.
What version of the Codex App are you using?
26.810.4967.0(x64)151.0.7922.13726.803.10989.0Windows AppX deployment Event ID 855 confirms that
26.803.10989.0was updated to26.810.4967.0at 2026-08-14 19:05:19 UTC+7. The regression began with this update.What platform is your computer?
10.0.26200, x6432.0.15.9621(596.21), dated 2026-04-13HwSchMode=1)OverlayTestMode=5)What issue are you seeing?
Starting work in any Codex Desktop thread causes severe system-wide degradation:
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
26.810.4967.0.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:
ChatGPT.exeGPU processdwm.exeOnly 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:
codex.exeservice: approximately 0.12% of total-machine CPU in the same sampling period.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:
nvlddmkm/ DxgKrnl / WHEA GPU-reset or hardware events: 0Current 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: 0This 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:
Related reports
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.