Claude Code Desktop for Windowsで「spawn UNKNOWN」発生　v2.1.87で新規セッション開始不能になる不具合を整理

Windows 11環境でClaude Code Desktopを使っているユーザーの間で、アップデート後に突然「Error: spawn UNKNOWN」が表示され、新しいセッションを開始できなくなる不具合が注目されています。特に今回のケースでは、CLI版は正常に動作している一方、Desktopアプリだけが会話開始時に即エラーを返すという点が厄介です。業務利用中にこの症状へ直面すると、作業が止まりやすく、原因の切り分けにも時間を奪われます。この記事では、報告内容からノイズを除去したうえで、発生状況、想定される原因、切り分けのポイント、当面の対処法までを実務目線でわかりやすく整理します。

• Claude Code Desktop for Windowsで「spawn UNKNOWN」発生　v2.1.87で新規セッション開始不能になる不具合を整理
  • Windows版Claude Code Desktopで発生した「spawn UNKNOWN」エラーとは何か
  • 今回の不具合で確認されている環境
  • 症状の特徴　CLI版は動くのにDesktop版だけ使えない
    • 1. Desktopアプリ独自のプロセス起動処理
    • 2. Desktop側の設定やセッション情報の破損
    • 3. バージョン2.1.87固有のWindows回帰
  • 再現手順から見える不具合の深刻さ
  • すでに試されている対処からわかること
  • 「spawn UNKNOWN」が示唆する技術的な背景
    • 実行パスの解決失敗
    • 権限または実行ポリシーの不整合
    • セキュリティソフトやWindows Defenderの干渉
    • 壊れたセッションデータやロックファイル
    • バージョン間の互換性問題
  • 今回のケースで最も有力な見方
  • 業務影響が大きい理由
  • 当面の現実的な対処法
    • CLI版を暫定の主力に切り替える
    • 自動更新直後なら前バージョン運用を検討する
    • ユーザーデータ領域の完全初期化を検討する
    • セキュリティソフトやDefenderの隔離履歴を確認する
    • Git、Node、PATHの認識差を見直す
  • 今後、同様の不具合に備えるための教訓
  • まとめ　問題の本質は「Windows版Desktopのセッション起動失敗」

Windows版Claude Code Desktopで発生した「spawn UNKNOWN」エラーとは何か

今回報告されている不具合は、Windows 11上でClaude Code Desktopを起動し、Codeタブから新しいセッションを開始、または既存セッションを再開しようとした瞬間に発生するものです。画面右上にエラー通知が出て、メッセージ送信や会話開始ができなくなります。

表示される代表的なエラーは、Desktopアプリ内部でローカルセッションを開始しようとしたタイミングで失敗し、「spawn UNKNOWN」という文言が返るというものです。ポイントは、アプリそのものが起動しないわけではないことです。プレビュー表示までは進むものの、実際のセッション開始処理だけが止まってしまうため、一見すると軽微な不具合に見えます。しかし実際には、チャット送信や作業継続が不可能になるため、実用上の影響はかなり大きいといえます。

この手のエラーは、Windows上で外部プロセスの起動に失敗した場合によく見られる系統です。つまり、Desktopアプリが内部的に必要とするプロセスや関連コマンドを立ち上げようとしたものの、何らかの理由で実行できず、汎用的な失敗コードとして「UNKNOWN」が返っている可能性が高いと考えられます。

今回の不具合で確認されている環境

報告内容を整理すると、問題が起きている主な環境は次のような条件です。

• OSはWindows 11

• Claude Codeのバージョンは2.1.87

• 導入方法は公式インストーラー

• Node.jsはv24.14.0

• Gitは2.53.0.windows.2

• 直前まで正常動作していたバージョンは2.1.86

特に重要なのは、「前のバージョンでは動いていたが、自動更新後の2.1.87で壊れた」と明確に示されている点です。これは単なる環境固有の設定ミスではなく、バージョン更新を契機にDesktopアプリ側の起動フローや依存関係の扱いが変化し、Windows特有の条件で不整合が起きた可能性を強く示しています。

また、強制再起動のあとに症状が出始めたという背景も見逃せません。アプリがフリーズしたあとにOSを強制再起動すると、セッション関連ファイル、ローカルキャッシュ、一時ディレクトリ、権限状態、あるいは実行中だった補助プロセスの整合性が崩れるケースがあります。アップデートのタイミングと強制再起動が重なったことで、症状が表面化した可能性もあります。

症状の特徴　CLI版は動くのにDesktop版だけ使えない

この不具合で最も重要なのは、「Claude Code CLIは正常に動作する」という点です。

具体的には、ターミナルからバージョン確認が通り、CLI自体も起動できています。つまり、Claude Code本体のすべてが壊れているわけではありません。コマンドライン環境では問題なく利用できる一方で、Desktopアプリ内からローカルセッションを作成する処理だけが失敗している構図です。

