A Claude Code 30 nap után törli az előzményeket: így mentheti el

A szolgáltatás használatával kapcsolatos segítségért tekintse meg az Ailoot dokumentációját.

Tényleg törli a Claude Code a munkamenetek előzményeit?#

Megnyitja a Claude Code-ot, hogy visszatérjen egy két hónappal ezelőtti munkamenethez — de az eltűnt. A fájlt teljesen törölték a lemezről. Ez nem hiba vagy ritka bug: így működik az alapértelmezett tisztítási mechanizmus.

Egyetlen beállítás szabályozza a tisztítást: cleanupPeriodDays. Alapértelmezett értéke 30. A Claude Code minden indításkor átvizsgálja az előzmények mappáját, és töröl mindent, ami régebbi ennél az időszaknál. Az én ~/.claude/settings.json fájlomban ez a beállítás egyáltalán nem szerepelt, ezért az alapértelmezett érték volt érvényben, és néhány régebbi munkamenetem már eltűnt.

Az Anthropic adattárában több hibajelentés is nyitva van az ügyben, és egyiket sem javították ki.

Hol tárolja a Claude Code a munkamenetek előzményeit?#

Könnyű megtalálni az előzményeket. Nyisson meg egy terminált, és nézze meg a mappa tartalmát:

ls ~/.claude/projects/

Minden almappa egy külön projekt. A neve az útvonalat kódolja: például a /Users/alex/dev/shop útvonalon lévő projektből a -Users-alex-dev-shop mappa lesz. A mappában munkamenetfájlok találhatók:

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← egy munkamenet = egy fájl
# a91b7d40-....jsonl

Minden .jsonl fájl sorról sorra vezetett napló: egy sor egy munkameneteseménynek felel meg. Többet tartalmaz a beszélgetés szövegénél. A döntései mögötti logikát őrzi: miért választott egy adott adatbázis-struktúrát, mely lehetőségeket vetette el, hol hibázott a Claude, és hogyan javította ki a hibát.

Lényegében ez egy projektfejlesztési napló. Ezért fáj az elvesztése: nem egy „csevegés” vész el, hanem a hetek alatt felépített kontextus. A kontextus felépítéséről a „Claude Memory vs. CLAUDE.md” című útmutatóban írtam.

Miért törli az Anthropic az átiratokat 30 nap után?#

A törlésnek van indoka, és érdemes megérteni, mielőtt teljesen kikapcsolná. Az átirat egyszerű szöveg. Ha a Claude elolvasott egy .env fájlt a munkamenet során, beillesztett egy kulcsot egy parancsba, vagy Ön jelszót másolt be egy promptba, mindez egyszerű szövegként került a .jsonl fájlba. Minél tovább marad egy ilyen fájl a lemezen, annál nagyobb az esélye, hogy egy napon kiszivárog.

Az Anthropic világosan fogalmaz: az átiratok forráskódot, hitelesítő adatokat és más érzékeny anyagokat tartalmazhatnak, és a szükségesnél hosszabb lemezen tartásuk valódi adatvédelmi kockázatot jelent. A 30 napos időszakot kompromisszumként választották.

A közösség három dolgot kifogásol: a törlés csendben történik (nincs figyelmeztetés a beállításkor vagy indításkor), nincs beleegyezés (nem kérdeznek rá), és nincs visszaállítás (a fájlok nem kerülnek a Kukába, és nincs visszagörgetés). A #59248-as issue-ban a fejlesztők egy dolgot kérnek: legyen méltányosabb a tisztítás — kapjanak figyelmeztetést és visszaállítási időszakot, az alapértelmezett időszak pedig legyen kevésbé szigorú.

Miért válthat ki maga a biztonsági mentési szkript is törlést?#

Ez a legtrükkösebb rész, és sokan beleesnek a csapdába, amikor saját maguk próbálják megvédeni az adataikat. A tisztítás az mtime-ot, vagyis a fájl utolsó módosításának időbélyegét nézi. Azt feltételezi, hogy az mtime azt mutatja, mikor dolgozott utoljára a munkamenetben. A gyakorlatban bármi módosíthatja: egy Dropbox- vagy iCloud-szinkronizáló kliens, az rsync, vírusirtó szoftver, indexelő vagy akár a saját biztonságimásolat-készítő szkriptje is.

Íme a csapda. Úgy dönt, megőrzi az előzményeket, ezért felhőszinkronizálást állít be a ~/.claude/projects/ mappára. Egy ponton a szinkronizálási szolgáltatás újraír egy fájlt, és korábbi dátumra állítja az mtime értékét (ez felhőbeli másolat visszaállításakor fordulhat elő). A Claude Code indításkor „régi” fájlt lát, és törli. Ön meg akarta őrizni a fájlt, de felgyorsította a törlését.

