Skip to content

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

Open
Open
Windows Desktop 26.707.9981: system cursor visually jitters when Codex becomes idle/background#33258
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@IAMZHURUI
IAMZHURUI
opened on Jul 15, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Jul 15, 2026

  2. github-actions commented on Jul 15, 2026

    @github-actions
    github-actionsbot
    on Jul 15, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. IAMZHURUI commented on Jul 15, 2026

    @IAMZHURUI
    IAMZHURUI
    on Jul 15, 2026
    Author

    Additional independent public reports found after filing:

    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.

  4. kingsleyonoh commented on Jul 30, 2026

    @kingsleyonoh
    kingsleyonoh
    on Jul 30, 2026

    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.

  5. chourunzhong-rgb commented on Aug 14, 2026

    @chourunzhong-rgb
    chourunzhong-rgb
    on Aug 14, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions