Come riprendere una sessione Claude Code senza perdere il filo

Riprendere una sessione Claude Code riapre la conversazione, ma il lavoro non vive soltanto nella conversazione. Nel frattempo possono essere cambiati file, branch, dipendenze, servizi locali e perfino l'obiettivo concordato dal team. Per continuare senza costruire sullo stato sbagliato, devi riallineare memoria e progetto.

Il metodo è semplice: assegna un nome riconoscibile alla sessione, lascia una nota di handoff prima di fermarti e, alla ripresa, verifica directory, Git e artefatti prima di modificare altro. I checkpoint possono aiutare a recuperare alcune modifiche, ma hanno un perimetro diverso da Git e dalle copie di sicurezza.

La documentazione Anthropic spiega che le sessioni sono collegate alla directory del progetto e che possono essere continuate o scelte tramite comandi dedicati. Indica anche che alcune impostazioni e condizioni dell'ambiente devono essere verificate di nuovo. Anthropic, sessions.

Tre stati da riallineare

Quando riapri il lavoro, considera tre stati distinti.

Il primo è la conversazione: richieste, decisioni, tentativi e risultati degli strumenti registrati nella sessione. Ti dice che cosa Claude e l'utente hanno visto o concordato, ma non garantisce che quel contenuto sia ancora attuale.

Il secondo è il filesystem: file presenti, modifiche non salvate altrove, artefatti generati, configurazioni e dipendenze. Può cambiare per mano di una persona, di un altro processo o di un'altra sessione.

Il terzo è Git: branch, commit, modifiche staged e unstaged, file non tracciati e rapporto con il remoto. Git osserva una parte del progetto, non ogni servizio o file ignorato, ma fornisce una base verificabile per capire che cosa è cambiato nel repository.

La ripresa è affidabile quando i tre livelli raccontano la stessa storia. Se la conversazione dice “test verdi” ma il branch è cambiato, quel risultato non è più una prova sufficiente. Se Git è pulito ma l'output importante è un file ignorato, devi controllarlo separatamente.

Dai un nome alla sessione utile

Un nome come sessione-3 invecchia male. Usa oggetto, risultato e, quando serve, contesto tecnico: checkout-validazione-indirizzo oppure report-vendite-import-settembre. Evita nomi che includano dati cliente, segreti o dettagli personali.

Il nome deve distinguere lavori simili nel selettore di ripresa. Non deve tentare di descrivere tutta la storia. La nota di handoff conterrà il dettaglio operativo.

Se la sessione cambia obiettivo in modo sostanziale, valuta se rinominarla oppure aprirne una nuova. Una conversazione nata per diagnosticare un bug e proseguita per rifare l'architettura può diventare difficile da ritrovare e da interpretare.

Registra anche la directory attesa. Sessioni con lo stesso nome in due worktree o copie del progetto possono vedere file diversi. Il nome aiuta la ricerca; il percorso conferma il contesto.

Lascia una nota di handoff prima di chiudere

Una nota breve nel progetto conserva ciò che serve anche se la cronologia viene riassunta o la sessione non è disponibile. Non deve duplicare ogni messaggio. Deve permettere a una persona di capire dove fermarsi, che cosa controllare e quale rischio resta aperto.

Puoi usare questo formato:

# Handoff · validazione indirizzo

Aggiornato: 2026-09-05 17:40 Europe/Rome
Sessione: checkout-validazione-indirizzo
Directory attesa: /progetti/shop
Branch atteso: fix/address-validation

## Obiettivo
Rifiutare CAP non coerenti con il paese senza cambiare il flusso ospite.

## Fatto
- riprodotto il problema con due casi minimi
- aggiunta la validazione nel modulo indirizzo
- test unitari del modulo verdi al commit indicato

## Aperto
- test end-to-end non eseguito perché il servizio locale non partiva
- testo dell'errore da rivedere con il team prodotto

## Verifica alla ripresa
- controllare branch e git status
- avviare il servizio con la configurazione corrente
- rieseguire unit e test end-to-end pertinenti

## Non fare
- non modificare lo schema del database
- non pubblicare o aprire una PR senza approvazione

Scrivi fatti e prove, non impressioni. “Sembra risolto” non dice quale caso è passato. “Tre test del modulo verdi sul commit X; end-to-end non eseguito” conserva il confine dell'evidenza.

Se la nota contiene un comando, specifica precondizioni e risultato atteso. Non copiare token o valori segreti. Indica il nome della variabile o il documento sicuro da consultare.

Riprendi con il comando adatto

La documentazione corrente elenca più modalità. claude --continue continua la sessione più recente della directory; claude --resume apre il selettore; claude --resume <nome-o-id> sceglie una sessione specifica. In una sessione attiva, /resume permette di selezionarne un'altra. Anthropic, sessions.

Usa la scorciatoia per la sessione più recente soltanto quando hai verificato directory e identità del lavoro. Se hai aperto altri task nello stesso progetto, il selettore o un nome specifico riducono l'ambiguità.

Riprendere non equivale a duplicare. La sessione continua la propria cronologia. Se vuoi esplorare un'alternativa senza modificare la storia originale, usa la funzione di fork prevista dal prodotto e un ambiente separato quando necessario.

Non affidare al comando il controllo dello stato. Appena la sessione si apre, leggi la nota di handoff e confrontala con il progetto corrente prima di chiedere nuove modifiche.

Verifica directory, branch e modifiche

Inizia con controlli in sola lettura. I comandi esatti dipendono dal progetto, ma la sequenza logica è stabile:

1. conferma il percorso di lavoro;

2. verifica branch e commit corrente;

3. elenca modifiche staged, unstaged e file non tracciati;

4. controlla se i file citati nell'handoff esistono ancora;

