[BUG] Windows desktop: idle session's activity dot keeps blinking forever AND burns ~10% CPU in the background (runaway loop, cleared only by restarting the app)

Resolved 💬 2 comments Opened Jun 29, 2026 by muhammetozeski Closed Jul 2, 2026
Note: This issue was written and filed by Claude Code (Opus 4.8) on behalf of the user.

What's wrong?

In the Claude Code Windows desktop app, every session in the left sidebar has a small activity dot. It is supposed to blink/pulse while Claude is actively working in that session, and stop once the turn is finished. This works correctly for most sessions.

However, one specific session got stuck with the dot blinking forever. It keeps blinking even when all of the following are true at the same time:

  • Claude has stopped responding in that session — the turn is fully finished.
  • No related Windows background process is running.
  • No background subagent / background task is running.

In the same window, two other sessions behaved correctly (their dots stopped blinking when idle). Only the one affected session stayed stuck in the perpetual-blinking state.

What should happen?

The activity dot should blink only while Claude is actively working in that session, and return to its idle (solid / non-blinking) state as soon as:

  • the turn has finished, and
  • there is no background process and no background subagent still running for that session.

Actual behavior

The dot for the affected session blinks indefinitely and never returns to idle, even though the session is completely idle with nothing running in the foreground or background.

CPU / performance impact (likely a runaway background loop)

This is not just a cosmetic stuck indicator — while a session is in this perpetual-blinking state, the Claude desktop GUI process sits at ~10% CPU continuously, and the machine's fans spin up and stay loud.

Evidence that the cost is tied to this state and is recoverable by a restart:

  • While the dot is stuck blinking: GUI process ~10% CPU, fans ramped up.
  • Fully quitting the Claude desktop app: CPU usage drops and the fans calm down.
  • Reopening the app: the affected session is no longer in the blinking state, and the fans stay calm again.

This strongly suggests something is stuck in a loop in the background (e.g. an animation/render loop or a polling loop) that:

  • is not driven by any user request, and
  • is not tied to any foreground/visible operation, and
  • never terminates on its own — it only clears when the whole app is restarted.

Working theory

A background loop for the session enters a state where it keeps running (and keeps the dot animating) even though the session has gone idle. Because it's detached from any actual foreground work or background task, nothing ever tells it to stop, so it burns CPU until the app is fully closed and reopened.

Steps to reproduce

This is intermittent — most sessions behave correctly, and only occasionally does a single session enter this stuck state.

  1. Use the Windows desktop app with multiple sessions in the sidebar.
  2. Run work in a session until it fully finishes (no foreground turn in progress, and no background tasks/subagents left running).
  3. Observe that session's activity dot in the sidebar.
  4. Usually: the dot stops blinking once the session goes idle (correct).
  5. Sometimes: the dot for one session keeps blinking permanently even though nothing is running for it.

Frequency / regression

  • Frequency: intermittent. The normal/expected path happens most of the time; the bug appears for a single session now and then, and once it appears it persists for that session.
  • Regression: unknown.

Environment

  • Platform: Windows 11
  • Surface: Claude Code Windows desktop app (GUI)
  • Model used in the affected session: Opus 4.8

Related

  • #71587 is a related feature request (the dot should reflect background-task activity). This report is different: here the dot keeps blinking when there is no activity at all — a stuck/stale "active" indicator that never clears.

Notes

  • A redacted screenshot (session names and message text removed) that points to the affected session can be provided on request. Because the bug is an animation (a continuously blinking dot), a static screenshot only shows which session is affected, not the blinking itself.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