{"version":"2.1.238","anchor":"sessions-can-advertise-that-they-will-not-accept-cross-sessi","canonical_anchor":"sessions-can-advertise-that-they-will-not-accept-cross-sessi","heading":"Sessions can advertise that they will not accept cross-session messages","tier":"notice","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/sessions-can-advertise-that-they-will-not-accept-cross-sessi","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### Sessions can advertise that they will not accept cross-session messages\n\nSessions that block incoming messages are now labelled, and sending to one is refused up front.\n\n**What**\n\nWhen you list other sessions, ones that have turned off incoming cross-session messages are now labelled as such, and an attempt to message them is refused before anything is sent rather than failing later as an unreachable session.\n\n**Details**\n\n- The listing marks a session unavailable from the server-side metadata field `cross_session_inbound`, and the row is rendered with a short label.\n- The permission path denies the send and records the failure as `errorClass: \"recipient_gate_off\"`.\n- No flag: it depends on the peer's metadata being present in the listing. A warm-cache lookup that throws falls open to \"unknown\", so the send is attempted as before.\n\n**Evidence**\n\n`can't receive cross-session messages (off in that session)`\n\n- Area: Cross-Session Messaging\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}