Cross-session SendMessage reports success for messages never delivered (incl. nonexistent session names) and silently truncates at ~4.7KB

Summary

Cross-session SendMessage (multi-machine, over Remote Control) returns success: true — with "delivered to a Claude session on another machine" phrasing — in three situations where no delivery occurs or the payload is altered:

1. Messages to sessions on one machine were never injected into the target session's context, while rendering under that session in the claude.ai client (so both endpoints look healthy).
2. A message addressed to a session name that has never existed also returned success/"delivered."
3. An oversized message was silently truncated (~4.7KB delivered of ~6.7KB sent) with no truncation indication in the result.

Environment

• Claude Code CLI, one account, 4+ machines, cross-session messaging over Remote Control.
• Affected receiver (defects 1–2): Windows 11, client 2.1.233 (above the observed min_version gate 2.1.139). Feature flags measured true on that box: tengu_ccr_bridge, tengu_ccr_bridge_multi_session; replBridgePlaceholders registered all 5 live sessions there, including the target.
• Working legs for contrast (and where defect 3 was measured): three macOS machines, same account, same period — round trips ~40s including sends to idle sessions, which were re-invoked on receipt and replied.

Defect 1 — silent non-delivery, both directions (2026-08-16 and 2026-08-20)

Five sends across two days from macOS senders to sessions on the Windows machine (targets in idle and running states): every send returned success: true; zero reached the target's model context (target transcripts show no incoming message block). The messages did render in the claude.ai client under the target session.

The reverse direction also fails, differently: sessions on that machine attempting to reply get "no agent reachable" (by name) or "cross-session messaging is not available in this session" (by raw session id), while their local bridge registration looks correct.

Net effect: sender files the work as handed off; receiver never knows anything was sent. Only a human watching both surfaces can detect it.

Defect 2 — success for a nonexistent name (2026-08-20)

One of the sends above was addressed to a stale pre-rename session name (sessions rename under a stable ref mid-life; the old name never appeared in any listing afterwards). The send did not error — same success/"delivered" result with nothing on the other end to receive.

Defect 3 — silent truncation at ~4.7KB (2026-08-22)

On a working macOS→macOS leg: a 6,000-character synthetic payload (pure repeating 0123456789; sha256[:16] 1bcbfd269f1f5971 measured at the sender immediately before send; ~6.7KB total message with framing text) arrived as 4,050 characters (sha256[:16] 4f33d034b5acbf4d). The receiver independently verified the received string is a clean, phase-aligned prefix of the cycle — truncation, not corruption. The send returned success: true with no indication.

Expected

• A send to a nonexistent/unreachable session should return an error, not a success string containing "delivered."
• Undeliverable/undelivered should be distinguishable from delivered at the API-result level (or the result wording should claim only acceptance).
• An oversized send should either refuse or report that it was cut; silent truncation loses the tail of exactly the messages long enough to matter.

Repro sketch

1. Two machines on one account, Remote Control connected on both.
2. From box A: ListAgents, pick an idle session on box B, SendMessage demanding an immediate reply. (On our Windows receiver: observe success + client-side rendering + nothing in the session context. macOS receivers replied in ~40s.)
3. Send to a fabricated name shaped like a session slug — observe success/"delivered."
4. Send a >6KB message to a working target and have the receiver measure length/sha of a marked payload line — observe a clean prefix and a clean success result.

Timestamps and session ids available on request.