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

Windows版のClaude Code Desktopで、別セッションへ送ったメッセージが届かず、受信側が「考え中」のまま16〜20分固まる不具合が2026年8月に起きました。GitHub Issue #86012で追跡され、2026年8月23日に閉じられています。直ったかどうかは、アプリ(Desktop)の番号ではなく、同梱されたエンジンの番号で見る必要があります。公式のchangelogが修正を記したv2.1.234でも、Store版では直らなかったという報告が出ているためです。

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

送信元のセッションがsend_messageを呼ぶと、送信元には成功が返ります。受信側のセッションは、新しいトークンを1つも出さないまま止まります。画面ではスピナーが回り続け、考え中に見えます。

受信側の動きが戻らないまま、Desktopアプリ自身の無応答監視が975〜1,227秒後に問い合わせを打ち切ります。その結果、セッションにはエラーバッジ、または橙色の警告と「Claude Code stopped responding」の表示が出ます。メッセージは再送されません。受信側のCLIの会話ログ(.jsonl)に何も残らなかった例も報告されています。

Issueの報告では、コーディネーター役のセッションが複数のワーカーへ作業を振る使い方で被害が目立ちました。並列セッション機能を自動連携に使うほど、1回の取りこぼしが全体の停止に響きます。

同じ不具合かどうかの見分け方

次の3つが揃えば、この不具合の可能性が高くなります。

• 受信側がisRunning: trueのまま、トークンも応答もなく長く止まっている
• 十数分たってから初めて「応答なし」の表示が出る(すぐにはエラーにならない)
• 送信元のsend_messageは成功を返している

受信側の状態で症状の出方が変わる点も、Issueでは繰り返し指摘されています。送信の瞬間に受信側が実際にターンの途中にいた場合は、正常に届く例が多くありました。起動していない待機中のセッションへの送信は、固まりやすい状況です。ターン間で待機しているisRunning: trueのセッションも、表示だけでは区別できません。

