Claude CoworkがWindowsでマウント失敗する原因を整理した — 2026年9月のKB5124008でPlan9共有が壊れた話
Claude Cowork（Windows版）でローカルフォルダがマウントされず作業できなくなる問題を整理。2026年9月のWindows更新KB5124008が原因のケースと、仮想化未有効化・ワークスペース設定中で止まる等それ以外の原因を症状別に分けて解説する。
エンジニアのゆとです。
ここ数日、Windows版のClaude Coworkで「さっきまで普通に動いてたのに、急にローカルフォルダを読み書きできなくなった」という報告がGitHubのIssueに固まって上がってる。症状はどれも似ていて、Coworkのタスクを実行するとsandbox-helper: no Plan9 drive shares mountedというエラーで止まり、接続したフォルダの中身が一切見えなくなる。
原因を追うと、2026年9月のWindows 11向け累積更新KB5124008（ビルド26200.9445）に行き着く。このKBを適用した端末だけ、Coworkのローカルサンドボックスがホストのドライブ共有を1つもマウントできなくなる。しかもホスト側のログは「成功しました」としか出ないので、原因がWindows側にあると気づくまでにかなり時間を溶かされる。
この記事では、まずこのKB5124008の不具合を実際のログつきで解説したうえで、それ以外によくある「Coworkがマウントできない・起動しない」系の原因も症状別に整理する。KBの件はいずれAnthropicかMicrosoft側で直る類のバグだけど、記事を読んでいる時点でまだ直ってないなら、この記事の手順で切り分けてほしい。
まず結論 — 症状で原因を切り分ける
Coworkがローカルフォルダを扱えない場合、症状によって原因がかなりはっきり分かれる。まずここで自分の症状がどれに近いか確認してから、該当セクションに飛んでほしい。
| 症状 | 主な原因 |
|---|---|
| 直前まで普通に使えていたのに、Windows更新後から突然マウントできなくなった | KB5124008によるPlan9マウント不具合（後述） |
| Coworkを使うのが初めてで、そもそも起動時点で止まる | Hyper-V / 仮想化プラットフォームが有効化されていない |
| タスク開始直後に「Claudeのワークスペースをセットアップ中」から進まない | 初回のVMイメージダウンロードが完了していない、または破損している |
| タスクの途中で急に止まって続かなくなる | 使用量制限への到達、またはタスクの複雑さによるタイムアウト |
| 指定したフォルダにファイルが出力されない | 出力先パスの誤認識（$HOME/mnt/配下を見ていない） |
KB5124008適用後にPlan9共有が0/9になる不具合
これが今回一番厄介なパターン。GitHub Issueに上がっている報告（Issue #92984）を実際のログで追う。
何が起きているか
CoworkのローカルサンドボックスはHyper-V上の軽量VMで動いていて、ホストのドライブをゲスト側に見せるのに「Plan9（9p）プロトコル」を使っている。KB5124008は、この9pハンドシェイクに関わるHyper-Vコンポーネント（vmcompute.exe・p9rdr.sys・p9np.dllなど）を更新するセキュリティパッチで、これを適用すると共有のマウントだけが失敗するようになる。
ホスト側のログ（cowork-service.log）を見ると、共有の追加自体は成功したように見える。
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] VM started successfullyhr=0x0はWindowsのHRESULTとして「成功」を意味するコードなので、ホスト側だけ見ていると何も問題が起きていないように見える。実際に失敗しているのはゲスト（VM内部）側で、ログ（coworkd\user-<SID>.log）にはこう出る。
[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
...
[hyperv] mounted 0/9 Plan9 sharesホストは「成功」、ゲストは「invalid argumentで失敗」——この食い違いのせいで、Cowork自体が壊れたと勘違いして再インストールしたり、接続フォルダの設定を疑ったりして時間を浪費しやすい。実際、Issueの報告者も「アプリの再インストール」「共有フォルダの変更」「VMバンドルの再ダウンロード（8GB分）」を一通り試したうえで、最後にWindows Update側が原因だと突き止めている。
確認方法
自分の環境がこれに該当するか確認する一番早い方法は、KB5124008を適用した直後かどうかを見ることだ。
# 適用済み更新プログラムの一覧からKB5124008を確認
Get-HotFix | Where-Object {$_.HotFixID -eq "KB5124008"}該当していて、かつCoworkのゲストログにPlan9 mount failed: invalid argumentが出ているなら、ほぼこのパターンで確定していい。WSL2（wsl -d docker-desktop等）のドライブ共有は正常に動くケースが多く、これは9p実装の経路がWSL2とCoworkで別物であるため。「WSLは動くのにCoworkだけ壊れる」という状態は、このバグの典型的なサインでもある。
直し方（暫定対処）
現時点で確認されている唯一の直し方は、KB5124008をアンインストールして再起動すること。
# 管理者権限のPowerShellで実行
wusa /uninstall /kb:5124008
# 再起動後に反映されるIssue内のタイムラインでも、アンインストール直後から「9/9 shares mounted」に戻り、ls $HOME/mnt/が即座に成功するようになったと報告されている。
ただしこれはセキュリティ更新のロールバックなので、恒久対策ではない。 KB5124008は9月の月例セキュリティパッチであり、アンインストールしたままにするとその分の脆弱性修正が未適用の状態が続く。Issue報告者自身も「Cowork側の修正か、少なくとも分かりやすいエラー表示が先に来てほしい」と書いている通り、これは本来Windows更新をブロックせずに直すべき問題だ。
現実的な運用としては、
- Coworkでどうしても今すぐローカルフォルダ作業が必要な場合のみ、一時的にKB5124008をアンインストールする
- 業務で複数人が同じ症状を踏んでいる場合は、Anthropic側のフィードバックに自分の環境情報を添えて追加コメントする（同一Issueへの報告集約は優先度判定に効く）
- Windows Update側の修正、またはCoworkの9pハンドシェイク側の互換対応、どちらか早い方を待つ
の順で考えておくのが無難。KB番号は月ごとに変わるので、この記事を読んでいる時点でIssue番号や該当KBが変わっている可能性もある。症状（ホスト側は成功ログ、ゲスト側はinvalid argumentで0/9）が一致するかどうかで判断してほしい。
それ以外でCoworkがWindowsで動かないパターン
KB5124008に該当しない場合、原因は大きく分けて次の3つに収束する。いずれも公式のトラブルシューティング項目でカバーされているが、日本語で症状ベースに整理されたものが少ないのでここでまとめる。
仮想化プラットフォームが有効化されていない
Coworkのローカルサンドボックスは前述の通りHyper-V VM上で動くため、Windows側で仮想化機能が有効になっていないとそもそも起動できない。「Coworkタブが表示されない」「起動しようとすると即エラーになる」場合はまずここを疑う。
コントロールパネル → プログラム → Windowsの機能の有効化または無効化
→ 以下3つにチェック
- Hyper-V
- 仮想マシンプラットフォーム
- Windowsハイパーバイザープラットフォーム
→ 再起動Windows 11 Homeエディションの場合はHyper-V自体が提供されないため、Coworkのローカルサンドボックス機能が制限される点も併せて確認しておくといい（Pro/Enterprise/Education相当が前提）。
BitLockerが有効な端末では、仮想化機能の有効化・無効化を切り替えるタイミングで回復キーの入力を求められて起動不能に陥るケースも報告されている。作業前にBitLockerの回復キーを控えておくか、可能であれば検証用の端末で先に試すほうが安全だ。
「Claudeのワークスペースをセットアップ中」から進まない
初回起動時、CoworkはVMイメージ（数GB規模）をバックグラウンドでダウンロードしている。回線が細い環境やプロキシ配下だと、この表示のまま数分から十数分待たされることがある。
公式の切り分け手順は次の通り。
- Claude Desktopを完全に終了し、再起動する
- それでも進まない場合、VMバンドル（
%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\vm_bundles\配下）を削除してから再度Coworkを起動し、クリーンな状態で再ダウンロードさせる - 社内プロキシ・SSL証明書のインターセプトがある環境では、ダウンロード自体がブロックされている可能性がある
3番目のプロキシ・証明書まわりは、Claude Code CLI側でも同じ系統のハマりどころがある。
指定したフォルダにファイルが出力されない
Coworkは接続したフォルダを、ゲストVM内部では$HOME/mnt/<フォルダ名>というパスにマッピングして扱う。ローカルのエクスプローラーで見えているパス（C:\Users\...）とゲスト内部のパスが一致していないため、タスクの指示に絶対パスを直接書いてしまうと見つからない、という問い合わせが公式ヘルプにも載っている。フォルダ名で指定する、またはCowork側が提示するパス表記に合わせるのが確実。
FAQ
Coworkが使えなくてもClaude Code CLIなら大丈夫?
Plan9マウントの不具合はCowork固有のローカルサンドボックス機構の話で、Claude Code CLI（ターミナルから使うclaudeコマンド）とは別のプロセス・別の実行環境。CLI側はこの不具合の影響を受けない。急ぎの作業なら、CLIに切り替えて作業を進めるのも一つの手。
KB5124008をアンインストールする以外に方法はない?
2026年9月10日時点で確認されている直し方はKB5124008のアンインストールのみ。セキュリティ更新なので恒久的な運用にはおすすめしない。Anthropic側・Microsoft側どちらかの修正を待つのが本筋だが、業務上どうしても今すぐ必要な場合の一時退避として使う。
WSL2は動くのにCoworkだけ動かないのはなぜ?
WSL2のドライブ共有（drvfs）とCoworkのPlan9共有は、どちらもHyper-Vを土台にしているが実装経路が異なる。KB5124008はCoworkが使う9pハンドシェイクの部分にだけ影響しており、WSL2側の経路は影響を受けていない、というのがIssue報告者の分析。
この不具合はmacOSでも起きる?
報告はいずれもWindows環境（Hyper-V + Plan9共有）に限定されている。macOS版CoworkはApple仮想化フレームワークを使っており、実装が別物のためこの不具合の対象外と考えていい。
