Duplicate/stale background-task completion notifications fire repeatedly after the task is already gone

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 20, 2026

Summary

A background subagent (Agent tool, local_agent task) completed and its final report was
delivered once via the normal SubagentHandback/<agent-message> flow. After that, the SAME
task id continued to fire <task-notification status="completed"> events into the session
several more times over a span of roughly 8+ hours, each with an escalating duration_ms,
even though the task no longer exists in the harness's own task registry.

Evidence

Task id: a98e8cf859f0763be (agent: "Build S1: shop location + monster-part catalog",
subagent_type: general-purpose, spawned via the Agent tool).

Sequence of <task-notification> events received for this same task id, well after its
one legitimate SubagentHandback report had already been delivered and acted on:

  • status=completed, duration_ms=887682
  • status=completed, duration_ms=2758930
  • status=completed, duration_ms=2762503
  • status=completed, duration_ms=31052056

Each notification's <result> block pointed back to the same already-delivered handback
message with no new content.

At the time of the later notifications:

  • ListAgents no longer listed the task at all (it had dropped out of the "Subagents" list

entirely — confirmed by calling ListAgents mid-sequence).

  • TaskStop with task_id: a98e8cf859f0763be returned `"No task found with ID:

a98e8cf859f0763be"`.

So the task is fully gone from the harness's own bookkeeping, yet notification delivery for
it kept re-firing, each time waking the parent session to process a duplicate/stale event.

Impact

  • Each duplicate notification consumes a full turn/context-processing cycle in the parent

session for zero new information.

  • In a long session doing multi-agent parallel work (5+ concurrent subagents), this produced

visible noise: the same "agent finished" event had to be manually recognized and dismissed
as a duplicate multiple times.

  • The growing duration_ms across repeats suggests the notification is being regenerated

from some kind of recurring poll/reconciliation pass rather than being a one-shot delivery,
and that pass isn't correctly suppressing already-delivered or already-reaped tasks.

Expected behavior

A background task's completion notification should be delivered exactly once. If a
reconciliation/poll process re-discovers a task in a "just completed" state, it should check
whether that task id has already been reported and/or still exists in the task registry
before re-emitting a <task-notification>.

Environment

  • Claude Code CLI, Windows 10 (10.0.19045), PowerShell primary shell.
  • Session involved ~5 concurrently-running Agent tool subagents (general-purpose) plus one

resumed subagent, all in the same parent session.

View original on GitHub ↗