2.1.229 Windows: cross-session message now delivers but immediately freezes the recipient session (zero output until watchdog) — regression persists from 2.1.227

Summary

On the latest desktop app (1.30096.0.0, bundled runtime 2.1.229, Windows 11 native), cross-session messaging has shifted failure modes rather than being fixed:

• Now working: message delivery. The send succeeds and the message renders in the recipient session (visible as a cross-session-message block). This matches the 2.1.228 changelog fix ("Fixed SendMessage reporting 'Message sent' when the write … had actually failed").
• Still broken: the moment the message is injected, the recipient session's next turn freezes with zero output — spinner ran 1m31s+ with no token and no tool call, human-observed on screen; the transcript shows the injected message as the last turn with nothing after it. This is the same hadFirstResponse=false hang as #86012, which we have now reproduced on 2.1.229 after a clean reboot.

Net effect: sending a message is now worse than before for the sender — it reliably freezes the recipient session for the 15–20 min watchdog window.

Environment

• Windows 11 Pro 10.0.26200 (native, not WSL)
• Claude Code desktop app 1.30096.0.0 (Store/MSIX), bundled runtime 2.1.229 (verified via running process path …\claude-code\2.1.229\claude.exe)
• Clean reboot after update, multiple concurrent local sessions, same OS user

Repro (fresh, today)

1. Update to 1.30096.0.0 / 2.1.229, reboot.
2. Session A (coordinator) sends a short message to session B via the session-management send_message.
3. Result: send returns success; message renders in B; B's next turn produces zero output and hangs (observed 1m31s+ before the operator interrupted; prior observations on 2.1.227 ran 16–20 min to watchdog kill).

Note: an earlier send a few minutes after reboot (possibly before B's inbox socket was bound) returned success but never appeared in B's transcript, with no held/expiry notice to the sender — may be a startup-window edge case worth checking alongside.

Related

• #86012 — original recipient-hang report (2.1.227); we reproduced it on 2.1.229 and commented there.
• #86275 — sender-side false-success report; that axis is fixed in 2.1.228+.

Filing this as a distinct report because the user-visible behavior on the current release is new (delivered-then-freeze rather than silent loss) and because the docs still list native Windows as unsupported for cross-session messaging while delivery now partially works there — an explicit platform gate or a fix for the hang would both resolve the operational hazard.