Receiver is never notified when a held cross-session message expires — the message is abandoned, not denied, and nobody downstream learns it existed

Status Open
Reported on v2.1.227
Maintainer reply None cached
Activity 1 comment · opened Aug 11, 2026

Claude Code 2.1.227, macOS 15.5 (Darwin 25.5.0).

Summary

When a cross-session message is held for approval and the dialogExpiry window (default 5 minutes) elapses with nobody at the terminal, the message is dropped. The receiving session is never told anything happened. A peer tried to reach it, and it has no record that the attempt occurred.

This is distinct from a denial. Nobody decided anything — the message was abandoned because no human was present. The receiver should be able to tell those apart, and today it cannot tell either one from "no message was ever sent."

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. Walk away. Let the dialog expire.
  5. Ask B whether any peer attempted contact.

Actual

B has no knowledge of the attempt — no notice, no log entry, nothing in context. Verified in the analogous held case: B reported "I never received it. There is no HELD-TEST message anywhere in this session's history." That is accurate; the content genuinely never reached it.

Expected

On expiry, the receiving session should get a low-noise notice along the lines of:

A message from <peer> arrived at <time> and was discarded because it was not approved within <dialogExpiry>. Content was not delivered.

Sender name and timestamp only — no body, since the body is exactly what was not approved. That preserves the security property while restoring the fact of the attempt.

Why it matters

The sender side is already specified to report delivered / denied / expired, and a persistent sender does receive those notices — that half works. The receiver half has no equivalent at all, so the outcome is asymmetric: the sender can eventually learn its message died, while the session it was aimed at never learns it was aimed at.

In an unattended fleet this is the common case, not the edge case. Any session left running without someone watching that specific terminal will silently miss every cross-class message sent to it, and will truthfully report that no one has contacted it.

A related gap worth considering in the same area: a message that expires produces no sender-side notice at all when the sender is a short-lived claude -p process, which exits long before the 5-minute window closes (see #85503).

Related: #85503, #85678.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