config-gc

Config GC – Garbage Collection für Claude Code-Installationen

Entlehnt aus der Laufzeit-Garbage Collection: Periodisch nach Objekten suchen, die nicht mehr referenziert, redundant, abgelaufen oder von geringem Wert sind, und den Speicherplatz zurückgewinnen. Der entscheidende Unterschied: Hier ist ein Mensch im Loop – niemals autonom löschen.

Wann aktivieren

• Der Benutzer bittet um Bereinigung, Audit oder Verschlankung seiner Claude Code-Konfiguration
• Der Benutzer beschwert sich über zu viele Skills, laute Hooks oder langsamen Sitzungsstart
• Eine monatliche/periodische Konfigurationsüberprüfung steht an
• Nach der Installation eines großen Skill-Pakets (z. B. dieses Repository), um Überschneidungen mit dem bestehenden Setup zu bereinigen

NICHT aktivieren für: Bereinigung von Projektquellcode (das ist Refactoring), Löschen des Chatverlaufs oder Deinstallation von Claude Code selbst.

Design-Philosophie

1. Nur-Ergänzen-Konfigurationen lecken. Skills, Memory-Dateien, Hooks und Berechtigungseinträge werden nur hinzugefügt. Ohne regelmäßige Überprüfung vergammeln sie still.
2. Regelmäßige Audits schlagen einmaligen Bereinigungen. Alle ~30 Tage scannen, jedes Mal eine kleine Liste von Kandidaten vorschlagen.
3. Pro-Kanal-Strategien. Jeder Akkumulationstyp (Skills, Hooks, Berechtigungen, …) hat eigene Veraltungssignale – nicht überall die gleiche Regel anwenden.
4. Soft-Deletes zuerst. Umbenennen in .disabled > Verschieben nach ~/.claude/_gc_trash/ > endgültiges Löschen. Immer einen Rückweg offen halten.
5. Erzwungener Mensch-im-Loop. Jeder Kandidat erhält seine eigene [y/n/skip]-Bestätigung. Keine „Ja zu allen“-Abkürzung.
6. Ein Log führen. Jeder GC-Lauf hängt an ~/.claude/gc_log.md an: Was wurde bearbeitet, warum und wie rückgängig zu machen.

Scan-Kanäle

#	Kanal	Pfad	Veraltungs-/Redundanzsignale
1	Skills	~/.claude/skills/*/	Stark überlappende Namen; nie in aktuellen Transkripten ausgelöst; Domänenkonflikt mit der tatsächlichen Arbeit des Benutzers; defekte oder leere SKILL.md
2	Memory	~/.claude/**/memory/*.md + sein Index	Mehrere Indexeinträge für ein Thema; Inhalte widersprechen neueren Einträgen; abgelaufene Daten; verwaiste Dateien ohne Indexeintrag; unter-100-Wort-Fragmente, die zusammengeführt werden sollten
3	Hooks	~/.claude/hooks/ + Einstellungen	Skripte auf der Festplatte, aber von keiner Hook-Konfiguration referenziert; alte Versionen, die durch Neuschreibungen ersetzt wurden
4	Berechtigungen	permissions.allow in settings.json / settings.local.json	Doppelte Einträge; spezifische Einträge, die bereits von einem Wildcard abgedeckt werden (z. B. Bash(git push) wenn Bash(*) erlaubt ist); einmalige Freigaben aus vergangenen Experimenten
5	MCP-Server	~/.claude.json oder Projekt .mcp.json	Server, die keine Verbindung herstellen können; funktionale Duplikate; lange nicht genutzt
6	Geplante Erinnerungen / Jobs	wo der Benutzer sie aufbewahrt	Bereits ausgelöste Einmalaktionen älter als 30 Tage; Jobs, deren Zielskripte nicht mehr existieren
7	Projekthistorie	~/.claude/projects/*/	Veraltete Übergabe-Snapshots; Sitzungsaufzeichnungen, die durch neueren Zustand ersetzt wurden
8	Laufzeit-Caches	cache/, file-history/, logs/, shell-snapshots/	Sortieren nach Größe und Änderungsdatum; Elemente älter als 30 Tage und groß vorschlagen

Arbeitsablauf

