# Claude Code sletter historikken etter 30 dager: slik lagrer du den
> Hvor Claude Code-økter lagres, hvordan du konfigurerer cleanupPeriodDays, og hvordan du organiserer et eksternt arkiv med rsync, launchd eller cron.
Source: https://ailoot.ai/blog/nb/claude-code-history-30-days/
Canonical: https://ailoot.ai/blog/nb/claude-code-history-30-days/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-056
Revision: sha256-d85a867195488f47c65f95aef5e26f6701d0ca2afec423da2f0188dc321b25bc
Se [Ailoot-dokumentasjonen](https://ailoot.ai/docs/) for hjelp med å bruke tjenesten.
## Sletter Claude Code virkelig økthistorikken din?
Hovedpunkter
Ja. Hver gang Claude Code starter, sletter det øktfiler som er eldre enn 30 dager. Innstillingen `cleanupPeriodDays` i `~/.claude/settings.json` er ansvarlig for dette; standardverdien er `30`. Slettingen skjer uten varsel, uten å be om samtykke og uten mulighet til å gjenopprette filene.
Du åpner Claude Code for å fortsette en økt fra to måneder tilbake — men den er borte. Filen er fullstendig slettet fra disken. Dette er ikke en feil eller en sjelden bug: slik fungerer standardmekanismen for opprydding.
Én innstilling styrer oppryddingen: `cleanupPeriodDays`. Standardverdien er `30`. Hver gang Claude Code starter, skanner det historikkmappen og sletter alt som er eldre enn denne perioden. Jeg hadde ikke denne innstillingen i `~/.claude/settings.json` i det hele tatt, noe som betydde at standardverdien gjaldt, og at noen av de eldre øktene mine allerede var borte.
Flere feilrapporter om dette er åpne i Anthropics repository, og ingen av dem er løst.
## Hvor lagrer Claude Code økthistorikken?
Hovedpunkter
Historikken for hver økt lagres i `~/.claude/projects/
/.jsonl`. Mappenavnet er den absolutte banen til arbeidsmappen der du kjørte Claude Code, med skråstreker erstattet av bindestreker. `.jsonl`-filen inneholder hele samtalen, én linje om gangen: promptene dine, modellens svar, verktøykall og filredigeringer. Dette er nettopp minnet som oppryddingen sletter.
Hovedpunkter
Anthropic begrunner dette med personvern og sikkerhet. Øktfiler lagres som ren tekst på disken og kan inneholde kildekode, passord og API-nøkler. Det er risikabelt å beholde dem for alltid: Hvis en bærbar PC blir stjålet, eller noen får tilgang til disken, får de tilgang til alle disse sensitive opplysningene. Perioden på 30 dager er deres avveining mellom «å gjenoppta nylig arbeid» og «ikke å beholde hemmeligheter på disken lenger enn nødvendig».
Det finnes en begrunnelse for slettingen, og det er verdt å forstå den før du slår av alt. En transkripsjon er ren tekst. Hvis Claude leste en `.env`-fil i løpet av en økt, satte inn en nøkkel i en kommando, eller du limte inn et passord i en prompt, havnet alt sammen som ren tekst i `.jsonl`-filen. Jo lenger en slik fil blir liggende på disken, desto større er sjansen for at den en dag lekker ut.
Anthropic sier det rett ut: Transkripsjoner kan inneholde kildekode, påloggingsinformasjon og annet sensitivt materiale, og det innebærer en reell personvernrisiko å beholde dem på disken lenger enn nødvendig. Perioden på 30 dager ble valgt som et kompromiss.
Innvendingene fra fellesskapet handler om tre ting: Slettingen skjer i det stille (det gis ikke noe varsel under oppsettet eller ved oppstart), samtykke innhentes ikke (du blir ikke spurt), og det er ingen mulighet for gjenoppretting (papirkurven brukes ikke, og det finnes ingen tilbakerulling). I sak \#59248 ber utviklere om én ting: Gjør oppryddingen rimeligere — gi et varsel, en gjenopprettingsperiode og en mindre aggressiv standardperiode.
## Hvordan kan et sikkerhetskopieringsskript i seg selv utløse sletting?
Hovedpunkter
Oppryddingen avgjør hva som skal slettes, basert på filens endringstid (mtime). Den sjekker ikke den faktiske siste aktiviteten i en økt. Enhver prosess som berører en `.jsonl`-fil — skysynkronisering, rsync, et redigeringsprogram eller et skript — kan endre mtime slik at en ny økt ser foreldet ut. Ved neste oppstart av Claude Code vil økten bli regnet som gammel og slettet. Paradokset er at et naivt forsøk på å sikkerhetskopiere historikken inne i den administrerte mappen fremskynder tapet av den.
Dette er den mest krevende delen, og den lurer folk som prøver å beskytte dataene sine selv. Oppryddingen ser på mtime, tidsstempelet for når filen sist ble endret. Den antar at mtime viser når du sist jobbet i økten. I praksis kan hva som helst endre mtime: en synkroniseringsklient for Dropbox eller iCloud, `rsync`, antivirusprogramvare, en indekserer eller ditt eget sikkerhetskopieringsskript.
Her er fellen. Du bestemmer deg for å lagre historikken og setter opp skysynkronisering av `~/.claude/projects/`. På et tidspunkt skriver synkroniseringstjenesten en fil på nytt og setter mtime til en tidligere dato (dette kan skje når en fil gjenopprettes fra en kopi i skyen). Claude Code ser en «gammel» fil ved oppstart og sletter den. Du ville lagre den, men fremskyndet slettingen.
Det finnes bare én konklusjon: **Sikkerhetskopien må ligge utenfor `~/.claude/projects/`**. Oppryddingen virker bare inne i denne mappen. En kopi som er lagret utenfor den, er utenfor rekkevidden til oppryddingen. Jeg bygger løsningen rundt dette prinsippet.
## Hvordan kan du stoppe sletting av historikken med en gang?
Hovedpunkter
Én innstilling. Åpne `~/.claude/settings.json` og sett `cleanupPeriodDays` til et stort tall — for eksempel `3650` (ti år). I praksis deaktiverer dette automatisk sletting: Ingenting blir eldre enn grensen. Viktig: Denne innstillingen beskytter bare det som ennå ikke er slettet. Historikk som allerede er slettet av oppryddingen, kan ikke gjenopprettes. Derfor bør du handle før du mister enda en økt.
Stopp slettingen i tre trinn:
1. Åpne innstillingsfilen: `~/.claude/settings.json` (opprett den hvis den ikke finnes).
2. Legg til innstillingen `cleanupPeriodDays` med en høy verdi:
```json
{
"cleanupPeriodDays": 3650
}
```
3. Lagre filen. Innstillingen trer i kraft neste gang Claude Code starter.
Verdien `3650` betyr ti år: I praksis vil sletting ikke lenger finne sted. Hvis du vil beholde oppryddingen, men gi den mer tid, setter du verdien til `365` (ett år); da forsvinner bare økter som er eldre enn ett år. Du kan kontrollere at innstillingen er tatt i bruk, med denne kommandoen:
```bash
grep cleanupPeriodDays ~/.claude/settings.json
```
En viktig detalj som er lett å overse: Det å forlenge perioden GJENOPPRETTER IKKE det som allerede er slettet. Oppryddingen kjører ved oppstart, og alt som ble slettet under tidligere oppstarter, er borte for godt. Derfor bør du sette dette først — det hindrer fremtidig tap, men bringer ikke tilbake det som allerede er slettet. Hvis du vil unngå å miste Claude Code-historikken din, og samtidig beskytte prosjektet ditt mot en utilsiktet kommando, kan du se veiledningen [«Slik konfigurerer du Claude Code så det ikke ødelegger prosjektet ditt»](https://ailoot.ai/blog/nb/claude-code-safe-overnight-setup/).
Økthistorikken din er en del av prosjektets andre hjerne: Den inneholder beslutningslogikk du ikke har dokumentert noe annet sted. `cleanupPeriodDays` bevarer filene, men gjør dem ikke om til et system som hjelper deg med å finne det du trenger om seks måneder.
## Hvordan arkiverer du historikken automatisk utenfor oppryddingsmappen?
Hovedpunkter
Kopier økter til et arkiv UTENFOR `~/.claude/projects/`, der oppryddingen ikke gjelder. En enkel `rsync -a` til en separat mappe én gang om dagen er nok: Nye filer legges til, og gamle blir værende. Fordi arkivet ligger utenfor, påvirkes det verken av `cleanupPeriodDays` eller mtime-feilen. Automatiser kjøringen med launchd (macOS) eller cron (Linux), så vokser historikken av seg selv.
Ideen er enkel: La Claude Code gjøre som det vil med sin egen mappe, mens du oppbevarer et separat arkiv utenfor den. Arkivet er beskyttet mot denne oppryddingsmekanismen, men kan fortsatt gå tapt ved diskfeil, utilsiktet sletting eller mislykket kopiering. Sett det opp slik:
1. Opprett en arkivmappe utenfor den administrerte katalogen:
```bash
mkdir -p ~/claude-history-archive
```
2. Kopier den nåværende historikken dit. Flagget `-a` bevarer strukturen og tidsstemplene; `--ignore-existing` lar filer som allerede er kopiert, være urørt:
```bash
rsync -a ~/.claude/projects/ ~/claude-history-archive/
```
3. Automatiser kjøringen én gang om dagen. Bruk launchd på macOS. Opprett filen `~/Library/LaunchAgents/com.example.claudearchive.plist`:
```xml
Label
com.example.claudearchive
ProgramArguments
/usr/bin/rsync
-a
/Users/YOUR_NAME/.claude/projects/
/Users/YOUR_NAME/claude-history-archive/
StartInterval
86400
```
4. Last inn agenten slik at den kjører i bakgrunnen:
```bash
launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist
```
På Linux gjør du det samme med én linje i crontab (`crontab -e`):
```bash
0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/
```
Hvorfor fungerer dette når synkroniseringen fra forrige avsnitt ikke gjør det? Arkivet ligger UTENFOR `~/.claude/projects/`, så oppryddingen kan ikke se det. Kopieringen skjer bare én vei (fra den aktive mappen til arkivet), og vi berører ikke mtime for aktive filer — derfor oppstår ikke mtime-feilen. Selv om Claude Code sletter en økt fra sin egen mappe i morgen, blir kopien liggende i arkivet.
## Hvordan gjør du øktarkivet om til en søkbar andre hjerne?
Hovedpunkter
Legg arkivet under git, så får du en versjonsstyrt, fullstendig søkbar database med alle øktene dine. Kjør `git init` i arkivmappen, og bruk `git add -A && git commit` daglig for å få en endringshistorikk og beskyttelse mot utilsiktet overskriving. Du kan søke i tidligere økter med vanlig grep og hente ut strukturert innhold med jq, siden `.jsonl` er JSON med én linje per oppføring. Dermed blir arkivet et praktisk verktøy.
Det er ikke nok bare å samle filer — du må kunne finne frem i dem. To trinn gjør arkivet til et fungerende verktøy.
Først versjonsstyrer du det med git. Initialiser et repository i arkivmappen:
```bash
cd ~/claude-history-archive
git init
git add -A && git commit -m "First snapshot of Claude Code history"
```
Legg `git add -A && git commit` til den samme daglige kjøringen som rsync. Nå har du en versjonshistorikk: Du kan se hva som dukket opp og når, og angre en utilsiktet overskriving med én kommando.
Søk deretter. `.jsonl`-filer er JSON med én oppføring per linje, så du kan bruke verktøy du kjenner fra før. Finn økten der et bestemt emne ble diskutert:
```bash
grep -rl "database migration" ~/claude-history-archive/
```
Hent bare teksten i promptene dine fra en økt (med jq, siden det er JSON):
```bash
jq -r 'select(.type=="user") | .message.content' session.jsonl
```
Nå begynner økthistorikken din å fungere som prosjektets andre hjerne: en database der du kan finne tilbake til «hvordan vi bestemte dette i mars» på få sekunder. Se veiledningen [«Hvor tokenene går i Claude Code»](https://ailoot.ai/blog/nb/where-claude-code-tokens-go/) for en egen gjennomgang av hvor konteksten havner i en økt, og hvordan du håndterer den.
## Kan du gjenopprette økter som allerede er slettet?
Hovedpunkter
Det finnes ingen innebygd metode. Claude Code legger ikke slettede filer i papirkurven og beholder ingen tilbakerulling; filen er slettet for godt. Den eneste muligheten er eksterne kopier som ble laget FØR slettingen: et Time Machine-øyeblikksbilde på macOS, versjonshistorikken i OneDrive eller Dropbox, eller en manuell sikkerhetskopi. Hvis ingen av disse finnes, er økten tapt. Derfor må beskyttelsen settes opp på forhånd — før det finnes noe å miste.
Det ærlige svaret: sannsynligvis ikke. Claude Code har ingen gjenopprettingsfunksjon, ingen papirkurv og ingen angrelogg for slettede transkripsjoner. Filen forsvinner ganske enkelt fra disken.
Det finnes én mulighet: sikkerhetskopier av systemet, hvis de var aktivert på forhånd:
1. **macOS Time Machine** — Hvis et øyeblikksbilde omfattet `~/.claude/projects/` før slettingen, kan du hente filen fra sikkerhetskopien for den aktuelle datoen.
2. **Versjonshistorikk i OneDrive / Dropbox** — Hvis mappen ble synkronisert med versjonshistorikk aktivert, kan du lete etter filen i skyens versjonshistorikk (men husk mtime-fellen: synkronisering kan også ha utløst slettingen).
3. **Manuelle kopier** — Alle `rsync`/`cp`-kopier du manuelt har lagt et sted utenfor den administrerte mappen.
Hvis ingen av disse fantes, er økten borte. Og dette er ikke uvanlig: En av forfatterne bak en bug i Anthropics repository hadde 26 av 38 oppføringer ødelagt, tilsvarende flere måneders arbeid. Den eneste pålitelige beskyttelsen er den som finnes FØR tapet. Sett opp `cleanupPeriodDays` og automatisk arkivering i dag, mens det fortsatt finnes noe å ta vare på.
## Hvilken verdi bør du velge for cleanupPeriodDays?
Hovedpunkter
For de fleste bør du bruke `3650` (ti år, noe som i praksis deaktiverer sletting) sammen med et eksternt, automatisk arkiv. Behold standardverdien `30` bare hvis du ikke trenger historikk, og det er viktigere å unngå å lagre hemmeligheter på disken. Verdien `365` er en fornuftig mellomløsning med årlig opprydding. Et annet alternativ er å ikke lagre historikk i det hele tatt: Bruk miljøvariabelen `CLAUDE_CODE_SKIP_PROMPT_HISTORY` eller flagget `--no-session-persistence`, men det tjener det motsatte formålet.
Det finnes én innstilling, men den kan bety flere ting. Sammenlign alternativene og velg det som passer for ditt bruk:
| Verdi | Hva den gjør | Hvem den passer for |
|----|----|----|
| `30` (standard) | Sletter økter som er eldre enn 30 dager ved oppstart | Du trenger ikke historikk; det er viktigere å unngå å lagre sensitive data på disken |
| `365` | Beholder ett års historikk og rydder deretter opp én gang i året | Du trenger nyere historikk, men ikke et arkiv uten tidsbegrensning |
| `3650` | Deaktiverer i praksis sletting | Du vil beholde alt + et eksternt arkiv (anbefalt) |
| `CLAUDE_CODE_SKIP_PROMPT_HISTORY` | Skriver ikke historikk til disken i det hele tatt | Maksimalt personvern; du trenger ikke historikk i det hele tatt |
En viktig sikkerhetsmerknad: Hvis du setter `3650` og beholder alt, samtykker du til å lagre transkripsjoner som kan inneholde nøkler og kode på disken. Dette er en bevisst avveining: hvor praktisk arkivet er, opp mot risikoen. Begrens risikoen: Oppbevar arkivet på en kryptert disk (FileVault på macOS), ikke legg det i en offentlig sky, og ikke legg det inn i et offentlig git-repository. Jeg har laget en egen veiledning om hvilke data som kan lekke gjennom Claude Code: [«Datasikkerhet i Claude Code»](https://ailoot.ai/blog/nb/claude-code-data-access-safety/).
## Hva bør du gjøre i dag: sjekkliste
Hovedpunkter
Disse trinnene reduserer historikktap: Forleng lagringen med `cleanupPeriodDays: 3650`, kopier økter utenfor `~/.claude/projects/` og versjoner arkivet. Bare vellykket kopierte filer er beskyttet mot Claude Codes opprydding. En daglig tidsplan lar opptil ett døgn med nylige endringer være uarkivert når kjøringene lykkes. Mislykkede eller uteblitte kjøringer forlenger gapet. En kopi på samme disk beskytter ikke mot diskfeil.
Sett opp beskyttelsen trinn for trinn:
1. Sett `cleanupPeriodDays: 3650` i `~/.claude/settings.json` — da har du stoppet slettingen.
2. Opprett `~/claude-history-archive` utenfor den administrerte mappen, og kjør den første `rsync -a`.
3. Planlegg en daglig kjøring med launchd (macOS) eller cron (Linux).
4. Initialiser git i arkivet, og legg til `git add -A && git commit` i den samme kjøringen.
5. Kontroller at arkivet ligger på en kryptert disk og ikke synkroniseres med en offentlig sky.
6. Kontroller hver planlagte kjøring for vellykket kopiering. Undersøk deretter en nylig arkivert økt, og gjenopprett jevnlig en prøve i en separat midlertidig mappe for å verifisere lesbarheten.
7. Hvis tap av enheten eller disken inngår i risikoen, behold en uavhengig lagret sikkerhetskopi med passende tilgangskontroll og test gjenopprettingen derfra også. Git-historikk på samme disk er ingen uavhengig sikkerhetskopi.
Økthistorikken er bare ett lag av konteksten som gjør Claude pålitelig.
### Kilder
- [Claude Code-dokumentasjon — innstillinger i settings.json (cleanupPeriodDays)](https://code.claude.com/docs/en/settings)
- [Claude Code-dokumentasjon — nyheter](https://code.claude.com/docs/en/whats-new)
Bli kjent med [Ailoot](https://ailoot.ai/).
## Spørsmål om denne veiledningen: Claude Code sletter historikken etter 30 dager: slik lagrer du den
### Garanterer et daglig arkiv at ingen økt kan gå tapt?
Nei. Det beskytter vellykket kopierte filer mot opprydding i den administrerte mappen. Med vellykkede daglige kjøringer kan opptil ett døgn med endringer mangle. Feilede kjøringer utvider gapet, og en kopi på samme disk kan svikte sammen med originalen.
### Hvordan sjekker jeg at arkivet er brukbart?
Bekreft at planlagte kopier lykkes, undersøk en nylig arkivert økt og gjenopprett jevnlig en prøve i en separat midlertidig mappe. Test også en sikkerhetskopi lagret uavhengig av originalen for beskyttelse mot tap av enheten eller diskfeil.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.