Come usare i checkpoint di Claude Code senza perdere lavoro

Claude Code modifica quattro file, poi capisci che la richiesta iniziale era sbagliata. Apri il rewind e torni indietro. Il codice sembra ripristinato, ma uno script eseguito nel frattempo ha generato altri file e una seconda sessione aveva una modifica non salvata nello stesso progetto.

Il checkpoint è utile perché permette di tornare a una fase precedente della conversazione e delle modifiche dirette. Diventa pericoloso soltanto quando lo tratti come un backup completo dell'ambiente.

Prima di ripristinare devi sapere che cosa è coperto, che cosa appartiene a te e quali conseguenze vivono fuori dal checkpoint. La procedura corretta non parte dal pulsante «indietro». Parte da un inventario.

Che cosa salva un checkpoint

La documentazione sul checkpointing spiega che Claude Code crea un checkpoint prima di ogni prompt e tiene traccia delle modifiche dirette ai file effettuate durante la sessione. Dal menu di rewind puoi scegliere di ripristinare il codice, la conversazione oppure entrambi.

Le tre scelte rispondono a problemi diversi:

• ripristinare la conversazione ti permette di ripartire da un punto precedente del ragionamento;

• ripristinare il codice annulla le modifiche dirette coperte dal checkpoint;

• ripristinare entrambi riallinea conversazione e modifiche a quel momento.

Il fatto che esistano opzioni separate è importante. A volte vuoi tenere una buona modifica e cambiare soltanto la direzione della conversazione. Altre volte vuoi annullare il codice senza perdere le osservazioni emerse dopo.

Checkpoint non significa backup completo

Il checkpoint non fotografa ogni stato raggiungibile dalla sessione. Anthropic documenta limiti precisi: le modifiche effettuate tramite comandi Bash, i processi esterni, gli interventi manuali e il lavoro di sessioni concorrenti possono non essere inclusi nel ripristino.

Immagina che Claude modifichi un file sorgente e poi esegua uno script di generazione. Il checkpoint può conoscere la modifica diretta, ma non devi presumere che ogni file prodotto dal comando venga riavvolto nello stesso modo. Se il comando ha scritto in un database o chiamato un servizio esterno, quella conseguenza vive fuori dal meccanismo locale.

Per questo il rewind non è una promessa di ritorno universale. È uno strumento con un perimetro dichiarato.

La mappa di copertura

Prima di usarlo, classifica lo stato in cinque aree:

La colonna non deve diventare una certezza basata sul tipo di file. Serve a decidere cosa ispezionare. Anche una modifica visibile nell'editor può appartenere a una persona o a un'altra sessione.

Se non riesci ad assegnare la proprietà di un cambiamento, fermati. Annullarlo potrebbe cancellare lavoro valido.

Prima del rewind fai l'inventario

Segui una sequenza breve.

1. Ferma nuove modifiche e altre sessioni che lavorano sullo stesso stato.

2. Inventaria file cambiati, file non tracciati e conseguenze esterne già avvenute.

3. Attribuisci ogni cambiamento alla sessione, a un comando, a una persona o a un altro processo.

4. Scegli il checkpoint e la componente minima da ripristinare.

5. Confronta lo stato prima e dopo.

6. Prova il comportamento che volevi recuperare.

Non fare affidamento sulla memoria della conversazione per l'inventario. Usa gli strumenti del repository e, se esistono, i registri dei servizi coinvolti.

Leggi lo stato Git prima di toccare qualcosa

git status mostra quali file sono modificati, preparati o non tracciati rispetto al repository. git diff mostra le differenze nel contenuto. La documentazione di Git sullo stato e quella sul confronto delle modifiche sono il riferimento per interpretare questi comandi.

Prima del rewind conserva almeno:

• elenco dei file modificati e non tracciati;

• diff delle modifiche che vuoi attribuire alla sessione;

• eventuali file già in staging;

• branch o commit di partenza;

• nota sulle attività parallele.

Non è necessario creare un commit per ogni tentativo. Devi però essere in grado di distinguere ciò che esisteva prima dalla parte che vuoi annullare.

Scegli il ripristino più piccolo

Se il problema è una direzione sbagliata nella conversazione, riavvolgi soltanto la conversazione. Se il codice è errato ma le osservazioni successive sono utili, valuta il ripristino del codice. Ripristina entrambi solo quando vuoi davvero tornare a quel punto in tutte e due le dimensioni.

Ridurre la portata facilita il confronto. Un ripristino ampio può eliminare cambiamenti validi insieme a quelli sbagliati e rende più difficile capire quale parte ha corretto il problema.

