{"version":"2.1.271","anchor":"peer-message-hold-visibility-into-parked-cross-session-mess","canonical_anchor":"peer-message-hold-visibility-into-parked-cross-session-mess","heading":"peer_message_hold: visibility into parked cross-session messages","tier":"internal","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/peer-message-hold-visibility-into-parked-cross-session-mess","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### peer_message_hold: visibility into parked cross-session messages\n\nA new peer_message_hold event reports when a message from another session is parked instead of delivered, and how it's later resolved\n\n**What**\n\nClaude 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.\n\nThe 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.\n\n**Why**\n\nThis 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.\n\n- Area: Cross-Session Messaging\n- Names: `crossSessionInbound`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}