Claude CodeがWSL2で突然落ちる──OOM Killの原因と対策¶

対象 / ポイント

対象: WSL2上でClaude Codeを使用中に強制終了を経験した開発者。セッションが復旧できず困っている方。

ポイント:

Claude Codeには既知のメモリリークがあり、WSL2のデフォルト設定では数十分〜数時間でOOM Killされる
強制終了されるとセッションインデックスが破損し、--resumeが効かなくなる
.wslconfigのメモリ・Swap調整とセッション運用の工夫で、発生頻度を大幅に下げられる

何が起きるのか¶

Claude Codeで作業中、突然プロセスが消える。ターミナルには何のエラーメッセージも残らない。claude --resumeで再開しようとしても、セッションが見つからない。

これはLinuxカーネルのOOM Killer（Out of Memory Killer）がClaude Codeプロセスを強制終了している。システムの物理メモリとSwapが枯渇したとき、カーネルが最もメモリを消費しているプロセスを選んでSIGKILL（シグナル9）で即座に殺す仕組みだ¹。

正常なシャットダウンではないため、Claude Codeはセッションファイルを書き込めずに死ぬ。結果、セッションの引き継ぎ（resume）ができなくなる。

なぜClaude Codeがメモリを食い尽くすのか¶

原因はClaude Code自体のメモリリークだ。GitHub上に多数のissueが報告されている。

Node.jsのV8ヒープ上でArrayBufferが際限なく蓄積される問題が確認されており、あるissueでは1時間あたり約92GBのペースでメモリが膨張するケースが計測されている²。別の報告では、プロセスが120GB以上のRAMを消費してOOM Killされた記録もある³。

実際の挙動を因果で追うと、以下のシーケンスになる。

Claude Code起動 → セッション内でツール実行を繰り返す → 会話コンテキスト＋ツール結果がメモリに蓄積 → V8ヒープが膨張 → 物理メモリ＋Swapを食い尽くす → カーネルOOM Killer発動 → SIGKILLでプロセス即死 → sessions-index.json未更新 → --resume不可

WSL2環境では、この問題が特に顕在化しやすい。理由は2つある。

1つ目は、WSL2のデフォルトメモリ上限が低いこと。 WSL2はホストPCの物理メモリの50%をデフォルト上限とする⁴。16GBマシンなら約8GB、Swapは4GB（RAMの25%）がデフォルト。Claude Codeに加えて常駐サービス（Elastic Agent、PostgreSQL、Zabbixなど）が動いていれば、数GBの余裕しかない。

2つ目は、2026年3月のWindowsアップデートKB5079473の影響。 このパッチ適用後、WSL2上のClaude Codeが毎回4.6GBでヒープ枯渇して停止するという報告がある⁵。Windows 11 25H2/24H2が対象で、開発者の多くに影響する可能性がある。

OOM Killされたかどうかの確認方法¶

WSL2内のターミナルで以下を実行する。

# カーネルログからOOM Killの記録を検索
dmesg | grep -i "oom\|killed process" | tail -20

Out of memory: Killed process XXXXX (claude) のような行が出れば、OOM Killが確定する。total-vm（仮想メモリ）とanon-rss（実メモリ）の値から、kill時のメモリ消費量も分かる。

現在のメモリ状況はこのコマンドで確認できる。

# システム全体のメモリ状況
free -h

# Claude Codeプロセスのメモリ使用量
ps aux --sort=-%mem | grep -E "claude|RSS" | head -10

Swapの使用率が80%を超えていたら、OOM Killはいつ起きてもおかしくない状態だ。

対策1：.wslconfigでWSL2のリソース上限を引き上げる¶

WSL2に割り当てるメモリとSwapを増やす。Windows側の%USERPROFILE%\.wslconfigを編集する。

設定値は環境に依存する

以下は物理メモリ16GBのPCでの設定例であり、万能の値ではない。ホストPCの搭載メモリ、Windows側の使用量、WSL2内の常駐サービス構成によって適切な値は異なる。まずfree -hで現状を把握し、自分の環境に合わせて調整すること。

[wsl2]
memory=10GB
swap=8GB

