Claude CodeのCowork機能がmacOSに警告なしで10GB VMを生成、削除しても再生成されCPU使用率が55%に

Claude Code の Cowork 機能をめぐって、2026年2月から重大なパフォーマンス問題がGitHub上で報告され続けている。マシンが何もしていないのにCPU使用率が常時高い、Claudeを再起動するたびにディスクが大量に消える──という報告が35件以上積み重なり、GitHub Issue #22543 は👍81件を集めた。

VMバンドルの実体

問題の核心は ~/Library/Application Support/Claude/vm_bundles/ ディレクトリ以下にClaudeが自動生成する claudevm.bundle だ。

~/Library/Application Support/Claude/vm_bundles/
└── claudevm.bundle/
    └── rootfs.img  # 10GB以上のraw diskイメージ

このVMバンドルはCowork機能（Claudeがユーザーマシン上でコードを実行するためのサンドボックス）のために使われる。問題なのは、Coworkを使っていなくても生成される点と、削除後も翌日に自動再生成される点だ。@willn-dev はCoworkを一度も有効にしたことがないにもかかわらず10GBが存在したと報告している。

サイズの報告には幅があり、最小でも10GB、@aestwick のケースでは21.47GBまで膨らんでいた。さらに rootfs.img.zst（圧縮版）が展開後も残存するため、実際に消費されるディスク容量は表示値より大きくなる。

VMのアーキテクチャ

CoworkのVMはAppleのVirtualization frameworkを使い、macOS上で軽量Linuxを動かす構成になっている。

項目	値
仮想化基盤	VZVirtualMachine（Apple Virtualization.framework）
ブート方式	EFI / GRUB
CPU割り当て	4コア
メモリ割り当て	4GB
ネットワーク	VZVmnetNetworkDeviceAttachment（共有モード）
ホスト⇔ゲスト通信	vsock

vsockとは

vsock（Virtio Socket）は、ハイパーバイザ経由でホストとゲストVMが直接ソケット通信するプロトコルだ。TCP/UDPのようなネットワークスタックを経由しないため、IPアドレスの設定やポートフォワーディングが不要で、オーバーヘッドが小さい。VMが起動すると guest_vsock_connect でホスト側と接続を確立し、以降のコマンド実行やファイルアクセスはすべてこの経路を通る。

なぜコンテナではなくVMなのか

AnthropicがDockerコンテナではなくフルVMを選んだ理由について、開発担当のFelix Rieseberg氏がHacker Newsで3点を挙げている。

Claude用の完全に独立した実行環境の提供
コンテナより強力なセキュリティ境界の確保
非技術ユーザーに対する承認ダイアログの連発（approval fatigue）の軽減

コンテナはホストカーネルを共有するため、カーネルの脆弱性を突かれるとホスト側に影響が及ぶ。VMはカーネルごと分離するので、AIが生成したコードがホストのファイルシステムやネットワークに直接触れるリスクを構造的に排除できる。非技術ユーザーがファイルアクセスのたびに許可ダイアログを出されることなくCoworkを使えるようにする設計意図もある。

トレードオフとして10GB超のディスク消費を強いることになり、これが今回の問題の根本にある。

CPU・メモリへの影響

VMが存在する状態でのClaude Desktopのリソース消費はこうなっている。

状態	CPU使用率
再起動直後（アイドル）	~24%
数分使用後	~55%
VM削除直後	正常値に戻る
VM削除後数分	再度上昇し始める

CPU 55%の内訳はrenderer 24%・main 21%・GPU 7%。MacのActivityMonitor で「Claude」プロセスグループを確認すると、アイドル中でもこの水準が続く。

メモリ面ではスワップの増加も確認されており、swapins が20,000から24,000以上に増加。8GB RAM 搭載機では全体的なシステムレスポンスが著しく低下する。

削除と再生成のループ

一時的な回避策として、以下のコマンドでVMバンドルとキャッシュを削除できる。

rm -rf ~/Library/Application\ Support/Claude/vm_bundles
rm -rf ~/Library/Application\ Support/Claude/Cache
rm -rf ~/Library/Application\ Support/Claude/Code\ Cache

削除直後はディスク使用量が11GB → 639MBまで減少し、CPU使用率も即座に75%程度改善する。ただし数分から数時間後にVMが再生成され、パフォーマンスが再び低下する。削除と再生成のループから抜け出せない。

@troy-may は手動削除後に13GBまで自動再増加したと報告しており、一度削除してもサイズが戻るだけでなく、元のサイズを超えるケースもある。VMの再生成を止める確実な方法は現時点ではなく、Claude Desktop をアンインストールしてCLIのみに移行したユーザーも出始めている。

macOS 26.xでのvsock接続障害

