Claude Code raderar historiken efter 30 dagar: så sparar du den

Om du behöver hjälp med tjänsten kan du läsa Ailoot-dokumentationen.

Raderar Claude Code verkligen din sessionshistorik?#

Du öppnar Claude Code för att återvända till en session från för två månader sedan – och den är borta. Filen har raderats helt från disken. Det här är inget fel eller någon sällsynt bugg: så fungerar standardmekanismen för rensning.

En inställning styr rensningen: cleanupPeriodDays. Standardvärdet är 30. Varje gång Claude Code startar genomsöker det historikmappen och raderar allt som är äldre än den perioden. Jag hade inte den här inställningen alls i min ~/.claude/settings.json, vilket innebar att standardvärdet gällde och att några av mina äldre sessioner redan var borta.

Flera felrapporter om detta är öppna i Anthropics repository, och ingen har åtgärdats.

Var lagrar Claude Code sessionshistoriken?#

Det är enkelt att hitta historiken. Öppna en terminal och titta på mappens innehåll:

ls ~/.claude/projects/

Varje undermapp motsvarar ett separat projekt. Namnet kodar sökvägen: till exempel blir ett projekt i /Users/alex/dev/shop mappen -Users-alex-dev-shop. Där inne finns sessionsfiler:

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

Varje .jsonl är en logg rad för rad: varje rad motsvarar en sessionhändelse. Den innehåller mer än konversationstexten. Där finns logiken bakom dina beslut: varför du valde en viss databasstruktur, vilka alternativ du avvisade, var Claude gjorde ett misstag och hur du rättade till det.

I praktiken är det en utvecklingsdagbok för projektet. Därför gör förlusten ont: du förlorar inte en ”chatt”, utan sammanhang som du har byggt upp under flera veckor. Jag har beskrivit hur detta sammanhang är strukturerat i guiden ”Claude Memory jämfört med CLAUDE.md”.

Varför raderar Anthropic transkriptioner efter 30 dagar?#

Det finns en anledning till raderingen, och den är värd att förstå innan du stänger av den helt. En transkription är klartext. Om Claude läste en .env-fil under en session, lade in en nyckel i ett kommando eller om du klistrade in ett lösenord i en prompt, hamnade allt detta i .jsonl-filen som klartext. Ju längre en sådan fil ligger kvar på disken, desto större är risken att den en dag läcker.

Anthropic uttrycker det tydligt: transkriptioner kan innehålla källkod, autentiseringsuppgifter och annat känsligt material, och att behålla dem på disken längre än nödvändigt innebär en verklig integritetsrisk. Perioden på 30 dagar valdes som en kompromiss.

Invändningarna från communityn gäller tre saker: raderingen sker i tysthet (ingen varning visas vid konfiguration eller start), det finns inget samtycke (du blir inte tillfrågad) och det går inte att återställa filerna (papperskorgen används inte och det finns ingen återställning). I ärende #59248 ber utvecklare om en sak: gör rensningen rimlig – ge en varning, en återställningsperiod och en mindre aggressiv standardperiod.

Varför kan ett säkerhetskopieringsskript i sig utlösa radering?#

Det här är den knepigaste delen, och den ställer till det för personer som försöker skydda sina data själva. Rensningen tittar på mtime, filens tidsstämpel för senaste ändring. Den utgår från att mtime visar när du senast arbetade i sessionen. I praktiken kan vad som helst ändra mtime: en Dropbox- eller iCloud-synkroniseringsklient, rsync, antivirusprogram, en indexerare eller ditt eget säkerhetskopieringsskript.

Här är fällan. Du bestämmer dig för att spara historiken och konfigurerar molnsynkronisering av ~/.claude/projects/. Vid något tillfälle skriver synktjänsten om en fil och anger ett tidigare datum som dess mtime (det kan hända när en kopia återställs från molnet). Claude Code ser en ”gammal” fil vid start och raderar den. Du ville spara filen, men påskyndade raderingen.

Det finns bara en slutsats: säkerhetskopian måste ligga utanför ~/.claude/projects/. Rensningen verkar bara i den här mappen. En kopia som lagras utanför ligger utom räckhåll för rensningen. Jag bygger lösningen kring den här principen.

Hur kan du stoppa raderingen av historiken direkt?#

Stoppa raderingen i tre steg:

1. Öppna inställningsfilen: ~/.claude/settings.json (om filen inte finns skapar du den).
2. Lägg till inställningen cleanupPeriodDays med ett stort värde:

{
  "cleanupPeriodDays": 3650
}

3. Spara filen. Inställningen börjar gälla nästa gång Claude Code startar.

Värdet 3650 motsvarar tio år: i praktiken kommer radering inte längre att ske. Om du vill behålla rensningen men tillåta mer tid anger du 365 (ett år); då försvinner bara sessioner som är äldre än ett år. Du kan kontrollera att inställningen har lästs in med det här kommandot:

grep cleanupPeriodDays ~/.claude/settings.json

En sak som är lätt att missa: om du förlänger perioden återställer det INTE sådant som redan har raderats. Rensningen körs vid start, och allt som raderades vid tidigare körningar är borta för gott. Därför bör du göra detta först – det förhindrar framtida förluster men återställer inte det som redan har raderats. Om du vill undvika att förlora din Claude Code-historik och ditt projekt genom ett oavsiktligt kommando kan du läsa guiden ”Så konfigurerar du Claude Code så att det inte förstör ditt projekt”.

Din sessionshistorik är en del av projektets andra hjärna: den innehåller beslutslogik som du inte har dokumenterat någon annanstans. cleanupPeriodDays sparar filerna, men gör dem inte till ett system där du kan hitta det du behöver om sex månader.