項目	デフォルト（16GB PCの場合）	設定例	効果
WSL2 RAM	8GB	10GB	+2GB。Claude Code＋常駐サービスに余裕
WSL2 Swap	4GB	8GB	+4GB。メモリスパイク時のバッファ倍増
合計	12GB	18GB	OOM Kill閾値が1.5倍に

反映にはWSLの再起動が必要だ。PowerShellから実行する。

wsl --shutdown

注意

wsl --shutdownは全WSLプロセスを停止する。Claude Codeのセッションも切れるため、作業の区切りで実行すること。

ただし、この設定はトレードオフを伴う。ホストPCの物理メモリが16GBの場合、WSL2に10GBを割り当てるとWindows側に6GBしか残らない。ブラウザやIDEを多数開いている環境では、Windows側がスワップに逃げて体感速度が落ちる。32GB以上のPCなら余裕を持って設定できるし、逆に8GBのPCではこの値自体が使えない。Swapを増やす方がリスクが低い（ディスクI/Oは遅くなるが、OOM Killは防げる）ため、まずSwapだけ増やして様子を見るのも手だ。

対策2：cgroupでClaude Codeのメモリ上限を制限する¶

メモリリークの根本解決はAnthropic側の修正を待つしかないが、プロセス単位でメモリ上限を設けることで「暴走しても他を巻き込まない」ようにできる。

# cgroup v2の場合（Ubuntu 22.04以降のWSL2）
sudo mkdir -p /sys/fs/cgroup/claude
echo "4G" | sudo tee /sys/fs/cgroup/claude/memory.max
echo $$ | sudo tee /sys/fs/cgroup/claude/cgroup.procs
claude  # このシェルから起動したClaude Codeに4GB制限が適用される

この方法ならClaude Codeが4GBを超えた時点でそのプロセスだけがkillされ、PostgreSQLやElastic Agentなど他のサービスは巻き添えにならない。

対策3：セッション復旧の手順¶

OOM Killされた後、--resumeでセッションが見つからない場合でも、セッションデータ自体は残っていることが多い⁶。

# 直近1日以内に更新されたセッションファイルを探す
find ~/.claude/projects/ -name "*.jsonl" -mtime -1 -ls

# sessions-index.jsonの場所を確認
find ~/.claude/ -name "sessions-index.json" -ls

セッションのJSONLファイルが存在するのにインデックスから消えている場合、インデックスを再構築すれば復旧できる。手順の詳細はZennの解説記事⁶が参考になる。

今後に備えて、重要なセッションは定期的にバックアップしておくと安心だ。

# セッションの定期バックアップ（cronに登録推奨）
mkdir -p ~/.claude/session-backups/$(date +%Y%m%d_%H%M%S)
cp -r ~/.claude/projects/ ~/.claude/session-backups/$(date +%Y%m%d_%H%M%S)/

対策4：運用で回避する¶

技術的な対策と併せて、セッション管理の運用を変えることでダメージを最小化できる。

こまめにセッションを区切る。 Claude Codeのメモリリークはセッション時間に比例して悪化する。1つのタスクが完了したらgit commitしてセッションを終了し、次のタスクは新しいセッションで始める。

セッションIDを控えておく。 Claude Code起動時にターミナルに表示されるセッションIDをメモしておけば、claude --resume <ID>で明示的に復帰できる。--continue（直前セッションの自動再開）よりも確実だ。

Claude Codeのバージョンを確認する。 過去にv2.1.27で致命的なメモリリークが混入し、20秒で7.5GBまで膨張する事象が発生した⁷。claude --versionで現在のバージョンを確認し、最新版にアップデートしておく。

npm update -g @anthropic-ai/claude-code
claude --version

まとめ¶

Claude CodeのOOM Kill問題は、Anthropic側のメモリリークバグが根本原因であり、ユーザー側で完全に防ぐことはできない。しかし、WSL2のリソース設定を適切に調整し、セッション管理を工夫することで、発生頻度と被害を大幅に減らせる。

最も即効性があるのは.wslconfigの修正（Swap 8GB化）で、これだけで状況がかなり改善する。長期的にはAnthropic側の修正（ArrayBufferの蓄積問題の解消）を待ちつつ、cgroupによる防御策とセッションバックアップを組み合わせて運用するのが現実的だ。

GitHub上ではメモリリーク関連のissueが継続的に報告・議論されている。Anthropicの対応状況は以下のissueで追跡できる。