Animated gradient causes high WindowServer CPU usage on macOS 26.3 (4K@144Hz+)
Problem
Claude Code displays a continuously-animated gradient light at the top of the terminal window (below the title bar). This animation redraws every frame at the display's refresh rate, causing significant WindowServer CPU overhead on macOS — ~30-40 percentage points at 144Hz.
<img width="1150" height="213" alt="Image" src="https://github.com/user-attachments/assets/ef9d06b3-5381-47be-ab73-3ad83f43ab09" />
This was discovered during a WindowServer CPU benchmarking investigation on macOS 26.3 with an external 4K display at 144Hz. The animation was the dominant contributor to WindowServer CPU usage, dwarfing the actual macOS compositing cost.
Measured impact (macOS 26.3, M1, 2560x1440@144Hz, DP 1.4 DSC)
| Condition | WindowServer CPU |
|-----------|-----------------|
| No Claude Code running | 0-7% |
| Claude Code running in iTerm2 | 36-53% |
| Claude Code running in Ghostty | 37-49% initially, drops to 3-7% after ~15s (Ghostty stops submitting frames when content is static) |
Terminal behavior differences
- iTerm2: Renders the animation at the display refresh rate continuously, even when content is static
- Ghostty: Detects no new content after ~15s and stops submitting frames, causing both its own and WindowServer CPU to drop
- Terminal.app: Lightest on compositor (no GPU-accelerated rendering)
Expected behavior
A setting (e.g., statusBarAnimationEnabled: false or extending prefersReducedMotion) that disables the gradient animation entirely, replacing it with a static indicator.
What doesn't work
prefersReducedMotion: true— does not affect the gradient animation (only covers "spinner shimmer, flash effects")- Custom
statusLinecommand — replaces status text but the gradient animation persists
Environment
- Claude Code (latest as of 2026-02-13)
- macOS 26.3 (25D125)
- iTerm2 3.6.6, Ghostty, Terminal.app
- LG 32GQ950-B 4K display at 144Hz
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