[BUG] Cross-session send_message reports success but message is never delivered (stuck loading, 0/4 delivery)
Environment
- Claude Code 2.1.228 (desktop app), Windows 11 (10.0.26200)
Bug
send_message (ccd_session_mgmt MCP, cross-session messaging) returns a success result to the sender — Message sent to session <id> ("<title>") — but the message is never delivered to the target session. In the desktop UI, the outgoing message is stuck in a perpetual loading state.
Observed tonight across multiple sends between two local sessions in the same workspace: 4/4 sends showed success to the sender, 0/4 were ever received by the target. The user had to manually relay every message between the sessions.
Target session state did not matter: it happened both while the target was busy (long tool-call chains) and after it went idle. Messages never arrived even later.
Expected
Either deliver the message (immediately or when the target becomes available), or return an error / pending status to the sender. An unconditional success return with no delivery is the worst case: the sender plans around "delivered", the receiver knows nothing, and nobody is told to retry.
Impact
Silent coordination failure for multi-session workflows (orchestrator/worker patterns). The success return value makes it undetectable from the sending side.
Notes
- This may be a recent regression — cross-session messaging had worked in earlier builds on this machine.
- Possibly related but distinct: #76714 covers the permission-grant UX for the same tool; this report is about delivery failing while reporting success.
Showing cached comments. Read the full discussion on GitHub ↗
6 Comments
Confirming — same regression, with log forensics pinning it to the 1.28929.0 desktop rollout.
Environment: macOS (arm64), Claude Desktop 1.26832.0 → 1.28929.0 (staged ~19:06 Aug 11, activated on relaunch 08:46 Aug 12, +04), embedded Claude Code 2.1.222 → 2.1.227. Multiple concurrent local sessions, heavy cross-session
SendMessageuse.Before/after from
~/Library/Logs/Claude/main.log:Cleanest single repro from the logs (session
local_8b4ac8e0…):10:36:41 LocalSessions.sendMessage … messageLength=25(user-typed message) → mapping →10:36:50 [Stop hook] Query completed→10:36:54 [CCD CycleHealth] healthy cycle (13s)— session healthy.10:37:26 Sending message to session local_8b4ac8e0…(cross-session send) → nothing: no CLI-session mapping, no transcript append, no error, no process exit. Session shows a permanent grey/pending state; subsequent typed messages queue and never run.No EPIPE/ENOENT/spawn/IPC errors at any delivery moment. The receiving process stays alive. Sender sessions keep working and get a success result. Possibly related to #85714 (peer messages queueing silently behind a blocking dialog) — we saw a low rate of that shape on 1.26832.0, but 1.28929.0 made first-message-kills-idle-session the common case.
Happy to provide fuller log excerpts.
Also saw this. My write up:
Using mcp__ccd_session_mgmt__send_message to send a message from one active session to another (both local, non-remote), the message appears in the recipient's UI as a "Message from X" card, and the tool call itself reports success ("Message sent"/"Message queued"). However, the recipient session never actually processes it as a turn — no "thinking..." indicator ever appears, only a timer that counts up indefinitely with no progress. The sending session also never receives a reply, since the recipient never actually runs.
Reproduced twice in the same working session: once with an inbound message (another session → mine), once outbound (mine → another session) immediately after. A client restart did not clear the stuck state on a subsequent attempt.
This affects any workflow built on sequential cross-session messaging (e.g., broadcasting a message to several sessions one at a time, waiting for each reply before advancing) — one silent delivery failure anywhere in the chain stalls everything downstream with no error or timeout surfaced to either party.
Seeing this too - I've seen failures since updating the desktop app last night (on Windows). All the message sends this morning between top-level sessions have been failures (throbber but no response on the recipient side), but messages between a top-level session and its subagents appear to be working so far.
#86067 looks very similar / the same
possible dupe of #86012
Update: downgraded the desktop app to 2.1.227 (via the official install script) and retested — cross-session send_message still fails the same way (sender gets success, recipient shows perpetual loading, nothing delivered). So this does not appear to be a client-side regression from the 2.1.228 build alone; the delivery path looks broken server-side (or in a component that isn't rolled back by downgrading the client). Timeline still matches: everything worked before the desktop update wave last night, broken since, on both 2.1.228 and now 2.1.227.