1. Scannen aller Kanäle (oder der vom Benutzer genannten Teilmenge). Kandidaten sammeln mit: Pfad, Kanal, auslösendem Signal, Größe, letzter Änderung.
2. Rangfolge nach Vertrauenswürdigkeit (defekt/verwaist = hoch; nur alt = niedrig) und als nummerierte Tabelle präsentieren. Auf ~20 Kandidaten pro Lauf begrenzen – GC ist periodisch, nicht erschöpfend.
3. Eins nach dem anderen bestätigen. Für jeden Kandidaten die Evidenz zeigen, dann [y/n/skip] abfragen. Der Benutzer kann jederzeit abbrechen.
4. Soft-Delete bestätigter Elemente: .disabled-Umbenennung für Skills/Hooks bevorzugen, _gc_trash/<datum>/-Verschiebung für Dateien. Berechtigungseinträge leben in JSON (keine Kommentare möglich): Einstellungsdatei sichern, jeden entfernten Eintrag wörtlich in gc_log.md notieren, dann mit jq aus dem allow-Array entfernen. Nur hart löschen, wenn der Benutzer es ausdrücklich verlangt.
5. Log des Laufs nach ~/.claude/gc_log.md: Zeitstempel, bearbeitete Elemente, Rückgängig-Anweisungen.
6. Bericht: freigegebene Größe, noch gesunde Kanäle, empfohlenes nächstes Prüfdatum.

Beispiel-Scan-Befehle

Verwaiste Hook-Skripte (Kanal 3) – Skripte auf der Festplatte, die keine Hook-Konfiguration referenziert:

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

Redundante Berechtigungseinträge (Kanal 4) – Duplikate und spezifische Freigaben, die von einem Wildcard überdeckt werden:

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

Größte veraltete Caches (Kanal 8) – du -k statt GNU-only find -printf, damit es auch auf macOS/BSD funktioniert:

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

Soft-Delete mit Rückweg (Datum einmal erfassen, damit das Log nicht mit dem Verzeichnis in Konflikt gerät):

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) verschoben skills/dead-skill -> _gc_trash/$gc_date/ (rückgängig: mv zurück)" >> ~/.claude/gc_log.md

Entfernen eines bestätigt redundanten Berechtigungseintrags (JSON hat keine Kommentare – sichern, loggen, dann bearbeiten):

cp ~/.claude/settings.local.json ~/.claude/settings.local.json.bak
echo "$(date -Iseconds) Berechtigungseintrag entfernt: Bash(git push) (rückgängig: .bak wiederherstellen oder neu hinzufügen)" >> ~/.claude/gc_log.md
jq '.permissions.allow -= ["Bash(git push)"]' ~/.claude/settings.local.json.bak \
  > ~/.claude/settings.local.json

Anti-Patterns

• Massenfreigabe. Die Frage „Alle 15 löschen? [y/n]“ untergräbt das Design. Ein Element, eine Entscheidung.
• Hartlöschen beim ersten Durchlauf. Wenn es keine _gc_trash/-Kopie oder .disabled-Umbenennung gibt, hast du es falsch gemacht.
• „Alt“ mit „tot“ gleichsetzen. Ein Skill, der 60 Tage nicht angerührt wurde, kann saisonal sein (Steuerzeit, Quartalsüberprüfungen). Alter ist ein Signal, kein Urteil – deshalb bestätigt ein Mensch.
• Memory durch Kürzen bereinigen. Das Zusammenführen zweier widersprüchlicher Memory-Dateien erfordert das Lesen beider und das Behalten der neueren Wahrheit, nicht das Löschen der längeren.
• Irgendetwas außerhalb von ~/.claude (oder dem projektbezogenen .claude/) anfassen. Config GC wandert nie in Quellcode-Bäume.

Best Practices

• Nach großen Ergänzungen ausführen, nicht nur nach Kalender: Die Installation eines 50-Skill-Pakets ist genau der Moment, in dem Überschneidungen mit bestehenden Skills auftauchen.
• Wenn sich zwei Skills überschneiden, denjenigen deaktivieren, der die schwächere Trigger-Beschreibung hat – das ist der, der wahrscheinlich ohnehin nie gefeuert hat.
• Berechtigungsbereinigung ist der Kanal mit dem höchsten Wert pro investierter Minute: Redundante Erlaubnis-Einträge erschweren das Sicherheits-Review.
• gc_log.md für immer behalten. Es ist winzig, und „wann habe ich diesen Hook deaktiviert und warum“ taucht öfter auf, als man denkt.

Verwandte Skills

• skill-stocktake – prüft die Skill-Qualität; config-gc prüft die Skill-Existenz. Stocktake auf dem ausführen, was GC überlebt hat.
• workspace-surface-audit – das additive Gegenstück: empfiehlt, was installiert werden soll. config-gc ist der subtraktive Teil desselben Lebenszyklus.
• configure-ecc – nach der Installation von Skills damit config-gc ausführen, um Überschneidungen mit dem bestehenden Setup zu bereinigen.
• continuous-learning – erzeugt die Memory-Dateien, die dieses Skill später prüft.
• security-review – harmoniert gut mit dem Berechtigungs-Kanal.