この差分から見えてくるのは、問題の中心が以下のどれかにある可能性です。

1. Desktopアプリ独自のプロセス起動処理

Electron系のデスクトップアプリでは、バックエンド処理やローカルワーカー起動時に内部で子プロセスを生成することがあります。このとき、PATH、シェル、実行ファイル位置、環境変数、権限、セキュリティ制御の影響を受けやすくなります。CLIが正常でも、Desktop経由のspawnだけ失敗することは十分ありえます。

2. Desktop側の設定やセッション情報の破損

強制再起動のあとに不具合が出た点を踏まえると、ローカルセッション関連の保存データやキャッシュが中途半端な状態になり、Desktopだけが正常に再初期化できなくなっている可能性があります。

3. バージョン2.1.87固有のWindows回帰

報告では2.1.86が最後の正常動作版とされています。これは典型的な回帰不具合の兆候です。新バージョンで導入された変更がWindowsの特定条件にだけ影響し、結果としてDesktopのLocalSessions開始処理が失敗している可能性があります。

再現手順から見える不具合の深刻さ

再現手順は非常に単純です。

1. Windows PowerShellを開く

2. Claude Code Desktop v2.1.87を起動する

3. Codeタブへ移動する

4. 新しいセッションを始める、または既存セッションを開く

5. すぐに右上へエラーが表示される

ここで厄介なのは、特定のプロジェクトや特殊な操作をしなくても発生することです。つまり、再現条件が狭い不具合ではなく、日常的な基本操作で即座に表面化するレベルの障害になっています。ユーザーにとっては「アプリは開くのに、実作業だけできない」という最悪に近いパターンです。

しかも、送信操作に入る前後で即失敗するため、ネットワーク不良やモデル側の混雑と誤認しやすいのも問題です。クラウドサービスの応答遅延ではなく、ローカル環境でのセッション生成失敗である点を見誤ると、無駄な再ログインやブラウザ確認に時間を使ってしまいます。

すでに試されている対処からわかること

報告者はかなり広範囲に対処を試しています。主な試行内容は次の通りです。

• npm経由および公式インストーラー経由での再インストール

• PowerShellの実行ポリシーをRemoteSignedへ変更

• Git Bashのパスをsettings.jsonへ追加

• セッションフォルダの削除

• PCのフル再起動

これだけ試しても改善していないという事実は重いです。一般的な初歩対応で直る範囲をすでに超えている可能性があります。特に、Git Bashのパス設定や実行ポリシー調整まで実施済みである点から、単純な初回セットアップ不足ではなく、アプリ側の起動フローそのものに問題があると見る方が自然です。

また、再インストールしても直らない場合、アプリ本体ではなくユーザープロファイル配下の設定、キャッシュ、権限、残存プロセス、あるいは更新時に引き継がれた状態データが原因であるケースが考えられます。Windowsアプリの不具合では、アンインストールしてもユーザーデータが残るため、見かけ上は再インストールしても同じ壊れ方を繰り返すことが珍しくありません。

「spawn UNKNOWN」が示唆する技術的な背景

このエラー文言だけで断定はできませんが、一般に「spawn UNKNOWN」は、アプリが外部コマンドや補助プロセスを生成しようとして失敗した際に現れることがあります。Windowsでは特に以下のような要因が絡みやすいです。

実行パスの解決失敗

必要な実行ファイルの場所をDesktopアプリが見つけられない場合、CLIでは通るのにGUIアプリでは失敗することがあります。ターミナルはユーザーのPATHを正しく読めていても、Desktopアプリ起動時の環境変数が異なると挙動が変わります。

権限または実行ポリシーの不整合

PowerShellやスクリプト実行に関係する処理が介在している場合、強制再起動後や更新後に権限周りの状態が変化し、必要な補助処理が起動できなくなることがあります。

セキュリティソフトやWindows Defenderの干渉

更新直後の実行ファイルや一時生成されるプロセスに対し、防御機構が働くケースもあります。CLIでは手動起動のため通っても、Desktop内部の自動spawnだけがブロックされることはありえます。

壊れたセッションデータやロックファイル

強制終了やフリーズのあとでは、セッションファイルや一時ファイルに矛盾が残り、次回起動時に新しいローカルセッションを生成できなくなる場合があります。

バージョン間の互換性問題

2.1.86から2.1.87への更新で、Windows向けの起動方法、依存関係、セッション管理方式のどこかが変更され、それが特定環境でのみ顕在化した可能性も高いです。

今回のケースで最も有力な見方

報告内容を素直に読むと、もっとも有力なのは「Windows版Desktopアプリの回帰不具合」です。理由は明確です。

まず、前バージョンでは正常に動作していました。次に、CLI版は引き続き使えています。さらに、設定調整や再インストールといった基本対応でも解消しません。そして、問題はローカルセッション開始というDesktop固有の処理で起きています。

