Claude Code Checkpoints und /rewind: dein Sicherheitsnetz fuer riskante Edits

Du lässt Claude Code dreissig Minuten lang refactoren, schaust kurz auf den Bildschirm, und der Test-Runner brennt rot. Drei Files sind kaputt, du weißt nicht mehr genau welcher Prompt was angefasst hat, und git diff zeigt einen Wall aus Änderungen. Genau für diesen Moment gibt es Checkpoints. Jeder Prompt den du absetzt erzeugt automatisch einen Snapshot deiner Files, und mit /rewind (oder zweimal Esc) springst du auf jeden Punkt der Session zurück. Ich nutze das mittlerweile zehnmal am Tag und will nicht mehr ohne arbeiten.

Hier sind die zehn Schritte mit denen du Checkpoints richtig einsetzt. Du sparst dir damit den Reflex jede Minute zu committen und kannst trotzdem aggressiv experimentieren.

Schritt 1: Verstehen was getrackt wird (und was nicht)

Claude Code legt bei jedem Prompt einen Checkpoint deiner Files an, aber NUR für Dateien die über Claudes Edit-Tools angefasst werden. Wenn Claude einen Bash-Command läuft wie rm file.txt oder mv old.txt new.txt, ist das für Checkpoints unsichtbar. Externe Änderungen die du im Editor machst sind ebenfalls aussen vor.

Heißt: Checkpoints sind kein Git-Ersatz. Sie sind ein Session-Undo für AI-Edits. Für den Long-Term-Verlauf bleibt Git zustaendig. Wenn dir das klar ist, vermeidest du den klassischen Anfänger-Fehler "ich rewind das mal eben" wenn ein npm install was kaputt gemacht hat. Bash-Stuff bleibt kaputt.

Schritt 2: Den Rewind-Menü öffnen

Tipp /rewind ein oder drück zweimal Esc wenn die Prompt-Zeile leer ist. Achtung: wenn da noch Text drin steht, leert Esc zuerst das Input-Feld (der Text landet in der History, hol ihn mit Pfeil-hoch zurück). Erst beim zweiten leeren Esc öffnet sich das Menü.

Das Rewind-Menü listet jeden Prompt den du in der Session abgesetzt hast, von oben (alt) nach unten (neu). Pfeil hoch und runter scrollt durch die Punkte, Enter wählt einen aus.

Schritt 3: Restore Code and Conversation (der harte Reset)

Die Standard-Option. Dreht sowohl deine Files als auch den Chat-Verlauf auf den Zustand vor dem ausgewaehlten Prompt zurück. Der urspruengliche Prompt landet wieder in der Input-Zeile, du kannst ihn editieren und neu schicken.

Das ist mein Default bei "ich habe Claude in die falsche Richtung geschickt vor zehn Minuten". Ein Klick, alles zurück, anderer Prompt, weiter geht's. Spart 20 Minuten Diskussion mit Claude wo er was falsch verstanden hat.

Schritt 4: Restore Code (Files zurück, Chat behalten)

Du willst den Code zurück weil ein Refactor was kaputt gemacht hat, aber die Discussion war eigentlich gut. Nimm "Restore Code". Files springen zurück, der Chat bleibt komplett erhalten.

Nuetzlich wenn Claude in der Discussion bereits den Fehler erkannt hat ("ah ich habe das Modul falsch importiert"), du aber nicht moechtest dass er die Änderung jetzt nochmal von Null aufrollt. Files zurück, dann sagen "ok bitte den Import-Fehler beheben aber sonst alles lassen".

Schritt 5: Restore Conversation (Chat zurück, Code behalten)

Spiegel-Variante. Den Chat-Verlauf willst du wegschneiden weil du ihn aus Versehen mit Side-Quests vollgeballert hast, aber der Code-Stand soll bleiben. Gute Wahl wenn Claude dreissig Minuten lang über das falsche Design-Pattern philosophiert hat, du aber den letzten funktionierenden Stand der Files behalten willst.

Effektiv ist das auch eine Form von Kontext-Reset ohne den Workspace zu verlieren.

Schritt 6: Summarize from here vs. Summarize up to here

Die zwei Summarize-Optionen sind das Killer-Feature wenn dein Kontextfenster vollläuft. Sie ersetzen Teile des Chats durch eine AI-generierte Zusammenfassung und schaffen so Platz.

