Wijzigingen in Claude Code ongedaan maken: /rewind en git

Praktische informatie over werken met Ailoot vind je in de documentatie.

Wat is ongedaan maken in Claude Code, en waarom zijn drie niveaus niet genoeg?#

Ik schakelde /rewind in mijn eerste week met Claude Code in, toen het de authenticatielogica van mijn project in twee prompts kapotmaakte. Ik draaide terug, haalde opgelucht adem en ging verder. Een maand later gebeurde er iets anders: ik schreef een schemamigratie, Claude hielp, ik committe, wisselde van branch — en besefte toen dat ik een noodzakelijke stap was vergeten. /rewind hielp niet; de sessie was inmiddels veranderd. git checkout naar de vorige commit hielp wel. Een maand later zei ik per ongeluk tegen de agent: “zet alles terug naar de laatste push”, waarna die git reset --hard uitvoerde en drie uur werk om zeep hielp. git reflog redde me: de hashes van de vernietigde commits stonden er nog.

Die drie verhalen laten drie beschermingsniveaus zien die verschillend werken, andere fouten opvangen en allemaal nodig zijn. Deze gids legt elk niveau uit met opdrachten, beperkingen en voorbeelden, en laat ook zien hoe je een project vooraf configureert zodat Claude het niet meteen de eerste keer om zeep helpt.

3 niveaus van ongedaan maken — wat en wanneer:

Hierna lopen we elk niveau langs: wat je precies moet doen, de valkuilen en hoe je alles zo configureert dat er niets ongedaan hoeft te worden gemaakt omdat er niets misgaat.

Hoe roep je /rewind op: met de opdracht of met Esc-Esc?#

Na elk antwoord maakt Claude automatisch een momentopname van alle bestanden die het in die sessie heeft bewerkt. Momentopnamen worden opgeslagen in ~/.claude/file-history/{sessionId}/ en maximaal 30 dagen bewaard. De momentopnamen zijn incrementeel: alleen de verschillen tussen toestanden worden opgeslagen, niet het hele bestand. Standaard worden er maximaal 100 momentopnamen per sessie bewaard. Dat betekent dat je in de meeste echte projecten op elk moment een volledige geschiedenis hebt van alle wijzigingen die Claude gedurende de werkdag heeft aangebracht.

Druk twee keer op Esc wanneer het invoerveld leeg is om het rewind-menu te openen:

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

Staat er tekst in het invoerveld, dan wist de eerste dubbele druk op Esc die tekst en slaat die op in de Up-geschiedenis. Dat is handig als je al bent begonnen met typen en beseft dat je moet terugdraaien. Een citaat uit de officiële documentatie van Anthropic:

De opdracht /rewind doet hetzelfde: die opent het menu. Er is een alias, /checkpoint, die naar dezelfde plek leidt. Welke methode handiger is, hangt af van je gewoonte. Ik gebruik Esc Esc: dat is sneller en ik hoef mijn handen niet van het toetsenbord te halen.

6 modi in het Rewind-menu: welke kies je en wanneer?#

Selecteer een punt in de lijst en je komt in het actiemenu. Zes opties, elk met een andere werking.

Volledige tabel met modi:

De functie Summarize up to here verscheen in Claude Code v2.1.139-v2.1.142, uitgebracht op 11–15 mei 2026, in week 20:

Het verschil tussen Restore en Summarize is fundamenteel. Restore brengt je terug naar een eerdere toestand en maakt alles ongedaan wat na het geselecteerde punt is gebeurd. Summarize maakt niets ongedaan; het comprimeert alleen: de oorspronkelijke berichten blijven ter referentie in het sessietranscript staan, maar alleen de samenvatting blijft in de actieve context. Gebruik restore als je wilt dat het “is alsof dit nooit is gebeurd”. Gebruik summarize als je het wilt “bewaren zonder context in beslag te nemen”.

Na Restore conversation of Summarize from here keert de oorspronkelijke tekst van de geselecteerde prompt terug naar het invoerveld; je kunt die bewerken en opnieuw versturen. Na Summarize up to here is het invoerveld leeg en blijf je aan het einde van het gesprek.

Welke wijzigingen maakt /rewind NIET ongedaan?#

Dit is de belangrijkste beperking waar mensen tegenaan lopen: /rewind toont een groen vinkje en zegt “rewind geslaagd”, maar het project is nog steeds stuk omdat Claude meer heeft aangepast dan alleen bestanden. Laten we de drie gevallen bekijken.

