Desktop cross-session send_message: 'queued' messages (target mid-turn) can be silently lost, no failure feedback to sender

Environment

• Claude Code Desktop app on Windows 11 (OS build 10.0.26200)
• Session-management MCP tools (mcp__ccd_session_mgmt__*), model claude-fable-5
• Two local desktop sessions in different project folders

Summary

When one session sends a cross-session message via mcp__ccd_session_mgmt__send_message while the target session has a turn in flight, the tool returns:

Message queued for session local_… ("Session A"); it will be processed after the in-flight turn finishes if that session stays healthy.

In practice the queued message was never delivered — it never appeared as a user turn in the target session, and the sending session received no failure feedback. The user only noticed because the target session later re-asked the same question. Re-sending the identical message later, while the target session was idle, returned Message sent to session … and was delivered normally.

So: queued can silently drop, and the sender has no way to know.

Steps to reproduce

1. Session A is busy: a long multi-step turn with many tool calls is in flight (in our case a session with ~3,000 transcript messages, so context compaction may also have occurred in the window).
2. From session B, call send_message targeting session A → result: Message queued for session … it will be processed after the in-flight turn finishes if that session stays healthy.
3. Let session A finish its turn and continue working.
4. Observe: the queued message never arrives in session A (no "From Session B" user turn).
5. Send the same message from B again while A is idle → result: Message sent to session … — arrives immediately and correctly.

Expected behavior

Either of:

• Queued messages reliably survive until the in-flight turn finishes and are then delivered, or
• the sending session is notified that delivery failed (so the model/user can retry).

A silent drop after an explicit "will be processed" promise is the worst case: the sending session reasonably reports "message delivered/underway" to its user, and the information is lost without anyone noticing.

Frequency

Observed twice in ~2 weeks of heavy multi-session use (2026-08-18 and about a week earlier), both times with the queued code path. Direct sent deliveries (target idle) have been reliable throughout.

Hypothesis

The queue does not survive whatever transition ended the target's in-flight turn — candidates: context compaction in the target session, an API error/retry ending the turn abnormally, or the queue being replaced when the target user submits their own next message before the queue flushes.