[BUG] TaskOutput returns 'No task found' for completed background agents

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When launching multiple background agents via Task(..., run_in_background=true), all agents complete successfully and deliver results via task-notification messages. However, when subsequently calling TaskOutput(task_id, block=true) with the returned agent IDs, it immediately fails with:

Error: No task found with ID: <agent_id>

The first TaskOutput call fails with "No task found", and all sibling parallel TaskOutput calls then cascade-fail with Sibling tool call errored.

This is NOT the same as #20236 (TaskOutput hanging). In #20236, TaskOutput blocks indefinitely. In this bug, TaskOutput returns immediately with an error — the task ID is simply not found in the registry, even though the agent completed moments before.

What Should Happen?

TaskOutput should be able to resolve completed background agent IDs and return their results. At minimum, it should return a clear status like "task already completed, results delivered via notification" instead of the misleading "No task found".

Error Messages/Logs

● Task Output a119d2e26b7e1d671
  ⎿  Error: No task found with ID: a119d2e26b7e1d671

● Task Output ac927dfc6323f6527
  ⎿  Error: Sibling tool call errored

● Task Output a36d9fabfa69a0075
  ⎿  Error: Sibling tool call errored

● Task Output a2c97b68567770109
  ⎿  Error: Sibling tool call errored

All 4 agents had already delivered complete results via task-notification before TaskOutput was called.

Debug log analysis (from /debug/<session>.txt):

• The error does NOT appear as [ERROR] in the debug log — it's returned purely as a tool-level result, making it harder to trace.
• No crash, no stack trace — just a silent "not found" for IDs that were valid moments before.

Steps to Reproduce

1. Launch 4 background agents in a single message (parallel tool calls):

``
Task(prompt="Read files...", subagent_type="Explore", run_in_background=true) // x4
``

1. Each Task call returns successfully with an agentId (e.g., a119d2e26b7e1d671)
2. Wait for all task-notification messages confirming agent completion (all 4 complete within 30-60 seconds)
3. In the next assistant turn, call TaskOutput for each agent ID:

``
TaskOutput(task_id="a119d2e26b7e1d671", block=true, timeout=60000) // x4 in parallel
``

1. Result: First call → No task found with ID: a119d2e26b7e1d671
2. Result: All sibling calls → Sibling tool call errored

Key observations:

• The agents DID complete — notifications with full results arrived
• The agent IDs were returned by the Task tool itself, so they were valid at creation time
• The IDs are no longer resolvable by TaskOutput after completion
• This suggests the task registry purges completed background agent entries before TaskOutput can read them

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.50 (Claude Code)

Platform

Anthropic API

Operating System

WSL (Windows Subsystem for Linux) — Linux 6.6.87.2-microsoft-standard-WSL2

Terminal/Shell

VS Code integrated terminal

Additional Information

Timing context:

• 4 Explore subagents launched simultaneously via run_in_background=true
• Agents completed in 24-64 seconds each
• TaskOutput was called after all 4 task-notification messages had been received
• The gap between last notification and TaskOutput call was approximately 1-2 minutes (user was reviewing output)

Workaround:

• Read the output files directly via Bash tail /tmp/claude-*/tasks/<agentId>.output
• Or simply rely on task-notification messages and don't call TaskOutput at all

Possibly related issues:

• #20236 — TaskOutput hangs (different symptom, possibly same root cause in task lifecycle management)
• #17540 — Session freezes with multiple background agents + blocking TaskOutput
• #24341 — TaskOutput burst polling causes context overflow

Hypothesis:
The task registry appears to have a lifecycle issue where completed background agents are removed from the registry after delivering their task-notification. This creates a race condition: if the model calls TaskOutput after the notification arrives (which is the natural flow), the task ID is already gone. The registry should either:

1. Keep completed task entries for a reasonable TTL (e.g., 5 minutes), or
2. Return a "completed" status with a pointer to the notification data, or
3. Document that TaskOutput is not intended for use after task-notification delivery