別のIssue(#85265)は、Taskツールのバックグラウンドサブエージェントが600秒の固定値で強制終了される問題です。Issue #86012の本文は、これを「同じ系統だが別の仕組み」として挙げています。単一セッション内の話なので、メッセージ送信後に起きる今回の症状とは切り分けられます。

どの版から壊れ、どの版で直ったのか

changelogとIssueを並べると、時系列は次のようになります。

発生前後の失敗率

Issue内のある報告は、5つのエンジン版(2.1.217〜2.1.222)をまたぐ約18日分の配信ログを残していました。数字は次のとおりです。

別のWindows環境からも、同じ版の境目を示すログが投稿されました。macOSでの再現報告もあり、Issueの題名は「Windows+macOS」になっています。

原因はどこにあったのか

Issueで最も詳しい原因分析は、起票と同じ8月12日に投稿されました。受信側のCLIがメッセージを受け取ったあと、新しいネイティブのクロスセッション通信として扱い、Windowsでは無効な機能として配信前に捨てる、という説明です。受信側のデバッグ出力には次の行が出ていたとされています。

[cross-session-inbound] refused inbound peer message — cross-session messaging disabled (kill switch) (remote-io: dropped before attachment materialization)

捨てられたことはDesktopへ伝わりません。Desktopは出ないトークンを待ち続け、監視が打ち切るまで送信側には成功と見えていました。changelogのv2.1.234の行(クロスセッションメッセージングが無効と読めたとき、受信側が黙って捨て、送信元が何分も考え中のまま残る不具合)は、この症状に当たります。

macOSの保留は、公式ドキュメントの受信ルールにも書かれています。何も設定が当たらないとき、権限確認を省く受信側は、送信側が同じく省くと名乗らない限りメッセージを保留し、承認ダイアログを出します。Desktopが挿入するメッセージはこの名乗りを持たなかった、というのが報告者の読みです。

直す手順 — アプリの版ではなくエンジンの版を見る

Issueで混乱を招いたのは、Desktopアプリの番号と同梱エンジンの番号が別だったことです。Microsoft Store(MSIX)版ではエンジンが単独で更新されず、Storeが新しいアプリを配って初めて進みます。報告から、次の組み合わせがわかります。

2.1.234は公式の修正版ですが、Store版では同梱が遅れ、同梱された後も報告が割れました。エンジン2.1.237の確認が複数の環境でそろった後にも、同じ版で再現したという報告が8月25日に1件あります。Issueの題名は、閉じる日に「fixed in 2.1.237 for some installs, stable channel still affected」へ改められました。

手元のCLIの版は、次のコマンドで出ます。v2.1.289で実行した出力を併記します。

claude --version

2.1.289 (Claude Code)

動作を確かめるときの落とし穴

受信側の会話ログへの記録は、メッセージを受け取った瞬間ではなく、キューから取り出された時点で書かれます。受信側がターンの途中だと、Desktopが「queued」を返してから数秒間、ログには何も出ません。この間を見て「届いていない」と判定すると、別の不具合として誤って分類してしまいます。

isRunningは失敗中もtrueを返すため、受信側にCLIが本当につながったかは判別に使えません。報告者はアプリのログ(%APPDATA%\Claude\logs\main.log)のMapping internal sessionという行を、接続できた印として使っていました。この行が出ないまま約1,000秒後にhadFirstResponse=falseの記録が並べば、今回の症状です。

更新後も、壊れたエンジンの時期に届かなかったメッセージの古いカードが受信側に残ることがあります。報告では、そのメッセージ自体は失われていて、セッションは問題なく使えるとのことでした。

アプリの再起動直後に送ると、起動中のセッションが取りこぼす別の問題(Issue #86326)に当たることがあります。こちらも症状が今回と同じなので、数分待ってから試すという報告者の助言が出ていました。

更新できない間に取れた手と、その限界

直る版が届くまでの間、Issueでは次の手が共有されました。いずれも公式の手順ではなく、利用者の報告です。

• 待機中のセッションへのsend_messageを避け、ターンの途中で受け取れる状態のときだけ送る
• コーディネーターからの一括送信をやめ、必要な指示を各セッションのウィンドウに直接入力する
• 環境変数CLAUDE_CODE_HARBOR_KITE=1を~/.claude/settings.jsonのenvに足す(2.1.229で配信が戻った報告が複数ありました。公式のenv-varsと設定リファレンスには載っていない変数です。ただし、Stable版(2.1.224系)のWindowsではこの変数が効かないという報告が、8月17日と8月23日に出ています)

古い版へ戻す方法には制約があります。非MSIXのインストーラー版では、Desktop 1.25927.0(エンジン2.1.221)へ戻して不具合が消えた報告がありました。ただし、アプリだけ古くしてもエンジンが新しいままだと再発します。MSIX版はStoreが古い版を提供しないため、戻す手がそもそもありません。MSIX配布のDesktopアプリを使う環境では、更新を待つのが主な道でした。

今のクロスセッション機能との関係

この記事の不具合は、v2.1.224以降のWindows向けの配信経路の話で、機能そのものの仕様ではありません。@メンションでの宛先指定や、crossSessionInboundによる受信の制御など、機能の基本は通常どおり動きます。それらの使い方はClaude Code @メンションでセッション間の連携を制御するで扱っています。

自分のセッションで機能が使えるかは、/list-agents(別名/peers)で確かめられます。このコマンドが認識されなければ、版の要件を満たしていません。コマンドは動くのに届かない場合は、受信側のcrossSessionInboundや、SendMessageを外す権限の拒否ルールが原因になりえます。/statusのPeer addressの行には、そのセッションの受信口のアドレスが出ます。

まとめ

Windows版Desktopでクロスセッションメッセージが固まるときは、アプリの番号ではなく同梱エンジンが2.1.237以降かを見てください。同梱版の確かめ方は「Windowsで直ったか確かめる」の手順にあります。Store版は同梱の更新が遅れやすいので、更新後にもう一度この確認を通すと取りこぼしません。