1. Bash-opdrachten worden niet bijgehouden. Als Claude in een beurt rm file.txt of mv old.txt new.txt uitvoert, worden die wijzigingen niet opgenomen in het checkpoint. De documentatie van Anthropic zegt dit uitdrukkelijk:

Dat betekent dat /rewind niet alles herstelt als Claude zelf een bestand verwijdert, verplaatst of kopieert met de bash-tool. git checkout of herstellen vanaf een back-up kan helpen, maar daarvoor is meer nodig dan twee toetsen indrukken.

2. Externe bewerkingen worden niet opgevangen. Als je handmatig een bestand opent in VS Code en iets bewerkt, of een tweede Claude-sessie dezelfde bestanden parallel wijzigt, kan de eerste sessie die wijzigingen niet zien. Een checkpointmomentopname wordt gemaakt wanneer Claude een beurt in de huidige sessie afrondt. Wat er tussen beurten gebeurt, valt buiten zijn verantwoordelijkheid.

3. Handelingen buiten bestanden vallen er helemaal buiten. Een Prisma-migratie die via npx prisma migrate dev is toegepast, heeft het databaseschema gewijzigd; /rewind maakt dat niet ongedaan omdat de database buiten het bestandssysteem van het project staat. Een force-push naar origin/main is hetzelfde: de commit is naar de externe server gegaan en het checkpoint brengt die niet terug. Een externe API-aanroep die geld heeft afgeschreven of een record heeft verwijderd, kan alleen met de eigen mechanismen van de API ongedaan worden gemaakt.

Regel: Als een taak iets buiten de projectbestanden beïnvloedt — databasemigraties, git push, externe API's — bereid dan voor elk extern effect een afzonderlijke terugdraaistrategie voor. /rewind is alleen de lokale bestandsgeschiedenis binnen de huidige sessie.

/rewind versus git: wat is het verschil en waarom heb je beide nodig?#

De documentatie van Anthropic beschrijft deze combinatie rechtstreeks:

De verschillen in één tabel:

De combinatie is eenvoudig: zodra je een toestand bereikt waarin “dit werkt en ik wil het niet kwijtraken”, maak je een git commit. Vertrouw tussen commits op /rewind: dat gaat direct, vereist geen commitbericht en vervuilt de git-geschiedenis niet met tussenstappen. Commit wanneer het werk klaar is, bij voorkeur met een betekenisvolle, ondeelbare commit.

Waarom dekt één /rewind niet de hele taak?#

Ongedaan maken is één onderdeel van context engineering. Beheer de sessiecontext (wanneer je commit, wanneer je /rewind gebruikt en welke regels je in CLAUDE.md zet) en je krijgt een voorspelbare Claude die het project niet vernietigt of werk kwijtraakt.

Waarom is git reset --hard gevaarlijk als je Claude vraagt om “terug te gaan”?#

Een verzoek om “de huidige toestand op te slaan en terug te gaan naar de laatste push” kan tot deze opdrachten leiden:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # niet-gecommitte wijzigingen opgeslagen
git reset --hard 35eb731                                                # commits d63695e..882e618 vernietigd

De eerste opdracht was correct: die sloeg de niet-gecommitte wijzigingen op in de stash. De tweede was destructief: die herschreef de branch naar commit 35eb731, waardoor alle commits tussen die commit en 882e618 verweesd raakten. Standaard blijven verweesde commits in .git/objects/ staan totdat git gc wordt uitgevoerd, meestal automatisch binnen twee weken. Maar als je op dat moment niet wist wat je moest doen, werkte de tijd al tegen je.

De logica is eenvoudig: in gewone taal betekenen “teruggaan”, “terugkeren”, “herstellen”, “terugdraaien” en “ongedaan maken” dat je “terugkijkt” of “naar een veilige plek terugkeert”. Ze betekenen niet “de geschiedenis vernietigen”. De opdracht git reset --hard vernietigt die: hij herschrijft de branch en verwijdert commits uit de reeks die via HEAD bereikbaar is. Een veilig alternatief is git checkout <commit>, dat een detached HEAD maakt en je de oude toestand laat bekijken zonder branches aan te raken.

De belangrijkste praktische les is om de huidige toestand met git commit vast te leggen voordat je aan een omvangrijke taak begint, vooral vóór het refactoren van meerdere bestanden. Eén commit maakt van elke blunder van Claude één git checkout .-opdracht, zonder werk te verliezen.

Hoe redt git reflog je na een destructieve reset?#

Voer na een destructieve reset meteen git reflog uit:

git reflog

De uitvoer ziet er zo uit:

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1} tot en met HEAD@{3} zijn precies die “vernietigde” commits. Ze zijn niet verdwenen uit de lokale objectopslag van git; ze zijn alleen niet meer bereikbaar via de branch. Zo herstel je ze:

# Maak een branch vanaf de laatste “vernietigde” commit
git branch recovered-work 882e618

# Of schakel er direct naartoe
git reset --hard 882e618

Daarna bevat de branch weer de volledige geschiedenis tot aan de ramp.

Beperkingen van reflog:

1. Alleen lokaal. De reflog staat in .git/logs/HEAD; hij staat niet in de externe repository. Als je een force-push uitvoert en daarna je lokale repositorykopie verwijdert, verdwijnt de reflog met de map.
2. Standaard 90 dagen. Oudere vermeldingen kunnen door git gc worden verwijderd. Je kunt dit configureren met git config gc.reflogExpire 200.days.ago.
3. Dekt niet wat nooit in HEAD stond. Als een commit alleen in de stash stond en de stash werd vernietigd, toont de reflog alleen de laatste toestand van de stash, niet de interne geschiedenis ervan.

Regel voor het team: voer vlak na een ramp nooit git gc --aggressive uit. Onderzoek eerst de situatie met reflog en herstel de gegevens; doe de rest daarna. Verwijder ook nooit de lokale repositorykloon voordat je zeker weet dat alles wat je nodig hebt is gepusht.

Hoe bescherm je een project met CLAUDE.md tegen destructieve git-opdrachten?#

De kwetsbaarheid is dat Claude standaard geen beschermende context heeft. Het interpreteert “teruggaan” als git reset --hard, omdat dat technisch gezien een geldige methode is. Zet de bescherming in CLAUDE.md, het systeempromptbestand van het project.

Minimale regel (voeg toe aan je CLAUDE.md):

## Git-veiligheidsprotocol

- Voer NOOIT destructieve git-opdrachten uit (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), tenzij ik uitdrukkelijk om deze handelingen vraag. Ongeoorloofde destructieve handelingen helpen niet en kunnen werkverlies veroorzaken.
- Wanneer ik “teruggaan”, “terugkeren”, “herstellen”, “terugdraaien” of “ongedaan maken” zeg, interpreteer dat dan als opdrachten om de situatie te BEKIJKEN: gebruik `git log`, `git diff`, `git checkout <commit>` (maakt een detached HEAD) of `git stash` (bewaart wijzigingen).
- Vraag ALTIJD om bevestiging vóór ELKE opdracht die:
  - De positie van HEAD naar een andere commit op een branch verplaatst
  - De commitgeschiedenis wijzigt
  - Niet-gecommitte wijzigingen kan verliezen
  - De vlaggen --hard, --force of --aggressive bevat
- Geef vóór elke destructieve opdracht een genummerde vergelijking:
  - VEILIG: gebruik `git checkout <commit>` om tijdelijk te kijken
  - DESTRUCTIEF: gebruik `git reset --hard` om iets permanent te vernietigen
- Wacht op mijn uitdrukkelijke keuze voordat je de opdracht uitvoert.

Uitgebreide regel voor het team (voeg toe aan CLAUDE.md in de hoofdmap van de repository):

## Git-werkwflowregels

- Maak bij elke werkende mijlpaal een commit. Voer vóór een WIP-commit `git status` en `git diff` uit, stage alleen expliciet beoordeelde bestanden op naam met `git add -- path/to/file` en bekijk daarna de staged diff voordat je commit. Een timer herinnert aan beoordeling en geeft geen toestemming om de hele werkboom te stagen.
- Gebruik voor commits van Claude nooit `git add .` of `git add -A`. Specificeer alleen bestanden op naam, na `git status` + `git diff`.
- Stop en vraag het voordat je `git push --force` naar main uitvoert. Force-push in featurebranches alleen voorzichtig en als je zeker weet dat ik bereid ben de vorige versie te verliezen.
- Kies bij het oplossen van mergeconflicten niet meteen “ours” of “theirs”; laat me eerst beide versies zien, dan beslis ik.
- `.gitignore` moet `.env*`, `.claude/personal/`, `node_modules/` en `dist/` bevatten. Ontbreken ze, voeg ze dan toe.

Nadat je deze blokken hebt toegevoegd, zou de volgende opdracht “teruggaan naar de laatste push” tot dit antwoord leiden:

Ik zie 3 niet-gecommitte bestanden en 4 commits vóór de laatste push. Er zijn twee opties:

1. VEILIG: maak met git checkout <last-push-hash> een view-last-push-branch aan; ik bewaar al het werk, maar toon tijdelijk de toestand van de push.
2. DESTRUCTIEF: git reset --hard <last-push-hash>; ik vernietig 4 commits en de niet-gecommitte wijzigingen permanent. Ze kunnen alleen binnen 90 dagen via git reflog worden hersteld. Welke optie kies je?

