Claude Code Desktopの「spawn UNKNOWN」エラーとは？Windows版2.1.87でセッション開始できない不具合を徹底整理

Claude Code DesktopのWindows版で、突然チャットセッションを開始できなくなる「spawn UNKNOWN」エラーが報告されています。特に、CLIは正常に動作しているのに、Desktopアプリだけが新規セッションや既存セッションの再開に失敗するという点が厄介です。しかも、アップデート直後や強制再起動のあとに発生しているケースがあり、日常業務やクライアント対応に直結する深刻な不具合として受け止められています。

本記事では、今回報告された現象からノイズを除去したうえで、エラーの概要、発生環境、考えられる原因、影響範囲、そして今すぐ取れる現実的な対処法までをわかりやすく整理します。単なる不具合紹介にとどまらず、「なぜCLIは動くのにDesktopだけ失敗するのか」という視点から、実務上役立つ読み解き方も掘り下げていきます。

Claude Code Desktopの「spawn UNKNOWN」エラーとは？Windows版2.1.87でセッション開始できない不具合を徹底整理

問題の概要：Windows版Desktopアプリでセッション開始時に「spawn UNKNOWN」

報告されている不具合の中心は、Windows 11環境でClaude Code Desktopアプリを利用した際、新しいセッションを開始しようとすると即座に「spawn UNKNOWN」というエラーが表示される、というものです。

表示される内容は、リモートメソッド呼び出しの失敗を示す長いエラーメッセージですが、利用者にとって重要なのは一点です。Desktopアプリ側が内部的に必要なプロセスを起動できず、会話セッションを立ち上げられない状態に陥っていることです。

この症状の厄介なところは、アプリそのものが完全に起動不能になるわけではない点にあります。見た目上はDesktopアプリが立ち上がり、プレビュー表示も行われるため、一見すると正常に見えます。しかし、実際にメッセージを送信したり、新しいセッションを開始しようとした瞬間に失敗するため、実用上はほぼ使えません。

発生している環境

報告内容から整理すると、発生環境は以下のようにまとめられます。

OS

Windows 11

Claude Codeのバージョン

2.1.87

インストール方法

公式インストーラー

Nodeバージョン

v24.14.0

Gitバージョン

2.53.0.windows.2

注目したいのは、CLI版のClaude Code自体は正常に動作していることです。たとえば、バージョン確認コマンドは問題なく通り、ターミナルからの起動も可能とされています。つまり、Claude Code全体が壊れているのではなく、「Desktopアプリがセッション開始のために呼び出すローカル実行処理」に何らかの不整合が起きている可能性が高いと考えられます。

具体的に何が起きているのか

今回の不具合を利用者目線で言い換えると、次のような状態です。

まず、Desktopアプリは起動します。画面も表示され、外形上は普段通り使えそうに見えます。ところが、Codeタブから新規セッションを始めたり、既存セッションを再開しようとした途端にエラー通知が表示されます。さらに、チャット欄に入力して送信しようとしても同様に失敗し、やり取りを続けることができません。

一方で、ターミナルからCLI版を使うと正常に動くため、「認証が切れている」「Claude Code自体が完全に破損した」という単純な話ではありません。Desktopアプリ特有のセッション起動経路、またはその依存先にだけ問題が出ていると見るのが自然です。

再現手順は非常に単純

再現までの流れは複雑ではありません。むしろ、普段通りの操作で即発生する点が深刻です。

Windows PowerShellを開く
Claude Code Desktopアプリを起動する
Codeタブへ移動する
新しいセッションを開始、または既存セッションを再開しようとする
その直後に「spawn UNKNOWN」エラーが表示される

このように、特定の特殊な設定や複雑な条件が必要な不具合ではなく、通常利用の最も基本的な導線で発生しています。業務で利用しているユーザーにとって影響が大きいのはこのためです。

何を試しても直らないという点が重要

報告では、すでに複数の一般的な対処法が試されています。しかし、それでも改善しなかったとされています。具体的には以下のような対応です。

