# Claude Code elimina la cronologia dopo 30 giorni: come salvarla > Dove vengono archiviate le sessioni di Claude Code, come configurare cleanupPeriodDays e come organizzare un archivio esterno usando rsync, launchd o cron. Source: https://ailoot.ai/blog/it/claude-code-history-30-days/ Canonical: https://ailoot.ai/blog/it/claude-code-history-30-days/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-056 Revision: sha256-a91caf8aea6d0083911b1d00449a3a19990eefbba1c1db54b9a2c63f89ba7a7e Per assistenza sull’uso del servizio, consulta la [documentazione di Ailoot](https://ailoot.ai/docs/). ## Claude Code elimina davvero la cronologia delle sessioni?
Punti chiave Sì. Ogni volta che Claude Code si avvia, elimina i file delle sessioni più vecchi di 30 giorni. La responsabile è l’impostazione `cleanupPeriodDays` in `~/.claude/settings.json`; il suo valore predefinito è `30`. L’eliminazione avviene senza avvisi, senza chiedere il consenso e senza possibilità di recuperare i file.
Apri Claude Code per riprendere una sessione di due mesi fa, ma non c’è più. Il file è stato completamente cancellato dal disco. Non è un malfunzionamento né un bug raro: è così che funziona il meccanismo di pulizia predefinito. La pulizia è controllata da un’unica impostazione: `cleanupPeriodDays`. Il suo valore predefinito è `30`. Ogni volta che Claude Code si avvia, esamina la cartella della cronologia ed elimina tutto ciò che è più vecchio di quel periodo. Nel mio `~/.claude/settings.json` questa impostazione non era proprio presente, quindi era attivo il valore predefinito e alcune delle mie sessioni più vecchie erano già sparite. Nel repository di Anthropic sono aperte diverse segnalazioni di bug al riguardo e nessuna è stata risolta. ## Dove archivia Claude Code la cronologia delle sessioni?
Punti chiave La cronologia di ogni sessione è archiviata in `~/.claude/projects//.jsonl`. Il nome della cartella corrisponde al percorso assoluto della directory di lavoro da cui hai eseguito Claude Code, con le barre sostituite da trattini. Il file `.jsonl` contiene l’intera conversazione, una riga alla volta: i tuoi prompt, le risposte del modello, le chiamate agli strumenti e le modifiche ai file. È proprio questa memoria che la pulizia elimina.
Trovare la cronologia è facile. Apri un terminale e guarda il contenuto della cartella: ```bash ls ~/.claude/projects/ ``` Ogni sottocartella corrisponde a un progetto. Il suo nome codifica il percorso: per esempio, un progetto in `/Users/alex/dev/shop` diventa la cartella `-Users-alex-dev-shop`. Al suo interno trovi i file delle sessioni: ```bash ls -lt ~/.claude/projects/-Users-alex-dev-shop/ # 3f8a1c2e-....jsonl ← una sessione = un file # a91b7d40-....jsonl ``` Ogni `.jsonl` è un registro riga per riga: una riga equivale a un evento della sessione. Contiene molto più del testo della conversazione. Racchiude la logica dietro le tue decisioni: perché hai scelto una certa struttura del database, quali opzioni hai scartato, dove Claude ha sbagliato e come hai corretto l’errore. In sostanza, è un diario dello sviluppo del progetto. Ecco perché perderlo fa male: non perdi una «chat», ma il contesto che hai costruito nel corso di settimane. Ho descritto la struttura di questo contesto nella guida [«Claude Memory vs. CLAUDE.md»](https://ailoot.ai/blog/it/claude-memory-claude-md-auto-memory/). ## Perché Anthropic elimina le trascrizioni dopo 30 giorni?
Punti chiave La posizione di Anthropic riguarda la privacy e la sicurezza. I file delle sessioni sono archiviati in testo semplice sul disco e possono contenere codice sorgente, password e chiavi API. Conservarli per sempre è rischioso: se un portatile viene rubato o qualcuno riesce ad accedere al disco, ottiene tutti quei dati sensibili. Il periodo di 30 giorni è il compromesso scelto tra «riprendere il lavoro recente» e «non conservare segreti sul disco più a lungo del necessario».
L’eliminazione ha una motivazione, che vale la pena capire prima di disattivarla del tutto. Una trascrizione è testo semplice. Se durante una sessione Claude ha letto un file `.env`, inserito una chiave in un comando o tu hai incollato una password in un prompt, tutto è finito nel `.jsonl` in testo semplice. Più a lungo un file del genere resta sul disco, maggiore è la possibilità che un giorno venga divulgato. Anthropic lo dice chiaramente: le trascrizioni possono contenere codice sorgente, credenziali e altro materiale sensibile, e conservarle sul disco più a lungo del necessario crea un reale rischio per la privacy. Il periodo di 30 giorni è stato scelto come compromesso. Le obiezioni della community riguardano tre aspetti: l’eliminazione è silenziosa (non viene mostrato alcun avviso durante la configurazione o all’avvio), manca il consenso (non ti viene chiesto) e non c’è modo di recuperare i file (non viene usato il Cestino e non è possibile annullare l’operazione). Nella segnalazione \#59248, gli sviluppatori chiedono una sola cosa: rendere equa la pulizia, con un avviso, un periodo di recupero e un periodo predefinito meno aggressivo. ## Perché uno script di backup può provocare l’eliminazione?
Punti chiave La pulizia decide quali file eliminare in base all’ora di modifica del file (mtime). Non controlla l’effettiva attività più recente di una sessione. Qualsiasi processo che tocchi un file `.jsonl` — sincronizzazione cloud, rsync, editor o script — può modificarne il valore mtime, facendo sembrare vecchia una sessione recente. Al successivo avvio di Claude Code, la sessione verrà considerata vecchia ed eliminata. Il paradosso: un tentativo ingenuo di fare il backup della cronologia nella cartella gestita ne accelera la perdita.
Questa è la parte più insidiosa e trae in inganno chi cerca di proteggere i propri dati. La pulizia controlla il valore mtime, cioè l’ora dell’ultima modifica del file. Presume che mtime indichi l’ultima volta che hai lavorato nella sessione. In pratica, qualsiasi cosa può modificare mtime: un client di sincronizzazione Dropbox o iCloud, `rsync`, un antivirus, un indicizzatore o il tuo script di backup. Ecco la trappola. Decidi di salvare la cronologia e configuri la sincronizzazione cloud per `~/.claude/projects/`. A un certo punto, il servizio di sincronizzazione riscrive un file e gli assegna una data mtime precedente (può succedere quando viene ripristinata una copia dal cloud). All’avvio, Claude Code vede un file «vecchio» e lo elimina. Volevi salvarlo, ma ne hai accelerato l’eliminazione. La conclusione è una sola: **il backup deve trovarsi fuori da `~/.claude/projects/`**. La pulizia agisce solo all’interno di questa cartella. Una copia archiviata altrove è fuori dalla sua portata. La soluzione che propongo si basa su questo principio. ## Come puoi fermare subito l’eliminazione della cronologia?
Punti chiave Basta un’impostazione. Apri `~/.claude/settings.json` e imposta `cleanupPeriodDays` su un numero elevato, per esempio `3650` (dieci anni). In pratica, disattiva l’eliminazione automatica: nulla supererà il limite. Importante: questa impostazione protegge solo ciò che non è ancora stato eliminato. La cronologia già cancellata dalla pulizia non può essere ripristinata. Quindi il primo passo è agire prima di perdere un’altra sessione.
Ferma l’eliminazione in tre passaggi: 1. Apri il file delle impostazioni: `~/.claude/settings.json` (se non esiste, crealo). 2. Aggiungi l’impostazione `cleanupPeriodDays` con un valore elevato: ```json { "cleanupPeriodDays": 3650 } ``` 3. Salva il file. L’impostazione entrerà in vigore al successivo avvio di Claude Code. Il valore `3650` corrisponde a dieci anni: in pratica, l’eliminazione non avverrà più. Se vuoi mantenere la pulizia ma avere più tempo, impostalo su `365` (un anno); a quel punto scompariranno solo le sessioni più vecchie di un anno. Puoi verificare se l’impostazione è stata recepita con questo comando: ```bash grep cleanupPeriodDays ~/.claude/settings.json ``` C’è un’avvertenza facile da trascurare: estendere il periodo NON ripristina ciò che è già stato eliminato. La pulizia viene eseguita all’avvio e tutto ciò che è stato cancellato nelle esecuzioni precedenti è perso per sempre. Ecco perché dovresti impostare questo valore per primo: previene le perdite future, ma non recupera quanto è già stato cancellato. Se vuoi evitare di perdere la cronologia di Claude Code e il progetto a causa di un comando accidentale, consulta la guida [«Come configurare Claude Code affinché non danneggi il tuo progetto»](https://ailoot.ai/blog/it/claude-code-safe-overnight-setup/). La cronologia delle sessioni fa parte del secondo cervello del tuo progetto: contiene una logica decisionale che non hai registrato altrove. `cleanupPeriodDays` salva i file, ma non li trasforma in un sistema che ti permette di recuperare ciò che ti serve tra sei mesi. ## Come archiviare automaticamente la cronologia fuori dalla cartella di pulizia?
Punti chiave Copia le sessioni in un archivio FUORI da `~/.claude/projects/`, dove la pulizia non si applica. Basta un semplice `rsync -a` al giorno verso una directory separata: i nuovi file vengono aggiunti e quelli vecchi restano. Poiché l’archivio si trova all’esterno, né `cleanupPeriodDays` né il bug di mtime lo riguardano. Automatizza l’esecuzione con launchd (macOS) o cron (Linux) e la tua cronologia crescerà da sola.
L’idea è semplice: lascia che Claude Code faccia ciò che vuole nella sua cartella, mentre tu conservi un archivio separato all’esterno. È protetto da quel meccanismo di pulizia, ma può ancora perdersi per guasti del disco, eliminazioni accidentali o copie fallite. Configuralo così: 1. Crea una cartella di archivio fuori dalla directory gestita: ```bash mkdir -p ~/claude-history-archive ``` 2. Copiaci la cronologia attuale. Il flag `-a` conserva la struttura e i timestamp; `--ignore-existing` lascia invariati i file già copiati: ```bash rsync -a ~/.claude/projects/ ~/claude-history-archive/ ``` 3. Automatizza l’esecuzione quotidiana. Su macOS, usa launchd. Crea il file `~/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. Carica l’agente perché venga eseguito in background: ```bash launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist ``` Su Linux, basta aggiungere una riga a crontab (`crontab -e`): ```bash 0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/ ``` Perché funziona, mentre la sincronizzazione della sezione precedente fallisce? L’archivio si trova FUORI da `~/.claude/projects/`, quindi la pulizia non può proprio vederlo. La copia avviene in una sola direzione (dalla cartella attiva all’archivio) e non tocchiamo mtime dei file attivi: quindi il problema di mtime non si verifica. Anche se domani Claude Code elimina una sessione dalla sua cartella, la copia resterà nell’archivio. ## Come trasformare l’archivio delle sessioni in un secondo cervello consultabile?
Punti chiave Metti l’archivio sotto git e otterrai un database con versionamento e completamente consultabile di tutte le tue sessioni. Esegui `git init` nella cartella dell’archivio, poi ogni giorno `git add -A && git commit` per avere una cronologia delle modifiche e proteggerti dalle sovrascritture accidentali. Puoi cercare le sessioni passate con il normale grep ed estrarre contenuti strutturati con jq, dato che `.jsonl` contiene JSON delimitato da righe. Così l’archivio diventa uno strumento pratico.
Non basta accumulare file: devi poterli consultare. Due passaggi trasformano l’archivio in uno strumento operativo. Per prima cosa, crea le versioni con git. Inizializza un repository nella cartella dell’archivio: ```bash cd ~/claude-history-archive git init git add -A && git commit -m "First snapshot of Claude Code history" ``` Aggiungi `git add -A && git commit` alla stessa esecuzione quotidiana di rsync. Ora hai una cronologia delle versioni: puoi vedere cosa è comparso e quando, e annullare una sovrascrittura accidentale con un solo comando. In secondo luogo, cerca. I file `.jsonl` sono JSON delimitati da righe, quindi puoi usare gli strumenti che già conosci. Trova le sessioni in cui si è discusso di un determinato argomento: ```bash grep -rl "database migration" ~/claude-history-archive/ ``` Estrai solo il testo dei tuoi prompt da una sessione (usando jq, dato che è JSON): ```bash jq -r 'select(.type=="user") | .message.content' session.jsonl ``` A questo punto, la cronologia delle sessioni inizia a funzionare come il secondo cervello di un progetto: un database in cui puoi recuperare in pochi secondi «come abbiamo preso questa decisione a marzo». Per una spiegazione separata di dove finisce il contesto in una sessione e di come gestirlo, consulta [«Dove vanno i token in Claude Code»](https://ailoot.ai/blog/it/where-claude-code-tokens-go/). ## È possibile recuperare sessioni già eliminate?
Punti chiave Non esiste un metodo integrato. Claude Code non sposta i file eliminati nel Cestino e non conserva una cronologia degli annullamenti: il file viene cancellato per sempre. L’unica possibilità sono copie esterne create PRIMA dell’eliminazione: uno snapshot di Time Machine su macOS, la cronologia delle versioni di OneDrive o Dropbox oppure un backup manuale. Se non ne esistono, la sessione è persa. Ecco perché la protezione va configurata in anticipo, prima di avere qualcosa da perdere.
La risposta onesta è: probabilmente no. Claude Code non dispone di una funzione di ripristino, di un Cestino né di un registro degli annullamenti per le trascrizioni eliminate. Il file semplicemente scompare dal disco. C’è un’unica possibilità: i backup del sistema, se erano stati abilitati in anticipo: 1. **Time Machine su macOS**: se uno snapshot ha acquisito `~/.claude/projects/` prima dell’eliminazione, puoi recuperare il file dal backup relativo alla data richiesta. 2. **Cronologia delle versioni di OneDrive / Dropbox**: se la cartella era sincronizzata con il versionamento attivato, cerca il file nella cronologia delle versioni del cloud (ma ricorda la trappola di mtime: la sincronizzazione potrebbe aver provocato l’eliminazione). 3. **Copie manuali**: qualsiasi `rsync`/`cp` che hai eseguito manualmente verso una destinazione esterna alla cartella gestita. Se non esisteva nessuna di queste copie, la sessione è persa. E non è un caso raro: un autore di un bug nel repository di Anthropic ha riscontrato la corruzione di 26 record su 38, equivalenti a mesi di lavoro. L’unica protezione affidabile è quella predisposta PRIMA della perdita. Imposta oggi `cleanupPeriodDays` e l’archiviazione automatica, finché c’è ancora qualcosa da salvare. ## Quale valore scegliere per cleanupPeriodDays?
Punti chiave Per la maggior parte delle persone, usa `3650` (dieci anni, che di fatto disattiva l’eliminazione) insieme a un archivio automatico esterno. Mantieni il valore predefinito `30` solo se non ti serve la cronologia e per te è più importante non conservare segreti sul disco. Il valore `365` è una via di mezzo ragionevole, con pulizia annuale. Un’altra opzione è non salvare proprio la cronologia: usa la variabile d’ambiente `CLAUDE_CODE_SKIP_PROMPT_HISTORY` o il flag `--no-session-persistence`, ma questo ha lo scopo opposto.
C’è una sola impostazione, ma può servire a scopi diversi. Confronta le opzioni e scegli quella adatta al tuo caso: | Valore | Cosa fa | A chi è adatto | |----|----|----| | `30` (predefinito) | All’avvio elimina le sessioni più vecchie di 30 giorni | Non ti serve la cronologia; per te è più importante evitare di archiviare dati sensibili sul disco | | `365` | Conserva un anno di cronologia, poi la pulisce una volta all’anno | Ti serve la cronologia recente, ma non un archivio permanente | | `3650` | Di fatto disattiva l’eliminazione | Vuoi conservare tutto + un archivio esterno (consigliato) | | `CLAUDE_CODE_SKIP_PROMPT_HISTORY` | Non scrive affatto la cronologia sul disco | Privacy massima; non ti serve proprio la cronologia | Un’importante avvertenza di sicurezza: se imposti `3650` e conservi tutto, accetti di archiviare sul disco trascrizioni che possono contenere chiavi e codice. È un compromesso consapevole tra praticità dell’archivio e rischio. Riduci il rischio: conserva l’archivio su un disco cifrato (FileVault su macOS), non metterlo in un cloud pubblico e non inserirlo in un repository git pubblico. Ho preparato una guida separata sui dati che possono essere divulgati attraverso Claude Code: [«Sicurezza dei dati in Claude Code»](https://ailoot.ai/blog/it/claude-code-data-access-safety/). ## Cosa fare oggi: checklist
Punti chiave Questi passaggi riducono le perdite: estendi la conservazione con `cleanupPeriodDays: 3650`, copia le sessioni fuori da `~/.claude/projects/` e versiona l’archivio. Solo i file copiati con successo sono protetti dalla pulizia di Claude Code. Una pianificazione quotidiana lascia fino a un giorno di modifiche non archiviate se funziona; esecuzioni fallite o saltate ampliano l’intervallo. Una copia sullo stesso disco non protegge dai suoi guasti.
Configura la protezione passo dopo passo: 1. Imposta `cleanupPeriodDays: 3650` in `~/.claude/settings.json`: hai esteso il periodo di conservazione. 2. Crea `~/claude-history-archive` fuori dalla cartella gestita ed esegui il primo `rsync -a`. 3. Pianifica un’esecuzione quotidiana con launchd (macOS) o cron (Linux). 4. Inizializza git nell’archivio e aggiungi `git add -A && git commit` alla stessa esecuzione. 5. Verifica che l’archivio si trovi su un disco cifrato e non venga sincronizzato con un cloud pubblico. 6. Controlla la riuscita di ogni copia pianificata, esamina una sessione recente archiviata e ripristina periodicamente un campione in una cartella temporanea separata per verificarne la leggibilità. 7. Se vuoi coprire la perdita del dispositivo o del disco, conserva un backup indipendente con accessi adeguati e provane il ripristino. La cronologia Git sullo stesso disco non è un backup indipendente. La cronologia delle sessioni è solo uno dei livelli di contesto che rendono Claude affidabile.
### Fonti - [Documentazione di Claude Code - impostazioni di settings.json (cleanupPeriodDays)](https://code.claude.com/docs/en/settings) - [Documentazione di Claude Code - novità](https://code.claude.com/docs/en/whats-new)
Scopri [Ailoot](https://ailoot.ai/). ## Domande frequenti ### Un archivio quotidiano garantisce che nessuna sessione possa andare persa? No. Protegge dalla pulizia della cartella gestita i file copiati con successo. Anche con esecuzioni quotidiane riuscite può mancare fino a un giorno di modifiche recenti; i guasti aumentano l’intervallo e una copia sullo stesso disco può perdersi con l’originale. ### Come verifico che l’archivio sia utilizzabile? Conferma la riuscita delle copie pianificate, esamina una sessione recente e ripristina periodicamente un campione in una cartella temporanea separata. Per proteggerti dalla perdita del dispositivo o disco, prova anche il ripristino di un backup conservato indipendentemente. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.