Claude Desktop（Windows）のCoworkが使えない原因と対処法まとめ：VMクラッシュ／タブ消失／sdk-daemon未接続を現場目線で整理

Windows版Claude Desktopの「Cowork」が、入力直後にエラーで落ちて何も進まない、VMがクラッシュして復帰してもすぐ死ぬ、再インストール後にCoworkタブ自体が消える——。こうした症状は単発の不具合というより、**Windows上でCoworkを成立させるための前提（VM通信・共有フォルダ・ネットワーク・アプリ版の互換）**のどこかが崩れたときに、複数のエラーとして噴き出しているケースが目立ちます。実際、同種の報告はGitHub上でも継続的に増えています。 GitHub+2GitHub+2

Claude Desktop（Windows）のCoworkが使えない原因と対処法まとめ：VMクラッシュ／タブ消失／sdk-daemon未接続を現場目線で整理

いま起きている典型症状（そのまま放置すると「一瞬直って即死」になりやすい）

報告が多い流れはだいたい次のパターンです。

プロンプト送信直後に即エラー（作業が始まらない）
たまに1回だけ成功→次の入力でまた即死
その過程でCoworkタブが消え、「Chat」しか残らない
再起動・再インストールで状態が揺れ、再現性が高いのに原因が見えにくい GitHub+1

この「揺れる」挙動は、Coworkが内部でWindows上のVM（仮想環境）と通信し、さらにホストのフォルダ共有や**ローカルのデーモン（sdk-daemon）**に依存しているため、どれか1つが不安定だと別のエラー文に化けて出るのが厄介な点です。 GitHub+1

エラーメッセージ別にみる“根っこ”の原因

1) `sdk-daemon not connected`：Coworkの土台が立ち上がっていない

Cowork側のローカル常駐プロセス／VM連携が途切れているときに出やすい代表格です。更新直後の不安定化や、VM起動失敗の“結果”として出ることもあります。 GitHub+1

2) `failed to write length: An established connection was aborted...`：ホスト側が接続を強制終了

Windows側（ホスト）が、CoworkとVM間の通信を途中で切っている状態で起きやすいです。クラッシュ後の再起動で固定化する報告もあります。 GitHub+1

3) `RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address`：共有フォルダ（virtiofs/Plan9）が死んでいる

Coworkはホスト（Windows）の作業フォルダをVM側にマウントしますが、ここが失敗するとワークスペースが立ち上がらず連鎖的に落ちます。OneDrive配下や特殊なパス、シンボリックリンク、ドライブ境界などが絡むと地雷になりやすいという指摘が出ています。 GitHub+2GitHub+2

4) `Prompt is too long`：本当に長いとは限らない（保険的なエラー表示）

「1〜2回の会話で突然出る」「普通の長さでも出る」という報告があり、実態としては内部状態の破損や接続不良を“別メッセージ”で見せている可能性があります（ユーザーが悪いわけではない）。 GitHub+1

5) Coworkタブが消える：機能フラグ／初期化／互換性の問題に巻き込まれている

Coworkの設定が残っているのにタブだけ出ない、再起動後に消えるなどの報告が複数あります。アプリ側の状態（キャッシュ・設定・VM関連フォルダ）が壊れていると、UIからCoworkが“なかったこと”にされることがあります。 GitHub+2GitHub+2

まず効く「現実的な切り分け」チェックリスト（上から順に）

ここからは、同種事例で改善報告が出やすい順に並べます。目的は「勘で再インストールを繰り返す」のをやめて、原因層を一段ずつ潰すことです。

A. アプリを“最新版でクリーン化”する（古いビルド残りが地味に多い）

CoworkはWindowsでの依存が多く、古いDesktop版が残っていると挙動が不整合になりがちです。完全終了→アンインストール→最新版を入れ直しは最初にやる価値があります。 Reddit+1

B. 仮想化（VT-x/AMD-V）とWindows側の仮想化機能を確認する

CoworkはVM前提なので、BIOSで仮想化が無効だと、起動できても不安定化しやすいです。環境によってはHyper-V系の競合も起こり得ます（WSL/他社VMツール併用など）。

C. 作業フォルダを“安全なローカルパス”へ移す（OneDrive・同期フォルダは避ける）

virtiofs/Plan9周りのエラーがあるなら最重要です。

OneDrive配下、クラウド同期、プレースホルダファイル
ドライブをまたぐリンク／NTFSシンボリックリンク
権限が特殊な場所（企業PCのリダイレクトなど）
これらを避け、まずは C:\work\project のようなシンプルなローカルに置いて動作確認するのが早いです。 GitHub+2GitHub+2

D. VPN・セキュリティ製品・ネットワークアダプタを疑う（通信が“ホスト都合で中断”される）

「接続がホストで中断された」系は、VPNやセキュリティ機能、不要な仮想NICが影響することがあります。VPNを切る／不要アダプタを無効化するだけで改善した例も共有されています。 LinkedIn+1

E. VM関連データの破損を疑い、Coworkのローカル状態を再生成する

クラッシュ→復帰→即死、タブ消失など“状態が揺れる”場合は、VMイメージやキャッシュが壊れている可能性が高いです。コミュニティでは、VM関連フォルダを削除して再生成させる手順が言及されています（削除前にバックアップ推奨）。 Reddit+1

再発しやすい人の共通点（“プロンプト”ではなく“環境”が原因）

同期フォルダ（OneDrive等）にプロジェクトを置いている
会社PCでセキュリティが強く、通信・仮想化・ドライバが制限される
WSL/他の仮想化ソフトを常用していて競合がある
直近のアプリ更新で急に不安定化した（特定バージョンでの不安定報告が出ている） GitHub+2GitHub+2

どうしても安定しないときの“現実解”

1〜2時間潰しても改善しない場合、仕事用途では割り切りが重要です。

CoworkではなくChatモードで作業を継続（ワークフローを止めない）
Windows上での利用を継続するなら、プロジェクト場所・VPN・仮想化周りを最小構成にする
エラー文と再現手順をまとめ、既存の同種Issueに寄せて報告する（重複を避けつつ解決の糸口が早い） GitHub+1

まとめ：エラーはバラバラでも、直す順番は同じ

CoworkのWindows不具合は、見えているエラーが違っても「VM」「共有フォルダ」「ローカルデーモン」「ホスト側の通信遮断」のどれかに収束しがちです。
最新版のクリーン化 → 仮想化確認 → ローカルフォルダへ移動 → VPN/セキュリティ切り分け → VM状態再生成。この順番で潰すと、闇雲な再インストールより短時間で“原因層”に当たりやすくなります。