Claude Codeの.claudeディレクトリに残るデータの消し方

~/.claudeにはユーザーが書くCLAUDE.mdやsettings.jsonとは別に、Claude Codeが動作中に書き込むデータが溜まります。その大半はcleanupPeriodDaysの掃除で期限が来れば消えますが、期限に関係なく残り続けるファイルも一定数あります。どれが自動で消え、どれが消えず、消えないものをどう手動で片付けるかを見ていきます。

自分で書いて編集する設定ファイルと、Claude Codeが動作の結果として書き込むデータは別物です。管理者だけが触れるエンタープライズ設定(OSごとに固定パスへ置く管理ファイル)、プロジェクトルートに手動で作る個人用のローカルメモ、claude pluginコマンドが管理するプラグインのクローンやキャッシュは、いずれも人がその内容を決めて配置する設定であり、本記事が扱う「Claude Codeが勝手に書き足していくデータ」には含めません。この記事の対象は、あなたが何も指示しなくてもセッションを重ねるだけで溜まっていく方のデータです。

~/.claudeのデータは2種類に分かれる

~/.claude配下のデータは平文です。ツールが読んだファイルの中身、コマンドの出力、貼り付けたテキストなど、ツール呼び出しを通過したものはすべてどこかのトランスクリプトに記録されます。このうちprojects/配下のセッショントランスクリプトやチェックポイント、デバッグログなどはcleanupPeriodDays(既定30日)の対象で、日数が過ぎれば起動時の掃除で削除されます。自動削除の対象・条件・OpenTelemetryでの監視方法はClaude Code cleanupPeriodDaysでデータの保持期間を変えるにまとめているため、本記事では扱いません。ここで扱うのは、その掃除の対象から外れ、自分で消さない限り残り続けるデータです。

消えずに残るファイル一覧

保持期間の掃除が触らないパスは次のとおりです。ログアウト時に削除される2つのキャッシュを除き、~/.claude配下に置かれたまま蓄積します。

これとは別に、機能ごとに現れる残すべき状態ファイルがあります。キャッシュではなく実体そのものなので、消すとその機能自体が使えなくなる点が、これまでのキャッシュ類とは決定的に違います。.credentials.jsonはログイン認証情報そのもので、消せば/loginからのやり直しになります。agent-memory/はサブエージェントがセッションをまたいで蓄積する永続メモリで、消せばそのサブエージェントは積み重ねてきた文脈を失った状態から再スタートします。失った永続メモリを自動で埋め合わせる再構築手段は無く、以後のセッションでまた一から積み直すことになります。jobs/とdaemon/はバックグラウンドセッションが自分の状態を保持する場所で、実行中に消すとそのバックグラウンドセッション自体が孤立しかねません。

日数管理でも永続でもない、3つの中間的な扱い

前節までの二分法(日数で消える/消えずに残る)には収まらないデータが3種類あります。

sessions/は実行中セッションを1つにつき1ファイルで表す、並行起動やクラッシュを検知するための仕組みです。日数による掃除の対象ではなく、セッションが正常終了した時点でそのファイルが個別に削除されます。クラッシュで残った分は次回起動時にまとめて片付けられます。

自動メモリ(projects/<project>/memory/配下)は、cleanupPeriodDaysの掃除でファイル単位に消えることはありません。ディレクトリが保持期間まるごと空であり続けた場合に限り、ディレクトリ自体が削除されます。v2.1.228より前のバージョンには、このメモリディレクトリの中身をセッションデータと誤認して、中の古いファイルまで消してしまう不具合がありました。

Claude DesktopとCoworkで開始・継続した会話のトランスクリプトは、既定では年齢に関係なく保持されます。年齢上限を設けたい場合はdesktopSessionCleanupPeriodDaysを設定しますが、実際の削除タイミングはこの値とcleanupPeriodDaysの両方を超えた時点です。既定の30日のままdesktopSessionCleanupPeriodDaysだけを7に縮めても、30日までは保持され続けます。組織がmanaged settingsでcleanupPeriodDaysを配布している場合、Claude Code v2.1.248以降ではその値がこのdesktopSessionCleanupPeriodDaysの代わりに直接適用されます(それより前のバージョンでは、そもそもDesktop/Coworkトランスクリプトを無期限保持する特別扱いが無く、cleanupPeriodDaysの値がそのまま使われていました)。

平文保存であることのリスクをどう抑えるか

トランスクリプトと履歴は保存時に暗号化されません。保護はOSのファイルパーミッションだけです。.envファイルをツールが読んだり、コマンドが認証情報を標準出力に出したりすると、その値はそのままセッションのトランスクリプトに書き込まれます。リスクを抑える手段は主に4つです。

• cleanupPeriodDaysを短くして、トランスクリプトを残す期間そのものを縮める
• desktopSessionCleanupPeriodDaysを設定し、Claude DesktopとCoworkのトランスクリプトにも年齢上限を設ける(既定では無期限に保持される)
• CLAUDE_CODE_SKIP_PROMPT_HISTORY環境変数で、どのモードでもトランスクリプトとプロンプト履歴の書き込み自体を止める。非対話モード限定なら-pと組み合わせる--no-session-persistenceフラグや、TypeScript版Agent SDKのpersistSession: falseでも同じことができる(Python SDKには相当するオプションが無い)
• 認証情報ファイルの読み取りを権限ルールで拒否する

