Claude Code sletter historik efter 30 dage: sådan gemmer du den

Hvis du har brug for hjælp til tjenesten, kan du se Ailoot-dokumentationen.

Sletter Claude Code virkelig din sessionshistorik?#

Du åbner Claude Code for at vende tilbage til en session fra for to måneder siden – og den er væk. Filen er blevet slettet helt fra disken. Det er ikke en fejl eller en sjælden bug: sådan fungerer standardmekanismen til oprydning.

Én indstilling styrer oprydningen: cleanupPeriodDays. Standardværdien er 30. Hver gang Claude Code starter, gennemgår det historikmappen og sletter alt, der er ældre end den periode. Jeg havde slet ikke denne indstilling i min ~/.claude/settings.json, hvilket betød, at standardværdien var gældende, og at nogle af mine ældre sessioner allerede var væk.

Flere fejlrapporter om dette er åbne i Anthropics repository, og ingen af dem er blevet rettet.

Hvor gemmer Claude Code sessionshistorikken?#

Det er nemt at finde historikken. Åbn en terminal, og se på indholdet af mappen:

ls ~/.claude/projects/

Hver undermappe er et separat projekt. Navnet afspejler stien: for eksempel bliver et projekt i /Users/alex/dev/shop til mappen -Users-alex-dev-shop. Indeni ligger sessionsfilerne:

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

Hver .jsonl er en log linje for linje: én linje svarer til én sessionshændelse. Den indeholder mere end samtaleteksten. Den rummer logikken bag dine beslutninger: hvorfor du valgte en bestemt databasestruktur, hvilke muligheder du afviste, hvor Claude begik en fejl, og hvordan du rettede den.

Kort sagt er det en udviklingsdagbog for projektet. Derfor gør tabet ondt: Du mister ikke en ”chat”, men kontekst, som du har opbygget over flere uger. Jeg har gennemgået, hvordan denne kontekst er struktureret, i guiden ”Claude Memory sammenlignet med CLAUDE.md”.

Hvorfor sletter Anthropic transskriptioner efter 30 dage?#

Der er en begrundelse for sletningen, og det er værd at forstå den, før du slår det hele fra. En transskription er klartekst. Hvis Claude læste en .env-fil under en session, indsatte en nøgle i en kommando, eller du indsatte en adgangskode i en prompt, endte alt sammen i .jsonl-filen som klartekst. Jo længere sådan en fil ligger på disken, desto større er risikoen for, at den en dag bliver lækket.

Anthropic siger det ligeud: Transskriptioner kan indeholde kildekode, legitimationsoplysninger og andet følsomt materiale, og det udgør en reel risiko for privatlivet at beholde dem på disken længere end nødvendigt. Perioden på 30 dage blev valgt som et kompromis.

Communityets indvendinger handler om tre ting: Sletningen sker i stilhed (der vises ingen advarsel under opsætningen eller ved start), der indhentes ikke samtykke (du bliver ikke spurgt), og der er ingen gendannelse (papirkurven bruges ikke, og der er ingen tilbagerulning). I issue #59248 beder udviklerne om én ting: Gør oprydningen rimelig – giv en advarsel, en gendannelsesperiode og en mindre aggressiv standardperiode.

Hvorfor kan et sikkerhedskopieringsscript i sig selv udløse sletning?#

Det er den mest besværlige del, og den går galt for folk, der prøver at beskytte deres data selv. Oprydningen ser på mtime, filens tidsstempel for seneste ændring. Den antager, at mtime viser, hvornår du sidst arbejdede i sessionen. I praksis kan hvad som helst ændre mtime: en Dropbox- eller iCloud-synkroniseringsklient, rsync, antivirussoftware, et indekseringsprogram eller dit eget sikkerhedskopieringsscript.

Her er fælden. Du beslutter dig for at gemme historikken og konfigurerer synkronisering af ~/.claude/projects/ med en skytjeneste. På et tidspunkt omskriver synkroniseringstjenesten en fil og angiver en tidligere dato som dens mtime (det kan ske, når en kopi gendannes fra skyen). Claude Code ser en ”gammel” fil ved opstart og sletter den. Du ville gemme den, men fremskyndede sletningen.

