[BUG] Background sub-agents stay "In esecuzione" in the Activity panel after they've completed

Corroborating this on the same environment: Claude Desktop 1.18286.0 (build 259c3f), macOS, embedded Claude Code engine 2.1.197.

Counted ~15 sub-agents stuck showing as "running" in the Activity panel over a 2-hour window today, none of which were actually active in the harness (same TaskStop/TaskList mismatch described above). While reporting this exact issue, two more phantom "running" entries appeared for agents that had already returned final output — and they were convincing enough that I (the human) assumed the assistant was still mid-task and didn't notice it was waiting on a reply. So beyond the token/trust erosion already noted, this actively stalls conversations: the UI signal that's supposed to tell the user "still working" vs "done, waiting on you" is exactly what's broken.

+1 for prioritizing — this is a session-blocking UX bug, not just a cosmetic one.

Small follow-up data point: stopping the two phantom "running" entries from the Activity panel's own Stop button worked fine (as it always has) — it's specifically the harness-side TaskStop/TaskList calls from the main loop that report them as already gone.

So this isn't just stale UI rendering with nothing behind it — the desktop-level supervisor still has something live to kill for these entries, while the harness's own task registry has already dropped them. Points at the two tracking systems (desktop/UI supervisor state vs. harness TaskList registry) drifting out of sync with each other, rather than one side simply failing to update.

Cross-linking a likely-related report: #73267 (Windows, filed ~5 hours before this one). Same root mismatch — harness-side task tracking (TaskList) correctly shows no active tasks once the agent(s) finish, but the desktop UI's own state never clears — just surfacing on a different UI element there (the whole session's "working" spinner, rather than a per-sub-agent row in the Activity panel here).

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 — a delivery-target bug in the agent-teams hierarchy. This issue is about a completed agent's entry in the desktop UI's Activity panel never clearing, even though the harness (TaskStop/TaskList) already correctly shows it as gone. Confirmed via a live repro: stopping the phantom entry from the UI's own Stop button worked fine, meaning the desktop-side supervisor still has something live to act on — the harness-side registry and the UI/supervisor state are just out of sync with each other. Different subsystem, different symptom.
• Not #61993 ("Sub-agents cannot spawn other sub-agents: Task/Agent primitive not exposed in nested contexts"). That's about the Agent tool being entirely absent from a sub-agent's tool surface. Not related — this issue has nothing to do with nested spawning; it's a single-level agent (no nesting involved) whose UI representation doesn't clear on completion.

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

Confirming this on macOS, same setup as the report.

• Claude Code desktop/web app, model Opus 4.8, Ultracode on.
• One session spawned several background sub-agents via the Agent tool (run_in_background: true), plus a couple of run_in_background shell commands. All of them finished: task-notifications were delivered and the agents returned their final results to the main loop.
• After they finished, the session's background chip keeps pulsing as if it's still working, even when the session is idle and I'm not sending anything.

Same mismatch you describe, checked from the main loop:

• TaskList returns "No tasks found."
• No lingering processes (checked with pgrep and the ports the background shells used).
• The turn ended normally, no pending tool calls.

So nothing is actually running. It reads as stale UI state that never clears once the background sub-agents complete, not real activity. Same symptom as the Windows report in #73267.