Queued cross-session message lands cleanly but doesn't trigger a new agent turn until something else flushes the queue

Summary

A message delivered via cross-session messaging (send_message / the CCD session-management MCP tools) can land cleanly in the target session's transcript as a real cross-session-message entry, but the receiving session does not automatically start a new turn to process it. The message just sits there — session status stays running/idle — until something unrelated (typically the user typing in that session) flushes the queue. There's no user-facing signal that a message is waiting, and no automatic follow-up.

This is a distinct failure mode from delivery loss: the message did arrive, correctly, and is visible in the transcript. The problem is purely that arrival doesn't trigger processing.

Reproduction (2026-08-12)

Sent a message via mcp__ccd_session_mgmt__send_message to a session whose previous turn had just completed ("done (success), 2 turns" in its own transcript; session state immediately after showed running). The message landed cleanly — visible as a proper cross-session-message entry in the target's transcript — but no follow-on assistant turn was generated. Checked again after ~15s and again after ~55s total; still nothing. The session's status stayed running/idle without ever processing the queued message into a reply.

Reproduces outside the specific harness this behavior was first noticed in — same underlying behavior via the CCD session-management MCP tools built on top of Claude Code's cross-session messaging.

Why this needs its own issue

This was originally reported as #66310, which the triage bot auto-closed as a duplicate of #56995. But that chain doesn't actually hold up:

• #56995 ("messages sent during agent execution can be silently lost or queued without UI indicator") was itself closed as a duplicate of #45969 — a closure the original reporter directly disputed with a side-by-side comparison, asked to be reopened, and couldn't be (GitHub won't let a non-maintainer reopen a DUPLICATE-closed issue). That thread is now auto-locked from inactivity.
• #45969 describes a third, different mechanism: a macOS-TUI-specific bug where a queued message gets misinterpreted as the answer to a question that appeared after it was typed — not a delivery or turn-triggering problem at all.
• None of the three describe this issue's actual mechanism: a message that arrives correctly, is visible in the transcript, and simply never triggers the receiving agent to act on it.

Filing fresh rather than trying to resurrect a three-deep closed/closed/locked chain whose own "duplicate" target was already contested.

Expected behavior

Either:

• (a) A queued message that lands in a target session's transcript while that session is idle should trigger a new turn automatically, the same as if the user had typed it, or
• (b) At minimum, a visible indicator (in the CLI/UI, or a queryable status via the session-management tools) that a message is waiting unprocessed, so a sending session/user isn't left assuming silence means the message was seen and ignored.

Supporting evidence

The official cross-session-messaging docs confirm delivery was never guaranteed by design — an inbound session can silently hold or refuse a message, and a held message expires and is dropped after 5 minutes with no notice back to the sender. That's consistent with what's described here, but doesn't cover the specific "landed-but-idle" case reproduced above, where the message is confirmed present in the transcript, not held or refused.

Related

• Original report: #66310 (closed as duplicate of #56995 — contested chain, see above)
• #56995 (closed as duplicate of #45969 — reopen requested by author, blocked, now locked)
• #45969 (closed/stale — different mechanism: misinterpretation, not non-triggering)
• #78338 — a related but distinct bug: a destructive-read race where messages are silently destroyed before delivery is confirmed, rather than delivered-but-unprocessed as described here.