### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Refiled from #77857, which I closed. That report was auto-labeled invalid on creation before I could correct the title's sco

[BUG] Windows: Claude Code sessions and chat switching in Claude Desktop cause system-wide cursor stutter whenever the window is focused — MSIX blocks the GPU compositing workaround

Open 💬 0 comments Opened Jul 15, 2026 by nullscanner

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

<html>
<body>
Refiled from #77857, which I closed. That report was auto-labeled <code>invalid</code> on creation before I could correct the title's scope, and the labeler doesn't re-run on edit. This is the same defect with corrected scope: the stutter reproduces in Claude Code sessions as well as chat, so it is not chat-only as #77857 implied.
Related to #67928, #67670, #26302, #56805, #51955 and #66495, but filed separately because the trigger is different and reproducible: unlike #67928 this requires no active agent — window focus alone is sufficient, and the worst stutter is on new-chat creation and chat/session switching.
<h2>What's Wrong?</h2>
Claude Desktop causes system-wide mouse cursor stuttering/teleporting and sustained GPU load whenever the app window has focus. The cursor skips/jumps intermittently and CPU/GPU fans audibly ramp. The machine is otherwise idle and performs normally when Claude is closed.
This is not workload-dependent. It occurs in chat and in Claude Code sessions equally — the trigger is window focus, not what the app is doing. It is worst when starting a new chat and when switching between chats/sessions, i.e. on full conversation-view re-renders, which points at the renderer's repaint path rather than at steady-state compositing alone.
Launching the executable directly with <code>--disable-gpu-compositing</code> completely resolves the issue, confirming the cause is Electron's GPU compositing layer interacting with Windows DWM — not the workload, and not local computation (no local model is running; all inference is server-side).
The core problem: there is no supported way to apply this flag. The app is MSIX-packaged, the taskbar/Start entries expose no <code>Properties</code> dialog (no <code>.lnk</code> Target to edit), and there is no hardware acceleration toggle in app settings. The only working workaround is invoking the packaged <code>.exe</code> directly, which loses package identity and breaks the app's disk cache.
Notable: this package was installed via the direct download from anthropic.com, not the Microsoft Store, and is still MSIX. Several existing reports assume MSIX means a Store install. It doesn't. Users who avoid the Store to retain flag control do not actually get it.
<h2>Environment</h2>

|
-- | --
Claude Desktop version | 1.21459.0.0
PackageFullName | Claude_1.21459.0.0_x64__pzs8sxrjxfjjc
PackageFamilyName | Claude_pzs8sxrjxfjjc
InstallLocation | C:\Program Files\WindowsApps\Claude_1.21459.0.0_x64__pzs8sxrjxfjjc
Install source | Direct download from anthropic.com (NOT Microsoft Store)
SignatureKind | Developer
OS | Windows 11 Pro — build 26200.8737
CPU | AMD Ryzen 9 9950X3D2 Dual Edition (16C/32T, Zen 5) — includes integrated Radeon Graphics (2 CU @ 2200 MHz)
Discrete GPU | NVIDIA GeForce RTX 5090
NVIDIA driver | 610.74 (GeForce Game Ready, released 2026-07-07) — WDDM 32.0.16.1074
iGPU driver | AMD Radeon(TM) Graphics — WDDM 32.0.21036.18
RAM | 128 GB DDR5
Motherboard | ASUS ROG Crosshair X870E Hero
Display 1 | Samsung Odyssey G95NC — 7680 × 2160 @ 59.99 Hz, 10-bit RGB, HDR on, 150% scaling — connected to RTX 5090
Display 2 | Asus ROG PG35V — 3440 × 1440 @ 59.97 Hz, 10-bit RGB, HDR on, 100% scaling, VRR supported (10–60 Hz) — connected to RTX 5090
Total desktop pixels | ~21.5 MP (16.6 MP + 5.0 MP)

