›_ Codex Issues
Codex Issues / #33258

Windows Desktop 26.707.9981: system cursor visually jitters when Codex becomes idle/background

Open 💬 4 comments Opened Jul 15, 2026 by IAMZHURUI
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

Codex Desktop for Windows causes the system cursor to visually jitter or flicker after the app enters an idle/background state. The issue is visible over Codex and other applications, including browsers.

This is visual composition jitter rather than real pointer input. During a 75-second affected sample, 2,367 cursor samples had zero cursor-handle changes and zero coordinate changes while the cursor still visibly jittered.

The behavior is timing-sensitive:

  • Opening Codex Desktop is the trigger.
  • Active message processing/streaming can temporarily stop the jitter.
  • The jitter usually returns when the task finishes, the app becomes idle, or focus moves to another application.
  • At other times it spreads to every visible page/window.
  • Closing every packaged Codex Desktop process is the only repeatable immediate recovery.
  • Rebooting clears the condition until Codex Desktop is opened again.

Reproduction

  1. Reboot Windows and confirm that the cursor is stable.
  2. Open Codex Desktop.
  3. Use a task normally, then leave the app idle or switch focus to a browser.
  4. Move or hold the cursor over Codex and other windows.
  5. Observe visual cursor jitter/flicker.
  6. Send a message to an active Codex task; the jitter may temporarily stop while output is streaming, then return after the task becomes idle.

Environment

  • Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Bundled Chromium observed: 150.0.7871.115
  • Windows 11 x64, build 26300
  • GPU: Intel Arc A380
  • Intel graphics driver: 32.0.101.8861
  • Two physical 2560x1440 displays, approximately 120 Hz
  • Codex CLI: 0.144.2

Controlled tests and exclusions

The symptom remained after these reversible, one-variable tests:

  • TRACE database logging stopped and WAL truncated
  • Empty .git probe storm repaired; repeated short-lived git.exe processes reduced to zero
  • UU Remote/GameViewer app, services, virtual display/input devices, and three driver packages fully uninstalled, followed by reboot verification
  • Wacom Professional Service stopped/disabled with no Wacom device connected
  • Old and current Intel graphics drivers
  • Both 60 Hz and 120 Hz display modes
  • DWM restart
  • MPO and HAGS mitigations
  • Mouse trails/software-cursor compatibility path
  • Windows Magnifier at 100% to force an accessibility composition path
  • Chromium background/occlusion throttling switches
  • --disable-direct-composition
  • Windows per-process power throttling disabled for every Codex main/GPU/renderer/app-server process

No-GPU/WARP launch modes are not viable because they produce a blank white window and very slow startup on this machine.

Several actions appeared to stop the issue briefly, but the jitter returned while the tested component remained disabled. Those correlations were therefore rejected as root causes.

Expected behavior

Codex Desktop should become idle without affecting system cursor composition in Codex or other applications.

Diagnostic interpretation

The stable cursor coordinates and handle during visible jitter point to a Windows DWM/GPU cursor-composition or presentation interaction triggered by the packaged Electron/Chromium desktop app, rather than mouse hardware or actual HID input.

Please investigate the Desktop app's idle/background renderer and GPU presentation behavior on Windows. A supported diagnostic switch or software-cursor fallback would also help affected users while the underlying issue is fixed.

Related reports: #32516, #30021, #30920, #16374.

Raw traces contain local paths and session metadata, so they are not attached publicly. Sanitized counter summaries and additional bounded traces can be provided if maintainers specify what is needed.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32550
  • #33074

Powered by Codex Action

IAMZHURUI · 1 month ago

Additional independent public reports found after filing:

  • #33074 reports system-wide mouse stutter during Codex startup/task switching on the same 26.707.9981.0 package. That reporter uses an NVIDIA RTX 4060 Ti and reproduced after a clean Windows 11 reinstall, lowering mouse polling rate, disabling a virtual display adapter, changing GPU preferences, disabling GPU rendering, and clearing Chromium shader/profile caches. Their WPR trace retained roughly 75-78% idle CPU, so the symptom was not explained by CPU/disk saturation.
  • #32178 reports massive stutter in the new Windows ChatGPT/Codex app and says the mouse can completely freeze when clicking in the app; ChatGPT Classic did not show the issue.
  • #33192 reports persistent DWM Composition handle growth after Codex tool-call tasks on the same 26.707 package / Electron 42 / Chromium 150 stack, including unreleased DirectComposition resource batches.
  • #16374 has 20 distinct human commenters reporting related Windows shell/taskbar/desktop degradation across NVIDIA, AMD, and Intel systems; several report immediate recovery only after killing the Codex GUI.

Together these reports show that this is not isolated to Intel Arc, UU Remote/GameViewer, one mouse, or one Windows installation. The common component is the current Windows Codex/ChatGPT Desktop rendering/runtime path.

kingsleyonoh · 29 days ago

