SendMessage over Remote Control says "may be on an older version" for current-version peers on the same machine, which makes agents send the message again

What happens

When a session sends a cross-session message to a peer on the same machine addressed as bridge:session_…, the tool result is:

accepted by the server for that session, but delivery is not confirmed: it has not reported that it can receive cross-session messages and may be on an older version that cannot; not confirmed read — that session may hold it (usually a different permission mode) or refuse it, and this route reports nothing back

This appears even when the receiving session is on the same version (2.1.296 on both ends), runs on the same machine, has an inbox socket, and advertises peerProtocol: 1 with peerFeatures: ["notify_idle", "reply_across_default_dirs", "artifact_yield"] in its session record.

By contrast, a bridge: send to a fresh session on a different machine (also 2.1.296) returned only …; not confirmed read — that session may hold it (usually a different permission mode) or refuse it, and this route reports nothing back, without the "delivery is not confirmed … older version" part. So the warning seems tied to same-machine peers addressed over the bridge, not to the peer's version.

In every case we checked, the message did arrive, about 20 ms to 1.5 s after the send (seen in the receiver's transcript as a queue-operation enqueue followed by a user turn).

Why it matters

The "may be on an older version that cannot" wording makes the model doubt delivery. In 3 of 3 recent sessions, the model either:

• sent the same message again over the local route (to: "<name>" or uds:…), so the receiver got it twice, or
• told the user that delivery "wasn't confirmed" when it had in fact been delivered.

The same warning has shown up since at least 2.1.261.

Expected

One of these:

1. The receiving client reports over the bridge that it can receive cross-session messages, so a current-version peer gets a confirmed receipt, or
2. The result wording says plainly that this route never confirms delivery, without suggesting the peer is out of date (for example: "accepted by the server; this route doesn't report delivery or read status").

It would also help if a bridge: send to a session that is reachable locally used the local route, or said that a local route exists. Sending to the same peer by name returns "in that session's inbox".

Environment

• Claude Code 2.1.296, macOS 26 (Darwin 25.6), both sessions interactive CLI, Remote Control connected
• The "older version" wording reproduces with sender and receiver on the same Mac; a cross-machine send to a current peer did not show it