Claude Code löscht den Verlauf nach 30 Tagen: So speicherst du ihn

Hilfe zur Nutzung des Dienstes findest du in der Ailoot-Dokumentation.

Löscht Claude Code deinen Sitzungsverlauf wirklich?#

Du öffnest Claude Code, um zu einer Sitzung von vor zwei Monaten zurückzukehren – und sie ist verschwunden. Die Datei wurde vollständig von der Festplatte gelöscht. Das ist weder eine Störung noch ein seltener Fehler: So funktioniert der standardmäßige Bereinigungsmechanismus.

Eine Einstellung steuert die Bereinigung: cleanupPeriodDays. Ihr Standardwert ist 30. Jedes Mal, wenn Claude Code startet, durchsucht es den Verlaufsordner und löscht alles, was älter als dieser Zeitraum ist. Diese Einstellung fehlte in meiner ~/.claude/settings.json vollständig. Deshalb galt der Standardwert, und einige meiner älteren Sitzungen waren bereits verschwunden.

Im Repository von Anthropic sind mehrere Fehlerberichte dazu offen, und keiner davon wurde behoben.

Wo speichert Claude Code den Sitzungsverlauf?#

Deinen Verlauf findest du ganz einfach. Öffne ein Terminal und sieh dir den Inhalt des Ordners an:

ls ~/.claude/projects/

Jeder Unterordner steht für ein eigenes Projekt. Sein Name codiert den Pfad: Ein Projekt unter /Users/alex/dev/shop erhält beispielsweise den Ordnernamen -Users-alex-dev-shop. Darin befinden sich die Sitzungsdateien:

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← eine Sitzung = eine Datei
# a91b7d40-....jsonl

Jede .jsonl-Datei ist ein zeilenweises Protokoll: Eine Zeile entspricht einem Sitzungsereignis. Sie enthält mehr als den Gesprächstext. Darin steckt die Logik hinter deinen Entscheidungen: warum du eine bestimmte Datenbankstruktur gewählt hast, welche Optionen du verworfen hast, wo Claude einen Fehler gemacht hat und wie du ihn korrigiert hast.

Im Grunde ist es ein Entwicklungsjournal für dein Projekt. Deshalb tut der Verlust so weh: Du verlierst keinen „Chat“, sondern den Kontext, den du über Wochen aufgebaut hast. Wie dieser Kontext strukturiert ist, habe ich in der Anleitung „Claude Memory vs. CLAUDE.md“ beschrieben.

Warum löscht Anthropic Transkripte nach 30 Tagen?#

Für die Löschung gibt es eine Begründung, und die sollte man verstehen, bevor man sie vollständig deaktiviert. Ein Transkript ist Klartext. Wenn Claude während einer Sitzung eine .env-Datei gelesen, einen Schlüssel in einen Befehl eingefügt oder du ein Passwort in einen Prompt kopiert hast, steht all das als Klartext in der .jsonl-Datei. Je länger eine solche Datei auf der Festplatte bleibt, desto größer ist die Wahrscheinlichkeit, dass sie eines Tages in falsche Hände gerät.

Anthropic formuliert es klar: Transkripte können Quellcode, Zugangsdaten und anderes sensibles Material enthalten. Sie länger als nötig auf der Festplatte zu behalten, birgt ein echtes Datenschutzrisiko. Der Zeitraum von 30 Tagen wurde als Kompromiss gewählt.

Die Einwände der Community betreffen drei Punkte: Die Löschung erfolgt still (weder bei der Einrichtung noch beim Start gibt es eine Warnung), es wird keine Zustimmung eingeholt (du wirst nicht gefragt), und es gibt keine Wiederherstellung (der Papierkorb wird nicht verwendet, und ein Zurücksetzen ist nicht möglich). In Issue #59248 fordern Entwickler eine faire Bereinigung: mit Warnung, einer Wiederherstellungsfrist und einem weniger aggressiven Standardzeitraum.

Warum kann ein Backup-Skript selbst die Löschung auslösen?#

Das ist der kniffligste Teil und bringt viele ins Stolpern, die ihre Daten selbst schützen wollen. Die Bereinigung prüft die mtime, also den Zeitstempel der letzten Dateiänderung. Sie geht davon aus, dass die mtime widerspiegelt, wann du zuletzt in der Sitzung gearbeitet hast. In der Praxis kann alles die mtime ändern: ein Dropbox- oder iCloud-Synchronisierungsclient, rsync, Antivirensoftware, ein Indexer oder dein eigenes Backup-Skript.

Hier liegt die Falle: Du willst deinen Verlauf sichern und richtest eine Cloud-Synchronisierung für ~/.claude/projects/ ein. Irgendwann schreibt der Synchronisierungsdienst eine Datei neu und setzt ihre mtime auf ein früheres Datum zurück (das kann passieren, wenn aus einer Cloud-Kopie wiederhergestellt wird). Claude Code sieht beim Start eine „alte“ Datei und löscht sie. Du wolltest sie sichern, hast ihre Löschung aber beschleunigt.

