Agent tool: passing `name:` creates a teammate that never runs its prompt and never reports back

Summary

Passing name: to the Agent tool silently changes what is created. Instead of a task-running subagent, the harness creates an agent-team teammate that never executes the prompt it was spawned with, produces no output file, does not appear in ListAgents, and never returns a result. The Agent call still reports success, so the caller believes a task is running.

The Agent tool's own description presents name as purely additive — "Name for the spawned agent. Makes it addressable via SendMessage({to: name}) while running." Nothing indicates it changes delivery semantics or suppresses the completion notification.

The practical cost is severe for orchestration: a fan-out of named agents consumes tokens, reports nothing, and cannot be observed with ListAgents. In one measured case three Opus reviewers budgeted at ~450k tokens produced zero output, and the stall was only noticed because a human watching the agent panel said the counters were still climbing.

Reproduction

Two Agent calls in the same message. Same model, identical one-word prompts. The only difference is name.

// A — no name
{ "description": "Probe unnamed agent return", "model": "haiku",
  "prompt": "Reply with exactly the word PONG-UNNAMED and nothing else. Do not call any tools." }

// B — with name
{ "description": "Probe named agent return", "name": "probe-named", "model": "haiku",
  "prompt": "Reply with exactly the word PONG-NAMED and nothing else. Do not call any tools." }

A — expected behaviour

Async agent launched successfully.
agentId: a2123954573badad6
The agent is working in the background. You will be notified automatically when it completes.
output_file: /tmp/.../tasks/a2123954573badad6.output

ListAgents showed it under Subagents (1) · general-purpose · completed. A completion notification arrived carrying the result:

<result>PONG-UNNAMED</result>
<usage><subagent_tokens>34053</subagent_tokens><tool_uses>0</tool_uses><duration_ms>1590</duration_ms></usage>

B — actual behaviour

Spawned successfully.
agent_id: probe-named@session-<sessionId>
name: probe-named
The agent is now running and will receive instructions via mailbox.

No output_file. No statement that a completion notification will arrive — and none ever did. Then:

• Never appeared in ListAgents. The listing showed no Subagents section at all, only peer sessions.
• Never executed its prompt. It emitted two idle_notification messages, idleReason: "available", ~30s apart — idle and available, having done nothing.
• A follow-up SendMessage was accepted and never processed. The call returned {"success":true,"message":"Message sent to probe-named's inbox"} with routing sender: "team-lead", target: "@probe-named". The agent went idle again afterwards without answering. PONG-NAMED was never produced in any form.
• TaskStop({task_id: "probe-named"}) succeeded and reported "task_type": "in_process_teammate".

Expected

Either of these would be fine:

1. A named agent runs its prompt and delivers its result the same way an unnamed one does — name affects only addressability, as documented; or
2. name is documented as selecting a fundamentally different execution mode, and the tool result says so — no output_file, no completion notification, prompt not executed as a task.

What should not happen is a success response that is indistinguishable from a working spawn.

Scope

Not model-specific and not tier-specific. Reviewed three session transcripts from one project: every Agent call that passed name got the mailbox stub and returned nothing (Sonnet and Opus alike); the only call that ever returned a result was the one that omitted it. All three transcripts have an isSidechain count of 0 — no subagent turn was ever recorded, which is a cheap way to confirm the symptom on any transcript.

Environment

• Claude Code 2.1.239
• Node 24.18.1
• Linux