[BUG] Cross-session send_message: receiving session hangs indefinitely on message-initiated turns (regression 2.1.221 to 2.1.227, persists in 2.1.231)

Environment

• OS: Windows 11 Home (10.0.26200)
• App: Claude Desktop (Microsoft Store package Claude_1.28929.0.0_x64)
• Claude Code runtime (app-bundled): 2.1.221 -> 2.1.227 (auto-updated). Also tested standalone CLI 2.1.231.
• Usage: 15-25 concurrent local sessions coordinating via mcp__ccd_session_mgmt__send_message

Summary

Cross-session messaging broke after the runtime auto-updated 2.1.221 -> 2.1.227. Two distinct symptoms isolated:

1. Delivery loss (2.1.227): message card renders in the target session's transcript UI, but never reaches the receiving model's context. Sender gets "sent/queued" success. -> Appears FIXED in 2.1.231.
2. Receive-turn hang (persists in 2.1.231): message delivers, card renders, receiving session starts a turn, then hangs indefinitely (7-10+ min observed) - spinner runs, zero output, no permission prompt. Happens even for a trivial instruction ("write one line to a file") sent to a fresh scrap session. Reproduced with Sonnet 5 / Opus 5 / Fable 5 receivers.

Typing the same instruction manually into the receiving session works instantly. The failure is specific to message-initiated turns.

Timeline evidence

• Runtime 2.1.221 in use Aug 6 - Aug 12: messaging worked daily at high volume.
• Runtime 2.1.227 downloaded Aug 12 16:31 JST, effective after app restart Aug 13 morning - breakage was immediate (same day: 1 silent message loss + 2 receiver hangs, then consistent repro in controlled tests).

Steps to reproduce

1. Two local sessions: A (any) and B (freshly created, idle).
2. From A, send_message to B with a trivial instruction (e.g. "write ACK to file X").
3. B renders the card, starts a turn, then spins indefinitely - no output, no tool calls, no permission prompt. File never written.
4. Type the same instruction into B manually -> executes in seconds.

Ruled out

• crossSessionInbound: "accept" - no effect
• PreToolUse hooks - reproduced with none interfering
• PC reboot - no effect
• Model/effort - reproduced across Sonnet 5 / Opus 5 / Fable 5
• Rollback - not possible: the app's runtime self-heal restores the pinned version on startup, so we cannot return to last-known-good.

Impact

Multi-session orchestration is unusable. We hard-disabled send_message org-wide via a PreToolUse deny hook and fell back to file-based queues + manual copy-paste relay.

Notes

• In-app feedback already submitted (with follow-up addendum); filing here for tracking.
• Possibly related to the "silently stalls mid-session" class (e.g. #40462), but here the hang is reliably triggered by message-initiated turns and manual input does NOT revive the stuck turn.