Claude Code verwijdert de geschiedenis na 30 dagen: zo bewaar je die

Bekijk de Ailoot-documentatie voor hulp bij het gebruik van de service.

Verwijdert Claude Code echt je sessiegeschiedenis?#

Je opent Claude Code om verder te gaan met een sessie van twee maanden geleden — maar die is weg. Het bestand is volledig van de schijf verwijderd. Dit is geen storing of zeldzame bug: zo werkt het standaard opruimmechanisme.

Eén instelling regelt het opruimen: cleanupPeriodDays. De standaardwaarde is 30. Telkens wanneer Claude Code start, scant het de geschiedenismap en verwijdert het alles wat ouder is dan die periode. Deze instelling stond helemaal niet in mijn ~/.claude/settings.json, waardoor de standaardwaarde gold en sommige oudere sessies al verdwenen waren.

In de repository van Anthropic staan hierover verschillende bugmeldingen open, en geen daarvan is opgelost.

Waar slaat Claude Code de sessiegeschiedenis op?#

Je geschiedenis vinden is eenvoudig. Open een terminal en bekijk de inhoud van de map:

ls ~/.claude/projects/

Elke submap is een apart project. De naam codeert het pad: een project in /Users/alex/dev/shop wordt bijvoorbeeld de map -Users-alex-dev-shop. Daarin staan sessiebestanden:

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← één sessie = één bestand
# a91b7d40-....jsonl

Elk .jsonl-bestand is een regel-voor-regellogboek: één regel staat voor één sessiegebeurtenis. Het bevat meer dan alleen de gesprekstekst. Het legt de logica achter je beslissingen vast: waarom je voor een bepaalde databasestructuur koos, welke opties je afwees, waar Claude een fout maakte en hoe je die corrigeerde.

In wezen is het een ontwikkelingsdagboek van je project. Daarom doet het verlies ervan pijn: je verliest niet zomaar een “chat”, maar de context die je in de loop van weken hebt opgebouwd. In de gids “Claude Memory versus CLAUDE.md” heb ik uitgelegd hoe deze context is opgebouwd.

Waarom verwijdert Anthropic transcripten na 30 dagen?#

Er is een reden voor het verwijderen, en die is het waard om te begrijpen voordat je alles uitschakelt. Een transcript is platte tekst. Als Claude tijdens een sessie een .env-bestand heeft gelezen, een sleutel in een opdracht heeft gezet of als jij een wachtwoord in een prompt hebt geplakt, is dat allemaal als platte tekst in het .jsonl-bestand terechtgekomen. Hoe langer zo’n bestand op de schijf blijft staan, hoe groter de kans dat het ooit uitlekt.

Anthropic zegt het duidelijk: transcripten kunnen broncode, inloggegevens en ander gevoelig materiaal bevatten, en die langer dan nodig op de schijf bewaren vormt een reëel privacyrisico. De periode van 30 dagen is als compromis gekozen.

De bezwaren van de gemeenschap betreffen drie dingen: het verwijderen gebeurt stilzwijgend (er is geen waarschuwing tijdens de configuratie of bij het opstarten), er wordt geen toestemming gevraagd (je krijgt geen vraag) en herstel is niet mogelijk (de prullenmand wordt niet gebruikt en terugdraaien kan niet). In issue #59248 vragen ontwikkelaars om één ding: maak het opruimen eerlijker — geef een waarschuwing, een herstelperiode en een minder agressieve standaardtermijn.

Hoe kan een back-upscript zelf het verwijderen veroorzaken?#

Dit is het lastigste deel en het brengt mensen in de problemen die hun gegevens zelf proberen te beschermen. Bij het opruimen wordt gekeken naar de mtime, het tijdstip waarop het bestand voor het laatst is gewijzigd. Er wordt aangenomen dat de mtime aangeeft wanneer je voor het laatst in de sessie hebt gewerkt. In de praktijk kan van alles de mtime veranderen: een Dropbox- of iCloud-synchronisatieclient, rsync, antivirussoftware, een indexeerprogramma of je eigen back-upscript.

Dit is de valkuil. Je besluit je geschiedenis te bewaren en stelt cloudsync in voor ~/.claude/projects/. Op een gegeven moment schrijft de synchronisatieservice een bestand opnieuw en stelt de mtime in op een eerdere datum (dit kan gebeuren wanneer je een bestand uit een cloudkopie terugzet). Claude Code ziet bij het opstarten een “oud” bestand en verwijdert het. Je wilde het bewaren, maar hebt het verwijderen versneld.