Adding a Windows 11 reproduction from the same cursor-composition failure family, with before-and-after counters from Codex Desktop 26.721.4979.0.

Environment

  • Windows 11 x64, build 26200
  • Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Intel Core i7-13700H, 20 logical processors
  • 32 GB RAM
  • Intel UHD Graphics driver 32.0.101.5542, dated 2024-06-08
  • Parsec Virtual Display Adapter driver 0.45.0.0, dated 2024-01-25
  • Parsec service was configured for automatic startup

Symptoms

  • Typing, task navigation, and general Codex interaction became progressively slow.
  • Cursor movement became visibly jittery.
  • Chrome and other Windows operations also became difficult to use during the worst stalls.
  • A concurrent Pi session in Warp made the condition worse, but closing Warp did not remove it.
  • Windows recorded Application Hang 1002 for ChatGPT.exe on 2026-07-28 15:10:25 and again on 2026-07-30 02:16:06.

Controls before changing the display path

I first removed the large local-history variable:

  • Deleted 548 non-Brain rollout files totaling about 4.07 GiB.
  • Reduced the remaining rollout store to 42 files and about 262 MiB.
  • Removed the old 466.15 MiB Codex log database. Codex recreated it at 1.69 MiB.
  • Restarted Codex.

The typing and cursor lag remained.

A live sample during the degraded state did not show an SSD, paging, or machine-capacity bottleneck:

  • Average physical-disk writes: 0.26 MiB/s
  • Peak physical-disk writes: 0.93 MiB/s
  • Average disk queue: 0.01
  • Minimum available memory: 9.61 GiB
  • Average page writes: 0/s
  • DPC time: 0.11% average
  • Interrupt time: 0.21% average
  • CPU was boosting rather than throttling

The direct process counters showed the composition imbalance:

  • dwm.exe: 136% of one CPU core on average, 199.2% peak
  • All ChatGPT.exe processes combined: 3% of one core on average, 24.7% peak
  • DWM private memory: about 524 MiB
  • ChatGPT private memory: about 1.86 GiB

Display-driver intervention

Windows showed two active display adapters:

  • Intel UHD Graphics
  • Parsec Virtual Display Adapter

Parsec was not needed on this machine. I removed its three registered components:

  1. Parsec
  2. Parsec Virtual Display Driver
  3. Parsec Virtual USB Adapter Driver

All three uninstallers returned exit code 0. Windows required a reboot to unload the display and USB drivers.

Post-reboot verification found:

  • No Parsec service
  • No Parsec process
  • No Parsec installed-app entry
  • No connected Parsec device
  • No Parsec driver-store package
  • No Parsec application or driver directory

Result after reboot

Codex typing and navigation immediately felt much more responsive. The broad cursor jitter disappeared. The remaining brief pauses occurred only while normal post-boot processes were starting.

Measured results:

| Counter | Before removal/reboot | After startup settled |
| --- | ---: | ---: |
| DWM CPU, percentage of one core | 136% average | about 4.6% average |
| DWM CPU, peak | 199.2% | about 12.4% |
| DWM private memory | about 524 MiB | about 148 MiB in the first post-reboot sample |
| Physical-disk writes | low during affected control | 0.35 MiB/s average after startup |
| ChatGPT total-machine CPU | low between stalls | 0.41% average after startup |

The post-reboot sample also showed dwm.exe at only 0.23% of total machine CPU across 20 logical processors.

Interpretation and limit

This does not prove Parsec is the sole root cause. The recovery step included a Windows reboot, which also resets DWM and DirectComposition state. It does show:

  • The problem survived an ordinary Codex restart.
  • It survived removal of about 4.07 GiB of unrelated rollout history and recreation of the large Codex log database.
  • The affected state had sustained DWM CPU and memory cost without disk, paging, DPC, interrupt, or RAM exhaustion.
  • Removing the unused Parsec virtual display path and rebooting produced a large measured DWM reduction and a clear user-visible recovery.

Parsec may be an amplifier for a Codex/Electron/Chromium presentation or DirectComposition lifetime problem rather than the original source. This also appears related to #33192 and #33776.

Useful diagnostics from the app would include:

  • Active physical and virtual display adapters at startup
  • DirectComposition resource counts grouped by renderer or task
  • DWM-facing surface creation and release counts
  • Renderer/GPU process recovery events
  • A supported switch to disable the affected presentation path without producing a blank window

No project names, paths, prompts, thread IDs, client information, credentials, or raw rollout contents are included.

chourunzhong-rgb · 14 days ago

Additional Windows reproduction report:

  • The issue is reproducible on every Codex Desktop launch.
  • Immediately after opening Codex, the system mouse cursor appears to drift/jitter abnormally for a short period.
  • After Codex has been open for a while, the cursor behavior returns to normal on its own.
  • This startup-related pattern is consistent and has been observed repeatedly.

This may be related to the Windows cursor/composition behavior described in this issue. The report is being added to help establish that the problem can also occur specifically during the Codex startup period.