最後の手段は運用の入口を絞る対処です。.envファイルや認証情報を置いたディレクトリへのReadをpermissions.denyで塞いでおけば、そもそもトランスクリプトに機密情報が乗る経路自体を断てます。設定を変える前に、まずどのディレクトリに秘密情報を置いているかを棚卸ししておくと、拒否ルールを漏れなく書けます。

書き込みを止める設定は--resumeによるセッション再開を犠牲にします。保持期間を縮めるだけで足りるか、書き込み自体を止める必要があるかは、セッション再開機能をどれだけ使うかで判断します。日常的に数日前のセッションへ戻る使い方をしているなら書き込みは止めずcleanupPeriodDaysの調整だけにとどめ、機密性の高いリポジトリを一時的に開くだけの短時間作業なら書き込み自体を止める、という使い分けが実務的です。

1プロジェクト分をコマンドでまとめて消す

蓄積したデータをプロジェクト単位でまとめて消したい場合、claude project purgeコマンドが用意されています。何が消えるかを先に確認できるドライランがあります。

claude project purge ~/work/my-repo --dry-run

このコマンドは対象パスに一致する状態が無いとエラー終了(status 1)します。実行すると、削除対象と削除理由を含む計画が表示されます。主な対象は次の4種類です。

• プロジェクトのトランスクリプトとmemory/ディレクトリ
• セッションごとのtasks/・debug/・file-history/エントリ
• ~/.claude.json内のプロジェクトエントリ(信頼設定・履歴・MCPサーバー)
• history.jsonlのうち該当プロジェクトの行

shell-snapshots/はプロジェクト単位のデータではないため対象外、backups/にも古い~/.claude.jsonのスナップショット経由でプロジェクト情報が残っている可能性があると計画に注記されます(最新5世代のみ保持され、自動でローテーションします)。つまり直近5世代のbackups/には、project purgeで消したはずのプロジェクト情報が削除前の状態のまま残っている点に注意が必要です。

実際に削除するには--dry-runを外すだけです。

claude project purge ~/work/my-repo

確認プロンプトが1回出て、yと答えたときだけ削除が実行されます。パスを省略すると対話的なプロジェクト一覧から選べます。スクリプトから使う場合は--yesで確認を省略、削除計画を1項目ずつ確認しながら進めたい場合は-iを使います。使い分けの判断軸は取り消せるかどうかです。CIやcronなど無人実行では--yesで止めずに進め、--allのように対象が広く取り消せない一括操作では-iで1項目ずつ確認しながら進めるのが安全です。--allを渡すとパス指定を1つのプロジェクトに絞らず、全プロジェクト分をまとめて対象にできます。この場合history.jsonlはプロジェクトごとの行だけをフィルタするのではなく、ファイルごと削除される点が単一プロジェクト指定との違いです。

パスを直接消してよいもの・いけないもの

claude project purgeを使わず、個々のパスを直接削除することもできます。前節の「残すべき状態ファイル」を除けば、~/.claude配下のパスはどれも新しいセッションの動作を妨げずに削除できます。ただし過去のセッションについて失うものはパスごとに異なります。

~/.claude.json・~/.claude/settings.json・~/.claude/plugins/の3つだけは削除しないでください。認証情報・個人設定・インストール済みプラグインを保持しているため、消すとログインや設定、プラグインの再構築が必要になります。

退職・PC譲渡のときはどこまで消せば十分か

契約終了者のPCを回収したり、開発機を別の担当者に引き継いだりする場面では、プロジェクト単位のclaude project purge --allだけでは足りません。shell-snapshots/やbackups/はプロジェクト単位のデータではないため、project purgeの対象から明示的に外れているからです。マシンそのものを渡す・初期化するなら、~/.claudeディレクトリごと削除するか、OS標準のディスク消去手順に委ねるのが確実です。逆に「このプロジェクトの痕跡だけ消えていればよい」場合はproject purgeで足り、~/.claude.json・settings.json・plugins/をそのまま残して次の担当者が使い続けられる状態にできます。どちらの状況かによって、選ぶコマンドと確認すべき範囲がまるごと変わる点を最初に切り分けておくと、消し忘れも消しすぎも避けられます。

よくある質問

history.jsonlを消すとプロンプトの中身がどこかに残るか

残りません。history.jsonlはローカルの~/.claude配下だけに存在するファイルで、削除すれば入力履歴機能そのものが空の状態から再開します。ただし各セッションのトランスクリプト(projects/配下)には別途プロンプトが記録されているため、両方消さない限り完全には消えません。

まとめ

~/.claudeのデータは、cleanupPeriodDaysで期限管理される種類と、history.jsonlやstats-cache.jsonのように期限に関係なく残り続ける種類に分かれます。後者を片付けたい場合、プロジェクト単位でまとめて消すならclaude project purge、個別のキャッシュだけを消すなら該当パスを直接削除して構いません。~/.claude.json・settings.json・plugins/の3つだけは認証・設定・プラグインの実体そのものなので手を出さないことが、この掃除で最初に守るべき境界線です。