Er is maar één conclusie: de back-up moet buiten ~/.claude/projects/ staan. Het opruimen vindt alleen binnen deze map plaats. Een kopie daarbuiten valt buiten het bereik van het opruimmechanisme. Ik bouw de oplossing rond dit principe.

Hoe kun je het verwijderen van geschiedenis nu meteen stoppen?#

Stop het verwijderen in drie stappen:

1. Open het instellingenbestand: ~/.claude/settings.json (maak het aan als het niet bestaat).
2. Voeg de instelling cleanupPeriodDays toe met een hoge waarde:

{
  "cleanupPeriodDays": 3650
}

3. Sla het bestand op. De instelling wordt van kracht wanneer Claude Code de volgende keer start.

De waarde 3650 staat voor tien jaar: in de praktijk wordt er dan niets meer verwijderd. Als je de opruiming wilt behouden maar meer tijd wilt toestaan, stel dan 365 in (één jaar); alleen sessies ouder dan een jaar verdwijnen dan. Met deze opdracht kun je controleren of de instelling is opgepakt:

grep cleanupPeriodDays ~/.claude/settings.json

Een kanttekening die gemakkelijk over het hoofd wordt gezien: de termijn verlengen herstelt NIET wat al is verwijderd. Het opruimen vindt plaats bij het opstarten, en wat tijdens eerdere starts is gewist, is voorgoed weg. Stel dit daarom eerst in: het voorkomt toekomstig verlies, maar brengt niet terug wat al is verwijderd. Als je je Claude Code-geschiedenis én je project tegen een onbedoelde opdracht wilt beschermen, bekijk dan de gids “Claude Code zo configureren dat het je project niet kapotmaakt”.

Je sessiegeschiedenis maakt deel uit van het tweede brein van je project: ze bevat de logica van beslissingen die je nergens anders hebt vastgelegd. cleanupPeriodDays bewaart de bestanden, maar maakt er geen systeem van waarmee je over zes maanden kunt terugvinden wat je nodig hebt.

Hoe archiveer je geschiedenis automatisch buiten de opruimmap?#

Het idee is eenvoudig: laat Claude Code met zijn eigen map doen wat het wil, terwijl jij daarbuiten een apart archief bewaart. Het archief is beschermd tegen dat opruimmechanisme, maar kan nog steeds verloren gaan door schijfuitval, onbedoeld verwijderen of een mislukte kopie. Stel het als volgt in:

1. Maak een archiefmap buiten de beheerde map:

mkdir -p ~/claude-history-archive

2. Kopieer je huidige geschiedenis daarheen. De vlag -a behoudt de structuur en tijdstempels; --ignore-existing laat bestanden die al zijn gekopieerd ongemoeid:

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

3. Automatiseer de uitvoering eenmaal per dag. Gebruik op macOS launchd. Maak het bestand ~/Library/LaunchAgents/com.example.claudearchive.plist aan:

<?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. Laad de agent zodat deze op de achtergrond wordt uitgevoerd:

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

Op Linux doe je hetzelfde met één regel in crontab (crontab -e):

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

Waarom werkt dit wel, terwijl de synchronisatie uit het vorige deel niet werkt? Het archief staat BUITEN ~/.claude/projects/, dus het opruimmechanisme kan het niet zien. Er wordt één kant op gekopieerd (van de actieve map naar het archief), en we wijzigen de mtime van actieve bestanden niet — daardoor treedt de mtime-bug niet op. Zelfs als Claude Code morgen een sessie uit zijn eigen map verwijdert, blijft de kopie in het archief bestaan.

Hoe maak je van je sessiearchief een doorzoekbaar tweede brein?#

Bestanden verzamelen is niet genoeg — je moet ze kunnen raadplegen. Twee stappen maken van het archief een bruikbaar hulpmiddel.

Beheer het eerst met git. Initialiseer een repository in de archiefmap:

cd ~/claude-history-archive
git init
git add -A && git commit -m "First snapshot of Claude Code history"

Voeg git add -A && git commit toe aan dezelfde dagelijkse uitvoering als rsync. Nu heb je een versiegeschiedenis: je kunt zien wat er is verschenen en wanneer, en een onbedoelde overschrijving met één opdracht ongedaan maken.

