Claude Code VS Code拡張、セッションが肥大化すると「応答なし」を繰り返す件を追った
Claude CodeのVS Code拡張で、長時間使ったセッションを開くと拡張ホストがクラッシュしてタブが全滅する不具合を、GitHub Issue #97229・#97230・#92089の一次情報から検証。原因はpost-compact省略処理の不具合と2GiB超で起きる整数オーバーフロー、確認方法と回避策まで整理した。
エンジニアのゆとです。
ふと気になって、自分の~/.claude/projects/をdu -shで覗いてみた。
du -sh ~/.claude/projects/*/*.jsonl | sort -rh | head -5一番大きいセッションファイルが746MB。二番目が504MB。どちらも「気づいたら育っていた」長期セッションだ。この時点では何も困っていなかったが、GitHub Issueを漁っていて背筋が冷えた。VS Code拡張のClaude Codeには、セッションのtranscript(会話履歴を保存する.jsonl)が肥大化すると拡張ホストごとクラッシュし、開いているClaudeタブが全部道連れで落ちる不具合が複数報告されている。しかも一部の条件では、一度壊れたセッションは二度と開けなくなる。
この記事ではanthropics/claude-codeのIssue #97229・#97230・#92089・#89075を一次情報として読み込み、何が起きているのか、自分のセッションが危険水域にあるかの確認方法、現状取れる回避策までを整理した。
まず結論 — 何が起きているか
| 項目 | 内容 |
|---|---|
| 症状 | VS Code拡張でセッションを開くと拡張ホストが応答なしになり、再起動ループに入る。開いていたClaudeタブが全部落ちる |
| 発生条件① | 圧縮(/compact)済みのセッションを開くと、本来スキップされるはずの圧縮前の履歴まで毎回フルパースされる(Issue #97230) |
| 発生条件② | セッションのtranscriptが2GiB(約21億バイト)を超えると、パーサーが整数オーバーフローで無限ループに陥り、そのセッションは二度と開けなくなる(Issue #97229) |
| 肥大化の原因 | /compactを2回目以降実行すると、圧縮前の履歴を再度書き込んでしまい、transcriptが圧縮のたびに指数的に膨らむ(Issue #92089) |
| 対象バージョン | Claude Code VS Code拡張 2.1.278〜2.1.282(2026年9月時点の最新) |
| 影響範囲 | Windows/Linuxで実測報告あり。拡張ホストはウィンドウ内の全Claudeタブで共有されているため、1つの巨大セッションが他の作業中セッションまで巻き添えにする |
いずれも2026年9月25日時点でOPENのままで、報告者(BlackWhiteYellow氏)は原因のコード箇所まで特定した非常に精度の高いレポートを提出している。
症状: 拡張ホストが「応答なし」を繰り返し、Claudeタブが全滅する
Issue #97230の報告によると、長時間の圧縮済みセッションを開いているウィンドウで、拡張ホストの再起動(拡張の自動更新・ロールバック・クラッシュなど何らかのきっかけ)が起きると、VS Codeは開いていたClaudeタブを一斉に復元しようとする。その復元処理が重なった瞬間に拡張ホストのメモリが限界を超え、また落ちる。落ちればまた自動再起動がかかり、また同じタブを復元しようとする——というループに入る。
報告者の環境では、合計4.3GiBのtranscriptを持つ5つのタブが13秒以内に同時復元され、21秒後にクラッシュ。これが47分間で13回発生している。ログにはこう出る。
renderer.log:
[info] Extension host (LocalProcess pid: <n>) is unresponsive.
[error] Extension host (LocalProcess pid: <n>) terminated unexpectedly. The following extensions were running: … Anthropic.claude-code …
[info] Automatically restarting the extension host.体感としては「Claude Codeのタブが急に固まる」「拡張機能が死んでいる通知が出る」「開き直しても同じタブでまた落ちる」という形で現れる。厄介なのは、原因になっている巨大セッションのタブ以外も、同じ拡張ホストを共有しているというだけで巻き込まれて落ちる点だ。
原因1: 圧縮済みセッションのはずが、毎回フルパースされている(#97230)
VS Code拡張には本来、5MiBを超えるtranscriptを開く際に「直近の圧縮境界(compact_boundary)より後ろだけを読む」という省略処理(post-boundary scanner)が入っている。圧縮済みセッションなら、本文全体ではなく圧縮後の差分だけを読めば済むはずだ、という設計だ。
ところが報告によると、この省略処理はcompact_boundaryのメタデータにpreservedSegmentまたはpreservedMessagesが含まれている場合、判定条件の作りが原因でバッファのリセットが一度も走らない。今のClaude Codeが書き出すcompact_boundaryは例外なくこの2つのフィールドを持つため、実質的に省略処理そのものが機能していないことになる。
つまり「圧縮したから軽くなっているはず」という前提が成り立たず、圧縮済みの長時間セッションほど、開くたびにファイル全体をV8のヒープに展開してしまう。報告者が実測した数値がこちらだ。
| 実transcriptサイズ | パースされた割合 | パース後のV8ヒープ |
|---|---|---|
| 212MiB | 100% | 258MiB |
| 543MiB | 100% | 643MiB |
| 874MiB | 100% | 1,063MiB |
| 954MiB | 100% | 1,141MiB |
| 1,803MiB | 100% | 1,935MiB |
拡張ホストの共有ヒープはElectronのポインタ圧縮の都合で4GiBが上限になる。冒頭で自分の環境にあった746MBのセッションも、この表に照らせば900MB前後のヒープを食っている計算になる。1本ならまだ耐えるが、複数の大きいタブを同時に開いた状態で拡張ホストが再起動すれば、合計値があっさり上限を超える。
原因2: 2GiBを超えると整数オーバーフローで永久に開けなくなる(#97229)
さらに踏み込んだ問題が、transcriptが2GiB(2,147,483,648バイト)を超えた場合に起きる。VS Code拡張のtranscriptパーサーは、buf.indexOf(10, pos)(改行コードの位置を探す処理)を使って1行ずつ読み進めているが、一致位置が2^31バイトを超えると、Node.jsのBuffer.prototype.indexOfは32bit整数のラップアラウンドで負の値を返す。
パーサー側はこの「見つからなかった」はずの負の値をそのまま次の探索開始位置として使ってしまい、同じ範囲を後ろ向きに読み続ける無限ループに突入する。ヒープを使い切るまで同じ行を重複して読み込み続けるため、最終的にFATAL ERROR: Ineffective mark-compact GCs near heap limitでクラッシュする。
これが厄介なのは、一度2GiBを超えたセッションは、拡張の更新やロールバックを試しても、ウィンドウを再読み込みしても直らないという点だ。ファイルサイズが2GiBを超えている限り、開こうとするたびに同じ場所で同じループに入る。報告者の検証では、2.01GiBのセッションを開いた直後に13回中11回のホストクラッシュが発生している。
原因1(post-compactスキップの不具合)によって「圧縮しても軽くならない」状態が常態化しているため、原因2(2GiB超のオーバーフロー)に到達するまでの距離が、本来の設計より大幅に近くなっているのがこの2つの問題の関係だ。
なぜここまで肥大化するのか——/compactが逆に肥大化させる矛盾(#92089)
そもそもtranscriptがここまで育つ背景には、別の不具合がある。Issue #92089によると、同一プロセス内で/compactを2回目以降実行すると、1回目の圧縮より前の履歴が丸ごとtranscriptに再度書き込まれてしまう。UUIDやタイムスタンプは元のまま複製されるため、圧縮を繰り返すたびに「圧縮前の履歴の重複コピー」が積み重なり、transcriptは圧縮回数に対して指数的に膨張する。
報告者の実測では、166MBのセッション(17,234行)のうち7,394行(104MB)がこの重複コピーだったという。/compactは本来「文脈を圧縮して軽くする」ための機能なのに、使えば使うほどファイルサイズは増える——という逆説的な状態になっている。
似ているようで違う: セッション一覧のOOMとは別の話(#89075)
もう1つ、紛らわしい別のIssueがある。#89075は「セッション一覧を開く時点で全セッションの履歴をまとめて読み込んでOOMになる」という報告で、今回扱っている「個別のセッションをタブで開いた時に起きるOOM」とは読み込み経路が異なる(前者はget_session_requestではなく一覧表示用のリクエスト経路)。ただし報告者自身も「同じtranscriptリーダーを使っているなら、この省略処理の不具合はセッション一覧側でもファイル全体を読んでいる可能性がある」と指摘しており、根が同じ実装バグに行き着く可能性は残っている。
自分のセッションが「危険水域」にあるか確認する方法
対処を考える前に、まず自分の環境がどのくらい危ないかを数字で把握しておく。ターミナルで次のコマンドを叩けば、サイズの大きいセッションを一覧できる。
# macOS/Linux
du -sh ~/.claude/projects/*/*.jsonl | sort -rh | head -10
# Windows (PowerShell)
Get-ChildItem -Recurse "$env:USERPROFILE\.claude\projects\*.jsonl" |
Sort-Object Length -Descending | Select-Object -First 10 FullName, @{N='MB';E={$_.Length/1MB}}目安は次の通りだ。
- 5MiB超え: post-boundary省略処理の対象になるサイズ。ただし#97230の不具合が直っていない現状では、圧縮済みでも実質フルパースされる
- 数百MB〜1GiB: 単体では致命傷にならないが、複数タブを同時に開いた状態での拡張ホスト再起動が危険になり始める帯
- 2GiB超え: #97229の整数オーバーフローに該当し、そのタブを開くたびにクラッシュを繰り返す危険水域
自分の環境で確認したところ、746MBと504MBのセッションが2本あった。まだ2GiBには届いていないが、複数タブを同時に開いていれば拡張ホストの共有ヒープ上限(4GiB)に近づく組み合わせは十分あり得る数字だった。
現状の回避策
根本的な修正(post-boundary省略処理の修正、2GiB超でのオーバーフロー対策)はまだ入っていない。現時点でIssue上に出ている、または実務的に取れる対処は次の3つだ。
1. 検証済みのworkaround: transcriptを圧縮境界から切り詰める
Issue #97229の報告者が検証済みとして提示している方法で、壊れたセッションのtranscriptから、parentUuidがnullになっているcompact_boundaryレコードを起点に、それ以降だけを新しいファイルとして残す。元のファイルは別の場所に退避しておく。報告者の環境では、2.01GiBだったtranscriptをこの方法で約96MiBまで切り詰めたところ、0秒で開けるようになったという。
ただし手動でJSONLの該当行を探して切り出す作業になるため、jqなどでの前処理を推奨する。作業前に必ずタブを閉じ、元ファイルのバックアップを取ってから行うこと。
2. セッションを長生きさせすぎない
原因1・原因2どちらも「セッションが育ちきってから」表面化する問題なので、1つのセッションを何日も--resumeで使い回すのではなく、区切りのいいタイミングで新規セッションに切り替える方が安全だ。とくに/compactを同一プロセス内で複数回実行する運用は、#92089の指数的膨張を直接踏み抜くことになるので避けたい。
3. 巨大セッションのタブを同時に開いたままにしない
拡張ホストはウィンドウ内の全Claudeタブで共有されている。数百MB級のセッションを何本も開きっぱなしにしていると、拡張の自動更新やクラッシュをきっかけにした一斉復元で、無関係な作業中タブまで巻き添えになる。使い終わったセッションのタブはこまめに閉じておくと、少なくとも「同時に読み込まれるtranscriptの合計サイズ」は抑えられる。
公式の反応と今後の見通し
3つのIssueはいずれも2026年9月25日時点でOPENのままで、まだ修正版はリリースされていない。ただし#97229・#97230の報告は、原因のコード行番号や再現用スクリプトまで添付された非常に精度の高いレポートで、報告者自身が5つの具体的な修正案(境界での確実なバッファリセット、チャンク単位のパース、ホスト外(ワーカースレッド)でのロード、タブの遅延復元、JSONキー順に依存しない境界判定)まで提示している。修正の難易度としては、緊急パッチが必要な部類の不具合だと見ていいはずだ。
一方で/compactの指数的膨張(#92089)は、今回の2つのクラッシュ系Issueの「肥大化を加速させる要因」として名指しされているにもかかわらず、単独では見過ごされやすい問題でもある。3つのIssueを合わせて読むと、「圧縮しているつもりが逆に肥大化していて、しかもその肥大化したファイルを毎回フルパースしてしまい、ある閾値を超えると二度と開けなくなる」という一本のストーリーとして繋がっている。
FAQ
CLI版(ターミナルのclaude)でも同じことが起きる?
今回扱っているのはVS Code拡張(GUIパネル)固有の問題で、拡張ホストというVS Code側のプロセスで起きている。CLI単体のFATAL ERROR: JavaScript heap out of memoryはNode.jsプロセス自体のヒープ上限に起因する別の不具合で、発生条件も対処法も異なる。
自分のセッションはもう手遅れ?
transcriptが2GiBを超えていなければ、まだ間に合う可能性が高い。数百MB程度であれば、セッションを区切って新規に始める・巨大タブを閉じるといった予防策で当面は回避できる。すでに2GiBを超えていて開けなくなっている場合は、圧縮境界からの切り詰めworkaroundを試すしかない。
拡張機能を再インストールすれば直る?
直らない。原因はtranscriptファイル自体のサイズと内容にあるため、拡張を消してもファイルは~/.claude/projects/に残ったままで、再インストール後も同じファイルを開けば同じ場所でクラッシュする。
この記事の情報はいつの時点のもの?
Issue #97229・#97230は2026年9月25日作成、#92089は9月4日作成、#89075は8月23日作成で、いずれも同日時点でコメントを確認している。Claude Code VS Code拡張のバージョンは2.1.278〜2.1.282での報告が中心。マイナーアップデートで頻繁に状況が変わる領域なので、実際に対処する際はcode --list-extensions --show-versionsで手元のバージョンを確認し、各Issueの最新コメントも合わせて見ておくのが確実だ。
Macでメモリ・パフォーマンス関連のトラブルに悩まされているなら、こちらも合わせてどうぞ。
Dockerがmacで遅い・メモリを食う原因を「ビルド・実行・I/O」の3層で切り分けて直す
CPU側が高止まりしている場合は原因が別系統なので、こちらを先に見たほうが早いかもしれない。
Claude CodeのCPU使用率が高い・張り付く問題を、GitHub Issueの実例で整理した