再インストール

npm経由と公式インストーラー経由の両方で再導入を実施

実行ポリシーの変更

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

Git Bash関連の設定

settings.jsonにGit Bashのパスを追加

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

ローカルのセッション関連フォルダをクリア

PCの再起動

フル再起動を実施

これだけ試しても解消しないとなると、単純な設定ミスや一時的なキャッシュ破損だけでは説明しにくくなります。特に、インストールし直しても同じ症状が続く場合、アプリのバージョン固有の回帰不具合、あるいはWindows環境特有のプロセス起動条件に関わる問題である可能性が高まります。

回帰不具合として見るべき理由

今回のケースでは、「2.1.86では動いていたが、2.1.87に自動更新されたあと壊れた」という情報が極めて重要です。これは典型的な回帰不具合の兆候です。

回帰不具合とは、以前のバージョンでは正常だった機能が、新しい変更の導入によって動かなくなる現象を指します。今回の事例では、利用者の操作方法が急に変わったわけではなく、アプリ更新後から症状が出ているため、2.1.87で加えられた何らかの変更がDesktop側のローカルセッション起動処理に影響した可能性があります。

さらに、問題の発端として「アプリのフリーズ後に強制再起動した」という経緯も示されています。この点は見逃せません。アップデート後の状態遷移が完全に終わる前にアプリやOSが異常終了すると、一部の設定、実行パス、内部状態、権限情報、またはセッション用の補助ファイルが中途半端な形で残ることがあります。これが新バージョンの挙動と噛み合わず、Desktopアプリだけが内部プロセスを正常起動できなくなった可能性もあります。

なぜ「CLIは動くのにDesktopだけダメ」なのか

この現象を理解するうえで最大のポイントはここです。CLIが正常なら、Claude Codeのコア機能やユーザー環境のすべてが壊れているわけではありません。にもかかわらずDesktopだけ失敗するのは、起動経路が異なるからです。

CLIは、ユーザーが直接ターミナルからプロセスを実行します。対してDesktopアプリは、内部で別のローカルプロセスや補助的なセッション管理機能を呼び出し、その結果をGUI上で扱います。つまり、同じClaude Codeを使っているように見えても、裏側では異なる実行ルートが存在します。

この違いから推測できるのは、次のような要因です。

パス解決の失敗

Desktopアプリが参照するNodeやGit、シェル、または内部バイナリの場所を正しく見つけられない

権限や実行コンテキストの差

PowerShellやターミナルでは動くが、GUIアプリとして起動されたプロセスからは同じ権限・同じ環境変数で実行できない

更新後の設定不整合

アプリ更新で必要な内部設定が変更されたが、既存設定やキャッシュとの整合が崩れた

セッション起動モジュールの不具合

ローカルセッション開始時だけ特定条件で例外が発生する

「spawn UNKNOWN」というメッセージ自体は原因を細かく示してくれませんが、少なくとも“何かを起動しようとしてOSレベルで失敗している”ことを示唆しています。だからこそ、ユーザー側では直しにくく、アプリ側の修正待ちになりやすい不具合です。

実務への影響は想像以上に大きい

この不具合は単なる軽微な表示崩れではありません。Desktopアプリで新規・継続セッションが開始できない以上、開発フローやレビュー作業、調査、ドキュメント生成など、普段GUI中心でClaude Codeを使っている人は一気に生産性を落とします。

特に、CLIには慣れていても、Desktopアプリのセッション履歴管理や視覚的な操作性を前提に業務を組んでいる人にとっては、代替が簡単ではありません。クライアントワークの締切が迫っている場面でこのエラーに遭遇すれば、単なる不便では済まず、作業計画そのものの見直しが必要になります。

今回の報告でも、まさに業務中で締切を抱えた状態で発生しており、現場へのダメージの大きさがうかがえます。

現時点で考えられる現実的な回避策

根本修正はアプリ側の対応が必要になる可能性がありますが、実務を止めないために検討したい回避策はあります。

