send_message (ccd_session_mgmt) silently stops delivering and wedges the recipient session — regression since CLI 2.1.227

Summary

Cross-session send_message (the ccd_session_mgmt MCP tool in Claude Desktop) silently stopped delivering on this machine on 2026-08-12 ~06:14 UTC. Since then, 197 consecutive sends returned a success acknowledgement and none were delivered — no error, no retry, no trace.

Worse, the same code path wedges the recipient session: after a peer message, the target enters timed out … hadFirstResponse=false, reason=no_response 37.4% of the time, versus 1.9% for human-typed messages on the same machine in the same period.

This is not a "message shows as Queued in the UI" cosmetic issue. The messages never reach the recipient model's context at all.

Environment

| | |
|---|---|
| Claude Desktop | 1.32885.1 |
| Claude Code CLI | 2.1.234 (current); regression first observed under 2.1.227 |
| Last known-good CLI | 2.1.222 (running 2026-08-09 → 08-10) |
| macOS | 26.5.2 (25F84), arm64 (M4) |
| Usage pattern | 8–11 concurrent local CCD sessions in one working tree, exchanging handoffs via send_message |

Impact

Multi-session workflows that rely on send_message for coordination lose work silently. Because the tool acknowledges success, neither the sender nor the user has any signal. In our case this went unnoticed for eight days and cost ~197 handoffs, including deployment requests that were never actioned.

Symptom 1 — silent non-delivery, with a success ack

Delivered peer messages appear in the recipient's transcript as a user turn whose text begins with <cross-session-message from="local_…">. Counting those strictly across all 211 transcript files in ~/.claude/projects/:

• 1,661 envelopes delivered between 2026-07-06 and 2026-08-12T06:14:19Z
• 0 delivered after that timestamp
• 197 send_message calls in that window, all returning either

Message sent to session <id> ("<title>"). or
Message queued for session <id> ("<title>"); it will be processed after the in-flight turn finishes if that session stays healthy.

Both acknowledgements fail equally — queued is not a distinct, worse state; both simply mean "the desktop accepted it".

Behavioural confirmation (not just file inspection): when asked directly, a recipient session replied "I have not received anything … nothing has reached me", and had taken no action on any of the four handoffs sent to it over 14 hours. So the content never entered the recipient's context — this is not merely a transcript-persistence gap.

Symptom 2 — peer messages hang the recipient (this is the more serious one)

From ~/Library/Logs/Claude/main*.log, classifying each Sending message to session <id> as peer (matched to a send_message tool call within ±90 s) or human (the remainder), and checking whether a Session <id> timed out after Ns of inactivity followed within 25 minutes:

| trigger | followed by a no_response timeout |
|---|---|
| peer (send_message) | 64 / 171 = 37.4 % |
| human-typed | 21 / 1099 = 1.9 % |

A ~20× difference on the same machine, same sessions, same period. Aggregate over the log window: 91 reason=no_response timeouts, 186 cycles with hadFirstResponse=false.

Representative sequence — the recipient CLI process was alive, idle, and had answered its human 90 minutes earlier:

21:27:04 [info] Sending message to session local_715d…      <- peer handoff
21:43:39 [warn] [CCD] Session local_715d… timed out after 995s of inactivity
                (hadFirstResponse=false, last_message_type=user,
                 last_tool_name=none, seconds_since_stderr=never)
21:43:39 [info] [CCD CycleHealth] unhealthy cycle for local_715d…
                (995s, hadFirstResponse=false, reason=no_response)
21:43:40 [info] Session local_715d… query iterator completed

995 s is measured exactly from the peer message. The CLI accepted the input and produced no first response. The session surfaces a yellow warning badge and appears "stuck doing nothing" — which is how the user first noticed. The same session answers human input normally.

Why the tool cannot tell the truth (root cause analysis)

From the shipped app.asar, the tool handler returns:

let d = await i.sendMessage(t, u, undefined, { origin: { kind: 'peer', from: r.sessionId, … } })
return d.delivered
  ? { text: d.queued ? `Message queued for session …` : `Message sent to session …` }
  : { text: `Message could not be delivered …: ${d.reason}`, isError: true }

Two structural problems:

1. delivered means "handed off to the CLI", not "delivered". The transcript is written by the recipient's CLI. If that CLI never responds, nothing is written and nothing is reported back. The acknowledgement is generated before any evidence of delivery exists.

1. The queue is in-memory and is discarded on teardown. Mid-turn sends are parked on o.deferredSends, and teardownQuery does:

``js
e.query = null, e.inputStream = null, …, e.deferredSends = void 0, …
``

drainDeferredSends only runs at a turn boundary and requires a live inputStream. So any teardown (timeout, crash-respawn, stale-credential cold respawn, cwd gone, app quit) destroys the queued messages with no persistence, no retry and no notification. The acknowledgement string even hedges this — "if that session stays healthy" — but the sender has no way to learn that it didn't.

Note the two symptoms compound: Symptom 2 causes the teardown that Symptom 1's in-memory queue cannot survive.

Reproduction

1. Open two local CCD sessions, A and B, in the same working directory.
2. From A, call send_message targeting B with any body.
3. Observe the tool result: Message sent… or Message queued….
4. Inspect B's transcript in ~/.claude/projects/<project>/<cliSessionId>.jsonl for a user turn whose text starts with <cross-session-message from=. It is absent.
5. Ask B directly whether it received anything. It has not.
6. Check ~/Library/Logs/Claude/main.log for Session <B> timed out after Ns … reason=no_response roughly 995 s later.

How to verify a fix

# count genuinely delivered envelopes (must start the turn text; a plain
# substring grep also matches prose mentions and compaction summaries)
grep -c 'cross-session-message from=\\"' ~/.claude/projects/*/*.jsonl

Two measurement traps we hit, in case they help:

• In the JSONL the quotes are escaped, so the probe is from=\", not from=".
• The origin field is not a usable discriminator: delivered peer messages are recorded with origin: {kind: "human"}, even those that arrived successfully before the regression.

Suggested fixes

1. Don't report success without evidence of delivery. Resolve the tool call only once the recipient CLI has echoed/committed the injected turn, or return a distinct "accepted, delivery unconfirmed" state the sender can act on.
2. Persist deferredSends alongside session metadata and re-inject on respawn, instead of deferredSends = void 0 on teardown.
3. Investigate why a peer-origin message yields no first response while a human-origin message on the same live CLI is handled normally. This is the primary defect; the silent loss is its consequence.
4. Surface reason=no_response teardowns to the sender, so a dropped handoff is at least observable.