Der er kun én konklusion: Sikkerhedskopien skal ligge uden for ~/.claude/projects/. Oprydningen virker kun i denne mappe. En kopi, der ligger udenfor, er uden for oprydningens rækkevidde. Jeg bygger løsningen på dette princip.

Hvordan kan du stoppe sletningen af historikken med det samme?#

Stop sletningen i tre trin:

1. Åbn indstillingsfilen: ~/.claude/settings.json (opret filen, hvis den ikke findes).
2. Tilføj indstillingen cleanupPeriodDays med en stor værdi:

{
  "cleanupPeriodDays": 3650
}

3. Gem filen. Indstillingen træder i kraft, næste gang Claude Code starter.

Værdien 3650 svarer til ti år: I praksis vil sletning ikke længere finde sted. Hvis du vil beholde oprydningen, men give historikken længere tid, skal du sætte værdien til 365 (ét år); så forsvinder kun sessioner, der er ældre end et år. Du kan kontrollere, om indstillingen er blevet indlæst, med denne kommando:

grep cleanupPeriodDays ~/.claude/settings.json

En vigtig detalje, som er nem at overse: Hvis du forlænger perioden, gendanner det IKKE det, der allerede er blevet slettet. Oprydningen kører ved opstart, og alt, der blev slettet ved tidligere kørsler, er væk for altid. Derfor bør du gøre dette først – det forhindrer fremtidige tab, men bringer ikke det, der allerede er slettet, tilbage. Hvis du vil undgå at miste din Claude Code-historik og dit projekt på grund af en utilsigtet kommando, kan du se guiden ”Sådan konfigurerer du Claude Code, så det ikke ødelægger dit projekt”.

Din sessionshistorik er en del af projektets anden hjerne: Den indeholder beslutningslogik, som du ikke har dokumenteret andre steder. cleanupPeriodDays gemmer filerne, men gør dem ikke til et system, der lader dig finde det, du har brug for, seks måneder senere.

Hvordan arkiverer du automatisk historik uden for oprydningsmappen?#

Idéen er enkel: Lad Claude Code gøre, hvad det vil med sin mappe, mens du opbevarer et separat arkiv uden for den. Arkivet er beskyttet mod denne oprydningsmekanisme, men kan stadig gå tabt ved diskfejl, utilsigtet sletning eller mislykket kopiering. Sådan konfigurerer du det:

1. Opret en arkivmappe uden for den administrerede mappe:

mkdir -p ~/claude-history-archive

2. Kopiér din nuværende historik derover. Flaget -a bevarer strukturen og tidsstemplerne; --ignore-existing lader allerede kopierede filer være urørte:

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

3. Automatisér kørslen én gang om dagen. På macOS bruger du launchd. Opret filen ~/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. Indlæs agenten, så den kører i baggrunden:

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

På Linux gør du det samme med én linje i crontab (crontab -e):

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

Hvorfor virker dette, når synkroniseringen fra det forrige afsnit mislykkes? Arkivet ligger UDEN FOR ~/.claude/projects/, så oprydningen slet ikke kan se det. Kopieringen foregår i én retning (fra den aktive mappe til arkivet), og vi ændrer ikke mtime for de aktive filer – derfor opstår mtime-fejlen ikke. Selv hvis Claude Code sletter en session fra sin egen mappe i morgen, bliver kopien liggende i arkivet.

Hvordan kan du gøre dit sessionsarkiv til en søgbar anden hjerne?#

Det er ikke nok bare at samle filer – du skal kunne få adgang til dem. To trin gør arkivet til et fungerende værktøj.

Først versionsstyrer du det med git. Initialisér et repository i arkivmappen:

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

Føj git add -A && git commit til den samme daglige kørsel som rsync. Nu har du en versionshistorik: Du kan se, hvad der kom til, og hvornår, og fortryde en utilsigtet overskrivning med én kommando.