Issue #22543 のバンドルサイズ問題とは別に、macOS 26.2以降ではVMの起動自体が失敗する問題も報告されている（Issue #23830、👍17件、コメント17件）。

症状はVMブートまでは成功するが、後続の guest_vsock_connect ステップで60秒間ハングし、タイムアウト後にリトライループに陥るというもの。

[VM:steps] guest_vsock_connect started
[VM:start] Connection timeout, last completed step: vm_boot
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

さらにリトライのたびにVMが正常停止できず、vmnetゲートウェイIPが67.1 → 68.1 → 69.1とインクリメントされていく。ネットワークリソースが解放されないまま新しいVMインスタンスが立ち上がるリソースリークだ。

graph TD
    A[VM起動] --> B[vm_boot 成功]
    B --> C[guest_vsock_connect 開始]
    C --> D{60秒経過}
    D -->|タイムアウト| E[前のVMを停止試行]
    E --> F[停止失敗]
    F --> G[vmnetリソース未解放]
    G --> H[ゲートウェイIP<br/>インクリメント]
    H --> A

原因はmacOS 26.xのVirtualization frameworkにおけるvsockソケット初期化の変更と推測されている。VMバンドル内の状態が破損し、一度この状態に陥ると自然回復はしない。

VMバンドルを作り直す

コミュニティが発見した回避策は、セッションデータだけバックアップしてからVMバンドルを丸ごと削除し、再ダウンロードさせるというもの。

# 1. Claudeを完全に終了
osascript -e 'quit app "Claude"'

# 2. セッションデータのバックアップ
mkdir -p ~/Documents/claude-vm-backup
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img \
   ~/Documents/claude-vm-backup/
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/macAddress \
   ~/Documents/claude-vm-backup/
cp ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/machineIdentifier \
   ~/Documents/claude-vm-backup/

# 3. VMバンドルを削除して再起動（~10GBの再ダウンロードが走る）
rm -rf ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle
open -a Claude

# 4. 再セットアップ完了後、セッションデータを復元
osascript -e 'quit app "Claude"'
cp ~/Documents/claude-vm-backup/sessiondata.img \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
cp ~/Documents/claude-vm-backup/macAddress \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
cp ~/Documents/claude-vm-backup/machineIdentifier \
   ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
open -a Claude

sessiondata.img、macAddress、machineIdentifier を復元すれば、Coworkの会話履歴やタスクセッション、インストール済みパッケージは保持される。失われるのはrootfsイメージ内の状態のみだが、再ダウンロードに10GB分の通信と時間がかかる点は変わらない。

デバッグ用ログの場所

vsock問題の調査には以下のログが使える。

ファイル	内容
`~/Library/Logs/Claude/cowork_vm_node.log`	VM起動ステップの進行状況
`~/Library/Logs/Claude/cowork_vm_swift.log`	Virtualization.framework側のログ
`~/Library/Logs/Claude/coworkd.log`	Coworkデーモンの全般ログ

Anthropicの対応

GitHub Issue #22543 は2026年2月13日に最初に報告され、3月3日現在もOpen 状態が続いている。担当者（@felixrieseberg）がアサインされ、bug・high-priority・oncall・performance のラベルが付与されているが、Anthropic からの公式コメントや修正の見通しはまだ出ていない。

HNでも299ポイント・多数コメントで議論が広がった。Felix Rieseberg氏はHNスレッドに登場し、VMの設計判断について「本当のトレードオフ」として認識していると述べ、改善案を検討中とコメントした。ただし具体的な修正時期やロードマップは示されていない。

コミュニティからの改善提案

HNとGitHub Issueで出ている主な提案は以下。

提案	内容
VM遅延起動	アプリ起動時ではなくCoworkタブを開いたときだけVMを起動する
増分更新	12GB全体の再ダウンロードではなく差分パッチで更新する
外部ディスク保存	VMバンドルの保存先をユーザーが選択できるようにする
軽量サンドボックス	Apple Seatbelt（sandbox-exec）等のOS組み込み機能で代替する
オプトイン化	Coworkを使わないユーザーにはVMを一切生成しない

特にVM遅延起動とオプトイン化は実装コストに対して効果が大きい。Coworkを使わないユーザーにとっては10GBのディスク消費とCPU負荷がまるごと無駄になっているためだ。Apple Seatbeltへの移行はセキュリティモデルの再設計が必要になるため短期的には難しいが、512GB SSDが主流の現在、10GBをサンドボックスのためだけに消費する設計は長期的に見直す必要がある。

Claude Desktopを日常的に使っていてディスクやCPUの異常に気づいたら、まず ~/Library/Application Support/Claude/vm_bundles/ のサイズを確認してみるといい。CLIのみで使うなら claude コマンド（npm版）に切り替えればVM問題は回避できる。