1. 一時的にCLI運用へ切り替える

もっとも現実的なのはこれです。CLIが正常動作しているなら、少なくとも作業自体を完全停止せずに済みます。GUIに依存していたフローは多少崩れますが、緊急避難としては十分価値があります。

Desktopの復旧を待つ間、重要案件だけでもCLI中心に移すことで、致命的な遅延を防げます。

2. 直前の正常版へ戻す

最後に正常動作していたのが2.1.86であれば、可能であればそのバージョンへのロールバックは有力です。回帰不具合である以上、最新版を維持することよりも、安定版へ戻すほうが実用的なケースは少なくありません。

ただし、ロールバック手段が正式に用意されているか、設定や自動更新をどう扱うかは慎重に確認する必要があります。更新直後に再び同じ状態へ戻されないようにする視点も欠かせません。

3. Desktopアプリの設定・キャッシュ・セッション関連データを重点確認する

すでにセッションフォルダ削除は試されているものの、Desktopアプリが参照する設定、環境変数、実行パス、シェルの指定先が更新後にズレていないかは改めて確認する余地があります。CLIで通っているパスとDesktopが参照するパスが一致しているとは限らないためです。

特にWindowsでは、ユーザー環境変数、システム環境変数、PowerShell側の設定、Git Bashの場所、Node実行パスなどが複雑に絡むことがあります。GUIアプリは、ターミナルで確認した値と完全に同じ文脈で起動していない可能性があります。

4. 強制終了後に壊れた内部状態を疑う

フリーズ後の強制再起動がきっかけになっている以上、更新そのものだけでなく、不完全な状態の残存も疑うべきです。内部的なローカルセッション管理情報、権限キャッシュ、一時ファイル、あるいはアプリが依存する周辺コンポーネントの整合が崩れている可能性があります。

そのため、単純な再インストールだけでなく、関連データをより広い範囲で見直すアプローチが必要になる場合があります。

この不具合から学べること

今回の事例は、開発支援アプリを業務の中核に置くときのリスク管理を考えるうえでも示唆に富んでいます。

まず、CLIとDesktopの両方が使える製品では、片方が落ちてももう片方で最低限の作業を継続できるようにしておくことが重要です。普段GUIしか使わない場合でも、最低限のCLI利用手順を把握しておくだけで緊急時の耐性が大きく変わります。

また、自動更新は便利ですが、業務クリティカルな環境では更新直後の挙動確認を挟む価値があります。安定性が最優先の現場では、即時更新よりも、正常性確認後に展開する運用のほうが事故を減らせることがあります。

さらに、Windows環境では「ターミナルで動く」と「Desktopアプリ内で動く」が必ずしも同義ではありません。見た目には同じ機能でも、実行コンテキストが異なる以上、依存関係や権限、パス解決の問題が別々に発生し得るという理解は持っておきたいところです。

まとめ：Desktop固有のセッション起動不具合として見るのが妥当

今回の「spawn UNKNOWN」エラーは、Windows版Claude Code Desktop 2.1.87において、ローカルセッション開始時に発生している深刻な不具合として整理できます。CLIが正常であること、2.1.86では動作していたこと、アップデート後かつ強制再起動後に発生していることから見ても、Desktopアプリ固有の回帰不具合、または更新後の内部状態不整合として捉えるのが自然です。

利用者側で一般的な対処を一通り試しても改善しない以上、根本的にはアプリ側の修正が必要になる可能性が高いでしょう。ただし、実務面ではCLIへの一時退避、安定版へのロールバック検討、Desktop固有の設定・キャッシュ再点検といった対応によって、被害を最小限に抑える余地はあります。

今回のような不具合は、単なる技術的なエラー表示以上に、「どこが壊れていて、何はまだ使えるのか」を冷静に切り分けることが重要です。Desktopが使えなくてもCLIが生きているなら、完全停止ではありません。そうした視点を持つだけでも、現場の混乱はかなり減らせます。今回のケースはまさに、その判断力が問われる典型例だといえるでしょう。