Reply to SendMessage from a nested subagent is delivered to the root session instead of the requesting parent

Environment

• Claude Code 2.1.246
• Windows 11, Git Bash / PowerShell
• No MCP servers required, no plugins required, no custom agents required

Summary

When a subagent (depth 1) spawns its own child subagent (depth 2), the child's
first answer is delivered to the parent correctly. If the parent then uses
SendMessage to ask the same child a follow-up question, the child answers,
but the answer is delivered to the root session rather than to the parent
that asked. The parent receives nothing and waits until the end of its turn.

A second, related problem: the awakened child sees the sender as
from="general-purpose". That is the agent type, not an address, and it
does not resolve — an explicit reply attempt fails with
No agent named 'general-purpose' is reachable. So the return path is closed
from both ends.

Steps to reproduce

1. Start Claude Code in an empty scratch directory.
2. From the root session, launch a subagent of type general-purpose with this

task (verbatim):

> Launch a child subagent of type general-purpose with the task: "reply
> with exactly one line: FIRST-ANSWER". Wait for its answer and report it.
> Then use SendMessage to ask the same child: "reply with exactly one
> line: SECOND-ANSWER". Wait for that answer and report it too. Do not
> finish until you have both answers or you are certain the second one will
> not arrive.

1. Watch the root session's own output while the parent is working.

Expected

The parent receives FIRST-ANSWER, then SECOND-ANSWER, and reports both.

Actual

• The parent receives FIRST-ANSWER and reports it.
• The child produces SECOND-ANSWER.
• SECOND-ANSWER appears in the root session (as a queued attachment),

not in the parent.

• The parent never receives it and stays parked waiting.

Frequency

4 out of 4 attempts across two unrelated parent/child pairs (one built from
general-purpose on both sides, one from custom agent definitions). The
first delivery is reliable: 18 out of 18 observations across two sessions
went to the parent as expected. Only the follow-up is misrouted.

Why this matters

Any clarifying dialogue between a parent subagent and its child is impossible
today, and it fails silently: the parent has no way to tell "the answer is
late" from "the answer went somewhere else", so it parks. The misdelivered
message also lands in the root session's context, where it reads as an
unsolicited fragment with no question attached.

Diagnostics that show it without trusting any agent's narration

• <session>/subagents/agent-*.meta.json — agentType, parentAgentId,

spawnDepth establish who is whose child.

• queue-operation entries in the session transcript — when a notification is

queued and with what reason it is dequeued. delivered_to_agent means the
parent got it; absorbed_mid_turn does not mean it was lost (a busy
parent receives on the turn boundary — we measured a 100 s delay with no
loss).

• attachment: queued_command for a depth-2 task appearing in the root

transcript — this is the signature of the misroute.

Observation about the likely place (not a claim about internals)

We looked at the packaged JS in claude.exe 2.1.246 to narrow down where the
recipient is chosen. This is a minified bundle and we did not instrument the
process, so the following is what it looks like, not something we can
assert:

• the notification is queued by a helper (minified name b2 in our copy) that

resolves the recipient through another helper (minified Zvt);

• the recipient resolves to the parent only while the parent is "running", or

is "completed" and still holds keepalive reasons;

• the keepalive reason is named agent:<taskId> and appears to be cleared once

a notification for that task has been delivered once;

• after that, a parked parent no longer satisfies the condition and the address

falls back to the root session.

That would explain the observed asymmetry — first notification delivered,
second one rerouted — but we are reporting the behaviour, not the cause.

Suggested fix direction (for triage only)

A SendMessage from a parent to its own child could re-arm the keepalive for
that child, or the reply could be addressed by the requester recorded on the
message rather than by the task's owner keepalive. Separately, the from=
attribute the child sees should carry an address that resolves, not the agent
type.

Re-verified 2026-08-29

Reproduced again on Claude Code 2.1.251 (up from 2.1.246 in the original
report — same behaviour across at least this version range), same steps as
above, general-purpose → general-purpose. Structural confirmation from the
transcript, not narration: the child's second-answer <task-notification>
(result: SECOND-ANSWER) was delivered directly to the root session, while the
parent agent's own completion notification for that same turn read only
"Message sent to the child agent. Waiting for its second reply." — it never
received the second answer.