Csak egy következtetés van: a biztonsági másolatnak a ~/.claude/projects/ mappán kívül kell lennie. A tisztítás csak ezen a mappán belül működik. Az azon kívül tárolt másolatot nem éri el. Erre az elvre építem a megoldást.

Hogyan állíthatja le azonnal az előzmények törlését?#

Három lépésben állítsa le a törlést:

1. Nyissa meg a beállításfájlt: ~/.claude/settings.json (ha a fájl nem létezik, hozza létre).
2. Adja hozzá a cleanupPeriodDays beállítást nagy értékkel:

{
  "cleanupPeriodDays": 3650
}

3. Mentse a fájlt. A beállítás a Claude Code következő indításakor lép érvénybe.

A 3650 érték tíz évet jelent: a gyakorlatban a törlés többé nem történik meg. Ha szeretné megtartani a tisztítást, de több időt hagyna, állítsa 365-re (egy évre); ekkor csak az egy évnél régebbi munkamenetek tűnnek el. Ezzel a paranccsal ellenőrizheti, hogy a beállítás érvénybe lépett-e:

grep cleanupPeriodDays ~/.claude/settings.json

Könnyű elfeledkezni egy fontos kitételről: az időszak meghosszabbítása NEM állítja vissza a már törölt adatokat. A tisztítás indításkor fut, és a korábbi futások során törölt tartalom végleg elveszett. Ezért először ezt állítsa be — megelőzi a jövőbeli veszteségeket, de nem hozza vissza a már törölt adatokat. Ha azt is szeretné elkerülni, hogy egy véletlen paranccsal a Claude Code-előzményeit és a projektjét is elveszítse, tekintse meg a „Claude Code beállítása a projekt károsításának megakadályozására” című útmutatót.

A munkamenetek előzménye a projekt második agyának része: olyan döntési logikát tartalmaz, amelyet máshol nem rögzített. A cleanupPeriodDays megőrzi a fájlokat, de önmagában nem alakítja őket olyan rendszerré, amelyből hat hónap múlva is előkeresheti, amire szüksége van.

Hogyan archiválhatja automatikusan az előzményeket a tisztítási mappán kívül?#

Az ötlet egyszerű: hagyja, hogy a Claude Code azt tegyen a saját mappájával, amit akar, miközben Ön külön archívumot tart azon kívül. Az adott tisztítási mechanizmus nem érinti, de lemezhiba, véletlen törlés vagy sikertelen másolás miatt továbbra is elveszhet. Így állítsa be:

1. Hozzon létre archívummappát a kezelt könyvtáron kívül:

mkdir -p ~/claude-history-archive

2. Másolja oda a jelenlegi előzményeit. Az -a jelző megőrzi a struktúrát és az időbélyegeket; az --ignore-existing érintetlenül hagyja a már átmásolt fájlokat:

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

3. Automatizálja a futtatást napi egy alkalomra. macOS-en használja a launchd-t. Hozza létre a ~/Library/LaunchAgents/com.example.claudearchive.plist fájlt:

<?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. Töltse be az ügynököt, hogy a háttérben fusson:

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

Linuxon ugyanezt egyetlen sorral elvégezheti a crontabban (crontab -e):

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

Miért működik ez, miközben az előző szakaszban említett szinkronizálás nem? Az archívum a ~/.claude/projects/ mappán KÍVÜL van, ezért a tisztítás egyáltalán nem látja. A másolás egyirányú (az aktív mappából az archívumba), és nem módosítjuk az aktív fájlok mtime értékét — így nem jelentkezik az mtime-hiba. Még ha a Claude Code holnap töröl is egy munkamenetet a saját mappájából, annak másolata megmarad az archívumban.

Hogyan alakíthatja a munkamenetek archívumát kereshető második aggyá?#

A fájlok puszta gyűjtése nem elég — hozzájuk is kell férnie. Két lépéssel használható eszközzé alakíthatja az archívumot.

Először kezelje verziókkal a git segítségével. Inicializáljon egy adattárat az archívummappában:

cd ~/claude-history-archive
git init
git add -A && git commit -m "A Claude Code előzményeinek első pillanatképe"

Adja hozzá a git add -A && git commit parancsot az rsync-kel azonos napi futtatáshoz. Így már verzióelőzményei is vannak: láthatja, mi és mikor került be, és egyetlen paranccsal visszavonhatja a véletlen felülírást.