Both displays are connected to the discrete GPU. The iGPU is enabled in BIOS but drives no display and measures 0% throughout.
On the factors implicated in sibling reports:
<ul>
<li>HDR is enabled on both displays by default, but is not the trigger. Disabling it changed nothing — see "What Was Ruled Out." Worth stating explicitly since #25801 / #45031 implicate HDR in a related MSIX/NVIDIA failure.</li>
<li>Both displays run at ~60 Hz, not high-refresh, and the stutter occurs regardless. #26302 and #25801 both implicate high-refresh panels; high refresh rate is not a necessary condition for this bug.</li>
<li>150% DPI scaling on the primary matches #26302's 1.5× scaling factor. Untested as an isolated variable.</li>
<li>~21.5 MP of desktop is the standout characteristic of this config — roughly 3.5× the pixel count in #26302 (3840×1600).</li>
</ul>
<h2>Steps to Reproduce</h2>
<ol>
<li>Install Claude Desktop via the direct download from anthropic.com on Windows 11.</li>
<li>Launch normally (taskbar pin / Start menu).</li>
<li>Move the mouse over the Claude Desktop window. Observe: cursor stutters and briefly teleports; fans ramp; GPU load rises.</li>
<li>Move focus to any other application — the stutter stops.</li>
<li>Click "New chat" from within the app. Observe pronounced cursor stutter/teleporting during and immediately after the transition.</li>
<li>Switch between several existing conversations in the sidebar. Observe the same, repeatably.</li>
<li>Open the Code tab and switch between Claude Code sessions. Same behavior — the stutter is independent of whether an agent is running or what the workload is.</li>
<li>Let the app sit idle on a single conversation — stutter reduces but does not stop while the window has focus.</li>
</ol>
Steps 5–7 are the reliable repro. Starting a new chat and switching between chats/sessions produce the most pronounced and most repeatable stutter. Both tear down and re-render the full conversation view, and the cursor stutter tracks those transitions directly. Step 3 is the ambient background symptom.
Unlike #67928, this does not require an active Claude Code agent. Window focus alone is sufficient.
<h2>Expected Behavior</h2>
A text-based chat application should not induce system-wide input stutter or sustained GPU load. Hardware acceleration should be user-disableable, as it is in Chrome, VS Code, Discord, Slack, and effectively every other Electron/Chromium app.
<h2>Actual Behavior</h2>
Continuous repaint/compositing load whenever the window has focus, causing DWM contention and system-wide cursor stutter.
<h2>Diagnostics</h2>
Integrated AMD Radeon Graphics (GPU 0) — measured while the stutter was occurring:
<pre><code>3D: 0%
Copy: 0%
Compute 0: 0%
Compute 1: 0%
Dedicated GPU memory: 0.0 / 2.0 GB
Shared GPU memory: 0.0 / 62.8 GB
Utilization: 0% Temp: 41 °C
Driver: 32.0.21036.18 (11/12/2025)
</code></pre>
The iGPU is doing nothing. This is the direct measurement behind the "cross-GPU frame transfer ruled out" claim below.
RTX 5090 (GPU 1): 0% at idle, 41 °C.
Task Manager cannot capture the spike. The stutter is transient — it fires during chat/session switches and mouse-over and is over faster than Task Manager's sampling interval, so the graphs show no meaningful excursion even while the cursor is visibly teleporting. This is a material difference from #67928, which reports sustained 90–95% iGPU load for the duration of an agent run. Whatever is happening here is bursty, tied to view transitions and window focus, and short enough to evade 1-second polling — while still being long enough to drop cursor frames system-wide.
If higher-resolution instrumentation would help (PresentMon, GPUView, ETW trace), I'm happy to capture it — just say which and how.
<code>Claude.exe</code> process count and total memory: 10 processes, ~1453 MB (via <code>Get-Process Claude</code>). For comparison, #26302 reported ~1.3 GB across 8 processes.
<h2>What Was Ruled Out</h2>
<ul>
<li>Cross-GPU frame transfer — RULED OUT. Windows Settings → System → Display → Graphics → Claude (Microsoft Store app) → High performance had zero effect. Measured directly: the integrated Radeon sits at 0% across 3D/Copy/Compute with 0.0 GB allocated while the stutter is occurring. Rendering is not being offloaded to the iGPU, so this is not the multi-GPU copy problem described in #56805 and #51955. Both displays are already on the discrete GPU; there is no cross-GPU frame copy to eliminate.</li>
<li>HDR — RULED OUT. Both displays run HDR by default. Disabling HDR changed nothing: the stutter is identical with HDR on and off. Noting this because #25801 / #45031 implicate HDR in a related MSIX/NVIDIA failure — it is not the trigger here.</li>
<li>High refresh rate — NOT REQUIRED. Both panels are high-refresh-capable but are running at ~60 Hz, and the stutter occurs anyway. #26302 and #25801 both implicate high-refresh displays; this report shows that is not a necessary condition.</li>
<li>Hardware/build issue — RULED OUT. New machine, no stutter with any other application, including GPU-heavy ones. Symptom appears and disappears strictly with Claude Desktop window focus.</li>
<li>Local model computation — N/A. No local inference running; all inference is server-side.</li>
<li>Mouse/USB — RULED OUT. Symptom is bound to Claude window focus, not to any input device state.</li>
<li>Elevation — NOT A FACTOR. The workaround's cache errors reproduce identically in an elevated shell.</li>
</ul>
<h2>Workaround (and why it isn't acceptable)</h2>
Only working invocation:
<pre><code class="language-powershell">& "C:\Program Files\WindowsApps\Claude_1.21459.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe" --disable-gpu-compositing
</code></pre>
This fixes the stutter completely, with no perceptible downside to app responsiveness on this CPU.
But it breaks the app. Because the process is launched from the package directory without package identity:
<pre><code>[ERROR:net\disk_cache\cache_util_win.cc:25] Unable to move the cache: Access is denied. (0x5)
[ERROR:net\disk_cache\disk_cache.cc:284] Unable to create cache
</code></pre>
Also observed on launch:
<pre><code>Error occurred in handler for '$eipc_message$_..._$_claude.buddy_$_BuddyBleTransport_$_reportState':
Error: No handler registered for '$eipc_message$_..._$_claude.buddy_$_BuddyBleTransport_$_reportState'
at Session.<anonymous> (node:electron/js2c/browser_init:2:114253)
at Session.emit (node:events:509:28)
</code></pre>
Additional problems with this workaround:
<ul>
<li>Running elevated produces the same cache errors — this is an identity failure, not a permissions failure.</li>
<li>The version-stamped path breaks on every app update.</li>
<li>No <code>.lnk</code> shortcut exists to attach the flag to; the taskbar context menu exposes no <code>Properties</code>.</li>
<li>Indirect flag mechanisms (<code>ELECTRON_EXTRA_LAUNCH_ARGS</code>, <code>electron-flags.conf</code>, NVIDIA Control Panel per-app profiles) are all ignored under MSIX, as documented in #26302 and #31643.</li>
</ul>
<h2>Requested Fix</h2>
<ol>
<li>Add a "Disable hardware acceleration" / "Disable GPU compositing" toggle in Settings. This is the single most-requested item across every related issue below, and it costs one <code>app.disableHardwareAcceleration()</code> call gated on a setting.</li>
<li>Investigate the conversation-view render path. The worst stutter correlates with new-chat creation and chat/session switching — full view re-renders — which suggests the mount/unmount path is doing far more compositing work than a text view should. #45127 additionally reports non-zero <code>nvidia-smi</code> SM usage on a fully idle window, suggesting an unconditional animation/render loop underneath.</li>
<li>Support a flag mechanism for MSIX builds, or ship a non-MSIX installer option for the direct download.</li>
</ol>
<h2>Related Issues</h2>
<ul>
<li>#67928 — GPU load scales with visible Claude Desktop window area during active agent runs</li>
<li>#67670 — Cursor stutter/lag over the app window on multi-GPU systems (Windows MSIX)</li>
<li>#26302 — Severe UI lag and mouse stutter; documents that MSIX ignores all standard Electron GPU flag mechanisms</li>
<li>#45127 — Cursor stutter/teleporting when window is visible; non-zero idle GPU usage via <code>nvidia-smi</code></li>
<li>#56805 — Screen flickering & mouse lag; <code>--disable-gpu-compositing</code> identified as the fix; requests a hardware acceleration toggle</li>
<li>#51955 — Performance issue on dual-GPU laptop (Intel Arc + NVIDIA)</li>
<li>#66495 — Progressive renderer degradation on Windows 11 / NVIDIA G-Sync</li>
<li>#31643 — Extreme input lag from React render loop; MSIX blocks GPU tuning workarounds</li>
<li>#25801 / #45031 — Black screen with HDR enabled (same MSIX GPU flag limitation)</li>
<li>#63650 — Blurry on high-DPI display; MSIX blocks DPI override</li>
</ul>
This has persisted across many releases — the reports above span versions 1.1.3189 through 1.12603.1, and this report is 1.21459.0.0. The requested toggle has been asked for repeatedly and not shipped.
Suggested labels: <code>area:desktop</code>, <code>bug</code>, <code>has repro</code>, <code>performance</code>, <code>platform:windows</code></body></html>
</body>
</html>

What Should Happen?

Expected Behavior

A text-based chat application should not induce system-wide input stutter or sustained GPU load. Hardware acceleration should be user-disableable, as it is in Chrome, VS Code, Discord, Slack, and effectively every other Electron/Chromium app.

Actual Behavior

Continuous repaint/compositing load whenever the window has focus, causing DWM contention and system-wide cursor stutter.

Diagnostics

Integrated AMD Radeon Graphics (GPU 0) — measured while the stutter was occurring:

3D: 0%
Copy: 0%
Compute 0: 0%
Compute 1: 0%
Dedicated GPU memory: 0.0 / 2.0 GB
Shared GPU memory: 0.0 / 62.8 GB
Utilization: 0% Temp: 41 °C
Driver: 32.0.21036.18 (11/12/2025)

The iGPU is doing nothing. This is the direct measurement behind the "cross-GPU frame transfer ruled out" claim below.

RTX 5090 (GPU 1): 0% at idle, 41 °C.

Task Manager cannot capture the spike. The stutter is transient — it fires during chat/session switches and mouse-over and is over faster than Task Manager's sampling interval, so the graphs show no meaningful excursion even while the cursor is visibly teleporting. This is a material difference from #67928, which reports sustained 90–95% iGPU load for the duration of an agent run. Whatever is happening here is bursty, tied to view transitions and window focus, and short enough to evade 1-second polling — while still being long enough to drop cursor frames system-wide.

If higher-resolution instrumentation would help (PresentMon, GPUView, ETW trace), I'm happy to capture it — just say which and how.

Claude.exe process count and total memory: 10 processes, ~1453 MB (via Get-Process Claude). For comparison, #26302 reported ~1.3 GB across 8 processes.

Error Messages/Logs

Steps to Reproduce

Install Claude Desktop via the direct download from anthropic.com on Windows 11.
Launch normally (taskbar pin / Start menu).
Move the mouse over the Claude Desktop window. Observe: cursor stutters and briefly teleports; fans ramp; GPU load rises.
Move focus to any other application — the stutter stops.
Click "New chat" from within the app. Observe pronounced cursor stutter/teleporting during and immediately after the transition.
Switch between several existing conversations in the sidebar. Observe the same, repeatably.
Open the Code tab and switch between Claude Code sessions. Same behavior — the stutter is independent of whether an agent is running or what the workload is.
Let the app sit idle on a single conversation — stutter reduces but does not stop while the window has focus.

Steps 5–7 are the reliable repro. Starting a new chat and switching between chats/sessions produce the most pronounced and most repeatable stutter. Both tear down and re-render the full conversation view, and the cursor stutter tracks those transitions directly. Step 3 is the ambient background symptom.

Unlike #67928, this does not require an active Claude Code agent. Window focus alone is sufficient.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.21459.0.0

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This machine was built three days before filing. That rules out progressive degradation as an
explanation — #31643 reports this class of symptom worsening "over weeks of use," and #66495
describes progressive renderer degradation. Here it was present on a clean Windows install
with a fresh Claude Desktop install from the first launch.

Happy to capture PresentMon/GPUView/ETW traces or test a build with the flag applied — the
transient nature of the spike means Task Manager isn't the right instrument and I'd rather
hand over real data than more prose.

View original on GitHub ↗