config-gc

Config GC — Claude Code 設定のガベージコレクション

ランタイムのガベージコレクションから着想を得て、定期的に参照されなくなったオブジェクト、冗長なオブジェクト、期限切れのオブジェクト、または低価値のオブジェクトをスキャンし、領域を解放します。重要な違いは、ここではコレクションに人間の介入が必要であることです。自律的に削除することは絶対に行わないでください。

いつ有効化するか

• ユーザーが Claude Code の設定をクリーンアップ、監査、またはスリム化したいと言ったとき
• ユーザーがスキルが多すぎる、フックがうるさい、セッション起動が遅いと不満を言ったとき
• 月次/定期的な設定レビューの時期が来たとき
• 大規模なスキルパック（例：このリポジトリ）をインストールした後、既存の設定との重複を調整するため

以下の場合には有効化しないでください：プロジェクトのソースコードのクリーンアップ（それはリファクタリングです）、チャット履歴の消去、Claude Code 自体のアンインストール。

設計思想

1. 追記専用の設定は漏れる。 スキル、メモリファイル、フック、パーミッションエントリは決して追加されるだけで削除されることはありません。定期的なレビューがなければ、静かに腐敗します。
2. 定期的な監査が一括パージよりも優れている。 約30日ごとにスキャンし、毎回少数の候補を提案します。
3. チャネルごとに戦略を変える。 各蓄積タイプ（スキル、フック、パーミッション...）には独自の陳腐化シグナルがあります。すべてに同じルールを適用しないでください。
4. まずソフトデリート。 .disabled へのリネーム > ~/.claude/_gc_trash/ への移動 > 本当の削除。常に元に戻すパスを残してください。
5. 強制的な人間の介入。 各候補には独自の [y/n/skip] 確認が必要です。「すべてはい」のショートカットはありません。
6. ログを残す。 GC 実行のたびに ~/.claude/gc_log.md に追記します。何に触れたか、その理由、元に戻す方法を記録します。

スキャンチャネル

#	チャネル	パス	陳腐化/冗長性シグナル
1	スキル	~/.claude/skills/*/	名前が大きく重複している；最近のトランスクリプトで一度もトリガーされていない；ユーザーの実際の作業とドメインが一致しない；SKILL.md が壊れているか空である
2	メモリ	~/.claude/**/memory/*.md + そのインデックス	1つのトピックに複数のインデックスエントリがある；内容が新しいエントリと矛盾している；日付が過ぎている；インデックスから欠落している孤立ファイルがある；マージすべき100語未満の断片がある
3	フック	~/.claude/hooks/ + 設定	ディスク上に存在するが、どのフック設定からも参照されていないスクリプトがある；書き換えによって置き換えられた古いバージョンがある
4	パーミッション	settings.json / settings.local.json 内の permissions.allow	重複エントリ；ワイルドカードで既にカバーされている特定のエントリ（例：Bash(*) が許可されている場合の Bash(git push)）；過去の実験からの一回限りの許可
5	MCP サーバー	~/.claude.json またはプロジェクトの .mcp.json	接続に失敗するサーバー；機能的に重複しているサーバー；長期間使用されていないサーバー
6	スケジュールされたリマインダー/ジョブ	ユーザーが保存している場所	30日以上前に発火したワンショット；対象のスクリプトがもう存在しないジョブ
7	プロジェクト履歴	~/.claude/projects/*/	古いハンドオフスナップショット；新しい状態によって置き換えられたセッションレコード
8	ランタイムキャッシュ	cache/, file-history/, logs/, shell-snapshots/	サイズと更新時刻でソート；30日以上経過していてサイズが大きいアイテムを提案する

ワークフロー

1. スキャン すべてのチャネル（またはユーザーが指定したサブセット）をスキャンします。候補を収集し、パス、チャネル、フラグを立てたシグナル、サイズ、最終更新日を記録します。
2. ランク付け 信頼度でランク付けします（壊れている/孤立している = 高；単に古い = 低）。番号付きの表で提示します。各実行は約20候補に制限します。GC は定期的なものであり、網羅的である必要はありません。
3. 一つずつ確認する。 各候補について証拠を示し、[y/n/skip] を尋ねます。ユーザーはいつでも停止できます。
4. 確認されたアイテムをソフトデリートする：スキルとフックには .disabled へのリネームを、ファイルには _gc_trash/<date>/ への移動を優先します。パーミッションエントリは JSON 内に存在します（コメントは不可）：設定ファイルをバックアップし、削除した各エントリを gc_log.md に逐語的に記録してから、jq で allow 配列から削除します。ユーザーが明示的に要求した場合にのみハードデリートします。
5. ログを記録する ~/.claude/gc_log.md に実行を記録します：タイムスタンプ、処理したアイテム、元に戻す手順。
6. 報告する：回収したサイズ、健康なチャネル、推奨される次回のレビュー日を報告します。

