Desktop app: send_message to a not-yet-loaded session shortly after launch queues silently and never invokes the target

Summary

In the Claude Code desktop app, a cross-session message sent with the ccd_session_mgmt send_message tool to a session that has not yet been loaded since app launch is accepted and recorded, but never invokes the target session. The tool result is indistinguishable from a normal delivery, so the sender has no signal that the message will not wake the target.

Environment

• Claude Code desktop app on Windows 11 Pro (10.0.26200)
• Multiple saved local sessions in the same workspace, coordinating via the mcp__ccd_session_mgmt__* tools

Steps to reproduce

1. Have several saved local sessions.
2. Restart the machine (or the desktop app).
3. Within roughly the first 5 minutes after app launch, from session A call send_message targeting an idle session B that has not been opened since launch.
4. Observe: the tool returns Message sent to session ...; session B's lastActivityAt (via list_sessions) updates to exactly the delivery instant; isRunning stays false and session B never runs a turn, indefinitely.

Expected

Either the delivery invokes the target session (as it does later in the app lifetime), or the tool result distinguishes "queued; target will not be auto-invoked" from a normal delivery so the caller can react.

Additional observations

• Identical send_message calls to three other not-yet-opened sessions ~18 minutes after app launch invoked each target within about a minute (observed isRunning=true and normal turns).
• A duplicate resend to the originally affected session, ~14 minutes after the first attempt, invoked it normally.
• The failure window therefore appears to be early app lifetime, consistent with the target sessions not yet being registered with whatever component performs the auto-invoke.
• Reference timestamps (UTC, same day): failed send delivered 02:40:01.509Z (activity bumped to exactly that instant, no turn ever ran); successful sends to other sessions 02:53:28Z-02:53:42Z; resend woke the original target ~02:54Z.
• Separate working path, not this bug: sends to a session that is mid-turn return "queued for session ...; it will be processed after the in-flight turn finishes" and are processed correctly.

Impact

Coordination setups where one session is expected to wake others after a restart can silently strand wake messages; the only workaround found was polling list_sessions for isRunning/lastActivityAt advancing past the delivery instant, and resending once when it does not.