Másodszor keressen az adatokban. A .jsonl fájlok soronként tartalmazzák a JSON-t, ezért használhat rajtuk ismerős eszközöket. Keresse meg azt a munkamenetet, amelyben egy adott témáról esett szó:

grep -rl "adatbázis-migráció" ~/claude-history-archive/

Nyerje ki egy munkamenetből kizárólag a promptjai szövegét (a JSON-formátum miatt jq használatával):

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

Ettől kezdve a munkamenetek előzményei a projekt második agyaként működnek: olyan adatbázisként, amelyből másodpercek alatt előkeresheti, „hogyan döntöttünk erről márciusban”. Arról, hogy hová kerül a kontextus egy munkamenetben, és hogyan kezelje, külön összefoglalót talál a „Hová kerülnek a tokenek a Claude Code-ban?” című útmutatóban.

Visszaállíthatók a már törölt munkamenetek?#

Az őszinte válasz: valószínűleg nem. A Claude Code nem kínál helyreállítási funkciót, Kukát vagy visszavonási naplót a törölt átiratokhoz. A fájl egyszerűen eltűnik a lemezről.

Egy lehetőség van: a rendszer biztonsági mentései, ha előre engedélyezte őket:

1. macOS Time Machine — ha egy pillanatkép rögzítette a ~/.claude/projects/ mappát a törlés előtt, a szükséges dátumhoz tartozó biztonsági mentésből visszakeresheti a fájlt.
2. OneDrive- / Dropbox-verzióelőzmény — ha a mappa verziókövetéssel szinkronizálódott, keresse meg a fájlt a felhő verzióelőzményeiben (de ne feledje az mtime-csapdát: a szinkronizálás a törlést is kiválthatta).
3. Kézi másolatok — bármely rsync/cp parancs, amelyet kézzel futtatott a kezelt mappán kívüli helyre.

Ha egyik sem létezett, a munkamenet elveszett. És ez nem ritka: az Anthropic adattárában található egyik hibáról szóló jelentés szerzőjénél 38 rekordból 26 megsérült, ami több hónapnyi munkának felelt meg. Az egyetlen megbízható védelem az, amelyet a veszteség ELŐTT beállít. Még ma állítsa be a cleanupPeriodDays értékét és az automatikus archiválást, amíg van mit megmenteni.

Milyen értéket válasszon a cleanupPeriodDays beállításhoz?#

Egyetlen beállítás van, de többféle célt szolgálhat. Hasonlítsa össze a lehetőségeket, és válassza az igényeinek megfelelőt:

Fontos biztonsági kitétel: ha 3650 értéket állít be, és mindent megőriz, azzal vállalja, hogy olyan átiratokat tárol a lemezen, amelyek kulcsokat és kódot tartalmazhatnak. Ez tudatos kompromisszum: az archívum kényelme a kockázattal szemben. Csökkentse a kockázatot: titkosított lemezen tárolja az archívumot (macOS-en FileVaulttal), ne tegye nyilvános felhőbe, és ne töltse fel nyilvános git-adattárba. Külön útmutatót állítottam össze arról, milyen adatok szivároghatnak ki a Claude Code-ból: „Adatbiztonság a Claude Code-ban”.

Teendők ma: ellenőrzőlista#

Lépésről lépésre állítsa be a védelmet:

1. Állítsa be a cleanupPeriodDays: 3650 értéket a ~/.claude/settings.json fájlban — ezzel leállította a törlést.
2. Hozza létre a ~/claude-history-archive mappát a kezelt mappán kívül, és futtassa le az első rsync -a parancsot.
3. Ütemezzen napi futtatást launchd-val (macOS) vagy cron-nal (Linux).
4. Inicializálja a git-et az archívumban, és adja hozzá a git add -A && git commit parancsot ugyanahhoz a futtatáshoz.
5. Ellenőrizze, hogy az archívum titkosított lemezen van-e, és nem szinkronizálódik-e nyilvános felhőbe.
6. Minden ütemezett futásnál ellenőrizze a másolás sikerét, majd nézzen meg egy friss archivált munkamenetet, és időnként külön ideiglenes mappába állítson vissza egy mintát az olvashatóság igazolására.
7. Ha az eszköz vagy lemez elvesztése is a hatókörbe tartozik, megfelelő hozzáférésvédelemmel független helyen tárolt mentést is tartson, és tesztelje annak visszaállítását. Az ugyanazon lemezen lévő Git-előzmény nem független biztonsági mentés.

A munkamenetek előzménye csak egy réteg abból a kontextusból, amely megbízhatóvá teszi a Claude-ot.

Ismerje meg az Ailootot.