Coworkで「workspace unavailable」と出たときの対処法
workspace unavailableは、ローカルセッションの隔離VMが起動できないときに出るエラーです。括弧内の理由の読み方、GitHub issueで報告された事例、再起動が効くかどうかの切り分けをまとめました。
Coworkでタスクを実行中に「workspace unavailable」と表示された場合、これはローカルセッションの隔離VM(仮想マシン)が起動できていないことを示すエラーです。ファイルやWebを使うツールはこの間も動き続けるため、影響範囲を正しく把握すれば過度に心配する必要はありません。VM自体は動いているのにアプリ全体の動作が重いという場合は、Claude DesktopとCoworkが重いときの原因と対処法で原因の切り分け方を扱っています。
workspace unavailableが示していること
Coworkのローカルセッションは、Claudeとの会話そのものをパソコン上でネイティブに実行する一方、シェルコマンドとコードの実行だけは、ホストOSから隔離された専用のLinux VM内で行います。この隔離を担うのは、macOSではApple Virtualization.framework、WindowsではHyper-Vというハイパーバイザーです。
VMがデバイス側の事情で起動できないとき、ファイルツールとWebツールは動き続けます。シェルコマンドとコード実行だけが、VMが復旧するまで「workspace unavailable」と報告されます。セッション全体が壊れたのではなく、コード実行の担当だけが不在という状態です。
Windowsでこの隔離用VMがそもそも起動できず、Coworkタブ自体が無効になる「Missing HCS services: vfpext」というエラーもあります。対処法はCoworkのvfpextエラー(Missing HCS services)を解消する方法にまとめました。
エラーの間に動く機能と止まる機能
workspace unavailableの間の状態
動き続ける
ファイルの読み書きとWeb取得。#68030の報告では、Claude in Chromeによるブラウザー操作も動いていました。調査・文書編集・Webからの情報収集のように、コード実行を伴わないタスクはそのまま進みます。
VMの復旧まで止まる
シェルコマンドの実行と、Claudeが書いたコードの実行。スクリプトを走らせる、データ処理コードを動かす、シェル経由でファイルを操作するといったタスクが該当します。
接続済みフォルダーへのファイルの読み書きは、デバイス上のエージェントループ側で動いており、VMの中では完結していません。ただし、コード経由のファイル処理(スクリプトによる書き込みや変換など)は完了しないまま止まります。
括弧の中の理由と併せて出ているメッセージで切り分ける
「workspace unavailable」は入口の表示で、原因は報告ごとに違い、画面の文言も一様ではありません。GitHubのanthropics/claude-codeリポジトリには、同じVM・サービス層の失敗として報告されている別々の経路があります。ここでの内容は利用者の報告であり、公式に確認された原因や修正済みの事実ではありません。
報告されている4つの経路
イメージのダウンロードが通らない(macOS)
issue #68030。アプリの自動更新後に「Workspace still starting」のまま進まなくなり、その後「Workspace unavailable. The isolated Linux environment failed to start」に変わりました。括弧内は最初が
net::ERR_CONNECTION_CLOSEDで、アプリを入れ直したあとはDownload failed. Check your internet connection and try again.でした。報告者は、チャット・ファイルツール・Web取得・Claude Codeモードは動いたと書いています。アプリからサービスへの設定が届かない(Windows)
issue #93650。UIには「Claude's workspace couldn't start — RPC pipe closed」と出ます。サービスのログは
Waiting for configuration from app via 'configure' method...で止まり、アプリが1秒ごとに接続して何も送らず切断する状態が続いた、という報告です。VMの作成にすら至っていないため、Hyper-Vやメモリーの不足とは別の層の問題だと報告者は見ています。VMサービスが落ちたまま復帰しない(Windows)
issue #92527。
CoworkVMService(cowork-svc.exe)が予期せず終了し、サービスの復旧動作を自分で設定できないため、再起動するまで落ちたままになる、という報告です。この報告での画面表示は「Unable to access your computer」で、workspace unavailableの文言とは別でした。SDKバージョンの検証エラー(Windows)
issue #93357のタイトルには
SDK version 2.1.260 not verifiedとあります。報告者はVM用キャッシュを消して入れ直しても変わらなかったと書いています。同じissueには、直前に入った2つの更新との相関を指摘する報告もあります。Windowsのセキュリティ更新(KB5124008)と.NET Frameworkのセキュリティ更新(KB5126052)で、両方を外して再起動したら動いたというコメントがあります。ただし公式の回避策ではありません。
控えておきたいのは、エラー文の括弧内やUIの追加メッセージです。通信系の文言(接続切断・ダウンロード失敗)ならネットワークやプロキシー、サービス系の文言(RPC pipe・サービス停止)ならWindowsのサービスの状態、と当たりが付きます。ただし#68030の報告者は、回線が正常でVPNを切り替えても直らず、きっかけはアプリの更新だったと書いています。なお、Windowsで報告者がログを見た場所はC:\ProgramData\Claude\Logs\cowork-service.logです。
クラウドセッションでも出ることはあるか
Coworkのセッションは既定でクラウドセッション(Anthropicのサーバー上で動く方式)です。隔離VMを使うのは、既存のデスクトップ展開を続けているローカルセッションです。クラウドセッションではセッションごとにAnthropicのサーバー上に一時的なサンドボックスが用意されます。
ただし、クラウドセッションが手元のデバイスを操作する場合は話が別です。クラウドセッションがローカルのファイルやブラウザーに触れるのは、そのデバイスのClaude Desktopアプリを経由するときだけです。issue #93650の報告者は、リンクされたクラウドセッションのdevice_bashから「Workspace unavailable. The isolated Linux environment on this device failed to start.」が返ったと書いています。メッセージ中の「on this device」が、失敗した場所をデバイス側と示しています。
今のセッションがローカルかクラウドかの見分け方は、Coworkがクラウド実行かローカル実行か見分ける方法で扱っています。
似た文言の別メッセージと混同しない
「workspace」を含むメッセージはもう1つあります。Coworkを開始した直後に「Setting up Claude's workspace」と表示されることがありますが、これはCoworkが最新版に更新して修正や改善を適用している最中であることを示す、想定内の表示です。VMが起動できていない「workspace unavailable」とは別物です。似た文脈で、Windows環境限定の「Plan9 mount failed」というRPCエラーも報告されています。対処法はCoworkの「Plan9 mount failed」エラーが出たときの対処法で扱っています。
もう1つ、管理者の設定とは切り分けておく点があります。組織設定では、Coworkの有効化とクラウドセッションのオン・オフが別のトグルで、クラウドだけを止めてローカルのCoworkを残すこともできます。MDMキーのisLocalDevMcpEnabledとisDesktopExtensionEnabledは、ローカルMCPサーバーと拡張機能を止める設定です。VMが起動できるかどうかとは別の話です。
対処の順番
VMが起動できない原因は、公式ドキュメントでは個別に列挙されていません。エラー文言が「復旧するまで」という一時的な状態を前提にしているため、負担の軽い順に試す流れになります。効果が確認された順序ではなく、報告事例から見た目安です。
軽い順に試す
- 1
少し時間を置いて再実行する
デバイス側のリソース競合のように一時的な要因なら、再試行だけで通ることがあります。
- 2
Claude Desktopアプリを再起動する
VMの起動処理がアプリ側で引っかかっている場合に、再起動が入口になります。
- 3
パソコンを再起動する
Windowsでは、VMサービスが落ちたまま復帰しない報告(issue #92527)があり、報告者は再起動するまで戻らなかったと書いています。同じ報告者は、
sc.exe start CoworkVMServiceでサービスを起動し直すと数秒で復旧し、セッションも再接続したと検証しています。これは報告者の回避策で、公式の手順ではありません。 - 4
アプリとOSを更新する
Claude Desktopアプリが最新でなければ更新し、OSの更新が溜まっていれば適用します。ただし#68030では、macOSの更新とMacの再起動でも直らなかったと報告されています。
一方で、アプリを入れ直しても直らない例(issue #68030)や、VM用キャッシュを消しても変わらない例(issue #93357)も報告されています。一通り試して解消しない場合は、コード実行を伴わない作業に切り替えて進めつつ、時間を置いて状況が変わるかを見る選択肢があります。
管理者が確認できること
組織でデバイスを管理している場合、IT管理者は仮想化機能そのものがポリシーで無効化されていないかを確認する価値があります。Coworkのローカルセッションは、エージェントのループを動かすアプリケーション層と、コード実行を担うVMの2層で成り立っています。後者はハイパーバイザーが有効であることが前提です。
管理対象デバイスでは、セキュリティ上の理由で仮想化機能が絞られている場合があります。その場合、繰り返し発生するエラーは個人の再起動だけでは解決しないことがあります。
クラウドセッションへ切り替える場合の注意
ローカルセッションでこのエラーに繰り返し遭遇するなら、クラウドセッションへの切り替えも選択肢です。クラウドセッションはAnthropicのサーバー上の隔離環境でコードを実行するため、デバイス側のハイパーバイザーに依存しません。
デバイスのファイルやブラウザーが必要な場面では、前節のとおりClaude Desktopアプリ経由になり、デバイス側の状態の影響を受けます。実際にissue #93047では、クラウドセッションからホストのフォルダー共有がマウントされない事例が報告されています。ファイル操作は動き、シェル側のマウントだけが戻らなかった、という内容です。
Pro・Maxでは、2026年10月6日から新しいCoworkタスクがクラウドで動き、Settings > Generalの「Only on your computer」が消えます。すでに手元で始めたタスクはそのまま手元に残ります。この変更後は、新規タスクでVMの問題に当たる場面が減る一方、残ったローカルタスクと、デバイス経由のクラウドセッションでは引き続きこのエラーがありえます。詳しい移行内容はCoworkのデスクトップを閉じたときの挙動にまとめています。
クラウド/ローカルの実行アーキテクチャの違いはClaude Coworkのデータ取得の仕組み、Computer UseとVMサンドボックスの全体像はClaude CoworkのComputer Use・VMサンドボックスで扱っています。ディスクを圧迫するVMバンドルの肥大化とその対処はVMバンドルが重くなる原因と対処法にまとめています。
まとめ
workspace unavailableが出たら、まずコード実行を使わない作業は続けられると割り切り、括弧内の文言やUIの追加メッセージを控えておくと、通信系かサービス系かの見当が付きます。再起動やOS更新で戻らない場合は、issueでも報告が続いている領域なので、文言とログを添えて報告する側に回る手もあります。