[BUG] Named Agent subagents unaddressable by Task tools — TaskOutput/TaskStop reject the agent_id the spawn result returns ("No task found with ID")

Preflight Checklist

• [x] I searched existing issues and found adjacent reports (#75092, #73916, #74614) but none covering this exact case: the agent_id returned by a named Agent spawn is not accepted by any Task tool.
• [x] This is a single bug report.
• [x] I am using the latest Claude Code version (2.1.210, current npm version at filing time).

What's Wrong?

When the Agent tool is invoked with a name, the spawn goes async and the tool result returns an agent identifier:

Spawned successfully.
agent_id: report-tester@session-<uuid-prefix>
name: report-tester
The agent is now running and will receive instructions via mailbox.

That agent_id (and the bare name) is not accepted by any task-addressing tool. Every attempt to retrieve the subagent's output by ID fails:

• TaskOutput(task_id: "report-tester@session-<uuid-prefix>") → No task found with ID: report-tester@session-<uuid-prefix>
• TaskOutput(task_id: "report-tester") → No task found with ID: report-tester
• TaskList returns No tasks found — it is the shared to-do list, a separate system that never contains Agent spawns.

The subagent itself is healthy the whole time: its final report is delivered to the parent as a pushed teammate/task notification, and SendMessage(to: "report-tester") round-trips correctly, resuming the idle agent from its transcript.

So the delivery mechanism works, but the addressing surface is a trap: the spawn result hands the model an ID that nothing accepts, the error message doesn't say what the correct channel is, and there is no discoverable mapping from agent_id to anything TaskOutput/TaskStop recognizes. In practice the parent model concludes the subagent's report is lost and either retries TaskOutput in a loop or reports failure to the user — which is exactly how this was discovered.

What Should Happen?

One of:

1. Named Agent spawns are registered in the task registry so TaskOutput/TaskStop accept the returned agent_id (or the name), or
2. The spawn result and the error message state the correct retrieval channel explicitly, e.g. No task found with ID: <id>. Named agents are not tasks; their final message is delivered automatically, and follow-ups use SendMessage(to: <name>).

Either resolves the failure mode; today neither the tool result, the error, nor the docs bridge the gap.

Error Messages/Logs

> TaskOutput {"task_id": "report-tester@session-<uuid-prefix>", "block": false, "timeout": 5000}
No task found with ID: report-tester@session-<uuid-prefix>

> TaskOutput {"task_id": "report-tester", "block": false, "timeout": 5000}
No task found with ID: report-tester

> TaskList {}
No tasks found

Steps to Reproduce

1. In any session, invoke the Agent tool with a name:

``json
{
"subagent_type": "general-purpose",
"description": "Produce tiny test report",
"name": "report-tester",
"prompt": "Return a 3-line report ending with the literal line REPORT-DELIVERY-TEST-OK."
}
``

1. Observe the tool result returns agent_id: report-tester@session-<...> and the spawn goes async ("will receive instructions via mailbox") — note this happens even without run_in_background (see #74614).
2. Call TaskOutput with that agent_id → No task found with ID.
3. Call TaskOutput with the bare name → same error.
4. Call TaskList → empty (different system).
5. Wait: the subagent's report nonetheless arrives as a pushed teammate notification, and SendMessage(to: "report-tester") works for follow-ups — confirming the ID-based tools are the only broken surface.

Claude Model

claude-fable-5 (parent and subagent).

Is this a regression?

I don't know. Adjacent reports suggest the task-registry/agent-identity mismatch is long-standing: #75092 (TaskStop finds no task), #73916 (TaskStop can't reach nested background sub-agents), #74614 (run_in_background: false ignored when the dispatch includes a name).

Claude Code Version

2.1.210 (Claude Code)

Platform

macOS CLI.

Operating System

macOS 26.5 / Darwin 25.5.0.

Terminal/Shell

zsh.

Additional Information

• TaskOutput is marked DEPRECATED in its own tool description, but it remains the only pull-style retrieval tool exposed, and models reliably reach for it when a spawn result hands them an ID. If the deprecation is the intended answer, the spawn result should stop returning an ID that looks addressable, or the error should redirect to the working channel.
• Related: #75092, #73916, #74614.