Hur arkiverar du historik automatiskt utanför rensningsmappen?#

Idén är enkel: låt Claude Code göra vad det vill med sin mapp, medan du behåller ett separat arkiv utanför den. Arkivet skyddas från just den rensningsmekanismen men kan fortfarande förloras vid diskfel, oavsiktlig radering eller misslyckad kopiering. Konfigurera det så här:

1. Skapa en arkivmapp utanför den hanterade katalogen:

mkdir -p ~/claude-history-archive

2. Kopiera din nuvarande historik dit. Flaggan -a bevarar strukturen och tidsstämplarna; --ignore-existing lämnar filer som redan kopierats orörda:

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

3. Automatisera körningen en gång om dagen. På macOS använder du launchd. Skapa 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. Ladda agenten så att den körs i bakgrunden:

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

På Linux gör du samma sak med en rad i crontab (crontab -e):

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

Varför fungerar detta när synkroniseringen i föregående avsnitt misslyckas? Arkivet ligger UTANFÖR ~/.claude/projects/, så rensningen kan inte se det alls. Kopieringen sker i en riktning (från den aktiva mappen till arkivet) och vi rör inte mtime för aktiva filer – därför uppstår inte mtime-buggen. Även om Claude Code raderar en session från sin egen mapp i morgon finns kopian kvar i arkivet.

Hur kan du göra sessionsarkivet till en sökbar andra hjärna?#

Det räcker inte att bara samla filer – du behöver kunna komma åt dem. Två steg gör arkivet till ett fungerande verktyg.

Först versionshanterar du det med git. Initiera ett repository i arkivmappen:

cd ~/claude-history-archive
git init
git add -A && git commit -m "Första ögonblicksbilden av Claude Code-historiken"

Lägg till git add -A && git commit i samma dagliga körning som rsync. Nu har du en versionshistorik: du kan se vad som dök upp och när, och ångra en oavsiktlig överskrivning med ett kommando.

Sök sedan. .jsonl-filer är radavgränsad JSON, så du kan använda välbekanta verktyg på dem. Hitta vilken session som diskuterade ett visst ämne:

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

Extrahera bara texten från dina promptar från en session (med jq, eftersom det är JSON):

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

Nu börjar sessionshistoriken fungera som projektets andra hjärna: en databas där du på några sekunder kan hitta ”hur vi fattade det här beslutet i mars”. I en separat genomgång av var sammanhanget tar vägen i en session och hur du hanterar det kan du läsa ”Vart tar token vägen i Claude Code?”.

Kan du återställa sessioner som redan har raderats?#

Det ärliga svaret är: troligen inte. Claude Code har ingen återställningsfunktion, ingen papperskorg och ingen ångralogg för raderade transkriptioner. Filen försvinner helt enkelt från disken.

Det finns ett alternativ: systemsäkerhetskopior, om de aktiverades i förväg:

1. macOS Time Machine – om en ögonblicksbild fångade ~/.claude/projects/ före raderingen kan du hämta filen från säkerhetskopian för det aktuella datumet.
2. OneDrive / Dropbox versionshistorik – om mappen synkroniserades med versionshantering aktiverad kan du leta efter filen i molnets versionshistorik (men kom ihåg mtime-fällan: synkroniseringen kan också ha utlöst raderingen).
3. Manuella kopior – alla rsync/cp-kopior du manuellt gjorde någonstans utanför den hanterade mappen.

Om inget av detta fanns är sessionen borta. Och det här är inte ovanligt: en författare till en bugg i Anthropics repository fick 26 av 38 poster förstörda, vilket motsvarade flera månaders arbete. Det enda tillförlitliga skyddet är det som finns på plats FÖRE förlusten. Ställ in cleanupPeriodDays och automatisk arkivering i dag, medan det fortfarande finns något att spara.

Vilket värde bör du välja för cleanupPeriodDays?#

Det finns en inställning, men den kan användas på flera sätt. Jämför alternativen och välj det som passar ditt användningsfall:

En viktig säkerhetsreservation: om du anger 3650 och behåller allt går du med på att lagra transkriptioner som kan innehålla nycklar och kod på disken. Det är en medveten avvägning: bekvämligheten med ett arkiv mot risken. Minska risken: förvara arkivet på en krypterad disk (FileVault på macOS), lägg det inte i ett offentligt moln och checka inte in det i ett offentligt git-repository. Jag har sammanställt en separat guide om vilka data som kan läcka via Claude Code: ”Datasäkerhet i Claude Code”.

Vad ska du göra i dag: checklista#

Konfigurera skyddet steg för steg:

1. Ange cleanupPeriodDays: 3650 i ~/.claude/settings.json för att förlänga lagringstiden; det stoppar inte all framtida radering.
2. Skapa ~/claude-history-archive utanför den hanterade mappen och kör den första rsync -a.
3. Schemalägg en daglig körning med launchd (macOS) eller cron (Linux).
4. Initiera git i arkivet och lägg till git add -A && git commit i samma körning.
5. Kontrollera att arkivet ligger på en krypterad disk och inte synkroniseras till ett offentligt moln.
6. Kontrollera att varje schemalagd kopiering lyckas, granska sedan en ny arkiverad session och återställ regelbundet ett prov till en separat tillfällig mapp för att verifiera läsbarheten.
7. Om förlust av enhet eller disk ingår i riskbilden behåller du en oberoende lagrad säkerhetskopia med lämplig åtkomstkontroll och testar även dess återställning. Git-historik på samma disk är ingen oberoende säkerhetskopia.

Sessionshistoriken är bara ett lager av det sammanhang som gör Claude tillförlitligt.

Lär känna Ailoot.