[BUG] SendMessage silently fails when using agent name — only agent ID works for resuming completed 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?

SendMessage with the to field set to an agent name (as the schema and documentation require) silently reports success but never delivers the message to the target agent. Only using the raw agent ID (alphanumeric string like a83ccf8943ca82483) actually works to resume completed agents.

This contradicts the tool's own schema which states:

to: Recipient: teammate name Refer to teammates by name, never by UUID.

What Should Happen?

SendMessage(to="my-reviewer") should resolve the name to the corresponding agent and deliver the message, consistent with the schema documentation.

Error Messages/Logs

Steps to Reproduce

1. Launch a session with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
2. Spawn an agent with a name: Agent(name="my-reviewer", description="Review the code", ...)
3. Agent completes and returns its result
4. Later, call SendMessage(to="my-reviewer", message="...")
5. Observe: {"success":true,"message":"Message sent to my-reviewer's inbox"} — but agent never receives it
6. Call SendMessage(to="a83ccf8943ca82483", message="...") (using the agent ID from the Agent tool result instead)
7. Observe: {"success":true,"message":"Agent \"a83ccf8943ca82483\" had no active task; resumed from transcript..."} — this one actually works

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.92

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment

• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 enabled
• Platform: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)

Evidence from Real Sessions

Session 1 (1251203f-04ed-4f5a-ab34-4ed08091b0ca)

An orchestrator agent spawned a subagent with name="tech-lead-po13526". The subagent completed and returned. Later the orchestrator tried to resume it:

| Time | Action | to field | Result |
|---|---|---|---|
| 13:24:39 | SendMessage | tech-lead-po13526 (name) | "success":true — silent failure, agent never received it |
| 14:12:46 | SendMessage | a83ccf8943ca82483 (agent ID) | "Agent had no active task; resumed from transcript" — actually worked |

The orchestrator followed the schema correctly by using the name, got a false success response, and had to retry with the agent ID to make it work.

Session 2 (c7fe2749-d39c-4db8-882a-95910ca4af7d)

Same pattern — name-based SendMessage silently fails, causing the orchestrator to spawn a redundant new agent:

| Time | Action | to field | Result |
|---|---|---|---|
| 19:24:10 | SendMessage | tech-lead-po13509 (name) | "success":true — silent failure |
| 19:24:42 | Spawned new Agent | — | Wasted agent spawn because SendMessage appeared to fail |
| 19:27:23 | SendMessage | ac7b27b139eb5759a (agent ID) | Successfully resumed original agent |

Session 3 (51274981-e1bf-47e9-873d-35e22942d804)

When using agent ID directly from the start, it works on the first try:

| Time | Action | to field | Result |
|---|---|---|---|
| 08:24:25 | SendMessage | a2162cfc306d8681e (agent ID) | "Agent resumed from transcript" — worked immediately |

Impact

• False success responses cause the orchestrating agent to believe the message was delivered, leading to hangs or unexpected behavior
• Agents that follow the schema (using names as documented) consistently fail
• The workaround (using agent IDs) contradicts the tool's own documentation
• In multi-agent pipelines, this causes wasted agent spawns and redundant work

Workaround

We implemented a PreToolUse hook that intercepts SendMessage calls, detects when to is a name (not an agent ID), resolves it by scanning the session's subagents/*.meta.json metadata, and returns updatedInput with the resolved agent ID. This transparently rewrites name-based calls to ID-based calls before execution.