Claude Media
Claude Codeの/resumeが壊れていた3つの原因(v2.1.31以降)

Claude Codeの/resumeが壊れていた3つの原因(v2.1.31以降)

v2.1.31以降/resumeでセッション履歴が読めなくなった不具合の3つの根本原因と、公式changelogで確認できる修正状況を扱います。

Claude Codeの/resumeでセッションが見えなくなった経緯

v2.1.31(2026年2月4日リリース)以降のClaude Codeでは、/resumeが過去のセッションのごく一部しか表示しない不具合が広く報告されました。GitHub issue #26123には、同種の報告が12件以上、合計29件超のリアクションと50件超のコメントで寄せられ、macOS・Windows・Linuxの3プラットフォームにまたがる問題として統合されています。

セッションデータ自体は失われていません。.jsonl形式のトランスクリプトファイルはディスク上にそのまま残っており、失われていたのは「それらを見つけて選ぶためのUI」でした。報告者の一人は、ディスク上に3,080件超の.jsonlファイルがあるのに/resumeピッカーには5〜10件しか出てこないと具体的な数字を挙げています。/resumeの基本的な操作方法や復元される状態についてはClaude Codeの/resumeコマンドで過去の会話を再開するで扱っており、本記事ではこの時期に限定して起きた内部的な原因を掘り下げます。

3つの根本原因

issueには、コミュニティによるcli.js(v2.1.39時点)のリバースエンジニアリングを根拠に、独立した3つの原因が整理されています。いずれもAnthropicが公式に原因として認めた記述ではなく、コード解析による報告である点に注意が必要です。

原因1: sessions-index.jsonの更新が止まっていた

sessions-index.jsonは、~/.claude/projects/以下の各プロジェクトディレクトリに保存される索引ファイルです。複数の報告者の集計によれば、2月4日00:33 UTC以降に作成されたセッションはこのファイルへ一件も追加されなくなり、ある報告では3,080件の.jsonlのうちインデックス済みは740件(24%)、2月4日以降分は0%だったとされています。同時期に~/.claude/usage-data/の更新も止まっていたという報告もあり、単一ファイルだけの不具合ではなさそうだという見立てでした。

この索引の欠落は、プランモードで計画を承認したあとに自動生成される実装用セッションでとくに目立っていました。@yulin0629の報告によれば、プランモードで「Yes, clear context and auto-accept edits」を選ぶと生成される実装セッションは、367行分の完全な.jsonlを持ちfirstPromptslugも正常に記録されているにもかかわらず、sessions-index.jsonには一件も登録されていませんでした。同じ報告者のプロジェクトディレクトリでは156件の.jsonlのうち63件(40%)しかインデックスされておらず、割合としては先の集計と近い水準です。

v2.1.47のリリース後も、原因1については解消が確認されないという報告が続きました。@vbhavsarはv2.1.50の時点で、自分のマシンにある68件の.jsonlのうちインデックス済みは25件にとどまり、欠落していた43件はいずれも2月上旬以降に作られたセッションだったと報告しています。ピッカー自体がディスクを直接スキャンする実装(原因2の修正)によって表示件数の問題は緩和されたものの、索引ファイルそのものの更新停止は別問題として残っていた、という見立てです。

原因2: ピッカーの初期表示件数が10件に固定されていた

@tracymelodyによる難読化済みcli.js(v2.1.39)の解析では、/resumeピッカーはそもそもsessions-index.jsonという文字列をソース中に持たず、このファイルを読んでいないことが分かりました。代わりにreaddirSync.jsonlファイルを直接スキャンし、更新日時でソートしています。この処理の初期バッチ件数を決めるKパラメータがK=10にハードコードされており、追加読み込みのトリガーがターミナルの行数に依存する実装だったため、24行程度の端末では条件を満たさず追加読み込みが発火しないケースが確認されています。

原因3: Windowsでworktreeパスの大文字・小文字の比較が一致しなかった

