Claude CodeでVMwareゲストがフリーズする原因 — 複数セッションの切り分け

VMwareゲストのLinuxでClaude Codeを複数セッション開くと、ゲスト全体が操作不能になる報告が上がっています。anthropics/claude-codeのissue #104932(open)では、2つ以上の claude を同時に開くとゲストがハードフリーズし、ホストからリセットするまで戻らないと書かれています。

この症状の特徴は、再起動後のログにOOM killerの記録が残らない点です。ここでは報告の内容、自分の環境が同じ症状かを見分けるコマンド、そして今すぐ取れる回避策を順に説明します。原因は報告者の推測の段階で、Anthropic側の修正は確認されていません。

報告されている症状と環境

報告者の環境は次のとおりです。

• Claude Codeのネイティブインストール版(Linux CLI。Desktopアプリではない)
• ゲストはUbuntu 22.04、カーネル6.8.0、VMware上、RAM 20GB、スワップ2GB、4 vCPU
• ホスト側のメモリには終始余裕があった

claude を2つ以上開いた状態(通常は1つが作業中、1〜2つがアイドル)で、ゲストが完全に応答しなくなります。静止(quiesce)もできず、ホストからのリセットが必要です。ここ1週間で繰り返し起きたとあります。

なぜOOMログが出ないのに「メモリ」が疑われるのか

OOM killerのログがないのに、メモリが疑われるのはなぜでしょうか。報告者の根拠は、同じマシンの過去の記録です。2026-08-06には通常のグローバルOOMが正常にログされ、そこにはClaude Code自身が約8.5GBの常駐メモリ(anon-rss 8465408kB)でkillされた行が残っています。

つまり、ログの経路自体は動いています。今回の件でそれが残らないのは、journaldがメッセージを書き出す前にスケジューラとメモリ回収が止まるほど重い停止が起きたため、というのが報告者の解釈です。rtkit-daemonのcanaryスレッドは、リアルタイムスレッドがCPUを占有していないかを見張る仕組みです。そのcanaryが飢餓状態になったログが最後に出ています。

ここは推測を含みます。issueには、Claude Codeのどの処理が停止を引き起こしたかの特定は載っていません。報告者が挙げた関連issue #104888はmacOSのDesktopアプリが対象で、アイドルのセッションがCLIとMCPのプロセスを残し続けてスワップを使い切る内容です。Linux CLIの件と同じ原因とは確認されていません。ただ、「アイドルのセッションが資源を持ち続ける」という方向性は共通しています。

自分の環境で同じ症状か確認する

手元のゲストで、次の順に見ます。いずれも標準的なLinuxのコマンドです。

# 直前のブートが異常終了していないか(-1 が前回のブート)
journalctl --list-boots | tail -3
 
# 前回ブートの末尾 20 行(rtkit の警告で終わっていないか)
journalctl -b -1 --no-pager | tail -20
 
# 前回ブートに OOM kill の記録があるか
journalctl -b -1 -k --no-pager | grep -iE "out of memory|oom-kill"

journalctl -b -1 の末尾が rtkit-daemon のcanary警告で終わり、OOMの行もpanicもなければ、報告と同じ型です。フリーズが短時間で復帰した場合は、-b -1 ではなく -b 0 で今回のブートを見てください。

次に、フリーズしていない通常時の使用状況を取ります。

# claude プロセスの数と常駐メモリ(KB)
ps -eo pid,etime,rss,args | grep -E "[c]laude" | sort -k3 -n -r | head
 
# 全体のメモリとスワップ
free -h

rss の列が数GBに達しているプロセスがあれば、メモリが主因の可能性が上がります。報告者の環境では20GBのRAMに対し、1プロセスが約8.5GBに達した記録があります。アイドルのセッションが経過時間(etime)の長いまま残っていないかも、あわせて見てください。

セッション側のメモリを見たいときは、Claude Codeの画面でも手がかりが得られます。セッションのヒープメモリが2.5GBを超えると、重大なメモリ使用量の警告が表示されます。この警告が出たセッションは、/compact で解消するか、Claude Codeを再起動して claude --continue で会話を再開すると、新しいプロセスに入れ替えられます。

