Peer messages queue silently behind a blocking UI dialog — no sender signal, and the session still reports status "idle"

Claude Code 2.1.227, macOS. Observed directly, twice, plus a knock-on effect on delivery notices.

Summary

A session sitting on a blocking interactive dialog — an approve/deny prompt, a tool-permission box, any question awaiting selection — continues to accept peer messages. They queue behind the dialog and are not read until a human answers it.

This is a fourth delivery outcome the documented delivered / held / refused taxonomy does not name, and it is the only one with no signal to anybody:

| Outcome | Sender learns? | Receiver learns? |
| --- | --- | --- |
| Held (permission-class mismatch) | ✓ eventually (held → approved/expired) | ✗ |
| Refused | ✗ (documented: no sender notice) | ✗ |
| Queued behind a dialog | ✗ nothing — it was accepted, not held | ✗ until the human clicks |

No hold fires, so no notice is generated. SendMessage returns success: true and the message may sit indefinitely.

Reproduction

1. In session B, trigger any blocking dialog and leave it unanswered.
2. From session A, SendMessage to B. Repeat.
3. Observe: every send returns success: true. Nothing reaches B's Claude.
4. Answer the dialog in B. All queued messages flush at once.

The state is invisible from outside

~/.claude/sessions/<pid>.json carries only status: "idle" | "busy". There is no value for "blocked awaiting user input," and no other field hints at it. A dialog-blocked session is indistinguishable from a genuinely idle one, so both a human reading /list-agents and an automated sender reasonably conclude it will be processed promptly.

This also undermines discovery: status is the natural field for a scheduler or router to consult when choosing a target, and it currently cannot express the one state that means "will not respond."

Compounding: silent drops at the queue cap

Accepted-but-unread messages are capped at 50 per session, and past that the oldest are dropped. A session left on a dialog overnight with an active sender accumulates toward that cap and then silently discards. Delivered → never read → discarded, with no signal at any point in the chain.

Knock-on: it delays delivery notices too

Sender-side notices are themselves subject to this. In one observed case a held + expired notice pair arrived ~90 minutes after the send, long after the recipient process had exited — because the sending session was itself behind a dialog, so its own telemetry queued.

So the failure modes compose: a dialog-blocked session delays not only inbound messages but the delivery information it is owed about its outbound ones.

Suggested fix

Two independent changes, either useful alone:

1. A sender-visible signal when a delivered message is queued behind a blocking dialog — the same channel that already reports held / approved / expired. Something like "queued behind a pending dialog in the recipient session."
2. A distinct session status (e.g. blocked) in the registry and in /list-agents, so the state is discoverable rather than masquerading as idle.

Why it matters

Multi-agent systems route on status and trust success: true. Today a router will preferentially pick a dialog-blocked session precisely because it reports idle, then never learn the message went unread.

This is now the fourth distinct way success: true does not mean what a caller would assume, alongside #85503 (returns before the inbound decision), #85678 (held-then-approved is invisible to the receiver), and #85690 (self-addressed sends loop back silently).

Related: #85503, #85678, #85679, #85690, #85699.