• Summarize from here: Alles VOR dem ausgewaehlten Prompt bleibt im Detail erhalten, der ausgewaehlte Prompt und alles danach werden zur Summary verdichtet. Nuetzlich wenn du eine wilde Debug-Session hattest und nur den Initial-Plan im Detail brauchst.
• Summarize up to here: Spiegelbild. Alles VOR dem ausgewaehlten Prompt wird verdichtet, ab dort bleibt es im Detail. Klassischer Setup-Reset: Früher Setup-Kram wird zur Summary, deine letzten 20 Minuten produktive Arbeit bleiben unangetastet.

Beide Varianten halten die Original-Messages im Session-Transkript, Claude kann sie also bei Bedarf noch referenzieren. Das ist gezielter als /compact welches einfach alles platt macht.

Schritt 7: Den Fork-Trick für Experimente kennen

Wenn du eine Alternative ausprobieren willst OHNE die laufende Session zu beruehren, ist Rewind die falsche Wahl. Nimm Fork: claude --continue --fork-session. Damit erstellst du einen Branch der Session, die Original-Session bleibt unangetastet.

Praktisches Pattern: Wenn ich unsicher bin ob ein Ansatz funktioniert, fork ich die Session, probier den Ansatz im Fork. Klappt es nicht, schmeisse ich den Fork weg und arbeite im Original weiter. Klappt es, merge ich die Files manuell rueber (oder mache es zur neuen Haupt-Session).

Schritt 8: 30-Tage-Persistenz nutzen

Checkpoints leben 30 Tage und ueberdauern Session-Restarts. Wenn du am Montag eine Session beendest und am Mittwoch mit claude --continue wieder reinkommst, sind alle Checkpoints noch da. Du kannst Tage später zurückspringen auf den Punkt wo Test A gruen war.

Pflicht-Routine: Wenn du einen wirklich kritischen Stand erreichst (Tests gruen, Deploy-ready), mach trotzdem einen Git-Commit. Checkpoints sind ein Komfort-Feature, kein Backup-System. 30 Tage sind schnell weg wenn du krank wirst oder Urlaub hast.

Schritt 9: Combo mit Plan-Mode und Sub-Agents

Wo Checkpoints richtig stark werden: in Kombination mit Plan-Mode. Plan-Mode lässt dich einen Schritt-für-Schritt-Plan vor der Ausführung absegnen. Wenn Claude während der Ausführung dann doch falsch abbiegt, rewind du auf den Punkt VOR dem Approval, korrigierst den Plan, lass nochmal laufen.

Das gleiche gilt für Sub-Agents. Wenn ein Sub-Agent in der Tiefe was Bloedes baut, ist es einfacher den Haupt-Prompt zu rewinden als zu versuchen den Sub-Agent-Output rückwärts zu reparieren.

Lies zu Plan-Mode unser Plan-Mode richtig nutzen Playbook, zum Sub-Agent-Setup Erster Sub-Agent in 30 Min.

Schritt 10: Anti-Patterns vermeiden

Drei Fehler die ich oft sehe und die du vermeiden willst:

1. Rewind als Git-Ersatz nutzen. Wenn du Bash-Commands für Datei-Operationen laufen lässt (mv, rm, cp), kannst du das nicht rewinden. Auch keine Manual-Edits im Editor. Für alles ausser Claude-File-Edits brauchst du weiter Git.
2. Vergessen, dass Externe nicht getrackt sind. Wenn parallel eine zweite Claude-Code-Session am gleichen Repo arbeitet (mache ich oefter mit verschiedenen Sub-Tasks), sieht Session A die Edits von Session B nicht im eigenen Checkpoint. Im Worst Case rewindest du eine Datei zurück die Session B gerade fuellt.
3. Summarize zu aggressiv nutzen. Beide Summarize-Optionen verdichten Information. Was Claude in der Summary für "unwichtig" hält, ist es nicht zwingend auch für dich. Wenn du gerade eine subtile Architektur-Entscheidung getroffen hast, summarize nicht direkt drueber. Lieber /compact mit expliziten Anweisungen oder Fork.

Was als nächstes

Wenn du Checkpoints intus hast, ist der nächste logische Schritt der saubere Kontext-Workflow. Schau dir Context-Window managen Claude Code an, dort gehen wir tiefer in /compact, Session-Forks und den Unterschied zwischen lokaler Recovery und permanentem Verlauf.

Wenn du Checkpoints in einem Team-Setup nutzen willst (mehrere Devs am gleichen Repo), kombiniere das mit unserem Claude Code im Team Playbook. Dort steht wie ihr CLAUDE.md sauber teilt damit Sessions konsistent bleiben.

Source

Spezifikationen verifiziert gegen die offizielle Dokumentation:

• Checkpointing Reference
• Interactive Mode (Keyboard Shortcuts)
• Session Forks