[BUG] Subagent card stays 'running' after completion notification is delivered; only manual stop freezes it, then persists as a ghost card visible from another session

Summary

A background subagent (Agent tool, run_in_background) completed its work and its <task-notification> was enqueued and delivered to the correct parent session — yet the TUI agent card kept showing it as "running", with the elapsed-time counter still ticking, for another 15 minutes until the user manually stopped it. The manual stop was recorded on disk ("stoppedByUser": true), but the frozen card still remained visible, including from a different chat session in the same project.

On-disk bookkeeping is fully consistent (completion delivered, stop recorded); only the UI card state never reconciles. This looks like the CLI-TUI sibling of #75085 (remote-control web UI badges) and #68992 (desktop mirror), with the added evidence that notification delivery provably succeeded — so the routing bug #76174 is ruled out for this case.

Environment

• Claude Code CLI 2.1.212, Linux 6.8.0-124-generic (x86_64), zsh, tmux
• Long-running orchestrator session (~186 MB session .jsonl)
• Possibly relevant setup detail: multiple CLAUDE_CONFIG_DIR accounts on one machine whose projects/<project>/*.jsonl session files are hardlinked across the config dirs, all served by a single claude daemon process (~/.claude/daemon.json). This did not cause the stale state (delivery was correct) but may explain why the ghost card was visible from a second session.

Timeline (all from on-disk transcripts, 2026-07-17 UTC)

| Time | Event | Evidence |
|---|---|---|
| 19:00:27Z | Subagent spawned (general-purpose, sonnet) via Agent tool | first line of subagents/agent-<id>.jsonl |
| 19:55:34Z | Completion <task-notification> enqueued for the parent session | {"type":"queue-operation","operation":"enqueue",...} in parent session jsonl |
| 19:55:34Z+ | Same notification delivered into the parent conversation | user-role <task-notification> entry immediately after |
| ~20:09Z | Card still ticking; user messages the agent "did you report back and done!?"; agent wakes and replies "Yes — done and reported" | tail of agent jsonl |
| 20:10:10Z | Second completion notification enqueued + delivered | parent session jsonl |
| 20:10:45Z | User manually stops the task | agent-<id>.meta.json mtime; content ends "stoppedByUser":true |
| after | Card persists, frozen at "1h 10m 17s" (= spawn → manual stop, to the second) — still rendered later, and visible from a different session in the same project | user observation |

The card's displayed elapsed time (1h 10m 17s) exactly matches spawn→manual-stop (1h 10m 18s), not spawn→actual-completion (~55m): the timer demonstrably kept running through a successfully delivered completion notification and only froze on manual intervention.

Expected

When a background subagent's completion notification is delivered to its parent session, the agent card transitions to a completed state (and eventually clears). A manually stopped task's card should also clear, and cards should not render in sessions that did not spawn the task.

Got

Card remained "running" with a live timer for 15+ minutes after delivered completion; survived a recorded manual stop as a frozen ghost card; and was rendered in a different chat session than the one that spawned the agent.

Related

• #75085 — same symptom in remote-control web UI badges
• #68992 — same symptom in desktop-mirrored conversations
• #76021 — we also observed two completion notifications for this agent, though a mid-turn user message to the agent sat between them, so the second may be legitimate
• #76174 — ruled out here: delivery provably reached the correct session