@agathoの報告(#24729)によれば、複数worktreeを使う経路ではdir.name === sという大文字と小文字を区別する比較が使われていました。git worktree listC:/...のような表記を返す一方、プロジェクトディレクトリ側はc--...のような表記でパスを保存しており、比較が静かに失敗してセッションが見つからなくなっていました。この症状は2つ以上のgit worktreeを併用している場合にだけ発生します。

公式changelogで確認できる修正状況

issueのコメント欄では、v2.1.47で原因2と原因3が修正されたと報告されています。実際に公式changelogを確認すると、この2件は同issue番号への参照付きで記録されています。

バージョン対応した原因変更内容
v2.1.47対応した原因原因2・原因3変更内容ピッカーの初期表示件数を10件から50件に拡大。Windowsでドライブレターの大文字・小文字が異なる場合のworktreeセッション照合を修正(いずれもissue #26123への参照付き)
v2.1.243対応した原因原因2の残存部分変更内容ピッカーがスクロールに応じて追加読み込みされるようになり、50件という上限自体が解消

原因1(sessions-index.jsonの更新停止)については、公式changelogの中に「索引ファイルの書き込みを再開した」と明記する項目は見当たりませんでした。一方で原因2の調査結果からは、/resumeピッカー自体はこの索引ファイルを最初から読んでいなかったことが分かっています。つまり索引の更新停止が実際に/resumeピッカーの表示件数へ与えていた影響は、当初の報告ほど直接的ではなかった可能性があります。ただし~/.claude/usage-data/など索引以外の用途への影響が解消したかどうかは、今回参照した情報だけでは確認できませんでした。

影響を受けやすかった利用形態

3つの原因は独立していたため、実際に受ける影響も利用形態によって差がありました。

利用形態影響度理由
セッション数が数十件までのライトユーザー影響度ほぼ影響なし理由ピッカーの初期表示件数(10件)に収まりやすく、原因2の症状が顕在化しにくい
数百件規模のセッションを抱えるヘビーユーザー影響度明確な影響あり理由原因1・原因2の両方が重なり、大半のセッションが事実上探せなくなる
プランモードの実装セッションを多用するユーザー影響度明確な影響あり理由実装用セッションが索引に登録されず、作業内容が多いセッションほど見失いやすい
複数のgit worktreeを併用するWindowsユーザー影響度条件次第理由原因3が加わり、worktree数が2以上のときだけ追加でセッションが見つからなくなる

セッション数が少ないうちは気づきにくく、プロジェクトが育って.jsonlが数百件を超えたころに症状が表面化する、という順序で報告が積み上がっていた点は、この不具合の発見が遅れた理由の一つとして読み取れます。

v2.1.47は12件の重複issueの統合を経て出た修正だった

issueのコメント欄には、原著者が「Anthropicの優先度判断は50件以上の合計コメント・リアクションが目安」という趣旨のやり取りを残しており、実際にこのissueは合計エンゲージメントが50件を超えた後に12件の重複issueを一本化する形で整理されています。個別の小さな報告のままでは埋もれていた可能性がある不具合が、根本原因まで踏み込んだ一つの統合issueにまとまったことで、v2.1.47の一括修正につながった経緯として読み取れます。

なお、Windowsのworktreeパス比較とは別に、Claude Code Desktopではセッション終了後もworktreeディレクトリが使い回される不具合も報告されています。こちらは/resumeが見つからない話ではなく、新規のはずのセッションに前回の状態が引き継がれる別種の症状で、Claude Codeのworktreeが再利用されるバグにまとめています。

セッションが見つからないときに切り分ける手順

同じ症状に心当たりがある場合は、まずディスク上のセッション数とピッカーの表示件数を突き合わせます。

# ディスク上の.jsonlファイル数を数える
find ~/.claude/projects -name "*.jsonl" | wc -l
 
# sessions-index.jsonの最終更新日時を確認する
for idx in ~/.claude/projects/*/sessions-index.json; do
  echo "$idx: $(stat -f '%Sm' "$idx" 2>/dev/null || stat -c '%y' "$idx" 2>/dev/null)"
done
 
# 現在のバージョンを確認する
claude --version

ディスク上のファイル数に対してピッカーの表示が極端に少ない場合、まずはv2.1.47以降(可能ならv2.1.243以降)にアップデートしているかを確認します。バージョンを上げても解決しない、あるいは古いバージョンから直せない事情がある場合は、claude --resume <キーワード>で検索語を直接渡すとピッカーを経由せず.jsonlを横断検索できるため、当座の回避策になります。セッションIDが分かっているならclaude --resume <session-id>も有効です。なおissueのコメント欄では、/renameで付けたカスタム名がピッカーに表示されないという別の不具合(原因1〜3とは別に報告された4件目の症状)も指摘されていました。セッションへの命名手段そのものはClaude Codeでセッションに名前をつけて管理するにまとめています。

/resumeを選んだ直後に読み込みが失敗してFailed to resume the conversationと表示される症状は、今回の3つの原因とは別の不具合です。対処法は「Failed to resume the conversation」の対処法にまとめているので、症状を混同しないよう切り分けてください。

issueのWorkaroundsの節には、上記以外の選択肢も挙がっていました。claude install 2.1.29で当時の最終安定版に戻す方法(直前の原因調査の段階では最後に問題なく動いていたバージョンとして名指しされていました)、そしてコミュニティ製のインデックス再構築スクリプトを使う方法です。いずれもissue内で個人が共有した非公式な手段であり、Anthropicが検証・配布しているものではない点は踏まえておく必要があります。

原著者はissue内で、セッション履歴が見つからない問題(#26123)と、コンパクション前の履歴をCtrl+O/Ctrl+Eで見られなくなる別の不具合(#26125)が併発しやすいことにも触れています。両方とも当時のセッション要約・メタデータ生成にまつわる変更と時期が近く、探す手段(#26123)と見る手段(#26125)の両方を同時に失うと、過去の作業に戻る手段がほぼ無くなるという指摘です。

まとめ

v2.1.31以降に報告された/resumeのセッション消失は、索引ファイルの更新停止・ピッカーの表示件数の固定・Windowsでのパス比較という独立した3つの原因が重なって起きていました。公式changelogで確認できる範囲では、ピッカーの表示件数の問題とWindowsのパス比較はv2.1.47とv2.1.243で解消されています。索引ファイルの更新停止そのものが公式に修正されたと明記する記述は見当たらず、この点は今回参照した情報の範囲では未確認のまま残ります。同様の症状に遭遇した場合は、バージョンの確認とあわせてclaude --resume <キーワード>のような索引に依存しない検索手段を経由することで、データ自体は失われていないことを確認できます。

この記事を共有:XはてブLinkedIn