GUI app: "thinking" indicator (✳) animation can freeze while the session is still actively working

Summary

In the desktop/web GUI app, the in-conversation "thinking" glyph (the coral ✳ asterisk shown below the transcript while Claude works) can stop animating entirely while the session is still alive and actively working. The glyph stays on screen but completely frozen, making healthy in-progress work look hung. A separate indicator — the per-session activity dot in the left-hand Recents list — keeps pulsing correctly the whole time, so the two indicators visibly disagree.

Expected vs actual

• Expected: while a session is working, the ✳ asterisk animates continuously (it normally "breathes"/flickers), and stops when work ends.
• Actual: the ✳ can freeze mid-work — zero animation — while the session is demonstrably still alive and producing output. A frozen asterisk is indistinguishable from a hang.

Evidence (frame-level measurement of one 10.6s screen recording, GUI app)

A 10.6s, 60fps screen recording was decomposed and the per-pixel brightness of each indicator measured across frames:

1. ✳ asterisk (main panel) — FROZEN. Over 159 frames @15fps its pixel brightness had std 0.00, range 0.03/255. Zero pulse/shimmer for the full 10.6s.
2. Session dot (Recents sidebar) — PULSING normally over the same clip; peak brightness oscillated 75 ↔ 137 /255 on a ~1s cycle:

119 111 87 137 76 132 95 101 126 77 137 82 118 114 83 136 75 131 94 100 125

1. The screen was live, not a frozen capture: the mouse cursor moved throughout; only the transcript text and the asterisk were static. So this is a genuine render stall of that one element, not a recording artefact.

Conclusion: the session was alive and working the entire time (proved by the pulsing heartbeat dot and by output resuming), yet the asterisk's animation loop had stalled — a render-thread stall decoupled from actual session state.

(Screenshots of the frozen asterisk and the bright-vs-dim dot can be attached.)

Impact

Users can't distinguish "busy" from "stuck" using the most prominent indicator, which drives unnecessary interrupts/restarts of healthy work and erodes trust in the indicator. Most likely during long turns, background tasks, or auto-continue loops where the asterisk sits visible for many seconds between output.

Suggested fixes

1. Drive the ✳ animation from the same session-activity source of truth as the sidebar dot (the dot stayed correct).
2. Watchdog the animation loop: if sessionState == working but the asterisk frame hasn't advanced for N ms, restart/repaint it.
3. Make "working" legible without relying on the single asterisk (surface the pulsing dot or an explicit "working…/elapsed" affordance in the main panel).

Environment

• App: Claude Code desktop/web GUI app — version: latest desktop app (2026-06-29)
• Model: Opus 4.8
• OS: macOS (Darwin 25.5.0), Apple M5