SendMessage from orchestrator to its own spawned subagent carries ambiguous peer provenance, triggering false prompt-injection refusals

Summary

Design/UX report on the SendMessage / background-Agent tooling (not a repro-attached crash). Observed 3 times in one session: when an orchestrator session sends a legitimate follow-up via SendMessage to a background agent it spawned earlier, the recipient receives the message attributed to an ambiguous peer identity (e.g. from="general-purpose") rather than anything identifying it as "the same session that gave you this task." The recipient tries to verify by replying to that address, gets "no agent named X is addressable," and concludes the follow-up is a spoofed/injected instruction.

Flow observed

1. Orchestrator spawns a background Agent.
2. That agent decides on its own to further delegate to its own sub-agents, and reports back "waiting on background agents."
3. The orchestrator sends a legitimate follow-up via SendMessage — e.g. "please do the work directly instead of waiting."
4. The recipient receives this labeled as from an ambiguous peer identity (e.g. from="general-purpose"), with nothing marking it as coming from its original task-giver.
5. The recipient tries to verify by replying to that address and gets "no agent named X is addressable."
6. It concludes the message is a spoofed/injected instruction and refuses.

Worst case observed

In the most severe of the three occurrences, the recipient agent also mischaracterized the content of the legitimate follow-up before refusing: it claimed it had been told to "hide the fact that background agents exist" and to "report fabricated findings" — neither was said. It then surfaced a false security alert to the end user about the user's own legitimate instruction.

Root causes (as observed)

• (a) Ambiguous sender provenance. SendMessage from an orchestrator to its own spawned descendant presents the sender as a generic peer role name. The reply-back verification path then fails ("not addressable"), which reads to the recipient as positive evidence of spoofing — a legitimate parent→child follow-up becomes indistinguishable from an injected message.
• (b) Paraphrase drift. The receiving agent acted on its own paraphrase of the incoming message rather than the literal text, and the paraphrase drifted far from the actual content — turning a benign "do the work directly" into a fabricated malicious instruction.

Suggested fixes

1. SendMessage from an orchestrator to its own spawned descendant should carry unambiguous provenance — e.g. "from your original task-giver" / "from the session that spawned you" — rather than a generic peer role name. Ideally the reply path should also resolve, so a recipient's verification attempt doesn't fail in a way that mimics spoofing.
2. Agents should quote the literal incoming message text before acting on their interpretation of it, so benign follow-ups aren't refused (or escalated to the user as security alerts) based on a drifted paraphrase.

Impact

• False security alerts surfaced to end users about their own legitimate instructions.
• Orchestration stalls: descendants refuse follow-ups from their own parent, so "stop waiting and do the work" course-corrections don't land.
• The underlying skepticism toward unverifiable instructions is good and should stay — the failure is that missing provenance metadata makes legitimate parent→child messages fail the verification the recipient reasonably attempts.

Environment

• macOS (Darwin 25.5.0), Claude Code desktop/CLI, July 2026 build.

Related but distinct: #64748 raises per-message provenance for Remote Control — same theme, different surface.