SendMessage to your own session's address succeeds silently and delivers the message back to yourself — no self-address guard

Claude Code 2.1.227, macOS. Observed across two machines on one account.

Summary

SendMessage accepts a session's own address as the to target. It returns success: true and delivers the message into that same session's context. There is no self-address guard and no warning.

A self-addressed send is almost never intentional, and the success response is indistinguishable from a genuine delivery to a peer.

Reproduction

1. In session A, note its own bridgeSessionId (from ~/.claude/sessions/<pid>.json, or the id in the /remote-control URL).
2. From session A, SendMessage with to: "bridge:session_<its own id>".
3. Observe: {"success": true, "msg_id": "..."}, and the message arrives in session A's own context.

The same shape should be checked for uds:/tmp/cc-socks/<own pid>.sock and for a session's own name [ref].

Actual

The send succeeds and loops back. Nothing distinguishes it from a delivery to a different session.

Expected

Reject a self-addressed send with a clear error, e.g.:

Cannot send to your own session (bridge:session_...). Did you mean the sender of the message you are replying to?

At minimum it should be distinguishable in the tool result.

How this actually happened

This was not a contrived test. Two sessions on different machines were exchanging protocol-research messages. My message to the peer said, in effect, "this one is addressed to bridge:session_011a..." — quoting the address I had used to reach it. When the peer composed its reply, it took that quoted id as the reply target. But that id was the peer's own bridge id, so the reply went to itself and never reached me. It only noticed because the message reappeared in its own context.

That is an easy and repeatable failure mode: a session cannot reliably tell its own address from a peer's when the address appears as text in a conversation (a session cannot read its own display name at all, since ListAgents excludes self). A guard in the tool is the natural place to catch it, because the model is structurally poorly placed to.

Why it matters

• Multi-agent frameworks generate to values programmatically from conversation content and envelopes. A self-address is a silent no-op that looks like success.
• It compounds with #85503 (success: true precedes the inbound decision): there is currently no return value that reliably means "delivered to the intended peer."
• The failure is invisible to the sender's user, who sees a successful send and an unexplained lack of reply.

Related: #85503, #85678, #85679.