[BUG] Claude Desktop 1.22209.0 (macOS 26.5.1): Chat UI causes system-wide input lag (WindowServer 43–48% while streaming, 80–102% renderer spikes opening chats) — Code-only sessions unaffected, resolves when app quits

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?

Summary: With the Claude Desktop app open on macOS, the Chat UI causes system-wide input lag — typing is delayed/dropped in ALL apps (Korean IME composition visibly breaks into stray jamo), and clicks feel like they double-fire. Two clean discriminators:

1. App fully quit → zero lag, all day (verified after reboot, living without the app open).
2. App open but using Claude Code sessions only → no lag.
3. Chat UI in use (opening conversations, response streaming) → system-wide lag. Reproduces even without opening any artifact-containing chat.

Measurements (Activity Monitor, sample, and a detached nohup sampler to avoid measuring our own turn):

• Idle after a turn ends: Claude Helper (Renderer) 0.5–2%, WindowServer 2–5% → normal.
• While a session is streaming / "working" spinner is animating: WindowServer 43–48%, renderer 21–45% → input latency everywhere, IME composition breaks.
• Opening any chat conversation: renderer momentarily spikes to 80–102%.
• Keeping a chat with an HTML artifact preview on screen: renderer sustained ~31%p higher (0.6% → 31–32%, back to ~5% on close). But note again: the lag reproduces without any artifact chat open.
• App startup: sample of the renderer shows CPU dominated by v8 ValueSerializer — looks like MCP tool-schema serialization. Pruning user-scope MCP servers (~230 remote tool schemas removed) made startup lighter but did NOT fix the chat-UI lag.
• Confounder we eliminated: ChatGPT desktop (another Electron app) idling added ~30%p to WindowServer (40.9% → 9.6% when quit). Even with it quit, Claude chat UI alone reproduces the lag.

Possibly related: #74944 (Cowork sidebar file preview wedges GPU process into busy-loop). Different signature though — that one survives closing the preview; this one correlates strictly with the chat UI drawing and fully resolves the moment the app quits.

What Should Happen?

Having the chat UI open — or a response streaming — should not push WindowServer/compositor load high enough to delay keyboard and mouse input system-wide. The working/streaming animations should be cheap or throttled (e.g. pause offscreen work, cap repaint rate) so that opening a conversation or waiting for a response never degrades typing in other apps. Idle behavior is already correct (0.5–2%); the drawing paths (conversation open, streaming spinner) are what need the same discipline.

Error Messages/Logs

Detached sampler excerpts (2026-07-18, KST):

While my session's turn was running (spinner/streaming):
  11:15:35-44  WindowServer 43-44% | Claude Helper (Renderer) 21-31%
After the turn ended (true idle):
  11:15:48-52  WindowServer 2-5%  | Claude Helper (Renderer) 0.5-2%

Opening chat conversations (no artifacts in them):
  renderer spike 80.8% -> settles to 5.0% after ~4s
  renderer spike 102.5% on another open

HTML artifact preview A/B:
  no preview: renderer 0.6% -> preview open: 31-32% sustained -> closed: 5.8%

App startup `sample "Claude Helper (Renderer)"`:
  top frames dominated by v8::ValueSerializer / ValueDeserializer
  (MCP tool schema serialization; ~230 remote tool schemas at the time)

Electron confounder eliminated:
  quitting idle ChatGPT desktop: WindowServer 40.9% -> 9.6%
  (Claude chat UI alone still reproduces the lag afterwards)

Steps to Reproduce

1. macOS 26.5.1, Claude Desktop 1.22209.0. Open the app and use only Claude Code sessions → input stays responsive system-wide.
2. Switch to the Chat side: open any conversation (no artifacts needed) → renderer spikes 80–102% for a few seconds; repeat while typing in another app and keystrokes stutter.
3. Send a message and let the response stream / "working" spinner animate → sample WindowServer and "Claude Helper (Renderer)" with top -o cpu or a detached sampler: WindowServer sits at 43–48%, renderer 21–45% for the duration of the turn. Typing in ANY app lags; Korean IME composition breaks into stray jamo.
4. Quit Claude entirely (Cmd+Q) → WindowServer back to 2–5%, no lag for the rest of the day.
5. (Amplifier, optional) Keep a chat with an HTML artifact preview visible → renderer holds 31%+ until the preview closes.

Measurement caveat that may explain why this is underreported: if you measure DURING your own diagnostic turn, the app's working animation contaminates the sample. Use a detached (nohup) sampler and read it after the turn ends — idle values look perfectly normal (renderer 0.5–2%), which hides the problem.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.198 (Claude Code) — Desktop app 1.22209.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Usage context: claude.ai Max subscription via the Claude Desktop app (Chat + Claude Code/Cowork in the same app). The comparison between the two surfaces of the SAME app is what isolates this to the chat UI: Code-tab-only usage never lags, chat usage does.

Setup: macOS 26.5.1 (25F80), Claude Desktop 1.22209.0. "Reduce Transparency" was considered as a mitigation but has not been validated.

Regression note: marked "I don't know" — no earlier clean baseline to compare against (the lag was initially masked by other factors we eliminated one by one: login-item storm after boot, MCP schema serialization at startup, an idling ChatGPT Electron app).

Filed on behalf of the user from their measurement logs (Activity Monitor, sample, detached shell sampler). Happy to run additional instrumented captures (sample WindowServer, powermetrics, Chromium tracing) on request.