Dat is een gesprek van een halve minuut in plaats van vier uur verloren werk.

Wat zijn de 5 manieren om iets in Claude Code ongedaan te maken, en hoe kies je de juiste?#

Het scenario “Claude heeft het kapotgemaakt, ik moet het dringend herstellen” volg je van onderaf op deze ladder. Begin altijd op niveau 1.

Niveau 1. /rewind — direct ongedaan maken binnen een sessie.

Druk op Esc Esc of typ /rewind. Kies het punt van vóór de fout. Kies een modus (meestal Restore code and conversation). Een seconde later ben je terug in het verleden en kun je opnieuw beginnen. Dekt 80% van de gevallen waarin “Claude iets verkeerds heeft gedaan”.

Niveau 2. git checkout . — alle niet-gecommitte wijzigingen ongedaan maken.

git diff                    # bekijk eerst wat er daadwerkelijk is gewijzigd
git checkout .              # maak alle niet-gecommitte wijzigingen in alle bestanden ongedaan
# of selectief:
git checkout -- path/to/file.ts   # slechts één bestand

Handig als /rewind niet werkte (bijvoorbeeld omdat Claude bestanden via bash heeft aangepast) of als je wijzigingen buiten de sessiegeschiedenis ongedaan moet maken. Alle niet-gecommitte wijzigingen verdwijnen permanent. Als je daar mogelijk spijt van krijgt, voer dan eerst git stash uit (zie niveau 2.5).

Niveau 2.5. git stash — zet je wijzigingen op de plank.

git stash save "might still need this"
# keer terug naar een schone toestand (zonder wijzigingen)
# ...
# van gedachten veranderd? Herstel vanuit de stash:
git stash pop

Een goed compromis tussen “voor altijd verliezen” en “laten zoals het is”. De stash blijft lokaal totdat je die uitdrukkelijk wist.

Niveau 3. git checkout <commit> — terug naar een oude commit zonder geschiedenis te verliezen.

git log --oneline               # vind de hash van de juiste commit, bijvoorbeeld abc1234
git checkout abc1234            # detached HEAD — bekijken zonder iets te wijzigen
# bevalt de toestand? Maak er een branch van:
git checkout -b recovery abc1234
# terugkeren:
git checkout main

Dit is een veilige “tijdelijke terugkeer”. Een detached HEAD wijzigt de branch niet; je huidige werk in main (of de branch waarop je zat) blijft intact. Als je in deze toestand wilt werken, maak dan een branch aan.

Niveau 4. git reset --hard <commit> — verplaats de branch terug naar een punt.

⚠️ Destructief. Commits na de opgegeven hash raken verweesd.

git reflog                                  # noteer de hash van de huidige toestand
git reset --hard abc1234                    # herschrijf de branch
# een fout ontdekt? Keer terug via reflog:
git reset --hard HEAD@{1}                   # terug naar de toestand van vóór de reset

Gebruik dit alleen als je zeker weet dat je de commits ervoor niet nodig hebt. Controleer altijd git reflog VÓÓR de reset, zodat je weet waar je naartoe kunt terugkeren als je van gedachten verandert.

Niveau 5. git reflog + herstel — een rampscenario.

Iemand (Claude, jij of een collega) heeft al git reset --hard of force-push uitgevoerd en het werk gewist. Wat doe je?

git reflog                                          # zoek de laatste hash van vóór de ramp
git branch recovered HEAD@{N}                       # maak daar een branch van
git checkout recovered                              # schakel ernaar over
git diff main                                       # vergelijk met de huidige toestand
git checkout main && git merge recovered            # herstel naar main als je het zeker weet

Als de reflog al is gewist (standaard na 90 dagen), is het laatste redmiddel git fsck --lost-found, dat dangling commits in .git/objects/ laat zien. Dit is bijna archeologie, maar soms werkt het.

Regel voor het kiezen van een niveau:

Hoe bescherm je een project zodat er niets ongedaan hoeft te worden gemaakt?#

Regel 1. Commit elke 30 minuten.

Wacht niet tot “de taak af is”. Commit elke tussenstap die werkt. Commitberichten mogen van alles zijn; het belangrijkste is dat Claude (of jij) met één git checkout-opdracht naar een werkende toestand kan terugkeren.

