Claude Code Windowsでクロスセッションメッセージが応答しなくなる不具合

Windows版のClaude Code Desktopで、別セッションへメッセージを送ると受信側が「Thinking」のまま固まる不具合が2026年8月に報告されました。十数分後にエラー表示だけが残り、メッセージそのものが消えます。GitHub Issue #86012としてまとめられ、複数のユーザーが同じ症状を独立に再現しています。

Windows版Claude Code Desktopで何が起きていたか

送信元セッションからsend_messageで別セッションへメッセージを送ると、送信元には成功と表示されます。それにもかかわらず、受信側セッションは新しいトークンを1つも出さないまま応答を止めます。画面上はスピナーが回り続け「考え中」に見えますが、実際には何も処理していません。

この状態はDesktopアプリ自身のアイドルタイムアウト監視によって強制終了されます。時間にして975〜1,227秒、およそ16〜20分後です。終了と同時にオレンジ色の警告と「Claude Code stopped responding」という表示に変わります。メッセージは再送されず、受信側の会話ログ(.jsonl)にも記録が残りません。送信内容はどこにも痕跡を残さず失われます。

Issue内の報告では、この現象がコーディネーター役のセッションが複数のワーカーセッションへタスクを振る運用で特に頻発したとされています。ワーカー側が最初のタスクを受け取った瞬間に固まるケースが多く見られました。複数セッションを並行運用する並列セッション機能を使うほど影響を受けやすい構図でした。

症状の見分け方

同じ不具合かどうかを切り分けるポイントは次の3つです。

• 受信側セッションがisRunning: trueのまま、トークンや応答なしで長時間止まっている
• 十数分待った後に初めて「応答なし」のエラー表示が出る(即座にエラーにはならない)
• 送信元セッションはsend_messageの成功結果を受け取っており、送信自体は失敗と表示されない

この3点、特に「送信は成功と表示されるのに受信側が動かない」という組み合わせが揃う場合、本不具合の可能性が高いといえます。通常の権限確認待ちやネットワーク遅延では起きにくい組み合わせです。単発で応答が遅いだけなら、多くは通常のモデル処理時間の範囲内です。

受信側の状態によって症状の出方が変わる

Issue内の複数の報告を突き合わせると、受信側セッションの状態によって届き方に差があったこともわかります。送信の瞬間に受信側が実際にターンの処理中(mid-turn)だった場合は、正常に届くケースが多く報告されています。一方でアイドル状態やターンとターンの間で待機中のセッションは、isRunning: trueと表示されていても固まりやすかったとされています。isRunningの表示だけでは判別できず、この区別が症状の再現しにくさにつながっていました。

似た症状の別バグと混同しない

