Cross-session messages now say why they were refused or dropped, including the recipient having it off.
What's wrong with this entry?
A cross-session message can now be turned down because the recipient has the feature off, reported as recipient_gate_off, alongside the existing refusal for elevated sessions. Sessions advertise this in their cloud listing, and the sender is told the target's Claude would never see it. Messages can also come back as dropped with a reason: rate-limited, duplicate, hop loop, hop runaway or queue full.
- The refusal text is "That session is not accepting cross-session messages (the feature is off there, or a setting or policy there refuses them); it was not delivered."; a shorter form goes back to the model.
- Before dialling a peer, a lookup checks the listing for whether it accepts peer messages and refuses without opening a connection.
- Drops print a warning and hand Claude a "[Cross-session delivery notice] Do not resend now:" note, so it does not retry on its own.
- Rate-limit drops are reported as "sender exceeded the peer message rate limit"; drop receipts are batched with trailing coalescing and a per-window cap.
- Nothing gates this on the sender's side; it follows what the recipient advertises.
[Cross-session delivery notice] Do not resend now:, That session is not accepting cross-session messages (the feature is off there, or a setting or policy there refuses them); it was not delivered., sender exceeded the peer message rate limit
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