[BUG] Team/subagent SendMessage notifications routed into the user prompt input buffer (editable, up-arrow-recallable)

Summary

When the main agent drives background subagents (spawned via the Agent tool with a name, coordinated with SendMessage to main), the inter-agent messages a subagent sends to the main conversation are delivered into the user's prompt input buffer — the composer where the user types — instead of a display/notification channel. The messages are editable and can be recalled with the up-arrow like the user's own draft input. They arrive wrapped in an "another Claude session sent a message" preamble.

In other words: the agent-team notification channel and the user-input channel are conflated. Peer/subagent → main traffic populates the field reserved for user-authored prompts.

Expected behavior

Subagent/teammate SendMessage notifications to main should render on a transcript/notification surface (as agent output the main loop consumes), not populate the user's editable prompt composer. The input buffer should hold only user-authored input.

Actual behavior

Each subagent → main message appears in the user's entry/input space:

• it sits in the composer, editable;
• it is up-arrow-recallable like a prior user prompt;
• the user can edit it and submit it as their own turn.

In a heavy multi-agent workflow (many subagents reporting completions/idle pings), the composer is repeatedly populated with agent traffic.

Confirmed firsthand (this session)

Reported directly by a user running a multi-agent session: the subagent messages arrive through the user's input channel, and the user's own genuine notes end up interleaved between agent messages in the same channel. A real user note typed mid-run was delivered sandwiched between two consecutive <agent-message from="..."> blocks — i.e., user-authored input and subagent traffic share a single channel, so a genuine user turn is positionally indistinguishable from agent-notification traffic.

Steps to reproduce

1. Start a session where the main agent spawns at least one background subagent via the Agent tool, passing a name (which engages the teammate/SendMessage protocol).
2. Have the subagent call SendMessage to to: "main" (e.g., a completion summary or an idle notification).
3. Observe the delivery on the client: the message lands in the user's prompt input buffer (editable, up-arrow-recallable), rather than only in the transcript / a notification area.

Impact

• Conflates the user-input channel with the agent-notification channel.
• Risk of accidentally editing/submitting a subagent's message as a user turn.
• Degrades the multi-agent UX: the composer fills with agent chatter during fan-out/coordination.

Environment

• Claude Code 2.1.197
• Platform: Windows 11
• Model: Opus 4.8 (1M context)
• Trigger: named background subagents + SendMessage teammate protocol (to: "main").

Possibly related

• #71723 — Agent tool name parameter silently switches to teammate protocol, losing background agent results (same protocol surface).
• #65464 — ScheduleWakeup re-injects a slash command as an apparent user invocation (same theme: agent/system messages leaking into the user-input channel).
• #67784 — Background agent duplicate task-notifications (adjacent notification-routing area).