Windows Desktop 26.707.9981: system cursor visually jitters when Codex becomes idle/background
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
- Reboot Windows and confirm that the cursor is stable.
- Open Codex Desktop.
- Use a task normally, then leave the app idle or switch focus to a browser.
- Move or hold the cursor over Codex and other windows.
- Observe visual cursor jitter/flicker.
- 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
.gitprobe storm repaired; repeated short-livedgit.exeprocesses 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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