Coworkの「Plan9 mount failed」エラーが出たときの対処法
Windows版CoworkでRPC error -1・Plan9 mount failedが出たときに、GitHub issueの60件のコメントから、効いた対処の順番と効かなかった対処、報告された原因の仮説を整理しました。
Windows版のClaude DesktopでCoworkを使っていると、「RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address」で止まることがあります。GitHubのissue #26554には60件のコメントが付き、OSが書かれた報告はすべてWindowsです。issueは2026年3月10日にクローズされ、3月26日に自動ロックされました。
ここでは、コメントに書かれた対処を「効いた」「効かなかった」に分け、原因について出ている仮説を症状別に並べます。どれもユーザーの報告で、原因が特定されたわけではありません。
このエラーはローカルセッションのVMで出る
Coworkの実行場所には、クラウドとローカルの2通りがあります。Plan9のエラーが出るのは、VMを使うローカルの側です。
Coworkの2つの実行場所
ローカルセッション
会話処理やファイルの読み書きはPC上でネイティブに動きます。シェルコマンドとコードの実行だけが、専用のLinux VM(仮想マシン)で行われます。VMを隔離するのは、macOSではApple Virtualization.framework、WindowsではHyper-Vです。
クラウドセッション
エージェントの処理とコード実行が、Anthropicのサーバー上の一時的なサンドボックスで動きます。手元のファイルやブラウザーが必要なときだけ、接続済みのフォルダーを通じてClaude Desktopに頼みます。
2026年10月6日から、ProとMaxプランの新しいCoworkタスクはクラウドで動き、設定の「Only on your computer」は削除されます。それ以前にPC上で始めたタスクは、PC上のまま続きます。TeamとEnterpriseでは、組織設定でクラウドセッションをオン・オフでき、ローカルのCoworkを残すこともできます。この切り替えの仕組みはCoworkの有効化とクラウド実行は別トグルにまとめています。
issueはどう動いたか
発生から修正の宣言、再発報告、ロックまでを日付で並べると、「直ったと言われたのに直らなかった」経緯が見えます。Coworkの全体像はClaude Cowork完全ガイドにあります。
issue #26554の経過
- 2月18日issueが立つ
Windows 11 Proで、Hyper-Vを有効にしていても質問のたびに同じエラーが出るという報告です。Desktopの版数は1.1.3363.0でした。
- 2月20日〜23日同じ報告が相次ぐ
2月20日にはタスクマネージャーでアプリを終了して再起動する方法が、23日にはログアウトを挟む方法が書き込まれました。
- 2月26日〜3月4日原因の仮説が出る
クロスドライブのシンボリックリンク、クラッシュ後の残骸、Windows 11 HomeのICSモードといった仮説が、別々の報告者から出ました。
- 3月10日修正の宣言とクローズ
コメントに「1.1.5749で直ったと考えている。再発したら知らせてほしい」と書き込みがあり、issueはクローズされました。
- 3月15日・18日再発の報告
「まだ同じエラーが出る」という書き込みが続き、18日の報告はTeamプランの利用者からでした。
- 3月26日自動ロック
クローズ後に動きがないissueとして、自動でロックされました。ロック通知は、同じ現象は新しいissueに書くよう案内しています。
修正の宣言に原因の説明はなく、1.1.5749以降も再発した報告が残っています。
報告された環境とログの見方
コメントに出てくる環境は、WindowsのエディションもPCの構成もばらばらです。
| 項目 | 報告内容 |
|---|---|
| OS | 報告内容Windows 11のHome、Pro、Pro for Workstations、Insider Preview |
| 仮想化機能 | 報告内容Hyper-V、Virtual Machine Platform、Windows Hypervisor Platformを有効にしていても発生 |
| プラン | 報告内容Max、Teamなどで報告 |
| 診断コマンド | 報告内容Get-VMにHyper-V VMが出ないのに、cowork-svcは動いている |
出方も一様ではありません。毎回出る人、2通目のプロンプトで出る人、セッションの途中や1時間ほどたってから出る人がいました。数日間は問題なく使えていたのに、システムを変えていないまま急に出始めた、という報告もあります。
自分の環境が同じ現象かどうかは、cowork_vm_node.logの次の行で見分けられます。
Spawn failed: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad addressこの報告者のログでは、VMへの接続自体は成功していて([startVM] VM already connected)、失敗はvirtiofsのマウントの段階でした。別の報告者のログでは、同じエラーの前後でStarting file watcherが4分間に5回繰り返されています。
報告された原因の仮説
原因については、コメントごとに違うことが書かれています。どれも「その人の環境ではそうだった」という報告で、共通の原因は示されていません。
症状別の仮説
.claudeがドライブをまたぐシンボリックリンク
C:\Users\<名前>\.claudeが別ドライブのD:\.claudeへのリンクになっていた環境の報告です。VMが共有するフォルダーの1つに.claudeが含まれていて、リンクの先をたどれないのが原因だと推測されています。プロジェクトのパスに空白があるときも不安定になる、という指摘が同じコメントにあります。異常終了した後の残骸
システムがクラッシュした後から出始めたという報告です。
CoworkVMServiceは動いたまま、存在しないマウントへの再接続を繰り返していて、%TEMP%\claudeに中身が0バイトのリンクが残っていたと書かれています。この報告者は、クラッシュのない環境では別の原因かもしれないとも添えています。Windows 11 HomeのICSモード
%APPDATA%\Claude\logs\main.logにvm_network_modeがicsと出る環境の報告です。HomeにはNetNatのWMIクラスがないためICSにフォールバックし、Get-NetNatが「Invalid class」を返す、と説明されています。この環境では1通目のメッセージで落ちたそうです。残留したClaudeのプロセス
アプリを閉じても
claude.exeが5〜10個残り、新しいセッションが使用中のアドレスを取りにいくのが原因ではないか、という報告です。別の報告者は、直った後に8個のプロセスが残っていたと書いています。
どの仮説にも反例が出ています。ある報告者は、空白もシンボリックリンクもクラウド同期もないローカルフォルダーで、Google共有ドライブでも失敗しました。OneDriveについては、ファイルを外に移したら15分おきの再起動が要らなくなったという報告と、内外で変わらなかったという報告の両方があります。
効いたという報告の順番
「直った」と書かれた対処を、軽い順に並べます。
試す順番
- 1
Claudeのプロセスをすべて終了して起動し直す
タスクマネージャー(Ctrl+Shift+Esc)の「詳細」タブで
Claude.exeを探し、残っているものをすべて終了してから起動します。アプリの終了操作だけでは残ることがあります。2〜3回の繰り返しが要った報告もあります。 - 2
ログアウトを挟んで再ログインする
ログアウトしてアプリを閉じ、残ったプロセスを終了し、起動してログインし直します。この方法を書いた報告者自身が「偶然かもしれない」と添えていますが、別の報告者が同じ手順で復旧しています。
- 3
CoworkVMServiceを再起動する
管理者権限のPowerShellで、サービスを止めて起動し直します。停止コマンドが失敗と表示されても、20秒ほど待ってから起動すると立ち上がったという報告があります。起動後にワークスペースが使えるまで数分かかった、という報告もあります。
- 4
パソコンを再起動する
ここまでで直らず、再起動で戻った報告があります。
サービスの再起動は、次の2行です。
net stop CoworkVMService
net start CoworkVMServiceCoworkVMServiceは、Windowsのサービス一覧では「Claude」という表示名で出る、という報告があります。
対処の後で「VM service not running. The service failed to start.」に変わる報告も2件あります。1件は、復旧にパソコンの再起動が要り、1日に何度も起きると書いています。もう1件は、ログアウトとプロセス終了のあとに同じ文言が出て、ワークスペースの再インストールでも直りませんでした。
vm_bundlesフォルダーを削除したら直ったが、セッションの途中でまた壊れた、という報告もあります。このフォルダーが膨らむ別の問題は、CoworkのVMバンドルが重くなる原因と対処法で扱っています。
コミュニティが公開したPowerShellスクリプト集もあり、プロセス終了・サービス停止・VMキャッシュの削除・再起動を自動で行います。直ったという報告のほか、毎回2〜3GBのVM資材を再ダウンロードする副作用の報告もあります。公式のものではないので、実行前に中身を読む必要があります。
効かなかった対処
あるMaxプランの利用者は、次の対処をすべて試してもマウントの失敗が続きました。
- AppData・MSIXパッケージ・CoworkVMServiceをすべて削除したうえでのクリーン再インストール
sfc /scannow(破損ファイルの修復には成功)DISM /Online /Cleanup-Image /RestoreHealth- Hyper-Vのサービス(
vmms、vmcompute)の再起動 - 修復後の完全な再起動と、VPNの無効化
別の報告者は、再インストールをしても変わらず、翌日にプロセスの終了とログアウトを試して直りました。OSの修復や再インストールより前に、上のステップを試す順番になります。
Hyper-Vの無効化は選べないことがある
仮想化機能が原因に見えますが、Hyper-Vを無効にできない環境もあります。WSL2とDocker Desktopが業務に必須だと書いた報告者は、この対処を選べませんでした。VirtualBoxに切り替えたら動いたという報告も1件ありますが、理由は書かれていません。
直らないときの選択肢
繰り返し出てVMを調整できないときは、いくつか道があります。
- クラウドセッションに切り替える: 実行場所が変わるとデータの扱いも変わります。Claude Coworkのデータ取得の仕組みで、切り替え前の違いを読めます。
- VMなしで使える範囲を知る: ローカルのVMが起動できないとき、ファイル操作とWebツールは動き続け、シェルコマンドとコード実行だけが「workspace unavailable」と報告します。この表示はCoworkで「workspace unavailable」と出たときの対処法にあります。
- 管理者に仮想化機能を尋ねる: 社給PCでは、仮想化機能をポリシーで制限していないかが論点になります。環境の報告には、BIOSの仮想化・Virtual Machine Platform・Windows Hypervisor Platformをすべて有効にしたうえで発生した例があります。
- 最新版のClaude for Windowsを使う: Claude Desktop for Windowsはすべての有料プランで使え、Coworkには最新版が必要です。
まとめ
版数を上げても再発した例があり、issueに原因の説明はありません。OSの修復や再インストールより、軽い対処で戻ったという報告が中心です。直らなければ、新しいissueにログの該当行を添えて報告する手があります。