Claude Codeが~/.claudeに残すデータと保持期間を整理する

Claude Code を使っていると、~/.claude/ 配下には自分で書いた設定ファイル以外にも、セッション中に自動生成されるデータがどんどん溜まっていきます。会話のトランスクリプト、入力したプロンプトの履歴、編集前のファイルスナップショット、各種キャッシュ——これらは**平文（暗号化なし）**で保存され、保護手段は OS のファイルパーミッションだけです。

「どのファイルが」「いつまで」残るのかを把握していないと、.env を読ませたセッションの中身が数ヶ月前のログとしてディスクに残り続ける、ということが普通に起こります。本記事では、公式ドキュメントをもとに調べた内容を整理します（2026年8月16日時点）。

まず結論

  • 自動削除の期間は settings.json の cleanupPeriodDays（デフォルト30日） で制御する
  • ただし history.jsonl（全プロンプト履歴）は自動削除の対象外 で、永続的に残る
  • プロジェクト単位で消したいときは claude project purge <path>
  • トランスクリプトは暗号化されないので、認証情報の扱いには別途対策が必要

保持期間の設定: cleanupPeriodDays

Claude Code は、後述する「自動クリーンアップ対象」の各ファイルが cleanupPeriodDays より古くなると自動的に削除します（保持期間を安全に判定できる場合に限る）。

項目値
デフォルト30日
最小値1（0 はバリデーションエラー）
設定場所settings.json
{
  "cleanupPeriodDays": 180
}

この日数は、孤立したワークツリー（orphaned worktree） の自動削除判定にも同じ基準として使われます。サブエージェントやバックグラウンドセッションが残したワークツリーの掃除も、この設定に連動するということです。

スイープが止まるケース

以下の場合、クリーンアップ（スイープ）は実行されません。

  • 設定ファイルが読めない・パースできない
  • cleanupPeriodDays に不正な値が入っている
  • claude -p --bare（bare mode）で実行中

設定エラーでスイープが**一時停止（pause）**している場合は /status に警告が出るので、そこで気づけます。組織の managed settings で cleanupPeriodDays が指定されている場合は、そちらの値が使われます。

自動的にクリーンアップされるデータ

cleanupPeriodDays を過ぎると削除されるものの一覧です。パスはすべて ~/.claude/ 配下。

パス内容
projects/<project>/<session>.jsonlセッションの全会話トランスクリプト（メッセージ・ツール呼び出し・ツール結果すべて）
projects/<project>/<session>/subagents/サブエージェントの会話トランスクリプト（親セッションの期限切れと一緒に削除）
projects/<project>/<session>/tool-results/サイズの大きいツール出力の退避ファイル
file-history/<session>/チェックポイント復元用の編集前ファイルスナップショット（直近100チェックポイント分）
plans/プランモードで書き出されたプランファイル
debug/--debug 起動時や /debug 実行時のみ書かれるデバッグログ
paste-cache/, image-cache/大きいペースト内容・添付画像の中身
session-env/セッションごとの環境メタデータ
tasks/タスクツールが書き出すセッションごとのタスクリスト
shell-snapshots/起動時に取得したエイリアス・関数・シェルオプション
backups/設定移行前に取られた ~/.claude.json のバックアップ
feedback-bundles//feedback が書き出す編集済みトランスクリプトアーカイブ
usage-data//insights が生成する report.html とキャッシュ済み分析データ
todos/, statsig/, logs/旧バージョンのレガシーディレクトリ（現行版では書き込まれない）

注目したいのは1行目の projects/<project>/<session>.jsonl です。ここにはツールの実行結果まで含めた会話の全内容が入ります。ファイル読み取りツールが読んだ中身も、Bash が吐いた標準出力も、すべてそのまま記録されます。

shell-snapshots/ は正常終了時に削除されるので、スイープで消えるのは基本的にクラッシュ後の残骸です。todos/ statsig/ logs/ の3つはレガシー扱いで、中身とディレクトリごとまとめて削除されます。昔から Claude Code を使っている環境では、このあたりが残っていることがあります。

スイープの例外（4つ）

年齢ベースのスイープから外れるものが4つあります。

  1. sessions/ — 実行中セッションごとの小さいファイル（同時実行検知・クラッシュ検知用）。年齢では消さず、セッション終了時に個別削除。クラッシュ後の残骸は次回起動時にクリアされる
  2. Auto memory — projects/<project>/memory/ はスイープ対象外。ディレクトリ自体は、保持期間まるごと空だった場合のみ削除される（v2.1.228 より前は、memory 配下のファイルも誤って削除される不具合があった）
  3. Bare mode — claude -p --bare 実行中はスイープが走らない
  4. Paused sweep — 保持期間が安全に判定できない設定エラー時はスイープ自体が停止

2番目は重要で、auto memory は「セッションの記録」ではなく「蓄積された知識」という位置づけなのでしょう。古いバージョンを使っている場合は、この不具合に該当しないかバージョンを確認しておくとよさそうです。

削除されず永続的に残るデータ

一方、cleanupPeriodDays をどれだけ短くしても消えないファイルがあります。

パス内容
history.jsonl入力した全プロンプト（タイムスタンプ・プロジェクトパス付き）。上矢印キーでの履歴呼び出しに使用
stats-cache.json/usage で表示される集計済みトークン・コスト
remote-settings.json組織の managed settings のキャッシュ（起動毎に更新）
cache/changelog.mdchangelog のキャッシュ（バックグラウンドで更新）
policy-limits.json組織のポリシー制限のキャッシュ