メモリがなかなか下がらないときは、/heapdump を実行します。JavaScriptヒープのスナップショットと、メモリの内訳を記したファイルが書き出されます。ヒープ外のネイティブメモリが大きい場合はスナップショットに映らないため、内訳ファイルの数値をissueへの追記材料にしてください。コマンドメニューには表示されないので、名前を最後まで入力します。

回避策1: バージョンを2.1.274に戻して固定する

報告者の回避策は2.1.274への固定です。ネイティブインストーラーはバージョン番号を指定できます。

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.274
claude --version

この手順はセットアップのページに載っている形式です。ただし戻した後に、自動更新が再び上書きしないよう止める必要があります。ここに落とし穴があります。

issueの報告者によると、~/.claude.json の "autoUpdates": false はネイティブの更新機構に無視され、毎日新しいビルドを取得して ~/.local/bin/claude を差し替え続けました。実際に止まったのは、settings.json の env に DISABLE_UPDATES=1(または DISABLE_AUTOUPDATER=1)を置いた場合だけだったとのことです。

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

公式の環境変数一覧では、DISABLE_AUTOUPDATER が自動更新を止めて手動の claude update は使える設定、DISABLE_UPDATES が手動の claude update と claude install も含めてすべて止める設定と説明されています。戻した版に留めたいなら、後者のほうが確実です。ただし DISABLE_UPDATES=1 のままではバージョン指定のインストールも止まる可能性があるため、戻す作業を先に済ませてから設定してください。

回避策2: 同時実行数を絞る

固定を使わない場合は、同時に走らせるセッション数を絞ります。報告者の症状は2セッション以上で出ているので、まず1セッションに戻して様子を見るのが最も単純な切り分けです。

• 作業が終わったセッションは /exit で閉じ、アイドルで放置しない
• 並列作業が必要なら、1つのセッション内のサブエージェントに任せる
• tmuxなどで裏に残したセッションがないか、ps で確認する

報告者は、ctrl+x ctrl+s(「今すぐ送信」)が入ったv2.1.275以降、特にv2.1.281で「今すぐ送信」が実行中のツールをキャンセルせずバックグラウンドへ移す挙動に変わった点を疑っています。公式の変更履歴にも、この挙動変更の記載があります。ツールのプロセスがターンをまたいで残り、アイドルのセッションに積み上がるという経路の推測です。確定した原因ではないため、「今すぐ送信」を使わない運用が効くかどうかは、自環境で試して確かめる段階です。

回避策3: ゲストの側で暴走を止める

Claude Code側の修正を待つ間、ゲストのOS側で上限を設ける方法もあります。これは一般的なLinuxの仕組みで、報告された症状への効果は未検証です。

# claude を 6GB で頭打ちにして起動(cgroup v2 / systemd 環境)
systemd-run --user --scope -p MemoryMax=6G -p MemorySwapMax=0 claude

上限に達したときは、ゲスト全体がスケジューラごと止まるのではなく、そのプロセスだけがkillされることを狙っています。ただしsystemdのuserスコープでメモリ制御が使えるかは環境によります。使えない場合はエラーになるので、その場合はこの手順を飛ばしてください。

また、報告の環境はスワップが2GBと小さめでした。RAMに対してスワップが極端に小さいゲストは、メモリ逼迫のときに回収が間に合わず停止に至りやすい構成です。vCPUやメモリの割り当てを増やすだけで解決する保証はありませんが、切り分けの1つとして試せます。

ほかの仮想化基盤の事例との違い

仮想マシン上でClaude Codeが止まる事例は、ほかの基盤でも報告されています。ただし症状と原因が異なります。

ProxmoxやHyper-Vの例は、1セッションでも起動時に止まる、CPUの機能が見えていないといった入口の問題です。VMwareの報告は、起動できて普段は動き、複数セッションで蓄積して初めて停止する点が異なります。クラッシュのたびにコアダンプが残るタイプのLinux固有の障害は、ARM64のSIGABRTの切り分けに別の手順があります。

まとめ

VMware上のLinuxゲストでのフリーズは、1件の報告に基づく状況です。再発条件は2セッション以上、ログの特徴はOOMなしでrtkitのcanary警告、有効だった回避策は2.1.274への固定です。まず journalctl -b -1 で自分のログの型を確かめ、型が一致するなら同時セッションを1つに絞って再現するかを見るのが、コストの低い順番です。固定は自動更新の設定とセットで考える必要があり、issueがclosedになった時点で外す前提で使ってください。