[BUG] Subagents cannot reply to inter-agent messages: incoming from= is the agent type ('general-purpose'), which is unroutable

Status Fixed / completed
Reported on v2.1.234
Maintainer reply ✓ Yes — dhollman
Activity 3 comments · opened Aug 23, 2026 · closed Aug 28, 2026
💡 Likely answer: A maintainer (dhollman, contributor) responded on this thread — see the highlighted reply below.

What's Wrong?

When a background subagent receives a SendMessage from another agent, the incoming message identifies the sender only as from=general-purpose — the agent type, not a routable id. Replying via SendMessage to that label fails with:

No agent named 'general-purpose' is reachable

and subagents have no ListAgents tool to resolve the sender's real address. So a subagent that is messaged mid-run by its parent/sibling has no way to answer — the reply channel dead-ends, and coordination falls back to files on disk.

What Should Happen?

The from= field on an inter-agent message should be a routable address (the sender's agent id), or subagents should have a way to resolve it — so that SendMessage(to=<from-value>) reaches the sender.

Steps to Reproduce

  1. Spawn background subagent A whose prompt is: "Spawn one background child B with the prompt 'When you receive any message, reply to its sender via SendMessage with the exact text ACK, quoting the from= value you used.' Then SendMessage B: 'ping'. End your turn."
  2. B receives the ping; the incoming envelope shows from=general-purpose.
  3. B calls SendMessage(to="general-purpose", message="ACK").
  4. Observe: the call fails with No agent named 'general-purpose' is reachable; B has no tool to discover A's real id.

Context (shared setup for this report)

We run deep background-subagent trees (session root → coordinator agent → slice agents → task agents, all general-purpose, fork mode on, interactive CLI session). Since all Agent spawns became asynchronous, "end the turn with live background tasks" is the wait primitive: the harness re-invokes the parent when a child completes. That contract holds for fresh spawns — this report is about one specific case where it breaks. Observed across ~9 long autonomous runs on Claude Code 2.1.234–2.1.238 (Linux/Fedora, Anthropic API).

Error Messages/Logs

(see Steps to Reproduce; key strings quoted inline)

Claude Model

Not sure / Multiple models (sonnet + opus subagents)

Is this a regression?

I don't know (observed on every version we ran: 2.1.234 → 2.1.238)

Claude Code Version

2.1.238 (Claude Code)

Platform

Anthropic API

OS

Linux (Fedora 44)

---
Related (distinct bugs in the same subsystem, filed separately per the single-bug rule): #89042, #89044, #89045. Together they make completion delivery unreliable for anything except fresh never-resumed spawns; field evidence: ~4–5 h of stalls across 9 multi-agent runs in one week.

View original on GitHub ↗

3 Comments

postoso · 1 month ago

Hit this tonight on 2.1.247 with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1: a background subagent's child received the parent's message labeled from=general-purpose, replied to that label, and got "No agent named 'general-purpose' is reachable" — the sender's agent TYPE is presented where a routable address should be, so the displayed reply-to is unusable. A routable agent ID (or a separate reply address) in the incoming message would fix it.

dhollman contributor · 1 month ago

Thanks—reproduced exactly as described: an unnamed subagent's message was stamped from=<agent type>, which isn't a routable address, so the reply failed with "No agent named … is reachable". A fix is in review that stamps the sender's agent id as the reply address (agent type stays as the display label). Should land in either today's release or tomorrow's.

postoso · 26 days ago

Confirming this is fixed for me on 2.1.277. Same drill, two unnamed general-purpose subagents: one messaged the other, and the incoming envelope showed from="<the sender's agent id>" rather than from=general-purpose. Replying blind to that value went straight through and the reply was received, so the round trip works in both directions. Tested on macOS with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, siblings rather than parent-to-child; I did not re-check on Linux. Thanks for the quick turnaround.