[BUG] Cross-session SendMessage: recipient can't resolve/reply to sender (from-name mismatch + asymmetric ListAgents)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment: Claude Code v2.1.224, Opus Plan (xhigh effort), Claude Enterprise, macOS (Darwin), two interactive sessions on the same machine both rooted at the same working directory.

Summary

When Session A sends a message to Session B via SendMessage, Session B has no reliable way to address a reply back to Session A. The wrapper attribute Session B actually receives doesn't match the tool's documented contract, and ListAgents run from Session B doesn't list Session A as a reachable peer at all — even though Session A can see and message Session B just fine. The practical result: an attempted reply silently gets routed to an unrelated third session instead of failing loudly or reaching the real sender.

Actual behavior

• The SendMessage tool description states an incoming message "arrives wrapped as <cross-session-message from="...">" and instructs replying by copying that from attribute. In practice, Session B receives the wrapper with a from-name="..." attribute (a free-text, self-reported display label from A), not a from="..." attribute containing a routable name/ref.
• Session B's SendMessage(to: <from-name value>) fails with "No agent named '<value>' is reachable."
• Session B's ListAgents does not list Session A as a peer at all — it only shows Session C, despite A having just sent it a message moments earlier. Visibility is asymmetric: A→{B,C} both resolve; B's peer list omits A entirely.
• Session B then falls back to sending its reply to Session C (the only peer ListAgents shows it), silently delivering a message intended for A to an uninvolved third session. No error or warninthat the reply was misrouted.

What Should Happen?

Either:

• The wrapper should include an attribute that is actually resolvable via that session's own SendMessage/ListAgents (matching the tool's documented from contract), so a direct reply always works; or
• If the sender is genuinely unaddressable (e.g., transient/one-way relay), ListAgents should reflect that consistently and SendMessage should fail clearly rather than let the agent guess a different, unrelated recipient from its peer list.

At minimum, silently sending a "reply" to a session that was never part of the conversation is a correctness/safety issue — it can leak conversation content to an unintended session with no indication anything went wrong.

Impact

Any workflow relying on cross-session reply-to-sender addressing is unreliable when the reply flows through the documented from-attribute pattern. Worse, the failure mode is silent misdelivery rather than an explicit error, which could send sensitive content to the wrong session.

Error Messages/Logs

Steps to Reproduce

1. Open three interactive Claude Code sessions on one machine, all in the same repo (call them A, B, C).
2. From A, run ListAgents — it correctly lists both B and C as peers.
3. From A, SendMessage a test message to: B.
4. In B, observe the incoming message and attempt to reply using the documented pattern ("copy its from attribute as to").
5. In B, also run ListAgents.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.224

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_