Claude Code Desktop: WindowServer at ~47% CPU while a response streams (deep CoreAnimation layer tree re-walked at 120 Hz)

Independent reproduction on materially different hardware, plus stack evidence from a different phase of the same pipeline than the one in the original report.

Short version: this is still present in Desktop 2.2553.1 on macOS 27.0, and on a weaker GPU driving a higher-refresh external display the cost roughly doubles — WindowServer reaches 55% of a core with only the working spinner animating, before any token streaming.

Environment

| | This report | Original report |
|---|---|---|
| Claude Desktop | 2.2553.1 | 1.52386.3 |
| macOS | 27.0 (26A428) | 26.6.2 (25G83) |
| SoC / GPU | M1, 7-core GPU | M3 Pro, 14-core GPU |
| Display | External 4K, 3840×2160 HiDPI @ 160 Hz, main display, mirrored to built-in 2560×1600 | Built-in XDR, 3024×1964 @ 120 Hz |
| Electron / Chromium | 44.2.0 / 152.0.7977.76 | — |

So: 1.5× the refresh rate, 1.6× the framebuffer pixels, half the GPU cores, and a mirrored second display pipeline.

Measurements

Measured as real CPU-seconds consumed over a fixed 30 s window (ps -o cputime= delta) rather than instantaneous %CPU:

| Process | Working spinner animating, no token streaming |
|---|---|
| WindowServer | 55.3% of a core |
| Claude Helper (GPU process) | 15.4% |
| Claude Helper (Renderer) | 15.7% |

Supporting signals:

• IDLEW = 0 on the GPU helper — it never returns to idle. This is sustained vsync-paced rendering, not a timer/wakeup busy-loop (which distinguishes it from #74944, whose signature was 690–740 idle wake-ups/sec).
• Per-second sampling over 40 s gives r = 0.669 between WindowServer CPU and Claude GPU-helper CPU.
• Quitting Claude Desktop restores smooth system-wide UI immediately and repeatably.
• WindowServer produced its first-ever cpu_resource.diag on this machine while Claude was open: "90 seconds cpu time over 178 seconds (51% cpu average), exceeding limit of 50% cpu over 180 seconds."

⚠️ One caveat on my own numbers: an earlier reading of 91% / 44% was taken while post-OS-upgrade background work (Spotlight reindex, mobileassetd, CoreSimulator runtime installs, dasd) was still saturating the machine. Disregard that pair. The 55.3% / 15.4% figures above were taken after verifying that all of it had gone quiescent.

Difference worth noting: the trigger threshold is lower here

The original report finds idle at 3–6% and only streaming at 41–51%. On this configuration I measure 55.3% with no token streaming at all — only the Code session's working spinner animating while a shell command ran. If the cost scales with refresh rate × framebuffer area as the layer-tree explanation predicts, then a 160 Hz 4K panel on a 7-core GPU crosses into "system-wide lag" territory from animations far cheaper than streaming text. That matches what the user experiences: the machine is unusable whenever Claude is open and doing anything at all.

This also suggests the original report's finding that external displays are not a factor may not generalise. On an M3 Pro with 14 GPU cores there is enough headroom to absorb it; on a 7-core M1 driving a mirrored 4K@160 Hz main display there is not.

Stack evidence from the render phase (complements the prepare-phase stack above)

The original report's stack lands in the prepare/commit phase — prepare_coreanimation → ca_prepare_begin_window_update → CA::Render::Updater::prepare_layer0 / prepare_sublayer0, ~50 levels deep. That is the CPU-side layer-tree walk.

From /Library/Logs/DiagnosticReports/WindowServer_*.cpu_resource.diag (Microstackshots) on this machine, 12 of 13 samples land in the per-frame display update, but in the render phase instead:

CGXRunOneServicesPass → post_port_data → non_coalesced_timer_handler
  → run_timer_pass → update_display_callback → CGXUpdateDisplay
    → WS::Updater::UpdateDisplays
      → WS::Displays::SLCADisplay::render_update
        → CompositorMetal::CompositeLayersToDestination
          → CompositorMetal::composite → MetalCompositeLayers → MetalCompositeLayer
            → WSSessionConnectionPerformWithPluginOwner
              → CARenderOGLRenderDisplayWithOptions → CA::OGL::render
                → CA::OGL::Renderer::render
                  → CA::OGL::render_layers
                    → CA::OGL::ImagingNode::render
                      → CA::OGL::LayerNode::apply
                        → CA::OGL::render_layers
                          → CA::OGL::ImagingNode::render
                            → CA::OGL::LayerNode::apply
                              → ... this triple repeats ~25 levels deep ...

Also appearing inside the recursion:

CA::OGL::ImagingNode::retain_surface(float&, unsigned int)
CA::OGL::FlattenNode::retain_surface(float&, unsigned int)

Why this matters beyond the tree walk: ImagingNode is a CoreAnimation filter layer, and each retain_surface allocates an offscreen buffer. So the nested layers are not only being walked every refresh — they are being re-rendered as ~25 stacked filter passes with offscreen surface allocation, at 3840×2160, every frame. That is consistent with a detail I could not otherwise explain: during the worst period WindowServer's footprint reached 1311.97 MB, against roughly 90 MB when idle.

Caveat: that report contains only 14 samples, so treat the stack as indicating where the work is, not as a precise profile. The 55.3% figure is from direct measurement and does not depend on it.

Taken together with the prepare-phase stack already in this issue, the nesting appears to cost twice per frame — once walking the tree, once rendering the filter chain into offscreen surfaces.

On mitigations

I did not independently re-test the ⌘H or window-size workarounds reported above, so I am not claiming to have confirmed them — I am only adding the measurements and stacks described here.

What I did check: no user-facing mitigation is exposed by the app. The app's Preferences and Local State contain no GPU, rendering, animation or transparency keys. Related: #25575's reporter documented that prefersReducedMotion: true does not suppress the animation, and the statusBarAnimationEnabled: false setting requested there still does not exist.

Suggested fix, in the order that would help this configuration most

1. Cap the animation's repaint rate so it does not scale with panel refresh rate — drive it at 30–60 fps regardless of 120/160/240 Hz. This alone would remove most of the cost here.
2. Flatten the animated region into a single composited layer, as already proposed in this issue. The ImagingNode chain above suggests specifically collapsing the nested filter layers, which are the expensive ones.
3. Stop the animation when content is static — a spinner should not cost 55% of a core.
4. Honour prefers-reduced-motion for this animation, and add the opt-out requested in #25575.

Related closed reports

Same signature, all closed without a fix, spanning March → July 2026 and Desktop 1.1.x → 1.22209.0: #78770, #33526, #32020, #74944, #25575. With this report the behaviour is confirmed to have survived into 2.x on macOS 27.

Reproduction

1. Apple Silicon Mac, external display at ≥120 Hz, HiDPI. The weaker the GPU and the higher the refresh rate, the more pronounced.
2. Open a Claude Desktop Code session; run any shell command so the working spinner animates. No token streaming needed.
3. Measure real CPU consumption over 30 s rather than reading instantaneous %CPU:

tosec(){ awk -F: '{if(NF==3)print $1*3600+$2*60+$3; else print $1*60+$2}'; }
cpu(){ ps -o cputime= -p "$1" | tr -d ' ' | tosec; }
WS=$(pgrep -x WindowServer); a=$(cpu $WS); sleep 30; b=$(cpu $WS)
echo "WindowServer: $(echo "($b-$a)/30*100" | bc -l)% of one core"

1. Quit Claude Desktop entirely (⌘Q, not just closing the window) and repeat.
2. Verify background OS activity is quiescent for both measurements — dasd, mds_stores, mobileassetd and Spotlight indexing will otherwise contaminate the reading. This is how I produced the bad 91% pair above.

Follow-up to my previous comment — I located the specific CSS rule that produces the nested filter layers, by reading the shipped bundle. The good news: it is already guarded by prefers-reduced-motion, so the fix is small and a user-side workaround may already exist.

Source: Claude.app/Contents/Resources/app.asar → .vite/renderer/main_window/assets/MainWindowPage-CVdxcOi4.css (Desktop 2.2553.1).

The animated element

.cds-root [data-cds-shimmer-clone]{
  -webkit-mask-image: linear-gradient(#000 0 0);
  -webkit-mask-clip: text;
  position: absolute; inset: 0; overflow: clip;
}
.cds-root [data-cds-shimmer-clone]:after{
  background-image: linear-gradient(120deg, transparent 37.5%,
                    var(--cds-shimmer-text-peak, transparent) 50%, transparent 62.5%);
  animation: 3s linear infinite cds-shimmer-text-band;
  animation-play-state: var(--cds-shimmer-text-play-state, running);
  inset: 0 -300% 0 0;
  translate: -62.5%;
}
@keyframes cds-shimmer-text-band{
  0%,15%{ translate:-62.5% } 85%,to{ translate:-12.5% }
}

Why this lands in CA::OGL::ImagingNode

-webkit-mask-image combined with -webkit-mask-clip: text forces CoreAnimation to build a mask/filter layer, which is exactly what an ImagingNode is. The animated pseudo-element is inset: 0 -300% 0 0 — four times the element width — and it animates translate continuously, so the masked filter layer is re-rendered every display refresh. Each masked text run gets its own clone element, so instances nest and stack.

That ties the CSS directly to the render-phase stack in my previous comment: CA::OGL::render_layers → ImagingNode::render → LayerNode::apply, repeating ~25 levels, with ImagingNode::retain_surface / FlattenNode::retain_surface allocating an offscreen buffer per level, at 3840×2160, every frame.

The guard already exists

Every one of the six infinite animations in this stylesheet is already guarded, two ways — a media query and an attribute selector:

@media (prefers-reduced-motion: reduce){
  .cds-root [data-cds-shimmer-clone]{ display: none }
}
.cds-root:where([data-reduce-motion=true], [data-reduce-motion=true] *)
  [data-cds-shimmer-clone]{ display: none }

The same pattern covers .cds-dot (dot-pulse), .cds-flipbook, the three SkeletonGroup animations (cds-skeleton-breathe, cds-skeleton-sweep), .cds-chip-in, and .cds-resolve-square / .cds-resolve-check.

But there is no way for a user to reach either guard. Searching the bundle: data-reduce-motion appears 220 times — all of them CSS selectors — while reduceMotion, reducedMotion and reduce_motion appear 0 times in the renderer JavaScript. So nothing in the app ever sets data-reduce-motion=true, and the app exposes no setting for it (Preferences and Local State contain no animation, rendering or GPU keys). The only remaining route is the OS-level accessibility setting, or forcing the media query at the Chromium level.

Suggested fix, smallest first

1. Cap cds-shimmer-text-band's repaint rate so it does not scale with panel refresh. At 160 Hz this animation is driving ~55% of a WindowServer core on a 7-core M1; at 30–60 fps it would be a fraction of that, and visually identical to most users.
2. Expose the existing guard. data-reduce-motion=true is already fully wired in CSS — surfacing it as a setting, or setting it from the OS reduce-motion preference, would cost close to nothing and give affected users an immediate opt-out. This is also what #25575 asked for as statusBarAnimationEnabled: false.
3. Avoid the masked-gradient construction for the shimmer. A 4×-width masked gradient layer is the expensive part. Animating background-position on a single non-masked layer, or compositing the band as one flattened layer, would remove the nested ImagingNode chain rather than just running it less often.
4. Pause it when the window is unfocused or content is static — animation-play-state is already parameterised via --cds-shimmer-text-play-state, so the hook is there.

Caveat on the workaround

I have not yet verified that Chromium's --force-prefers-reduced-motion actually reaches the renderer in this Electron build (44.2.0 / Chromium 152.0.7977.76) — only that the CSS guard it would trigger exists and targets the right element. If it does work, it is a clean app-scoped workaround that requires no display or system changes. I will follow up with measurements either way.

Measured follow-up, as promised. Forcing the existing prefers-reduced-motion guard works, and it is a large win.

Launching Desktop 2.2553.1 with Chromium's --force-prefers-reduced-motion, same machine and same display configuration as my earlier comment (M1 7-core GPU, 3840×2160 HiDPI @ 160 Hz, mirrored), 30 s measurement windows, real CPU-seconds consumed:

| Process | Default launch | --force-prefers-reduced-motion | Change |
|---|---|---|---|
| WindowServer | 55.3% | 29.2% | −47% |
| Claude Helper (GPU) | 15.4% | 2.3% | −85% |
| Claude Helper (Renderer) | 15.7% | 4.9% | −69% |

No display, refresh-rate, mirroring or system accessibility settings were changed — the flag is scoped to the Claude process alone. This confirms that the @media (prefers-reduced-motion: reduce){ … display:none } guard identified in my previous comment is on the right element, and that the shimmer animation accounts for the large majority of the GPU-helper cost and roughly half of the WindowServer cost on this configuration.

This is the strongest argument for suggestion 2 in my previous comment: the guard is already written and already correct. Wiring data-reduce-motion=true to a setting, or honouring the OS reduce-motion preference, would hand every affected user this result with no rendering work at all.

Practical notes for anyone trying to reproduce this

• A cold start is required. open -a Claude --args --force-prefers-reduced-motion silently drops the arguments if Claude is already running — macOS only passes --args on launch. Quit fully with ⌘Q first (closing the window is not enough).
• The flag does not appear on the helper processes' command lines. Electron keeps it on the main process only:

``
/Applications/Claude.app/Contents/MacOS/Claude --force-prefers-reduced-motion
`
Checking ps` output for the helpers will make it look like the flag was ignored. It was not — judge by the numbers.

• Measure real CPU-seconds over a fixed window rather than instantaneous %CPU, and verify no OS background work is competing (see the reproduction steps in my first comment).

Two things this does not settle

1. WindowServer is still at 29.2%, well above the 3–6% idle baseline reported at the top of this issue. Both of my measurements ran while an unrelated runaway dasd loop was consuming a full core on this machine, so I cannot attribute the remainder — the true post-flag figure is likely lower than 29.2%, and I have no clean reading yet for what is left. I will not speculate about the residual.
2. This avoids the cost rather than reducing it. Users lose the shimmer, skeleton-breathe, dot-pulse and related animations entirely. That is an acceptable trade when the alternative is system-wide input lag, but it is a workaround, not a fix. Rate-capping the animation (suggestion 1) would keep the visual and remove the pathology.