[BUG] Teammate subagents of a forked-skill agent cannot reply to their parent; SendMessage to "team-lead" false-succeeds into an orphaned inbox

Summary

Subagents spawned as named mailbox teammates by a forked-skill background agent have no working reply path back to their parent — and one of the failure modes returns success: true while dropping the message. The parent deadlocks waiting for replies that can never arrive, with success signals on both sides.

Environment

• Claude Code 2.1.228, macOS (darwin 25.5.0)
• Model: claude-fable-5
• Trigger: /code-review max --fix <path> (the skill runs as a forked background agent and fans out ~10 "finder" subagents via the Agent tool with name: set, mailbox-style)

What happened

The review agent spawned 10 named finder agents. Each spawn returned "Spawned successfully… will receive instructions via mailbox." All 10 finders ran to completion (their transcripts are on disk as top-level session .jsonl files) and each tried 3–4 times to deliver its findings. Every route failed:

1. SendMessage({to: "main"}) → {"success":false,"message":"You are the main conversation — \"main\" addresses you. Send to a named agent instead."}

Each finder's context treats the finder itself as the main conversation, so the documented reply path for background subagents doesn't exist from inside this spawn mode.

1. SendMessage({to: "code-review"}) (the parent's registered name) → {"success":false,"message":"No agent named 'code-review' is reachable."}

The forked-skill parent's name is registered only in the original session's registry; its own children can't resolve it.

1. SendMessage({to: "team-lead"}) → {"success":true,"message":"Message sent to team-lead's inbox","msg_id":"…"}

This is the worst one: the parent is not running as a team lead and nothing ever drains a "team-lead" inbox, so the message is dropped after a success response.

Meanwhile the forward direction worked fine: the parent's SendMessage pings to the finders returned "Message sent to finder-X's inbox" and demonstrably woke all 10 finders within a minute. So the channel is one-way, and both directions report success.

Net effect: the parent sat idle "waiting for finder reports" indefinitely. From the outer session it looked healthy — the parent's spawn results, its pings, and the finders' team-lead sends all said success. I only found the findings by grepping the finders' transcripts and hand-delivering the payloads to the parent.

One extra footgun for anyone debugging the same thing: these teammate-style subagents do not write subagents/agent-*.jsonl files — their transcripts are top-level <uuid>.jsonl session files under ~/.claude/projects/<project>/, and the transcript does not contain the agent's own registered name.

Expected

• A subagent should always have at least one working address for the agent that spawned it (parent name resolvable, or main routing to the spawner).
• SendMessage must not return success: true for an inbox no consumer will ever drain — an unreachable recipient should be an error, like case 2.

Related

• #74113 (background agents go idle without delivering their final SendMessage report) — similar symptom; in my case the sends themselves fail or false-succeed, so a re-ping cannot recover it.
• #25135 (closed, stale) — same false-success-into-mismatched-inbox mechanism as case 3, reported against Agent Teams.