Cross-session and mid-turn messages silently dropped (SendMessage reports success, message never arrives)

Summary

Cross-session messages (via the in-process agent messaging mechanism) and messages typed mid-turn by the user are sometimes silently lost, with no error surfaced to either side. This is a regression from prior behavior (reported as new "over the past few days").

Two distinct symptoms observed, both under Claude Code 2.1.273 on macOS (Darwin 25.6.0):

Issue 1 — Cross-session message reports delivered but never reaches the target session

Two Claude Code sessions running concurrently on the same machine (mesh-demo-01 and sm-dispatch-target-verification).

Timeline (from each session's own transcript):

1. 22:18:30 — mesh-demo-01 sends a cross-session message to sm-dispatch-target-verification. The tool call returns {"success":true,"message":"...→ sm-dispatch-target-verification (another Claude session on this machine)","msg_id":"1bcde2a7-454b-4a64-ba26-9ca76f14f06a"}.
2. sm-dispatch-target-verification's transcript has no record whatsoever of that message arriving — no queue-operation entry, no attachment, no user-role turn. At 22:26:16, mid-conversation, that session states explicitly: "I don't see any incoming message from mesh-demo-01 in my transcript — nothing was delivered to me."
3. 22:26:52 — mesh-demo-01 resends the identical message ("Resending — my last message apparently didn't land"). The tool again returns success:true, and this time it does land — visible in the target's transcript as a normal queue-operation (enqueue) → attachment (queued_command) → user-role turn sequence a few seconds later.

The sending side's tool result gave no indication anything had failed. Nothing was logged as an error. The only reason it was caught was that the target session happened to explicitly check its own transcript when asked.

Issue 2 — A pending-message indicator leaks into generated output instead of being surfaced as its own turn

Separately, in an interactive session, a message sent by the user while Claude was mid-turn (running a chain of tool calls) was rendered as a chat bubble in the transcript, but Claude's response continued on its prior track without engaging with it at all. In the same response, the literal string 1 new message (click) ↓ — which appears to be the terminal UI's own "you have a pending message" indicator — ended up embedded as literal text inside a markdown table cell that Claude generated, rather than being displayed as a proper out-of-band notification.

Screenshot attached showing: a user message ("I already told you the keychain commmand has been ran...") rendered inline but never addressed by the following response, and the 1 new message (click) ↓ string sitting inside a generated table.

Expected behavior

• A SendMessage/cross-session-message call that reports success:true should guarantee the message reaches the target session's queue, or should report a failure/warning if it cannot confirm delivery.
• A message arriving while Claude is mid-turn should be reliably queued and surfaced as a distinct turn once the current turn/tool-round completes — never silently dropped, and never rendered as literal text inside generated content.

Environment

• Claude Code 2.1.273
• macOS Darwin 25.6.0 (arm64)
• Installed via Homebrew cask (claude-code)
• Multiple concurrent interactive sessions on the same machine, communicating via the cross-session SendMessage mechanism