[BUG] [BUG] セッション間メッセージ送信後、セッションがisRunning:trueのまま応答せず凍結する

GitHub Issue #86016 追加報告文（コピペ用・英語）

Environment

• Claude Code (Desktop app, Windows), appVersion 1.28929.0, nodeVersion 24.18.0, CCD 2.1.227
• Reproduced after full uninstall + reinstall — not a corrupted install issue.

This looks like a known systemic gap, not a one-off

While researching this, we found a structurally identical failure mode reported on a different platform: #57092 ("TeamCreate: stuck agents cannot be terminated from lead session — user must close and restart Claude to recover", macOS). There, a shutdown_request sent to an agent mid-synchronous-tool-call is accepted but never processed until the tool call finishes, and none of the four termination paths (SendMessage shutdown, TaskStop, TeamDelete, UI stop button) have a timeout — recovery requires killing the whole app.

That is the same shape of bug we're reporting here: an acknowledgment-based control message (there: shutdown_request/ack, here: the "echo" for a drained deferred send) has no timeout or fallback, so when the ack is dropped or delayed for any reason, the session deadlocks permanently instead of degrading gracefully. The trigger differs (mid-tool-call state on macOS vs. the Stop-hook-timing race on Windows), but the missing safety net is the same: nothing in the messaging IPC layer gives up on waiting for its counterpart's echo/ack and recovers.

We'd suggest treating this as one systemic fix rather than two platform-specific ones: add a timeout to whatever waits for the echo/ack in the cross-session/team messaging layer, so a dropped acknowledgment degrades to "message failed, session usable" instead of "session dead, requires a hard restart." That single fix would likely resolve both this issue and #57092's family.

Root cause #1: the native-Windows platform gate is not enforced

Per the official docs (https://code.claude.com/docs/en/cross-session-messaging), under Availability:

"Operating system: available on macOS and Linux, including Linux inside WSL 2. Claude Code doesn't offer cross-session messaging on native Windows."

This does not match observed behavior. We are running Claude Code natively on Windows (not WSL2). send_message / cross-session messaging is fully callable from this environment and works most of the time — it only deadlocks intermittently (18 times over 2 days, see below). If the feature is genuinely meant to be off on native Windows, the gate that's supposed to disable it isn't working, and the tool is left exposed and unstable there instead of being cleanly unavailable.

What we actually want: native Windows support for cross-session messaging that works, not a feature that's quietly disabled there. We rely on this daily across a 16-session multi-agent workflow, and Linux/WSL2-only support is a real gap for any Windows-based team running Claude Code this way. Please prioritize bringing native Windows to parity with macOS/Linux by fixing the underlying race (#2 below), rather than treating "disable on Windows" as the resolution.

That said, as a stopgap only, until native Windows is properly supported: enforcing the documented gate (making send_message/ListAgents fail cleanly on native Windows instead of deadlocking) would at least stop the silent freezes in the meantime. This is not the fix we're asking for — it's harm reduction while the real fix (working Windows support) is built.

Root cause #2: the unechoed-input deadlock itself (from main.log analysis)

Every single freeze (15/15 occurrences over 2026-08-13 to 2026-08-14, across 5 different sessions) follows this EXACT 3-line sequence with zero exceptions:

[Stop hook] Query completed for session <id>
[LocalSessionManager] drained 1 deferred send(s) for <id>
[LocalSessionManager] isRunning held by unechoed input at result for <id>
{ resultUuid: '...', pendingEchoUuids: [ '...' ], nextCycleUuid: null, hasPendingCycle: true, inputStreamHasPending: false }

This is a 100% reproducible race condition, not a flaky timing issue:

1. A message sent via cross-session messaging arrives while the target session is still finishing its current turn → it gets queued as a "deferred send" instead of delivered immediately.
2. The moment the Stop hook fires (query completes), the deferred send is drained/flushed.
3. Immediately after, the system enters an "unechoed input" wait state expecting an echo acknowledgment for that just-drained input.
4. The echo never arrives. isRunning stays true forever. hasPendingCycle: true + nextCycleUuid: null = a cycle is expected to advance but its only advance condition (receiving the echo) is never satisfied → permanent deadlock.

The session never recovers on its own. It requires manual intervention (killing the session) to unstick.

Suspected trigger condition

The bug appears specifically when a sendMessage call lands at/near the exact moment the target session's Stop hook fires — i.e. a message sent "just as" the previous turn finishes. This is consistent with cross-session messaging (send_message) being the common denominator across all 15 occurrences.

Correlation with WarmLifecycle idle-timeout

Separately observed: sessions also carry a 900-second (15-min) idle-timeout auto-pause mechanism (WarmLifecycle). Not conclusively linked to the freeze itself, but noted because a Hermes Agent Telegram-gateway hang of similar duration (~15 min) was observed the same day and may be a coincidence worth ruling out separately — not claimed as the same bug.

Impact

Confirmed happening in a live multi-agent workflow (16 concurrent Claude Code sessions coordinating via cross-session messaging) — 15 freezes in 2 days, requiring manual session kills each time. Full reinstall of the app did not resolve it, confirming this is a logic bug, not a corrupted installation.

Update (2026-08-15): confirmed the bug still reproduces after updating to app version 1.30096.5 (CCD 2.1.229 unchanged). Live-tested by deliberately sending a cross-session message to an idle session — it froze within seconds (isRunning stuck true, 6+ minutes with zero progress, spinner running but no response). One difference this time: the exact 'isRunning held by unechoed input' log line did not appear for this occurrence, even though the symptom (isRunning stuck true, lastActivityAt frozen) is identical to the other 18+ occurrences that did log it. Possibly a related variant of the same underlying deadlock, or the logging changed slightly in this version. No workaround exists other than manually killing/restarting the frozen session.

Critical update (2026-08-15, same day, ~10 min after previous comment): reproduced AGAIN, this time on a target confirmed genuinely idle (isRunning:false, no activity for 15+ minutes before send) — not the Stop-hook-timing race originally hypothesized. Log shows nothing at all after 'Sending message to session <id>' (no 'unechoed input' line even), just silence — the receiving session's spinner ran indefinitely with zero progress. This suggests the bug may not be narrowly scoped to the Stop-hook race condition we described earlier; it may be failing much more broadly, closer to 'most/all send_message calls on native Windows are unreliable' rather than a specific timing window. Given this, our internal recommendation is shifting from 'use send_message carefully' to 'avoid send_message entirely on native Windows until fixed.' One positive finding: right-click the target session in the sidebar → 'Open in' → 'New Window' recovers a frozen session without losing conversation history — this is a usable workaround for anyone hitting this.

Workaround confirmed reliable: pressing the stop button in the chat input area (the circular 'running' indicator next to the message box) immediately unsticks a frozen session, with conversation history intact. This is more reliable than closing/reopening the window (which we tried and found inconsistent — an earlier report of that working was likely coincidental timing, not a real fix). For anyone hitting this: just hit stop on the frozen session, no need to restart anything.