Windows desktop app: session stuck showing 'working' spinner after background agents complete

Cross-linking a likely-related report: #73400 (macOS, filed ~5 hours after this one). Same root mismatch — harness-side task tracking (TaskList) correctly reports no active tasks once the background agent(s) finish, but the desktop UI's own state never clears — here it's the whole session's "working" spinner that sticks; over there it's individual completed sub-agents staying shown as "running" (In esecuzione) in the Activity panel.

Flagging as related rather than a literal duplicate: different OS (Windows vs macOS) and different UI surface, so worth tracking whether the fix needs to land in one shared desktop-UI/harness sync path or two platform-specific ones. Please don't auto-close either as a dup of the other — they're two manifestations of what looks like the same underlying desync, not the same bug report.

Pre-emptively distinguishing this from two other open issues that share "subagent"/"background agent" vocabulary but describe different bugs, in case a dedup pass clusters them:

• Not #69212 ("Subagent results route to root teammate instead of spawning teammate"). That's about where a nested agent's completion gets routed in the agent-teams hierarchy — a delivery-target bug. This issue is about the session's own "working" spinner never clearing after its background agent(s) finish, confirmed via TaskList returning "No tasks found" while the UI still shows active. No nested/teammate spawning involved.
• Not #61993 ("Sub-agents cannot spawn other sub-agents: Task/Agent primitive not exposed in nested contexts"). That's about the Agent tool being unavailable inside a sub-agent's own tool surface. Unrelated — this report doesn't involve a sub-agent trying to spawn anything; it's the top-level session's UI state failing to sync with harness state after normal (non-nested) background agents complete.

Leaving this note so the two get triaged independently rather than merged.

Confirming this on Windows desktop app as well. Same symptom: after a session's work is completely finished, the session indicator keeps pulsing as if it's still actively working. Opening the session shows the work is actually done and nothing is running — the indicator appears to be stale UI state that doesn't clear on completion, not a reflection of real background activity.

Still present on macOS at 2.1.220, so this is not Windows-specific and has survived ~214 releases since the original report.

Environment

• Claude Code 2.1.220, macOS 26.5.2 (25F84), arm64
• Viewed via the mobile Remote control surface attached to a CLI session
• Model: Opus 5

Sequence

1. Turn spawned one background subagent via the Agent tool (a code-review agent).
2. The agent completed; its task-notification was delivered and I acted on the results.
3. The turn ended normally — final text message, no pending tool calls, no queued input.
4. The session continued to render the working indicator, with Queue for after this turn… in the composer.

Verified idle at the time the spinner was showing

$ ps -eo pid,etime,command | grep -E 'gh run watch|pytest|xcodebuild' | grep -v grep
(no output)

No background shell processes, no watchers, no scheduled wakeups, no live subagent. The only recent artifacts were completed task output files.

Impact
Low severity but real: the operator could not tell whether work was in flight, and asked directly whether anything was still running. On a long session that ambiguity is the whole value of the indicator — an indicator that can be wrong in the 'busy' direction trains people to ignore it.

Matches the original report in that it followed background-agent completion, and that no tokens appeared to be consumed — UI state only.

Happy to add more detail if a specific artifact would help (agent invocation shape, notification timing, etc.).