{"version":"2.1.238","anchor":"cross-session-messages-a-refused-receipt-and-a-guard-drop-on","canonical_anchor":"cross-session-messages-a-refused-receipt-and-a-guard-drop-on","heading":"Cross-session messages: a \"refused\" receipt and a guard drop on release","tier":"notice","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/cross-session-messages-a-refused-receipt-and-a-guard-drop-on","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### Cross-session messages: a \"refused\" receipt and a guard drop on release\n\nCross-session messages refused after approval now return a \"refused\" receipt instead of \"expired\".\n\n**What**\n\nMessages held for approval between sessions gained two new outcomes. If policy refuses a message after it is approved, the sender gets a `refused` receipt instead of \"expired\" or \"denied\", and a released message is re-checked against the receiving session's inbox guard, which can now drop it.\n\n**Details**\n\n- The recipient sees a warning when the inbox guard had no room for a released message.\n- The sending session's Claude gets delivery notices for the `refused` and `dropped` cases, telling it not to resend.\n- On the wire, refused is sent as `status: \"expired\"` with `status_detail: \"refused\"`; drops add `drop_reason` and `dropped_msg_ids`.\n- Part of the existing cross-session peer feature, which the code still describes as having a kill switch and a per-session opt-out.\n\n**Evidence**\n\n`The recipient session is not accepting cross-session messages (the feature is off there, or a setting or policy there refuses them); your message was not delivered to its Claude.`\n\n- Area: Cross-Session Messaging\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}