{"version":"2.1.238","anchor":"messages-to-another-session-check-the-recipient-first-and-ea","canonical_anchor":"messages-to-another-session-check-the-recipient-first-and-ea","heading":"Messages to another session check the recipient first, and each session reports its own inbound state","tier":"notice","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/messages-to-another-session-check-the-recipient-first-and-ea","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### Messages to another session check the recipient first, and each session reports its own inbound state\n\nMessaging another session checks the recipient first and gives a specific reason when refused.\n\n**What**\n\nSending to another session by address, cloud name or remote-control name now runs a recipient check up front, with its own denial wording and telemetry class instead of the generic unreachable-session message. Sessions also report their own inbound availability upstream.\n\n**Details**\n\n- The check reads the target's `crossSessionInbound` setting (accept, hold, refuse); when it is off, the send is denied with a distinct decision reason.\n- Each session mirrors `cross_session_inbound` as available or unavailable, with new last-reported and last-known fields and a reseed path so the value is re-sent after the connection handle changes.\n- The check itself is unconditional on this build.\n\n**Evidence**\n\n`target session reports it cannot receive cross-session messages`\n\n- Area: Cross-Session Messaging\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}