Dernæst søger du. .jsonl-filer er linjeafgrænset JSON, så du kan bruge velkendte værktøjer på dem. Find den session, hvor et bestemt emne blev diskuteret:

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

Udtræk kun teksten fra dine prompts fra en session (med jq, da det er JSON):

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

Nu begynder din sessionshistorik at fungere som projektets anden hjerne: en database, hvor du på få sekunder kan finde ”hvordan vi traf denne beslutning i marts”. Se guiden ”Hvor bliver tokens af i Claude Code?” for en separat gennemgang af, hvor konteksten ender i en session, og hvordan du håndterer den.

Kan du gendanne sessioner, der allerede er blevet slettet?#

Det ærlige svar er: sandsynligvis ikke. Claude Code har ingen gendannelsesfunktion, ingen papirkurv og ingen fortrydelseslog for slettede transskriptioner. Filen forsvinder ganske enkelt fra disken.

Der er én mulighed: systemsikkerhedskopier, hvis de blev aktiveret på forhånd:

1. macOS Time Machine – hvis et øjebliksbillede indeholdt ~/.claude/projects/ før sletningen, kan du hente filen fra sikkerhedskopien for den relevante dato.
2. OneDrive / Dropbox-versionshistorik – hvis mappen blev synkroniseret med versionshistorik aktiveret, kan du lede efter filen i skyens versionshistorik (men husk mtime-fælden: synkroniseringen kan også have udløst sletningen).
3. Manuelle kopier – enhver rsync/cp, du manuelt har kørt til et sted uden for den administrerede mappe.

Hvis ingen af disse fandtes, er sessionen væk. Og det er ikke sjældent: En forfatter til en bug i Anthropics repository fik 26 af 38 poster ødelagt, svarende til flere måneders arbejde. Den eneste pålidelige beskyttelse er den, der er på plads FØR tabet. Indstil cleanupPeriodDays, og konfigurér automatisk arkivering i dag, mens der stadig er noget at gemme.

Hvilken værdi skal du vælge for cleanupPeriodDays?#

Der er én indstilling, men den kan bruges på flere måder. Sammenlign mulighederne, og vælg den, der passer til dit behov:

En vigtig sikkerhedsbemærkning: Hvis du angiver 3650 og beholder alt, accepterer du at gemme transskriptioner, som kan indeholde nøgler og kode, på disken. Det er en bevidst afvejning: bekvemmeligheden ved arkivering over for risikoen. Begræns risikoen: Opbevar arkivet på en krypteret disk (FileVault på macOS), læg det ikke i en offentlig sky, og commit det ikke til et offentligt git-repository. Jeg har samlet en separat guide om, hvilke data der kan lække via Claude Code: ”Datasikkerhed i Claude Code”.

Hvad skal du gøre i dag: tjekliste#

Konfigurér beskyttelsen trin for trin:

1. Indstil cleanupPeriodDays: 3650 i ~/.claude/settings.json – så har du stoppet sletningen.
2. Opret ~/claude-history-archive uden for den administrerede mappe, og kør den første rsync -a.
3. Planlæg en daglig kørsel med launchd (macOS) eller cron (Linux).
4. Initialisér git i arkivet, og føj git add -A && git commit til samme kørsel.
5. Kontrollér, at arkivet ligger på en krypteret disk og ikke synkroniseres til en offentlig sky.
6. Kontrollér hver planlagt kørsel for vellykket kopiering. Undersøg derefter en nylig arkiveret session, og gendan jævnligt en prøve i en separat midlertidig mappe for at verificere, at den kan læses.
7. Behold en uafhængigt lagret sikkerhedskopi med passende adgangskontrol, hvis tab af enhed eller disk er omfattet, og test også dens gendannelse. Git-historik på samme disk er ikke en uafhængig sikkerhedskopi.

Sessionshistorikken er blot ét lag af den kontekst, der gør Claude pålidelig.

Lær Ailoot at kende.