5. confronta le dipendenze o configurazioni cambiate;

6. individua processi o servizi necessari ai test.

Non correggere subito una differenza. Prima attribuiscila. Se compaiono modifiche che la sessione non riconosce, potrebbero appartenere a una persona o a un'altra attività. Conservale e chiedi quale stato usare; non sovrascriverle per tornare alla storia ricordata.

Una disciplina di controllo delle modifiche nei workflow AI aiuta nei processi di produzione. Nella ripresa di una sessione basta applicarne il principio: ogni differenza importante deve avere provenienza e decisione.

Controlla anche ciò che Git non vede. File ignorati, database locali, output di build e servizi possono essere cambiati. Se la prova precedente dipendeva da uno di questi elementi, ricreala oppure dichiara che non è più verificabile.

Fai riassumere il punto corrente con prove

Dopo i controlli, chiedi a Claude di ricostruire lo stato usando la nota e le evidenze attuali. La risposta dovrebbe distinguere quattro categorie: completato e verificato, completato ma da riverificare, ancora aperto, nuovo scostamento.

Un prompt utile può essere:

Leggi HANDOFF.md e confrontalo con directory, branch, git status
e file citati. Non modificare nulla.

Restituisci:
1. elementi ancora coerenti con l'handoff;
2. differenze osservate con relativa evidenza;
3. verifiche da rieseguire;
4. prossimo passo minimo e reversibile.

Non dichiarare verde un test sulla base della sola cronologia.

Il riassunto non deve riscrivere la realtà per farla coincidere con l'handoff. Se il commit non è quello atteso, questa è la prima informazione da risolvere. Se un file è stato modificato dopo la nota, la prova precedente appartiene a una versione diversa.

Solo quando il quadro è coerente scegli il prossimo passo. Preferisci un controllo piccolo che riduca l'incertezza, per esempio rieseguire il test del modulo prima dell'intera suite.

Usa i checkpoint per il loro perimetro

Claude Code crea checkpoint che possono permettere di riavvolgere conversazione, modifiche al codice o entrambe. La documentazione precisa però che il meccanismo riguarda le modifiche effettuate con gli strumenti di editing di Claude Code. Non registra tutto ciò che può cambiare nel progetto. Anthropic, checkpointing.

In particolare, modifiche prodotte da comandi shell o processi esterni non sono coperte nello stesso modo. Se un comando ha generato file, eseguito una migrazione o cambiato dati locali, un rewind della conversazione non garantisce il ripristino di quegli effetti.

I checkpoint servono per tornare a un punto della sessione o recuperare un edit nel perimetro documentato. Git serve a versionare il repository, confrontare stati e condividere una storia di modifiche. Le copie di sicurezza proteggono dati e file secondo un altro perimetro ancora. Nessuno dei tre strumenti sostituisce automaticamente gli altri.

Prima di usare un ripristino, controlla che cosa verrà cambiato e conserva il lavoro altrui. Non usare il rewind come scorciatoia per eliminare differenze che non hai attribuito.

Quando conviene iniziare una sessione nuova

Apri una sessione nuova quando cambia l'obiettivo, quando la cronologia è dominata da un'ipotesi ormai scartata oppure quando devi lavorare in un ambiente isolato. Una nuova sessione riduce il contesto ereditato, ma richiede un briefing completo e una verifica dello stato.

Non aprirla soltanto perché il lavoro è difficile. Se la conversazione contiene decisioni ancora valide e il progetto è coerente, riprendere può evitare di ricostruire il percorso. Il criterio è la qualità del contesto, non l'età della sessione.

Le istruzioni persistenti del progetto possono stare in CLAUDE.md, secondo la documentazione Anthropic sulla memoria. Anthropic, project memory. Non usare però quel file come diario del singolo task: regole stabili e stato temporaneo hanno funzioni diverse.

Se avvii una nuova sessione, forniscile obiettivo, vincoli, nota di handoff e stato verificato. Non chiedere alla vecchia sessione un riassunto e trattarlo come prova sufficiente senza confrontarlo con i file.

Un protocollo di ripresa in sette minuti

Il tempo è indicativo, non un requisito. La sequenza serve a evitare che i primi minuti vengano spesi a modificare lo stato sbagliato.

1. Apri la directory e verifica che sia il progetto atteso.

2. Controlla branch, commit e modifiche locali.

3. Riprendi la sessione specifica tramite nome, ID o selettore.

4. Leggi l'handoff e individua prove scadute o passaggi incompleti.

5. Chiedi un confronto in sola lettura fra nota e stato attuale.

6. Riesegui la verifica minima pertinente.

7. Aggiorna la nota prima di ripartire con nuove modifiche.

Se compare una differenza non attribuita, il protocollo si ferma. I sette minuti non sono un obiettivo da rispettare a costo della chiarezza. La ripresa è completa quando sai su quale stato stai lavorando e quale prova serve dopo.

Per task soggetti a retry o automazioni, aggiungi un identificatore del run e una regola di idempotenza. L'articolo sui retry idempotenti nei workflow AI approfondisce come evitare che una ripresa produca due effetti esterni indistinguibili.

Applica il protocollo a un progetto

Scegli una sessione non sensibile e prepara l'handoff prima di chiuderla. Il giorno dopo, prova a ricostruire lo stato senza affidarti alla memoria. Il punto debole emergerà presto: nome poco chiaro, prova non registrata, branch ambiguo o file non tracciato.

Nel programma per lavorare con Claude Cowork e Code di MAIKER HUB puoi applicare il protocollo a un progetto, distinguere memoria e stato e progettare verifiche che restino comprensibili anche dopo una pausa. Porta un repository di esercitazione o un caso privo di dati riservati.