スキャンコマンドの例

孤立したフックスクリプト（チャネル3）— ディスク上に存在するが、どのフック設定からも参照されていないスクリプト：

for f in ~/.claude/hooks/*; do
  name=$(basename "$f")
  grep -rq "$name" ~/.claude/settings.json ~/.claude/settings.local.json 2>/dev/null \
    || echo "ORPHAN: $f"
done

冗長なパーミッションエントリ（チャネル4）— 重複、およびワイルドカードによって隠蔽された特定の許可：

jq -r '.permissions.allow[]' ~/.claude/settings.local.json | sort | uniq -d
if jq -e '.permissions.allow | index("Bash(*)")' ~/.claude/settings.local.json >/dev/null; then
  jq -r '.permissions.allow[]' ~/.claude/settings.local.json \
    | grep '^Bash(' | grep -vF 'Bash(*)'
fi

最大の古いキャッシュ（チャネル8）— GNU 独自の find -printf の代わりに du -k を使用するため、macOS/BSD でも動作します：

find ~/.claude/file-history ~/.claude/shell-snapshots -type f -mtime +30 \
  -exec du -k {} + 2>/dev/null | sort -rn | head -20

元に戻せるソフトデリート（ログがディレクトリと矛盾しないように、日付を一度だけ取得）：

gc_date=$(date +%Y-%m-%d)
mkdir -p ~/.claude/_gc_trash/$gc_date
mv ~/.claude/skills/dead-skill ~/.claude/_gc_trash/$gc_date/
echo "$(date -Iseconds) moved skills/dead-skill -> _gc_trash/$gc_date/ (undo: mv back)" >> ~/.claude/gc_log.md

確認済みの冗長パーミッションエントリの削除（JSON にはコメントがありません — バックアップ、ログ、そして編集）：

cp ~/.claude/settings.local.json ~/.claude/settings.local.json.bak
echo "$(date -Iseconds) removed permission entry: Bash(git push) (undo: restore from .bak or re-add)" >> ~/.claude/gc_log.md
jq '.permissions.allow -= ["Bash(git push)"]' ~/.claude/settings.local.json.bak \
  > ~/.claude/settings.local.json

アンチパターン

• 一括承認。「15個すべて削除しますか？ [y/n]」と尋ねるのは設計に反します。1アイテム、1判断です。
• 最初のパスでハードデリート。 _gc_trash/ コピーや .disabled リネームがなければ、やり方を間違えています。
• 「古い」を「死んでいる」と見なす。 60日間触れられていないスキルは、季節的なもの（確定申告シーズン、四半期レビュー）である可能性があります。経過時間はシグナルであって、断定ではありません。だからこそ人間が確認するのです。
• メモリを切り詰めてクリーンアップする。 矛盾する2つのメモリファイルをマージするには、両方を読み、新しい方の真実を保持する必要があります。長い方のファイルを削除するのではありません。
• ~/.claude（またはプロジェクトの .claude/）の外部に手を出す。 Config GC がソースツリーに迷い込むことは決してありません。

ベストプラクティス

• 大きな追加の後に実行します。カレンダーベースだけでなく。50個のスキルパックをインストールするときは、まさに既存のスキルとの重複が現れるときです。
• 2つのスキルが重複する場合、トリガーの説明が弱い方のスキルを無効にすることを優先します。おそらく、それはそもそも一度も発動していなかったスキルだからです。
• パーミッションのクリーンアップは、費やす時間あたりの価値が最も高いチャネルです。冗長な許可エントリはセキュリティレビューを困難にします。
• gc_log.md は永久に保持します。サイズはごくわずかで、「あのフックをいつ、なぜ無効にしたか」という質問は想像以上によく出てきます。

関連スキル

• skill-stocktake — スキルの品質を監査します。config-gc はスキルの存在を監査します。GC を生き残ったスキルに対して stocktake を実行します。
• workspace-surface-audit — 追加の対となるスキルです。何をインストールすべきかを推奨します。config-gc は同じライフサイクルの削減側です。
• configure-ecc — これを使ってスキルをインストールした後、config-gc を実行して既存の設定との重複を調整します。
• continuous-learning — このスキルが後で監査するメモリファイルを生成します。
• security-review — パーミッションチャネルとよく組み合わせます。