send_message (cross-session): sender gets "Message sent", recipient session is never written to and stops responding permanently

Summary

mcp__ccd_session_mgmt__send_message reports success to the sender, but on the recipient side the message is never persisted and the session stops responding from that point on. The receiving session appears frozen: no new turn, no new transcript records, ever again.

The failure is silent in both directions — the sender sees Message sent to session ... ("<title>"), and the recipient's user sees a session that simply stops working.

Environment

| Item | Value |
|---|---|
| Surface | Claude Desktop app (Windows) |
| Plan | Max 20x |
| OS | Windows 11 Pro 26200 |
| Tool | mcp__ccd_session_mgmt__send_message (CCD session management MCP) |

Evidence (from local transcripts)

Recipient session f7cd507f-9485-4f1f-af5c-ffb25dfedfb5 ("MAKE_UI 공통모듈 정리 세션"), 2026-08-17:

Sender side — five sends, all reported successful:

14:48:39.982Z  is_error=None  "Message sent to session local_f7cd507f-… ("MAKE_UI 공통모듈 정리 세션")."
15:10:12.277Z  is_error=None  "Message sent to session local_f7cd507f-… (…)."
15:23:13.095Z  is_error=None  "Message sent to session local_f7cd507f-… (…)."
15:46:26.285Z  is_error=None  "Message queued for session local_f7cd507f-… ; it will be processed after the in-flight turn finishes…"
16:40:08.551Z  is_error=None  "Message sent to session local_f7cd507f-… (…)."

Note the tool resolved the correct session title each time, so the target was found and addressed.

Recipient side — last events in its transcript:

2026-08-17T14:36:30.727Z  assistant       (normal response)
2026-08-17T14:36:33.264Z  system
2026-08-17T15:03:27.719Z  user            "아 이거 또 문제네"   ("this is broken again")
2026-08-17T15:03:29.654Z  user            [Request interrupted by user]
<end of file — 5888 records, nothing after this>

Two things to note:

1. The inbound message text never appears in the recipient transcript. Grepping the recipient file for distinctive strings from the delivered messages returns 0 matches for every one of the five sends. It was not delivered as a user turn, not queued visibly, not recorded at all.
2. The recipient session ends permanently at 15:03:29, 15 minutes after the first send. Four more messages were delivered afterwards (15:10, 15:23, 15:46, 16:40) — all reported as sent — and the recipient produced zero records for any of them. The user's own message at 15:03 got no response and had to be interrupted.

Secondary issues found while investigating

(a) Duplicate tool_use records for a single send. Several sends appear twice in the sender transcript with byte-identical timestamps:

2026-08-17T15:18:01.868Z -> local_32590fb5-…   (x2, same timestamp)
2026-08-17T15:18:26.786Z -> local_1d922d2b-…   (x2, same timestamp)
2026-08-16T16:34:46.074Z -> local_04…          (x2, same timestamp)

If this reflects an actual double-delivery rather than a logging artifact, it may be related to the wedge.

(b) A one-character session-id corruption produced a plain "not found" rather than a validation error:

13:25:11.368Z  is_error=True  "Session local_ada7cef9-af12-4e3a-b336-d1ba81dad5ed not found."
13:26:05.249Z  is_error=None  "Message sent to session local_ada7cef9-af12-4e3a-b336-d1ba81dac5ed ("회사홈페이지")."

This one at least failed loudly, which is the correct behavior — and highlights by contrast that the frozen-recipient case fails silently.

Expected

• The message arrives in the recipient as a user turn labelled From <sender title>, as documented.
• The recipient session continues to accept input afterwards.
• If delivery cannot be completed, the sender gets an error instead of Message sent.

Actual

• Nothing is written to the recipient transcript.
• The recipient session stops producing any records and never responds again.
• The sender is told the message was delivered.

Impact

Cross-session handoff is unusable in practice: using it costs you the receiving session. Because the sender is told delivery succeeded, the sending session's user believes the handoff happened and continues on a false assumption. Recovering means starting the receiving work over in a new session.

Suggestion

• Persist the inbound message to the recipient transcript before acknowledging to the sender, so a wedge is at least diagnosable.
• Have send_message return a delivery-confirmed result (or an explicit queued/failed) rather than an optimistic sent.
• Investigate whether an interrupted or idle recipient turn can leave the inbound-message queue in a state that blocks all subsequent turns.

Related: #87366, #87646 (same machine, long-session behavior).