Coworkの「Plan9 mount failed」エラーが出たときの対処法

Windows版のClaude DesktopでCoworkを開始しようとすると、あるエラーで止まることがあります。「RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address」という文言です。GitHubのissueには20件のコメントが寄せられ、報告はすべてWindows環境に集中しています。原因の切り分け方と、実際に効果が確認された対処の順番をまとめました。

このエラーが起きている場所

Coworkのローカルセッションは、Claudeとの会話そのものは端末上でネイティブに動きます。一方、シェルコマンドとコードの実行だけは、ホストOSから隔離された専用のLinux VM(仮想マシン)内で行われます。この隔離を担うハイパーバイザーは、macOSではApple Virtualization.framework、WindowsではHyper-Vです(このアーキテクチャ全体はClaude Cowork完全ガイドで扱っています)。

「Plan9 mount failed: bad address」は、このLinux VMとホスト側のファイルシステムをつなぐ「virtiofs」という共有機構がマウントに失敗したときに出るエラー文字列です。エラー文言にはvirtiofsとPlan9という2つの共有方式の名前が同時に現れますが、両者の技術的な関係や、Hyper-V側の処理のどこで失敗しているかは公開情報からは確認できません。エラーメッセージ自体はCoworkのVM起動プロセス(cowork_vm_node.log)が出力するものです。GitHub issue #26554に寄せられた報告は、Windows 11のHome / Pro / Insider Previewの各エディションにまたがっています。同様の報告はmacOS側では見当たりません。

報告に共通する環境

issueのコメントを見ると、発生環境にはいくつかの共通点があります。

patrick-looramが共有したcowork_vm_node.logには、次の行がそのまま残っていました。

Spawn failed: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

自分の環境のcowork_vm_node.logに同じ行が出ているかを確認すると、今回のissueと同じ現象かどうかを切り分けられます。

Get-VMが空を返す一方でcowork-svcは動いているという報告があり、VMの作られ方が通常のHyper-V VMと異なる可能性もあります。patrick-looramの報告では、VMへの接続自体は一度成功しており、失敗しているのはvirtiofsのマウント処理だけだったとされています。ただし、GitHub issue上でAnthropicの担当者による原因の技術的な特定は共有されていません。この先の切り分けは、ユーザー側の再現条件の蓄積にとどまっています。

Fryden77の報告では、それまで数日間は問題なく使えていたCoworkが、システム側の変更に心当たりがないまま突然このエラーを出すようになったとされています。初回セットアップ時だけでなく、しばらく使えていた環境でも発生します。同じくローカルセッションのVMに関連する別のエラーとしては、Coworkで「workspace unavailable」と出たときの対処法もあわせて確認すると切り分けがしやすくなります。

効果が確認された対処の順番

issueのコメントでは、次の順で試すと解消したという報告が複数あります。

1. Claude Desktopをタスクマネージャー(Ctrl+Shift+Esc)で完全に終了してから再起動します。アプリの「終了」操作だけでは常駐プロセスが残ることがあります。「詳細」タブでClaude.exeを探し、複数残っていればすべて選択して「タスクの終了」してから起動し直します。GungorEfeの報告では2〜3回繰り返す必要がありました。
2. ログアウトしてからアプリを閉じ、残存プロセスを終了して再ログインします。手順は「ログアウト → アプリを閉じる → タスクマネージャーで残存プロセスを終了 → 再起動してログインし直す」です。KB3Toolsが効果を確認した手順で、dgilchristも同じ手順で解消したと報告しています。単なる再起動よりも、ログアウトを挟むことがポイントです。
3. それでも直らない場合はパソコン自体を再起動します。Hyper-V自体が、OS起動時の状態異常を引きずっている可能性があります。

対処後に「VM service not running. The service failed to start.」という別のエラーに切り替わることがあります。この場合はdgilchristの報告どおり、パソコン自体の再起動が必要になるケースが多いようです。Fryden77はこの手順を試した後、タスクマネージャーにClaudeのプロセスが8個も残っていたと報告しています。1回のアプリ終了で複数プロセスが残留する挙動自体が、別の不具合である可能性があります。

試しても効果がなかった対処

patrick-looramの報告は、切り分けの参考として有用です。次の対処はすべて試した上で、Plan9マウントの失敗自体は解消しませんでした。

• Claude Desktopのクリーンな再インストール(AppDataフォルダー・MSIXパッケージ・CoworkVMServiceをすべて削除してからの再インストール)
• sfc /scannow(破損したシステムファイルの検出・修復には成功)
• DISM /Online /Cleanup-Image /RestoreHealth
• Hyper-V関連サービス(vmms、vmcompute)の再起動
• 上記の修復後のフルシステム再起動
• VPNの無効化

つまり、OS側の破損や設定不備を疑って再インストールやsfc/DISMを試す前に、まずは前段の「プロセスの完全終了 → 再起動」を試すほうが時間の節約になります。

Hyper-Vを無効化する対処は選びにくい

仮想化機能そのものが原因に見えるため、Hyper-Vを無効化して回避する発想も出てきます。しかし、InfantLabの報告はこの対処が現実的でないことを示しています。WSL2やDocker Desktopが業務に必須の環境では、これらもHyper-V(またはVirtual Machine Platform)に依存しているため、Hyper-Vを止めるとCowork以外の開発環境まで止まってしまいます。仮想化機能自体を切るのではなく、前段のプロセス終了・再ログイン・再起動を先に試すのが現実的な順番です。

管理者が確認できること

GitHub issue上の報告はHyper-Vが有効な環境でも起きているため、有効・無効の切り替えだけが原因とは限りません。ただし、企業のデバイス管理で仮想化機能そのものをポリシーで制限している場合、そのポリシーが影響している可能性はあります。個人のPCでは意識しないことが多い設定です。社給PCでCoworkのローカルセッションを使う場合は、IT管理者に仮想化機能(Hyper-V、Virtual Machine Platform、Windows Hypervisor Platform)がBIOSとOSの両方で有効になっているかを確認してもらうという選択肢があります。Coworkのローカルセッション自体はPro / Max / Team / Enterpriseの各有料プランで利用でき、Windows版は「Claude for Windows」の最新版が前提です。

クラウドセッションへの切り替えという選択肢

繰り返し発生し、Windows側の仮想化環境をすぐに調整できない場合は、セッションをクラウドで実行する設定に切り替えるという選択肢もあります。ローカルセッションとクラウドセッションの違いや、組織側のトグルの仕組み・既定値はCoworkの有効化とクラウド実行は別トグルで扱っています。ローカルとクラウドでデータの扱いがどう変わるかはClaude Coworkのデータ取得の仕組みが詳しく解説しているので、切り替え前に確認しておくと安心です。

まとめ

「Plan9 mount failed: bad address」は、CoworkのローカルセッションがLinux VMとホストをつなぐvirtiofsのマウントに失敗したときに出るエラーです。報告はWindows環境に集中しています。再インストールやシステムファイルの修復では解消しないという報告が複数ある一方、タスクマネージャーでClaudeの常駐プロセスを完全に終了してから再ログインする方法や、パソコン自体の再起動で解消したという報告があります。Hyper-Vの無効化はWSL2やDocker Desktopに影響するため選びにくい対処です。仮想化機能そのものが組織のポリシーで制限されていないかの確認と、解消しない場合のクラウドセッションへの切り替えも選択肢に入ります。