この並びを見る限り、ユーザーの操作ミスというより、アップデート後のDesktopアプリがWindows環境で外部プロセス起動に失敗する条件を抱えていると考えるのが自然です。もちろん、強制再起動によるローカルデータ破損が引き金である可能性は残りますが、それでも「2.1.87で発生し、2.1.86では発生しなかった」という差は非常に大きい材料です。

業務影響が大きい理由

この不具合は、単なる軽微なUIエラーではありません。特にクライアントワークや開発補助でClaude Code Desktopを使っている人にとっては、かなり厳しい障害です。

理由は、アプリが完全に落ちるわけではないため、最初は「少し不安定なだけ」と誤解しやすいことにあります。ところが実際には、新規セッション開始も継続も不可能で、会話入力そのものが止まります。見た目だけ動いて中身が使えない状態は、作業判断を遅らせ、復旧までの時間を余計に延ばします。

しかもCLIは使えるため、完全停止ではないものの、普段Desktop中心で運用していた人ほど workflow の再構築が必要になります。セッション管理、視認性、操作の一貫性、チーム内共有のやり方がDesktopベースだった場合、業務効率は大きく落ちるでしょう。

当面の現実的な対処法

根本修正はアプリ側のアップデート待ちになる可能性がありますが、実務上は止まらないことが最優先です。そこで、現時点で現実的な対処を整理します。

CLI版を暫定の主力に切り替える

報告ではCLIが正常動作しています。まずはDesktop復旧にこだわりすぎず、期限のある作業はCLI中心へ切り替えるのが最も合理的です。使える経路が残っているなら、業務停止を避ける判断が先です。

自動更新直後なら前バージョン運用を検討する

最後に正常だったバージョンが明確な場合、安定版へ戻す判断は有力です。特に本番作業で使うツールは、新版の不具合が落ち着くまで一世代前を使う方が安全なことがあります。

ユーザーデータ領域の完全初期化を検討する

通常のアンインストールで消えない設定やキャッシュが残っていると、再インストールの効果が出ません。Desktopアプリ関連のローカルデータ、キャッシュ、セッション保存領域を慎重に退避してから完全初期化することで改善するケースがあります。ただし、作業履歴や設定消失のリスクがあるため、むやみに実行せずバックアップ前提で進めるべきです。

セキュリティソフトやDefenderの隔離履歴を確認する

更新された実行ファイルや子プロセス生成がブロックされていないかは確認価値があります。特にWindowsでは、GUIアプリの裏側で動く補助プロセスだけ防御対象になることがあります。

Git、Node、PATHの認識差を見直す

CLIで動くから大丈夫と決めつけず、Desktopアプリから見えている環境変数や参照先が一致しているかを疑うことも重要です。Git Bashのパス設定をしていても、実際にアプリが必要としているのは別のシェルや別形式のパスかもしれません。

今後、同様の不具合に備えるための教訓

今回のケースは、AI開発支援ツールを実務投入するうえでの重要な教訓も含んでいます。

ひとつは、デスクトップ版とCLI版の二系統を使える状態にしておくことです。どちらか一方が不安定になっても、もう一方で業務を継続できれば被害は大きく減ります。

もうひとつは、自動更新を無条件で本番環境へ入れないことです。便利な反面、回帰不具合が混入した場合の影響は大きくなります。特に締切前や案件繁忙期には、安定版維持の方が価値を持つ場面があります。

さらに、強制再起動のあとにアプリ不具合が出たときは、単なる再起動で済ませず、ログ、キャッシュ、セッションデータ、更新履歴をまとめて確認する姿勢が重要です。表面的には同じエラーでも、原因は権限、パス、破損データ、回帰バグのどれかで大きく変わります。

まとめ　問題の本質は「Windows版Desktopのセッション起動失敗」

今回の報告を整理すると、本質は非常にシンプルです。Windows 11上のClaude Code Desktop v2.1.87で、ローカルセッション開始時に「spawn UNKNOWN」が発生し、新規・継続を問わずDesktopチャットが使えなくなる。しかもCLIは正常なため、問題はClaude Code全体ではなく、Desktopアプリのセッション起動処理に集中している可能性が高い、ということです。

加えて、2.1.86では動いていた事実から、2.1.87での回帰不具合である疑いはかなり強いと見てよいでしょう。再インストールや基本設定の見直しでも解消しない以上、現場では「なぜ壊れたか」を追いかけるより、「どう業務を止めないか」を優先するのが正解です。CLIへの一時退避、安定版へのロールバック検討、ローカルデータの慎重な初期化、この3つが当面の現実策になります。

Windows版のDesktopツールは便利ですが、今回のように内部のプロセス起動失敗が起きると、見た目以上に深刻な作業停止へ直結します。同じ症状に遭遇した人は、自分の設定だけを疑って時間を消耗するのではなく、「バージョン依存の回帰」「Desktop固有の障害」という視点で切り分けることが、最短で復旧に近づくポイントです。