Agent tool honours a `name` parameter that the schema shown to the model omits

Version: 2.1.278, Linux.

What the docs say. The sub-agents page: "Claude can give a subagent a name by passing a name parameter on the Agent tool call, and may do so on its own, without asking you first. The name makes the subagent addressable."

What the model is shown. In this session the Agent tool's schema, as rendered to the model, lists description, isolation, model, prompt and subagent_type. No name. The TaskStop description in the same session does mention "a background agent spawned with a name", so the feature is on.

What actually happens. A call carrying name: "name-probe" is accepted; ListAgents then shows name-probe · general-purpose · running, and the subagent's hand-back arrives labelled name-probe. Strings in the binary show the parameter with validation (letters, digits, underscores, hyphens; at most 64; not main/team-lead; not id-shaped), described as "Name for the spawned agent. Makes it addressable via SendMessage({to: name}) while running."

Consequence. Since the schema never shows the parameter, a model passes a name only when something outside the schema tells it to. Measured: a nested claude -p session asked to spawn a subagent "passing name X if the tool accepts a name parameter" passed none. Every subagent therefore shows up by its type, so a session with several general-purpose subagents has several rows that read the same.

Repro.

1. Ask Claude to spawn a subagent and to pass a name if the Agent tool accepts one. It reports no such parameter and spawns without one.
2. Have it call Agent with name set explicitly. The call is accepted and the name is honoured in ListAgents and in the hand-back.

Ask. Either include name in the schema the model is shown, or say in the docs that it is accepted but not advertised.

Start by comparing the Agent tool schema rendered to the model with the sub-agents page and the TaskStop description, then inspect the Agent, ListAgents, and TaskStop entry points involved in the repro. Done means the supported name parameter is either visible in the Agent schema or its undocumented status is resolved, and the two reported repro steps behave consistently.