history.jsonl は全プロジェクト共有の1ファイル

ここが個人的に一番の発見でした。

トランスクリプト本体である projects/<project>/<session>.jsonl はプロジェクトごとにディレクトリが分かれています。ところが history.jsonl はそうではなく、~/.claude/ 直下に1つだけ存在するグローバルファイルです。使ったことのある全プロジェクトの入力プロンプトが同じファイルに追記され続け、各行の project フィールドでどのプロジェクトの入力かを区別しています。

自分の環境でどうなっているかは、次のコマンドで確認できます。

# 総行数（＝これまで入力したプロンプト数）
wc -l < ~/.claude/history.jsonl

# プロジェクトごとの件数を多い順に集計
jq -r '.project' ~/.claude/history.jsonl | sort | uniq -c | sort -rn

出力はこんな形になります。

  77 /Users/you/work/project-a
  37 /Users/you/work/project-b
  22 /Users/you/work/project-c
  ...

実際に手元で叩いてみると、しばらく使っている環境なら想像以上の行数・プロジェクト数が1ファイルに混在しているはずです。「もう触っていない古いプロジェクトで入力したプロンプト」も、そのまま残り続けています。

cleanupPeriodDays を短くしてもこのファイルは消えません。特定プロジェクト分だけ消したい場合は、次に説明する claude project purge を使います。

手動でのデータ削除: claude project purge

プロジェクト単位で保持データをまとめて削除するコマンドです。

claude project purge ~/work/my-repo --dry-run   # プレビューのみ
claude project purge ~/work/my-repo             # 確認プロンプトつきで削除
claude project purge ~/work/my-repo --yes       # 確認なしで削除（スクリプト用）
claude project purge --all                      # 全プロジェクト分をまとめて削除

削除対象は以下の4つです。

  • projects/ 配下のトランスクリプトと auto memory
  • セッションごとの tasks/、debug/、file-history/
  • history.jsonl 内の該当プロンプト行
  • ~/.claude.json 内のプロジェクトエントリ

history.jsonl は「ファイルごと削除」ではなく「該当プロジェクトの行だけをフィルタして削除」してくれるのがポイントです。--all を渡した場合のみ、ファイルごと削除されます。

なお shell-snapshots/ と backups/ はプロジェクトに紐づかないため対象外で、実行プランに警告が表示されるだけです。

まずは --dry-run で何が消えるかを確認してから実行するのが安全です。

セキュリティ上の注意（平文保存）

冒頭でも触れましたが、トランスクリプトと履歴は暗号化されずに保存されます。

ツールが .env を読んだり、実行したコマンドが認証情報を標準出力に吐いたりすると、その値は projects/<project>/<session>.jsonl にそのまま書き込まれます。デフォルトなら30日間、cleanupPeriodDays を伸ばしていればその分だけ、平文でディスクに残るということです。

露出を減らす方法は3つあります。

1. 保持期間を短くする

{
  "cleanupPeriodDays": 7
}

2. 履歴の書き込み自体をスキップする

環境変数 CLAUDE_CODE_SKIP_PROMPT_HISTORY を設定すると、どのモードでもトランスクリプトとプロンプト履歴の書き込みをスキップできます。

export CLAUDE_CODE_SKIP_PROMPT_HISTORY=1

非対話モードでは -p と併用で --no-session-persistence、TypeScript Agent SDK では persistSession: false でも同様のことができます（Python SDK に同等のオプションはありません）。

ただしこれを有効にすると、セッションの再開や上矢印キーでの履歴呼び出しもできなくなるので、常用するというより「機密情報を扱うセッションだけ」といった使い分けが現実的でしょう。

3. permission rules で読み取りを拒否する

そもそも認証情報ファイルを読ませないのが根本的な対策です。permission rules で .env などの読み取りを denyしておけば、トランスクリプトに書き込まれること自体を防げます。

Anthropic 側のデータ保持ポリシー

ローカルだけでなく、サーバー側の保持期間も整理しておきます。

ユーザー種別データ利用でモデル改善に協力保持期間
Consumer（Free/Pro/Max）許可あり5年
Consumer（Free/Pro/Max）許可なし30日
Commercial（Team/Enterprise/API）標準30日
Commercial（Enterprise、対象組織のみ）Zero Data Retentionサーバー側保存なし

ローカルキャッシュについては、公式ドキュメントでも「~/.claude/projects/ 配下にセッション再開のためプレーンテキストでデフォルト30日保持」と明記されています。cleanupPeriodDays のデフォルト値と一致しますね。

Consumer プランでモデル改善への協力を許可している場合の5年は、意識しておいたほうがよい数字だと思います。

参考リンク

まとめ

  1. 保持期間: settings.json の cleanupPeriodDays（デフォルト30日、最小1）。orphaned worktree の削除判定にも共用される
  2. 自動削除される: トランスクリプト、サブエージェント、ツール結果、ファイルスナップショット、各種キャッシュ
  3. 例外は4つ: sessions/、auto memory、bare mode、設定エラーによる pause
  4. 消えないもの: history.jsonl（全プロジェクト共有の1ファイル）、stats-cache.json など
  5. 手動削除: claude project purge <path>。まずは --dry-run で確認
  6. 平文保存: 認証情報の露出対策は、保持期間の短縮・CLAUDE_CODE_SKIP_PROMPT_HISTORY・permission rules の3本立て

~/.claude/ は普段あまり覗かないディレクトリですが、一度 jq で history.jsonl を集計してみると「こんなに残っていたのか」と実感できます。棚卸しのきっかけとしておすすめです。