Daraus folgt nur eines: Das Backup muss außerhalb von ~/.claude/projects/ liegen. Die Bereinigung wirkt nur innerhalb dieses Ordners. Eine außerhalb gespeicherte Kopie ist für die Bereinigung unerreichbar. Darauf baue ich die Lösung auf.

Wie kannst du die Löschung des Verlaufs sofort stoppen?#

So stoppst du die Löschung in drei Schritten:

1. Öffne die Einstellungsdatei: ~/.claude/settings.json (wenn die Datei nicht existiert, erstelle sie).
2. Füge die Einstellung cleanupPeriodDays mit einem großen Wert hinzu:

{
  "cleanupPeriodDays": 3650
}

3. Speichere die Datei. Die Einstellung wird beim nächsten Start von Claude Code wirksam.

Der Wert 3650 entspricht zehn Jahren: In der Praxis findet keine Löschung mehr statt. Wenn du die Bereinigung beibehalten, aber mehr Zeit haben möchtest, setze den Wert auf 365 (ein Jahr); dann verschwinden nur Sitzungen, die älter als ein Jahr sind. Mit diesem Befehl kannst du prüfen, ob die Einstellung übernommen wurde:

grep cleanupPeriodDays ~/.claude/settings.json

Ein leicht zu übersehender Vorbehalt: Eine Verlängerung des Zeitraums stellt NICHT wieder her, was bereits gelöscht wurde. Die Bereinigung läuft beim Start, und alles, was in früheren Durchläufen gelöscht wurde, ist endgültig verschwunden. Deshalb solltest du diese Einstellung zuerst setzen: Sie verhindert künftige Verluste, bringt aber bereits Gelöschtes nicht zurück. Wenn du deinen Claude-Code-Verlauf und dein Projekt vor einem versehentlichen Befehl schützen möchtest, lies auch die Anleitung „Claude Code so konfigurieren, dass dein Projekt geschützt bleibt“.

Dein Sitzungsverlauf ist Teil des zweiten Gehirns deines Projekts: Er enthält Entscheidungslogik, die du nirgendwo sonst festgehalten hast. cleanupPeriodDays bewahrt die Dateien, macht daraus aber noch kein System, mit dem du in sechs Monaten findest, was du brauchst.

Wie archivierst du Verlauf automatisch außerhalb des bereinigten Ordners?#

Die Idee ist einfach: Claude Code kann mit seinem Ordner machen, was es will, während du außerhalb davon ein separates Archiv aufbewahrst. Es ist vor diesem Bereinigungsmechanismus geschützt, kann aber durch Laufwerksfehler, versehentliches Löschen oder fehlgeschlagene Kopien verloren gehen. Richte es so ein:

1. Erstelle einen Archivordner außerhalb des verwalteten Verzeichnisses:

mkdir -p ~/claude-history-archive

2. Kopiere deinen aktuellen Verlauf dorthin. Das Flag -a erhält Struktur und Zeitstempel; --ignore-existing lässt bereits kopierte Dateien unverändert:

rsync -a ~/.claude/projects/ ~/claude-history-archive/

3. Automatisiere den Lauf einmal täglich. Verwende unter macOS launchd. Erstelle die Datei ~/Library/LaunchAgents/com.example.claudearchive.plist:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.claudearchive</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/rsync</string>
    <string>-a</string>
    <string>/Users/YOUR_NAME/.claude/projects/</string>
    <string>/Users/YOUR_NAME/claude-history-archive/</string>
  </array>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

4. Lade den Agenten, damit er im Hintergrund läuft:

launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist

Unter Linux erledigst du dasselbe mit einer Zeile in der Crontab (crontab -e):

0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/

Warum funktioniert das, während die Synchronisierung aus dem vorherigen Abschnitt scheitert? Das Archiv liegt AUSSERHALB von ~/.claude/projects/, sodass die Bereinigung es gar nicht sehen kann. Kopiert wird nur in eine Richtung (vom aktiven Ordner ins Archiv), und wir ändern die mtime der aktiven Dateien nicht – der mtime-Fehler tritt also nicht auf. Selbst wenn Claude Code morgen eine Sitzung aus seinem eigenen Ordner löscht, bleibt ihre Kopie im Archiv erhalten.

Wie kannst du dein Sitzungsarchiv in ein durchsuchbares zweites Gehirn verwandeln?#

Dateien einfach nur anzusammeln reicht nicht – du musst auch darauf zugreifen können. Zwei Schritte machen das Archiv zu einem funktionierenden Werkzeug.

Erstens: Versioniere es mit git. Initialisiere ein Repository im Archivordner:

cd ~/claude-history-archive
git init
git add -A && git commit -m "Erster Schnappschuss des Claude-Code-Verlaufs"