Zoek daarna in de bestanden. .jsonl-bestanden bevatten JSON met één object per regel, zodat je er vertrouwde hulpmiddelen op kunt gebruiken. Zoek welke sessie een bepaald onderwerp behandelde:

grep -rl "database migration" ~/claude-history-archive/

Extraheer alleen de tekst van je prompts uit een sessie (met jq, omdat het JSON is):

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

Vanaf dit punt gaat je sessiegeschiedenis werken als het tweede brein van een project: een database waarin je binnen enkele seconden kunt terugvinden “hoe we dit in maart hebben besloten”. Bekijk voor een apart overzicht van waar context in een sessie terechtkomt en hoe je die beheert de gids “Waar de tokens naartoe gaan in Claude Code”.

Kun je sessies herstellen die al zijn verwijderd?#

Het eerlijke antwoord: waarschijnlijk niet. Claude Code heeft geen herstelfunctie, geen prullenmand en geen ongedaanmakingslogboek voor verwijderde transcripten. Het bestand verdwijnt gewoon van de schijf.

Er is één mogelijkheid: systeemback-ups, als die vooraf waren ingeschakeld:

1. macOS Time Machine — als een snapshot ~/.claude/projects/ heeft vastgelegd voordat het bestand werd verwijderd, kun je het voor de gewenste datum uit de back-up ophalen.
2. OneDrive / Dropbox-versiegeschiedenis — als de map was gesynchroniseerd met versiebeheer ingeschakeld, zoek dan het bestand op in de versiegeschiedenis van de cloud (maar onthoud de mtime-valkuil: synchronisatie kan het verwijderen ook hebben veroorzaakt).
3. Handmatige kopieën — elke rsync/cp die je handmatig naar een locatie buiten de beheerde map hebt uitgevoerd.

Bestond geen van deze mogelijkheden, dan is de sessie verdwenen. En dat is niet zeldzaam: een auteur van een bugmelding in de repository van Anthropic had 26 van de 38 records beschadigd; dat vertegenwoordigde maanden werk. De enige betrouwbare bescherming is bescherming die al aanwezig is VOORDAT je iets verliest. Stel vandaag cleanupPeriodDays en automatisch archiveren in, zolang er nog iets te bewaren valt.

Welke waarde kies je voor cleanupPeriodDays?#

Er is één instelling, maar die kan verschillende dingen betekenen. Vergelijk de opties en kies wat bij jouw gebruik past:

Een belangrijke kanttekening voor de beveiliging: als je 3650 instelt en alles bewaart, ga je ermee akkoord transcripten met mogelijk sleutels en code op de schijf te bewaren. Dat is een bewuste afweging: gemak van het archief tegenover risico. Beperk het risico: bewaar het archief op een versleutelde schijf (FileVault op macOS), zet het niet in een openbare cloud en commit het niet naar een openbare git-repository. Ik heb een aparte gids opgesteld over welke gegevens via Claude Code kunnen uitlekken: “Gegevensbeveiliging in Claude Code”.

Wat moet je vandaag doen: checklist#

Stel de bescherming stap voor stap in:

1. Stel cleanupPeriodDays: 3650 in ~/.claude/settings.json in — het verwijderen is gestopt.
2. Maak ~/claude-history-archive buiten de beheerde map aan en voer de eerste rsync -a uit.
3. Plan een dagelijkse uitvoering met launchd (macOS) of cron (Linux).
4. Initialiseer git in het archief en voeg git add -A && git commit aan dezelfde uitvoering toe.
5. Controleer of het archief op een versleutelde schijf staat en niet met een openbare cloud wordt gesynchroniseerd.
6. Controleer elke geplande run op een geslaagde kopie, bekijk daarna een recente gearchiveerde sessie en herstel periodiek een steekproef naar een aparte tijdelijke map om leesbaarheid te controleren.
7. Moet ook verlies van apparaat of schijf worden afgedekt, bewaar dan een onafhankelijk opgeslagen back-up met passende toegangsbeperking en test ook het herstel daarvan. Git-geschiedenis op dezelfde schijf is geen onafhankelijke back-up.

Sessiegeschiedenis is slechts één van de contextlagen die Claude betrouwbaar maken.

Maak kennis met Ailoot.