Prima di confermare, formula l'obiettivo in una frase: «Voglio rimuovere le modifiche introdotte dopo la richiesta X, conservando il lavoro manuale sul file Y». Se lo strumento non può garantire quel confine, salva o separa prima il lavoro da proteggere.

Come aprire il rewind

La documentazione corrente indica che puoi aprire il menu di rewind premendo Esc due volte oppure usando /rewind. Da lì scegli un checkpoint e il tipo di ripristino.

Considera questi dettagli come interfaccia, non come procedura completa. Prima vengono inventario e proprietà; dopo vengono confronto e prove. Se la scorciatoia cambia in una versione futura, il metodo resta valido.

Non eseguire il rewind mentre altre attività continuano a scrivere sugli stessi file. Congela prima il perimetro oppure lavora su una copia o un worktree separato.

Controlla che cosa è rimasto dopo

Dopo il ripristino esegui di nuovo git status e git diff. Confronta l'elenco dei file con l'inventario precedente e cerca tre categorie:

• modifiche attese che sono scomparse;

• modifiche valide che non dovevano essere toccate;

• conseguenze non coperte che sono ancora presenti.

Poi esegui i test pertinenti. Tornare a un diff precedente non dimostra che il progetto sia in uno stato funzionante. Un file generato, una cache o un database locale possono essere rimasti disallineati.

Applica il principio del controllo delle modifiche nei workflow AI: stato iniziale, delta reale ed esito delle prove devono restare distinguibili.

Gestisci separatamente Bash e file generati

Se durante la sessione è stato eseguito un formatter, un generatore o uno script, ricostruisci la sua conseguenza prima del rewind. Leggi il comando, identifica quali file o dati può aver cambiato e controlla lo stato attuale.

Non cancellare file generati solo perché non compaiono nel checkpoint. Potrebbero esistere prima della sessione o essere condivisi con un altro processo. Se devono essere rigenerati, usa la procedura del progetto e confronta il risultato.

Per comandi che alterano dati, tratta l'operazione come una migrazione o un intervento separato. Serve una procedura esplicita di recupero, non un'ipotesi basata sul ritorno del codice.

Le conseguenze esterne non tornano indietro

Un push, un deploy, una pubblicazione, un invio o una scrittura su un database remoto non vengono annullati ripristinando la conversazione. Ogni sistema esterno ha il proprio stato, le proprie ricevute e un eventuale processo di compensazione.

Prima di intervenire:

• verifica se la conseguenza è avvenuta davvero;

• identifica chi è autorizzato a modificarla;

• usa la procedura prevista dal servizio;

• conserva una traccia del prima e del dopo;

• evita un secondo tentativo automatico se l'esito è incerto.

La guida al fallback manuale nei workflow AI aiuta a definire uno stop sicuro quando il recupero automatico non copre il sistema coinvolto.

Checkpoint e Git lavorano insieme

I checkpoint sono comodi per esplorare alternative dentro una sessione. Git conserva una cronologia durevole e condivisibile del progetto. Nessuno dei due va usato come imitazione incompleta dell'altro.

Puoi usare il checkpoint per tornare rapidamente a un prompt precedente e Git per sapere quali differenze esistono rispetto a un commit noto. Prima di una modifica ampia, un branch o un commit pulito rende il punto di partenza più leggibile. Durante il lavoro, il diff permette di controllare ciò che è cambiato anche se non vuoi ancora consolidarlo.

Un audit trail del workflow AI serve quando la decisione deve restare comprensibile oltre la singola sessione: chi ha autorizzato, quale prova è stata raccolta e quale stato è stato raggiunto.

Prova il recupero prima dell'emergenza

Non imparare il rewind su un progetto con lavoro non salvato di altre persone. Crea un ambiente controllato, modifica due file innocui, esegui un comando che produce un terzo effetto e prova le tre opzioni di ripristino. Osserva che cosa torna indietro e che cosa resta.

Registra la procedura adatta al tuo progetto:

• come congelare attività concorrenti;

• quali comandi mostrano lo stato;

• quali directory contengono artefatti generati;

• quali sistemi esterni richiedono una verifica separata;

• quali prove confermano il recupero.

La prova trasforma un pulsante rassicurante in una procedura conosciuta.

Costruisci una procedura di recupero minima

Scrivi una scheda con cinque righe: ferma, inventaria, ripristina il minimo, confronta, prova. Aggiungi i comandi reali del tuo progetto e un elenco dei sistemi che il checkpoint non può coprire. Poi eseguila in un ambiente senza dati importanti.

Nel programma su Claude Cowork e Code di MAIKER HUB puoi costruire e verificare questa procedura sul tuo flusso. Il checkpoint è utile quando sai esattamente quale parte del lavoro stai affidando al rewind e quale parte richiede ancora la tua verifica.