Cross-session messages refused after approval now return a "refused" receipt instead of "expired".
What's wrong with this entry?
Messages 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.
- The recipient sees a warning when the inbox guard had no room for a released message.
- The sending session's Claude gets delivery notices for the
refusedanddroppedcases, telling it not to resend. - On the wire, refused is sent as
status: "expired"withstatus_detail: "refused"; drops adddrop_reasonanddropped_msg_ids. - Part of the existing cross-session peer feature, which the code still describes as having a kill switch and a per-session opt-out.
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.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Messages injected by a host are classified separately from peer messages
Both mention cross
-
v2.1.234
Cross-session control requests check ids more carefully
Both mention cross
-
v2.1.234
Notice acks now wait for the record to persist
Both mention cross