Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
Cross-Session MessagingArea: what it touches
Internal ChangesKind: in v2.1.271,
Internal ChangesSection of the release
What
Claude Code sessions can receive messages from your other sessions (cross-session messaging). A new peer_message_hold system event now reports when an incoming message from another session is parked rather than queued for delivery, for example because the permission mode doesn't match or because the crossSessionInbound setting is set to hold. This event is emitted on the standard output stream in non-interactive (-p) and SDK-driven sessions.
The event also reports what happens next: whether the held message is later released, or instead dropped, expired, refused, or discarded, along with details like which channel it arrived on and why it was held.
Why
This gives tools and integrations built on Claude Code visibility into cross-session messages that would otherwise silently disappear, so a host application can show the user what happened to a message from another session instead of it just vanishing.
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed sinceAnthropic's documentation has since written up crossSessionInbound, on Deploy managed settings.| `crossSessionInbound` | Treated as `refuse`, the most restrictive value, so inbound [cross-session messages](/docs/en/cross-session-messaging#control-inbound-messages) are refused until the value is fixed. The developer sees [a warning](…managed-settingssee the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up crossSessionInbound, on Deploy managed settings.
