何が起きているか
VS Code にダイアログが表示されます: The window has crashed (reason: 'oom', code: '139')。エディターがフリーズし、ウィンドウが真っ白になり、ワークスペース全体が落ちることもあります。これはOOM（メモリ不足）による強制終了です — ヒープ領域が不足したため、OSまたはElectronランタイムがレンダラープロセスを終了させたのです。
大規模なモノレポ、同時に実行される拡張機能が多すぎる場合、または巨大な型グラフを持つTypeScriptプロジェクトが主な原因です。解決策は2つに集約されます: VS Codeにより多くのメモリを割り当てること、そして実際に消費しているものを削減することです。
手順1 — 本当にOOMか確認する
すぐに修正に飛びつかないでください。まず、壊れた拡張機能や不正なワークスペース状態が真の原因でないことを確認します。
VS CodeのプロセスエクスプローラーをOpenします: Help → Open Process Explorer。クラッシュを再現しながら Memory 列を監視してください。レンダラープロセスが1〜2GBを超えて突然消えた場合、OOMの問題です。
Linuxでは、カーネルのOOMキラーログで確認します:
dmesg | grep -i 'killed process'
# または
journalctl -k | grep oom
code または code-oss バイナリに関連する Out of memory: Killed process の行を探してください。これでVS Codeのバグではなく、OSが強制終了したことが確認できます。
手順2 — レンダラーのヒープ上限を引き上げる
ElectronのV8レンダラーはプラットフォームによって約700MB〜1.5GBのヒープで起動します。大規模プロジェクトではこの上限に簡単に達してしまいます。上限を引き上げましょう。
VS Codeの起動フラグファイルを開きます:
Ctrl+Shift+P → "Preferences: Configure Runtime Arguments"
ヒープを4GBに引き上げるために以下のエントリを追加します:
{
"js-flags": "--max-old-space-size=4096"
}
保存後、VS Codeを完全に再起動してください — すべてのウィンドウを閉じてください。単に再読み込みするだけでは不十分です。目安: 8GBのマシンでは 4096、16GBでは 8192 を使用します。
ターミナルから起動する場合は、代わりにフラグを直接渡します:
code --js-flags="--max-old-space-size=4096" .
手順3 — メモリリークしている拡張機能を特定する
拡張機能は単一のホストプロセスを共有しています。出来の悪い拡張機能1つが、他はすべて問題なさそうに見える中で、静かに数ギガバイトを消費することがあります。拡張機能の二分探索を使ってすばやく特定しましょう:
Ctrl+Shift+P → "Start Extension Bisect"
VS Codeは拡張機能の半分を無効にし、クラッシュを再現するよう求め、手動で切り替えることなく自動的に範囲を絞り込んでいきます。
直接的なアプローチを好む場合は、すべてをオフにして起動します:
code --disable-extensions .
クラッシュが消えた場合、拡張機能が原因です。よくある容疑者: 大規模Pythonプロジェクトでのpylance、広大なJSコードベースでのESLint、数万コミットのリポジトリでのGitLens、そして全般的に言語サーバーが挙げられます。
手順4 — 大規模プロジェクトのTypeScriptメモリをチューニングする
TypeScript言語サーバーはVS Codeの上位メモリ消費者の常連です。デフォルトの上限は3GBで、小規模プロジェクトには十分ですが、500以上のソースファイルを持つ大規模モノレポには足りません。
ワークスペースの .vscode/settings.json に追記します:
{
"typescript.tsserver.maxTsServerMemory": 8192,
"typescript.tsserver.experimental.enableProjectDiagnostics": false
}
ついでに tsconfig.json の除外設定も確認してください。これがないと、tsserverはプロジェクトルート以下のすべてを型チェックします — node_modules 内の数百万行のコードも含めて:
{
"exclude": [
"node_modules",
"dist",
"build",
"**/*.spec.ts"
]
}
この exclude ブロックが1つ欠けているだけで、tsserverのメモリ使用量が2倍や3倍になることがあります。
手順5 — ワークスペースの範囲を絞る
ワークスペース内のすべてのフォルダに対して、ファイルウォッチャー、検索インデックス、言語機能が有効になります。ホームディレクトリ全体や巨大なモノレポのルートを開くと、1文字入力する前からVS Codeは膨大なバックグラウンド処理を行っています。
.code-workspaceファイルを使用して、実際に編集するサブディレクトリのみを含めましょう。- ファイル監視と検索から、大きな生成フォルダを除外しましょう:
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/.git/objects/**": true
},
"files.exclude": {
"**/node_modules": true
},
"search.exclude": {
"**/node_modules": true,
"**/dist": true
}
}
手順6 — 使わない機能を無効にする
VS Codeの一部の組み込み機能は、意外なほどコストが高いです。不要なものはオフにしましょう:
{
"editor.minimap.enabled": false,
"editor.codeLens": false,
"git.decorations.enabled": false,
"extensions.autoUpdate": false,
"telemetry.telemetryLevel": "off"
}
Code Lensは意外と見落とされがちな問題の原因です。インラインの参照カウントやテスト実行ボタンを表示するために、VS Codeは常にライブのシンボルテーブルをメモリ上に保持する必要があります。これを無効にするだけで、大規模なTypeScriptプロジェクトでは100〜300MBを解放できることがあります。
修正を確認する
まずクリーンな再起動を行います — ウィンドウを再読み込みするだけでは不十分です:
- VS Codeを完全に閉じます（Linuxでは必要に応じて
pkill code）。 - プロジェクトを再度開きます。
- すべての言語サーバーのインデックス作成が完了するまで2〜3分待ちます。
- Help → Open Process Explorer を開きます — レンダラープロセスは上昇し続けるのではなく、新しいヒープ上限以下で安定するはずです。
Linuxではターミナルでメモリをリアルタイムに監視できます:
watch -n 2 'ps aux | grep code | grep -v grep | awk "{print \$6/1024 \" MB \", \$11}"'
通常使用で1時間後もメモリが安定し、OOMクラッシュが再発しなければ、修正完了です。
クイックリファレンス
--disable-extensionsでクラッシュが止まる → 拡張機能の二分探索を実行して問題のある拡張機能を特定する。- 大規模TypeScriptプロジェクトでのみクラッシュする →
typescript.tsserver.maxTsServerMemoryを引き上げ、適切なtsconfig.jsonの除外設定を追加する。 - どのプロジェクトでもクラッシュする →
argv.jsonの--max-old-space-sizeを引き上げる。 - Linuxでのみクラッシュする →
dmesgを確認する。VS Code自身のヒープ上限が効く前にカーネルがVS Codeを終了させている可能性があります。RAMが少ない（8GB未満）場合は、スワップファイルを追加すると改善することがあります。