Stop hook false-positive: stale subagent IDs block session end

Resolved 💬 4 comments Opened Apr 15, 2026 by benjibradley Closed May 28, 2026

Bug

When a Stop hook is configured and subagents (via the Agent tool) were used during a session, subsequent stop attempts are blocked by an internal runtime check with:

Stop:Callback hook blocking error from command: "callback": Background subagents are still running. Use `TaskOutput task_id="..." block=true` to wait for their results before ending your turn.

However, all subagents have completed and TaskOutput returns "No task found" for every agent ID.

Repro steps

  1. Configure a Stop hook that blocks on the first stop attempt (e.g. to prompt for end-of-session questions), then allows on subsequent attempts via a state file gate.
  2. During the session, spawn multiple subagents via the Agent tool. Let them all complete and consume their results.
  3. The Stop hook fires correctly on the first stop attempt — blocks, surfaces the prompt, works as intended.
  4. After addressing the prompt, attempt to stop again.
  5. Expected: The Stop hook allows (state file exists), session ends.
  6. Actual: The runtime's internal pre-stop check detects stale agent IDs and blocks with the "Background subagents are still running" error. The Stop hook never fires because the runtime blocks first.

Root cause (hypothesis)

Claude Code's task lifecycle tracking retains completed agent/task IDs in an active-task registry. When the Stop hook blocks and forces a new turn, the runtime's pre-turn/pre-stop check sees these stale IDs and assumes tasks are still running. TaskOutput correctly reports "No task found" — the tasks are genuinely done, but the registry wasn't cleaned up.

Environment

  • Claude Code Desktop (Code tab), v1.2581.0+
  • macOS (Apple Silicon)
  • Max plan, Opus 4.6
  • Stop hook: Python script using {"decision": "block", "reason": "..."} protocol
  • 4 subagents spawned via Agent tool (all foreground, all completed)

Workaround

The user can continue chatting past the error. The session isn't truly stuck — it just can't cleanly stop until the stale IDs are somehow cleared.

View original on GitHub ↗

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