Held-then-approved cross-session messages arrive with no marker — receiver cannot tell it was gated, and reports the hold never happened

Claude Code 2.1.227, macOS 15.5 (Darwin 25.5.0).

Summary

When a cross-session message is held for approval and the user approves it, the released message is delivered to the receiving Claude indistinguishable from a normally-delivered message. There is no marker, notice, or metadata indicating it was ever held.

The practical result: the receiving session confidently reports that no hold occurred, because from inside the session that is literally true. Anyone using the receiver to verify delivery behavior gets a sincere but wrong answer.

Reproduction

1. Run session A with --dangerously-skip-permissions (bypass class).
2. Run session B as plain claude -c (prompting class).
3. From A, SendMessage to B. The class mismatch triggers a hold.
4. Approve the dialog in B's terminal.
5. Ask B whether the message was held.

Actual

Three observers disagree about one message:

| Observer | What it saw |
| --- | --- |
| User (B's terminal) | Approve/deny dialog |
| Sender (A) | held for the recipient user's approval → approved and released |
| Receiver (B's Claude) | An ordinary message, no notice |

B reported verbatim: "No approval dialog and no held-message notice. It arrived inline as a normal cross-session message, same as any other." and concluded "The documented default ... did not hold in practice here." Both statements are honest and both are wrong, because B has no way to observe the gate.

Expected

A released message should carry some indication it was held and approved — an attribute on the <cross-session-message> wrapper, or a note that the user approved it at a given time. It does not need to be prominent; it needs to exist.

Why it matters

Holding untrusted content out of the model's context until a human consents is clearly correct, and I am not asking for that to change. The problem is only that the fact of the gate is erased on release. Consequences:

• A receiving session cannot self-report delivery conditions accurately, so it is unusable for verifying messaging behavior.
• Multi-agent systems that ask the receiver to confirm receipt get answers that cannot distinguish "delivered normally" from "gated by a human 4 minutes ago."
• Combined with #85503 (sender sees success: true before the inbound decision), there is currently no participant in the exchange who can determine after the fact whether a message was held — only a human who happened to be watching the terminal at the time.

Related: #85503, #85497.