# aan het begin van een taak
git status                        # bekijk alle staged en unstaged paden
git diff                          # beoordeel de wijzigingen
# Vervang dit voorbeeldpad door het echte bestand dat je hebt beoordeeld.
git add -- path/to/file.ts
git diff --cached                 # controleer precies wat wordt gecommit
git commit -m "wip: starting User schema migration"

# na 30 minuten (of na de eerste werkende iteratie)
git status
git diff
git add -- path/to/file.ts         # echt beoordeeld pad, geen directorywildcard
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# aan het einde van de taak — een betekenisvolle commit
git reset --soft HEAD~2           # voeg de drie wip-commits samen tot één
git commit -m "feat(auth): add lastLoginAt field to User table"

Voeg je een PostToolUse-herinnering toe, behoud dan dezelfde regel voor beoordeling en expliciete paden bij het stagen. Maak van een timer geen ongecontroleerde autocommit: anders kunnen ongerelateerde bewerkingen of al gestagede bestanden in de commit terechtkomen.

Regel 2. Minimale .gitignore.

Deze regels zijn vereist in de hoofdmap van het project:

# geheimen
.env
.env.local
.env.*.local

# lokale Claude Code-instellingen (niet naar de teamrepository pushen)
.claude/personal/
.claude/sessions/
.claude/file-history/

# afhankelijkheden en build
node_modules/
dist/
.next/
build/

Ik bewaar de map .claude/personal/ voor mijn eigen experimenten en notities; die mag niet in de gedeelde repository terechtkomen. De mappen .claude/sessions/ en .claude/file-history/ zijn de lokale opslag van Claude Code; ze horen niet in de repository, nemen veel ruimte in en zijn gekoppeld aan een specifieke machine.

Regel 3. Experimenteer op een aparte branch.

Is de taak groot (10+ bestanden refactoren, overstappen op een nieuwe database, een module herschrijven), doe het dan niet op de main-branch:

git checkout -b experiment/auth-rewrite
# werk en commit elke 30 minuten
# als het werkt:
git checkout main
git merge experiment/auth-rewrite
# als het niet werkt:
git checkout main
git branch -D experiment/auth-rewrite     # verwijder de branch
# klaar, de main-branch is intact

Deze eenvoudige gewoonte verandert “Claude heeft het project vernield” in “Claude heeft één branch vernield, ik heb die verwijderd en we beginnen opnieuw”.

Regel 4. Gebruik vóór gevaarlijke handelingen git tag.

Maak vóór een databasemigratie, grote refactor of afhankelijkheidsupdate een tag aan:

git tag pre-prisma-migration-v2
# werk
# gaat er iets mis:
git reset --hard pre-prisma-migration-v2
# of kijk alleen even:
git checkout pre-prisma-migration-v2

Een tag is een benoemde verwijzing naar een commit die je zelfs na het opschonen van de reflog niet kwijtraakt.

Wat nu: hoe past ongedaan maken in context engineering?#

Deze drie niveaus van ongedaan maken vormen de infrastructuur voor één vaardigheid: weten hoe je een toestand herstelt wanneer er iets stukgaat. Op zichzelf is die vaardigheid beperkt. Maar in combinatie met andere tools voor context engineering wordt het iets meer.

Plan Mode laat je niet meteen code schrijven: eerst komt het plan, dan de bevestiging en daarna de uitvoering. Dit is preventief ongedaan maken: je schrijft niets wat je later moet terugdraaien, omdat het plan vooraf is beoordeeld. Lees meer in de gids over Plan Mode in Claude Code.

CLAUDE.md bevat regels die Claude standaard respecteert, waaronder het hierboven besproken Git-veiligheidsprotocol. Dit is preventieve bescherming tegen destructieve opdrachten.

Het Second Brain geeft Claude tussen sessies door geheugen over het project: het weet welke code je hebt, wat de bedrijfslogica is en welke afspraken eerder zijn gemaakt. Hoe meer geheugen, hoe kleiner de kans dat het iets verkeerd doet.

Skills en subagents zijn je methodologie in code. Als de juiste git-workflow in een Skill is ingebouwd, voert geen enkele subagent git reset --hard uit zonder bevestiging.

En dit alles samen is Context Engineering. Beheer de context vóór de prompt, niet tijdens het uitvoeren ervan. Lees meer over wat context engineering is.

Ongedaan maken is de laatste verdedigingslinie. Plan Mode + CLAUDE.md + Second Brain + Skills zijn de eerste vier. Als die zijn ingesteld, hoef je zelden iets ongedaan te maken en gaat dat snel. Zijn ze niet ingesteld, dan wordt het een dagelijks ritueel.

Ongedaan maken begint waar plannen eindigt.

Ailoot openen.