Issue内では、Taskツールを使うサブエージェントが600秒でwatchdogに強制終了される別の不具合(Issue #85265)も「似た症状」として言及されています。ただしこちらは単一セッション内のサブエージェント機構が原因で、本記事が扱うDesktopのクロスセッションメッセージング経路とは別の仕組みです。強制終了までの時間も600秒前後とここで扱う975〜1,227秒とは異なり、切り分けの目安になります。

影響を受けたバージョンの時系列

Issueへの報告と公式changelogを突き合わせると、発生から修正までの時系列は次のとおりです。

Issueが作成されたのは2026年8月12日です。複数のユーザーがWindows 11環境で症状を再現し、独立した検証で2.1.222から2.1.227〜2.1.229への更新を境に発生することを確認していました。

発生頻度はどの程度だったか

Issue内のある報告では、2.1.222までの約18日間・5,156件のクロスセッション配信で失敗が一度もなかった環境が、2.1.227への更新直後の最初の送信バッチから約35.6%の失敗率に転じたとされています。別の環境でも同様の現象が確認され、更新直後の失敗率はおよそ40%前後だったと報告されています。更新前は安定して動いていた機能が、エンジンの更新を境に急に不安定化したことがうかがえます。

原因はどこにあったか

Anthropicから技術的な原因説明が公式に出ているわけではありませんが、公開されている事実を並べると輪郭が見えてきます。ネイティブWindows版のクロスセッションメッセージング機能は、公式ドキュメントによればv2.1.234以降で要件を満たすようになりました。一方でmacOS・Linuxはv2.1.224時点で既に対応しています。

つまりv2.1.224からv2.1.233までの期間、Windows版のネイティブ機能はまだ正式対応前の状態でした。Issue上のユーザー調査では、Desktopアプリが従来から使っていた内部的なセッション間通信の経路が関わっていたと報告されています。この移行期間中、届いたメッセージが黙って保留・破棄されており、その失敗がDesktopアプリ側へ伝わっていなかったというものです。受信側セッションは応答を待ち続け、送信元には「成功」と表示され続けました。この失敗が可視化されない設計だったことが、症状をわかりにくくしていたとされます。

この読み方が正しければ、v2.1.234でネイティブWindows対応が要件を満たす形になったタイミングと、changelogに記載された修正のタイミングが一致することにも説明がつきます。

対処法 — v2.1.234以降への更新

公式changelogのv2.1.234には次の記載があります。

Fixed Claude Desktop inter-session messages being silently dropped by the recipient session when cross-session messaging read as disabled, which left the sender's query "thinking" for many minutes

日本語に訳すと「クロスセッションメッセージングが無効と判定されたときに、Claude Desktopのセッション間メッセージが受信側で黙って破棄され、送信元のクエリが何分も『考え中』のままになる不具合を修正」という内容です。Issue内で報告されていた症状とほぼ一致します。この不具合の公式な修正版と見てよい記載です。

対処はシンプルで、Claude Code DesktopとバンドルされているCCDエンジンをv2.1.234以降に更新することです。CLIから使っている場合は、現在のバージョンを確認してから更新してください。

claude --version

表示されたバージョンが2.1.234より前であれば、アプリの自動更新を待つか、Desktopアプリを再起動して最新版を取得してください。Microsoft Store(MSIX)版はアプリと内部エンジンが別々に更新されます。アプリのバージョン表示だけでなく、エンジンの実バージョンも合わせて確認するとより確実です。

更新までの回避策と限界

修正版が出るまでの期間、Issue内では次のような一時的な対応が共有されていました。

• アイドル状態のセッションへsend_messageで新規タスクを振るのを避け、必要な指示は手動でそのセッションのウィンドウを開いて直接入力する
• コーディネーター役からワーカーへの一括タスク振り分けを避け、進行中のセッションを手動でリレーする

いずれも根本的な解決ではなく、複数セッションを自動連携させるという本来のワークフローを一時的に諦める対応です。Issue内ではロールバックを試みた報告もありました。ただしMicrosoft Store版はストアの仕組み上ダウングレードができません。MSIX配布のDesktopアプリを使っている場合、この回避策も選べませんでした。バージョンを固定できない環境では、アップデートを待つことが現実的な対応でした。

クロスセッションメッセージング機能そのものとの違い

本記事が扱うのはv2.1.224〜v2.1.233の期間にWindowsで発生した障害で、すでにv2.1.234で修正されています。crossSessionInbound設定による受信制御や@メンションでの宛先指定、SendMessageの基本的な使い方そのものは不具合の対象ではなく、現在も通常どおり機能します。これらの機能全般についてはClaude Code @メンションでセッション間の連携を制御するにまとめています。

まとめ

2026年8月、Windows版Claude Code Desktopでクロスセッションメッセージが受信側に届かず、送信元には成功と表示されたまま受信側セッションが16〜20分後に強制終了される不具合が報告されました(GitHub Issue #86012)。公式changelogによれば、この不具合はv2.1.234で修正されています。現在この症状に遭遇している場合は、Claude Code DesktopとCCDエンジンの両方がv2.1.234以降になっているかをまず確認してください。