Füge git add -A && git commit zum selben täglichen Lauf wie rsync hinzu. Jetzt hast du einen Versionsverlauf: Du kannst sehen, was wann hinzugekommen ist, und mit einem Befehl ein versehentliches Überschreiben rückgängig machen.

Zweitens: Suche. .jsonl-Dateien sind zeilengetrenntes JSON, deshalb kannst du vertraute Werkzeuge dafür verwenden. Finde heraus, in welcher Sitzung ein bestimmtes Thema besprochen wurde:

grep -rl "Datenbankmigration" ~/claude-history-archive/

Extrahiere nur den Text deiner Prompts aus einer Sitzung (mit jq, da es sich um JSON handelt):

jq -r 'select(.type=="user") | .message.content' session.jsonl

Damit beginnt dein Sitzungsverlauf als zweites Gehirn für dein Projekt zu funktionieren: als Datenbank, in der du in Sekunden nachschlagen kannst, „wie wir das im März entschieden haben“. Eine separate Erklärung dazu, wohin der Kontext während einer Sitzung wandert und wie du ihn verwaltest, findest du in „Wohin die Tokens in Claude Code gehen“.

Kannst du bereits gelöschte Sitzungen wiederherstellen?#

Die ehrliche Antwort: wahrscheinlich nicht. Claude Code bietet keine Wiederherstellungsfunktion, keinen Papierkorb und kein Rücksetzungsprotokoll für gelöschte Transkripte. Die Datei verschwindet einfach von der Festplatte.

Es gibt eine Möglichkeit: System-Backups, sofern sie vorher aktiviert wurden:

1. macOS Time Machine – wenn ein Snapshot ~/.claude/projects/ vor der Löschung erfasst hat, kannst du die Datei aus dem Backup für das gewünschte Datum abrufen.
2. Versionsverlauf von OneDrive / Dropbox – wenn der Ordner mit aktivierter Versionierung synchronisiert wurde, suche die Datei im Versionsverlauf der Cloud (denk aber an die mtime-Falle: Die Synchronisierung kann die Löschung ebenfalls ausgelöst haben).
3. Manuelle Kopien – jedes rsync/cp, das du manuell an einen Ort außerhalb des verwalteten Ordners ausgeführt hast.

Wenn es nichts davon gab, ist die Sitzung verloren. Und das kommt durchaus vor: Bei einem Fehler im Repository von Anthropic wurden laut einem Autor 26 von 38 Aufzeichnungen beschädigt – das entsprach monatelanger Arbeit. Der einzig zuverlässige Schutz ist der, der VOR dem Verlust eingerichtet wurde. Setze cleanupPeriodDays und die automatische Archivierung heute auf, solange es noch etwas zu sichern gibt.

Welchen Wert solltest du für cleanupPeriodDays wählen?#

Es gibt eine Einstellung, aber sie kann Verschiedenes bedeuten. Vergleiche die Optionen und wähle die passende für deinen Anwendungsfall:

Ein wichtiger Sicherheitshinweis: Wenn du 3650 einstellst und alles aufbewahrst, erklärst du dich damit einverstanden, Transkripte, die möglicherweise Schlüssel und Code enthalten, auf der Festplatte zu speichern. Das ist ein bewusster Kompromiss zwischen dem Komfort des Archivs und dem Risiko. Minimiere das Risiko: Bewahre das Archiv auf einem verschlüsselten Laufwerk auf (FileVault unter macOS), lege es nicht in einer öffentlichen Cloud ab und committe es nicht in ein öffentliches git-Repository. Eine separate Anleitung dazu, welche Daten über Claude Code offengelegt werden können, findest du hier: „Datensicherheit in Claude Code“.

Was du heute tun solltest: Checkliste#

Richte den Schutz Schritt für Schritt ein:

1. Setze cleanupPeriodDays: 3650 in ~/.claude/settings.json – damit ist die Aufbewahrungsfrist verlängert.
2. Erstelle ~/claude-history-archive außerhalb des verwalteten Ordners und führe den ersten rsync -a-Lauf aus.
3. Plane einen täglichen Lauf mit launchd (macOS) oder cron (Linux).
4. Initialisiere git im Archiv und füge git add -A && git commit zum selben Lauf hinzu.
5. Prüfe, dass das Archiv auf einem verschlüsselten Laufwerk liegt und nicht mit einer öffentlichen Cloud synchronisiert wird.
6. Prüfe jeden geplanten Lauf auf eine erfolgreiche Kopie. Öffne eine aktuelle archivierte Sitzung und stelle regelmäßig eine Probe in einem separaten temporären Ordner wieder her, um Lesbarkeit zu bestätigen.
7. Soll auch Geräte- oder Laufwerksverlust abgedeckt sein, halte ein unabhängig gespeichertes Backup mit passenden Zugriffsrechten vor und teste dessen Wiederherstellung. Git-Historie auf demselben Laufwerk ist kein unabhängiges Backup.

Der Sitzungsverlauf ist nur eine Ebene des Kontexts, die Claude verlässlich macht.

Lerne Ailoot kennen.