Desktop app (CCD): inter-session messages delivered but never processed — wake deferred ~8h, dies offline, never retried

Summary

Since ~Aug 10 (desktop app bundling claude-code 2.1.234), inter-session messages sent via the ccd_session_mgmt send_message MCP tool are delivered to the receiving session's UI (the "Message from <session>" card renders) but the receiving session never processes them — no agent turn ever runs on the message. The sender gets a successful "Message sent"/"Message queued" tool result. This silently breaks multi-session coordination workflows (host session fanning out findings to worker sessions).

Environment

• macOS (Darwin 25.5.0), Claude desktop app, bundled claude-code 2.1.234
• Heavily multi-session use: ~10 concurrent local CCD sessions on git worktrees
• Laptop sleeps frequently between work windows

What the logs show (root-cause hypothesis)

Delivery works, and the app does schedule a wake of the receiving session with the message pending as a user turn — but the wake is armed ~8 hours out, which lands overnight while the machine is asleep/offline. The single processing attempt then dies with no first API response and is never retried:

1. Sends at 2026-08-19 21:36-21:37Z from the sender session all return success.
2. main.log shows for each recipient session, identically at 2026-08-20 04:17:01 local:

[CCD] Session local_734718aa-... timed out after 970s of inactivity (hadFirstResponse=false, last_message_type=user, last_tool_name=none, seconds_since_stderr=never)
[CCD] Session local_c521952c-... timed out after 970s of inactivity (hadFirstResponse=false, last_message_type=user, ...)
[CCD] Session local_7e0c2575-... timed out after 970s of inactivity (hadFirstResponse=false, last_message_type=user, ...)

1. Surrounding log is full of sleep/offline signals at those windows: [event-loop-stall] main process blocked for 779912ms [likely sleep], net.isOnline() is false, ERR_INTERNET_DISCONNECTED, and [CCD CycleHealth] api_error ... Unable to connect to API: SSL certificate hostname mismatch / Connection refused immediately post-wake.
2. The message text never appears in the receiving session's transcript .jsonl — only in the sender's transcript. loop wakeup armed for <+8h> lines correspond to the deferred processing.

So: one delivery attempt, deferred into a window where the API is unreachable, killed on timeout, never retried — including after network restore or when the user later opens the session.

Expected

• Process the queued message promptly on delivery when the app is online; otherwise retry on network-restore/app-wake.
• A wake attempt that dies with hadFirstResponse=false should requeue the message, not drop it.
• At minimum, surface the failure in the UI instead of showing the message card as if handled.

Impact

Fan-out coordination between sessions is unreliable enough to be unusable — a batch of 4 addendum messages sent between sessions on Aug 19 was 100% dropped. Spawning new sessions (chips) works; messaging existing ones does not.