[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 None cached
Activity 2 comments · opened Aug 23, 2026 · closed Aug 28, 2026

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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