Comment annuler des modifications dans Claude Code : /rewind et git

Des informations pratiques sur l’utilisation d’Ailoot sont disponibles dans la documentation.

Qu’est-ce que l’annulation dans Claude Code, et pourquoi trois niveaux ne suffisent-ils pas ?#

J’ai activé /rewind pendant ma première semaine d’utilisation de Claude Code, après qu’il a cassé la logique d’authentification de mon projet en deux prompts. J’ai fait un rewind, soufflé un bon coup et repris le travail. Un mois plus tard, une autre situation s’est présentée : j’écrivais une migration de schéma, Claude m’a aidé, j’ai fait un commit, changé de branche, puis je me suis rendu compte que j’avais oublié une étape nécessaire. /rewind n’a pas aidé : la session était déjà différente. git checkout vers le commit précédent, oui. Un mois après, j’ai accidentellement dit à l’agent : « remets tout à l’état du dernier push », et il a exécuté git reset --hard, détruisant trois heures de travail. git reflog m’a sauvé : les hashes des commits détruits étaient encore là.

Ces trois histoires illustrent trois niveaux de protection qui fonctionnent différemment, détectent des erreurs distinctes et sont tous nécessaires. Ce guide explique chaque niveau, avec ses commandes, ses limites et des exemples. Il montre aussi comment configurer un projet à l’avance pour que Claude ne le mette pas à terre dès la première fois.

3 niveaux d’annulation — quoi et quand :

Nous allons maintenant passer en revue chaque niveau : ce qu’il faut faire précisément, les pièges à éviter et comment configurer les choses pour n’avoir rien à annuler parce que rien n’a cassé.

Comment lancer /rewind : avec la commande ou Esc-Esc ?#

Après chaque réponse, Claude prend automatiquement un instantané de tous les fichiers qu’il a modifiés pendant cette session. Les instantanés sont enregistrés dans ~/.claude/file-history/{sessionId}/ et conservés jusqu’à 30 jours. Ils sont incrémentiels : seules les différences entre les états sont enregistrées, pas le fichier entier. Par défaut, jusqu’à 100 instantanés sont stockés par session. Cela signifie que, dans la plupart des projets réels, tu disposes à tout moment d’un historique complet de toutes les modifications apportées par Claude au cours de la journée de travail.

Pour ouvrir le menu Rewind, appuie deux fois sur Esc lorsque le champ de saisie est vide :

[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)
  ...

Si le champ de saisie contient du texte, le premier double appui sur Esc l’efface et l’enregistre dans l’historique, accessible avec la touche Up. C’est utile si tu as déjà commencé à taper et que tu te rends compte qu’il faut faire un rewind. Voici une citation de la documentation officielle d’Anthropic :

La commande /rewind fait la même chose : elle ouvre le menu. Il existe un alias, /checkpoint, qui mène au même endroit. La méthode la plus pratique dépend des habitudes de chacun. J’utilise Esc Esc : c’est plus rapide et je n’ai pas à retirer les mains du clavier.

6 modes dans le menu Rewind : lequel choisir, et quand ?#

Choisis un point dans la liste pour accéder au menu des actions. Six options, chacune ayant un effet différent.

Tableau complet des modes :

La fonction Summarize up to here est apparue dans Claude Code v2.1.139-v2.1.142, publié du 11 au 15 mai 2026, pendant la semaine 20 :

La différence entre Restore et Summarize est fondamentale. Restore ramène à un état antérieur et annule tout ce qui s’est passé après le point sélectionné. Summarize ne défait rien : il compresse uniquement le contenu. Les messages d’origine restent dans la transcription de la session pour référence, mais seul le résumé subsiste dans le contexte actif. Utilise Restore quand tu veux que ce soit « comme si rien de tout cela ne s’était passé ». Utilise Summarize quand tu veux « le garder, mais sans occuper d’espace dans le contexte ».

Après Restore conversation ou Summarize from here, le texte d’origine du prompt sélectionné réapparaît dans le champ de saisie : tu peux le modifier et le renvoyer. Après Summarize up to here, le champ de saisie est vide et tu restes à la fin de la conversation.

Quelles modifications /rewind NE défait-il PAS ?#

C’est la principale limite à laquelle les gens se heurtent : /rewind affiche une coche verte et indique « rewind successful », mais le projet est toujours cassé parce que Claude a touché autre chose que des fichiers. Examinons les trois cas.

1. Les commandes bash ne sont pas suivies. Si Claude exécute rm file.txt ou mv old.txt new.txt au cours d’un tour, ces modifications ne sont pas incluses dans le checkpoint. La documentation d’Anthropic le précise explicitement :

Cela signifie que si Claude supprime, déplace ou copie un fichier de son propre chef avec l’outil bash, /rewind ne restaurera pas tout. git checkout ou une restauration depuis une sauvegarde peut aider, mais cela demande plus que d’appuyer sur deux touches.

2. Les modifications externes ne sont pas prises en compte. Si tu ouvres manuellement un fichier dans VS Code et le modifies, ou si une seconde session Claude modifie les mêmes fichiers en parallèle, la première session ne peut pas voir ces changements. Un instantané du checkpoint est pris lorsque Claude termine un tour dans la session en cours. Ce qui se passe entre les tours ne relève pas de sa responsabilité.

3. Les opérations hors des fichiers ne sont pas couvertes du tout. Une migration Prisma appliquée avec npx prisma migrate dev a modifié le schéma de la base de données : /rewind ne l’annulera pas, car la base se trouve en dehors du système de fichiers du projet. Un force-push vers origin/main, c’est pareil : le commit est parti sur le serveur distant et le checkpoint ne le fera pas revenir. Un appel à une API distante qui a débité de l’argent ou supprimé un enregistrement ne peut être annulé qu’au moyen des mécanismes propres à cette API.

Règle : si une tâche a des effets en dehors des fichiers du projet — migrations de base de données, git push, API distantes —, prépare une stratégie de restauration distincte pour chaque effet externe. /rewind ne couvre que l’historique des fichiers locaux dans la session en cours.

/rewind et git : en quoi diffèrent-ils, et pourquoi faut-il les deux ?#

La documentation d’Anthropic décrit directement cette complémentarité :

Les différences en un tableau :

La complémentarité est simple : dès que tu arrives à un état où « ça fonctionne et je ne veux pas le perdre », fais un git commit. Entre les commits, fie-toi à /rewind : c’est immédiat, ne demande aucun message de commit et n’encombre pas l’historique git avec des états intermédiaires. Quand le travail est terminé, fais un commit — de préférence pertinent et atomique.

Pourquoi un seul /rewind ne couvre-t-il pas toute la tâche ?#

L’annulation est un cas de Context Engineering. En gérant le contexte de la session (quand faire un commit, quand appuyer sur /rewind, quelles règles mettre dans CLAUDE.md), tu obtiens un Claude prévisible qui ne détruit pas le projet et ne perd pas de travail.

Pourquoi git reset --hard est-il dangereux quand tu demandes à Claude de « revenir en arrière » ?#

Une demande d’« enregistrer l’état actuel et de revenir au dernier push » peut aboutir à ces commandes :

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

La première commande était correcte : elle a enregistré les modifications non commitées dans le stash. La seconde était destructrice : elle a réécrit la branche vers le commit 35eb731, et tous les commits entre celui-ci et 882e618 sont devenus orphelins. Par défaut, les commits orphelins restent dans .git/objects/ jusqu’à l’exécution de git gc, qui se lance généralement automatiquement dans les deux semaines. Mais si tu ne savais pas quoi faire à ce moment-là, le temps jouait déjà contre toi.

La logique est simple : en langage naturel, « revenir en arrière », « retourner en arrière », « restaurer », « revenir sur » et « annuler » signifient « regarder l’historique » ou « revenir à un endroit sûr ». Cela ne signifie pas « détruire l’historique ». La commande git reset --hard le détruit : elle réécrit la branche et retire des commits de l’ensemble de ceux qui sont accessibles par HEAD. Une alternative sûre est git checkout <commit>, qui crée un HEAD détaché et permet de consulter l’ancien état sans toucher aux branches.

La principale leçon pratique consiste à faire un git commit de l’état actuel avant toute tâche importante, en particulier avant de refactoriser plusieurs fichiers. Un commit transforme n’importe quelle erreur de Claude en une seule commande git checkout ., sans perte de travail.

Comment git reflog te sauve-t-il après un reset destructeur ?#

Après un reset destructif, exécute git reflog immédiatement :

git reflog

La sortie ressemble à ceci :

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} à HEAD@{3} sont précisément ces commits « détruits ». Ils n’ont pas disparu du magasin d’objets local de git ; ils sont simplement devenus inaccessibles via la branche. Pour les restaurer :

# Create a branch from the last “destroyed” commit
git branch recovered-work 882e618

# Or switch directly
git reset --hard 882e618

Après cela, la branche contient à nouveau tout l’historique jusqu’à la catastrophe.

Limites de Reflog :

1. Local uniquement. Le reflog est stocké dans .git/logs/HEAD ; il ne se trouve pas dans le dépôt distant. Si tu fais un force-push puis supprimes ta copie locale du dépôt, le reflog disparaît avec le dossier.
2. 90 jours par défaut. Les entrées plus anciennes peuvent être supprimées par git gc. Tu peux configurer cette durée avec git config gc.reflogExpire 200.days.ago.
3. Ne couvre pas ce qui n’a jamais été dans HEAD. Si un commit se trouvait uniquement dans le stash et que celui-ci a été détruit, le reflog n’affichera que son dernier état, pas son historique interne.

Règle pour l’équipe : n’exécute jamais git gc --aggressive juste après une catastrophe. Examine d’abord le reflog et récupère le travail ; tout le reste vient après. Et ne supprime jamais le clone local du dépôt avant d’être sûr que tout ce dont tu as besoin a été poussé.

Comment protéger un projet des commandes git destructrices avec CLAUDE.md ?#

La vulnérabilité est que Claude ne dispose par défaut d’aucun contexte de protection. Il interprète « revenir en arrière » comme git reset --hard, car c’est techniquement une méthode valide. Ajoute la protection dans CLAUDE.md, le fichier contenant le prompt système du projet.

Règle minimale (à insérer dans ton CLAUDE.md) :

## Git Safety Protocol

- NE JAMAIS exécuter de commandes git destructrices (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), sauf si je demande explicitement ces actions. Prendre des mesures destructrices sans autorisation n’est pas utile et peut entraîner une perte de travail.
- Quand je dis « roll back », « go back », « restore », « revert » ou « undo », interprète cela comme des commandes d’EXAMEN : utilise `git log`, `git diff`, `git checkout <commit>` (crée un HEAD détaché) ou `git stash` (préserve les modifications).
- TOUJOURS demander confirmation avant TOUTE commande qui :
  - déplace la position de HEAD vers un autre commit sur une branche
  - modifie l’historique des commits
  - pourrait faire perdre du travail non commité
  - inclut les options --hard, --force, --aggressive
- Avant toute commande destructrice, présenter une comparaison numérotée :
  - SÛRE : utiliser `git checkout <commit>` pour consulter temporairement l’état
  - DESTRUCTRICE : utiliser `git reset --hard` pour détruire définitivement l’état
- Attendre mon choix explicite avant l’exécution.

Règle étendue pour l’équipe (à ajouter au CLAUDE.md à la racine du dépôt) :

## Git Workflow Rules

- Fais un commit à chaque étape fonctionnelle. Avant un commit WIP, lance `git status` et `git diff`, indexe seulement les fichiers nommés explicitement revus avec `git add -- path/to/file`, puis inspecte le diff indexé. Le rappel horaire invite à la revue, sans autoriser l’ajout de tout l’arbre.
- Claude ne doit jamais utiliser `git add .` ou `git add -A` pour ses commits. Indiquer uniquement les fichiers par leur nom, après `git status` + `git diff`.
- Avant `git push --force` vers main, arrêter et me demander. Sur les branches de fonctionnalité, utiliser le force-push avec prudence et uniquement si tu es sûr que je suis prêt à perdre la version précédente.
- Lors de la résolution de conflits de fusion, ne jamais choisir immédiatement « ours » ou « theirs » : montre-moi d’abord les deux versions, puis je déciderai.
- `.gitignore` doit contenir `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. S’il manque des entrées, les ajouter.

Après l’ajout de ces blocs, la prochaine phrase « reviens au dernier push » susciterait cette réponse :

Je vois 3 fichiers non commités et 4 commits depuis le dernier push. Deux options :

1. SÛRE : créer une branche view-last-push avec git checkout <last-push-hash> — je préserverai tout le travail, mais afficherai temporairement l’état du push.
2. DESTRUCTRICE : git reset --hard <last-push-hash> — je détruirai définitivement 4 commits et les modifications non commitées. Elles ne pourront être restaurées qu’avec git reflog pendant 90 jours. Que choisis-tu ?

Cela prend une demi-minute de conversation, au lieu de quatre heures de travail perdues.

Quelles sont les 5 façons d’annuler dans Claude Code, et comment choisir la bonne ?#

Le scénario « Claude a tout cassé, je dois restaurer rapidement » suit cette échelle de bas en haut. Commence toujours au niveau 1.

Niveau 1. /rewind — annulation instantanée au sein d’une session.

Appuie sur Esc Esc ou saisis /rewind. Choisis le point précédant le problème. Choisis un mode (généralement Restore code and conversation). Une seconde plus tard, tu es revenu dans le passé et tu peux recommencer. Couvre 80 % des cas où « Claude a fait fausse route ».

Niveau 2. git checkout . — annuler toutes les modifications non commitées.

git diff                    # first see what actually changed
git checkout .              # undo all uncommitted changes in all files
# or selectively:
git checkout -- path/to/file.ts   # only one file

Utile lorsque /rewind n’a pas fonctionné (par exemple, si Claude a touché aux fichiers par bash) ou lorsque tu dois annuler des modifications en dehors de l’historique de la session. Toutes les modifications non commitées disparaîtront définitivement. Si tu risques de le regretter, exécute d’abord git stash (voir le niveau 2.5).

Niveau 2.5. git stash — mettre ses modifications de côté.

git stash save "might still need this"
# return to a clean state (without changes)
# ...
# if you change your mind—restore from stash:
git stash pop

Un bon compromis entre « perdre pour toujours » et « laisser tel quel ». Le stash reste local jusqu’à ce qu’il soit explicitement supprimé.

Niveau 3. git checkout <commit> — revenir à un ancien commit sans perdre l’historique.

git log --oneline               # find the hash of the right commit, e.g. abc1234
git checkout abc1234            # detached HEAD—view without changing anything
# like the state? create a branch from it:
git checkout -b recovery abc1234
# return:
git checkout main

C’est un « retour temporaire » sans risque. Le HEAD détaché ne modifie pas la branche ; ton travail actuel dans main (ou la branche sur laquelle tu te trouvais) reste intact. Si tu veux travailler à partir de cet état, crée une branche.

Niveau 4. git reset --hard <commit> — ramener la branche à un point donné.

⚠️ Destructeur. Les commits situés après le hash indiqué deviennent orphelins.

git reflog                                  # note the hash of the current state
git reset --hard abc1234                    # rewrite the branch
# found a mistake? return through reflog:
git reset --hard HEAD@{1}                   # to where you were before the reset

À utiliser uniquement si tu es sûr de ne pas avoir besoin des commits situés après. Et vérifie toujours git reflog AVANT le reset pour savoir où revenir si tu changes d’avis.

Niveau 5. git reflog + récupération — scénario catastrophe.

Quelqu’un (Claude, toi, un collègue) a déjà exécuté git reset --hard ou un force-push et a effacé le travail. Que faire ?

git reflog                                          # look for the last hash before the disaster
git branch recovered HEAD@{N}                       # create a branch from it
git checkout recovered                              # switch to it
git diff main                                       # compare with the current state
git checkout main && git merge recovered            # restore into main, if you're sure

Si le reflog a déjà été purgé (au bout de 90 jours par défaut), le dernier recours est git fsck --lost-found, qui affichera les commits pendants dans .git/objects/. C’est presque de l’archéologie, mais cela fonctionne parfois.

Règle pour choisir un niveau :

Comment protéger un projet pour n’avoir rien à annuler ?#

Règle 1. Faire un commit toutes les 30 minutes.

N’attends pas que « la tâche soit terminée ». Commits chaque étape intermédiaire qui fonctionne. Les messages de commit peuvent être quelconques ; l’essentiel est que Claude (ou toi) puisse revenir à un état fonctionnel avec une seule commande git checkout.

# at the beginning of a task
git status                        # inspecter les chemins indexés et non indexés
git diff                          # revoir les changements
# Remplacer ce chemin illustratif par le fichier réellement revu.
git add -- path/to/file.ts
git diff --cached                 # vérifier le contenu exact du futur commit
git commit -m "wip: starting User schema migration"

# after 30 minutes (or after the first working iteration)
git status
git diff
git add -- path/to/file.ts         # chemin réellement revu, pas un dossier entier
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# at the end of the task—a meaningful commit
git reset --soft HEAD~2           # combine the three wip commits into one
git commit -m "feat(auth): add lastLoginAt field to User table"

Si tu ajoutes un rappel PostToolUse, garde la revue et l’indexation explicite des chemins. Ne transforme pas le minuteur en commit automatique non vérifié : des modifications sans rapport ou déjà indexées pourraient y entrer.

Règle 2. .gitignore minimal.

Ces lignes sont requises à la racine du projet :

# secrets
.env
.env.local
.env.*.local

# local Claude Code settings (not pushed to the team repository)
.claude/personal/
.claude/sessions/
.claude/file-history/

# dependencies and build
node_modules/
dist/
.next/
build/

Je garde le dossier .claude/personal/ pour mes propres expériences et notes, qui ne doivent pas être incluses dans le dépôt partagé. Les dossiers .claude/sessions/ et .claude/file-history/ sont le stockage local de Claude Code ; ils n’ont pas leur place dans le dépôt, prennent beaucoup de place et sont liés à une machine donnée.

Règle 3. Faire ses expériences sur une branche distincte.

Si la tâche est importante (refactorisation de 10+ fichiers, migration vers une nouvelle base de données, réécriture d’un module), ne la réalise pas sur la branche principale :

git checkout -b experiment/auth-rewrite
# work, commit every 30 minutes
# if it works:
git checkout main
git merge experiment/auth-rewrite
# if it doesn't:
git checkout main
git branch -D experiment/auth-rewrite     # delete the branch
# that's it, the main branch is intact

Cette simple habitude transforme « Claude a saccagé le projet » en « Claude a saccagé une branche, je l’ai supprimée et nous recommençons ».

Règle 4. Avant les opérations risquées, utiliser git tag.

Avant une migration de base de données, une refactorisation importante ou une mise à jour de dépendance, crée un tag :

git tag pre-prisma-migration-v2
# work
# something went wrong:
git reset --hard pre-prisma-migration-v2
# or just take a look:
git checkout pre-prisma-migration-v2

Un tag est un pointeur nommé vers un commit que tu ne perdras pas, même après le nettoyage du reflog.

Et ensuite : quelle place l’annulation occupe-t-elle dans le Context Engineering ?#

Ces trois niveaux d’annulation forment l’infrastructure d’une compétence : savoir restaurer un état lorsqu’il casse. Cette compétence est en soi assez limitée. Mais combinée à d’autres outils de Context Engineering, elle devient quelque chose de plus.

Le Plan Mode ne te laisse pas écrire du code tout de suite : d’abord vient le plan, puis la confirmation, puis l’exécution. C’est une annulation préventive : tu n’écris pas ce que tu devras annuler ensuite, car le plan a été examiné à l’avance. Pour en savoir plus, consulte le guide sur le Plan Mode dans Claude Code.

CLAUDE.md définit des règles que Claude respecte par défaut, notamment le Git Safety Protocol présenté plus haut. C’est une protection préventive contre les commandes destructrices.

Le Second Brain fournit à Claude une mémoire du projet entre les sessions : il sait quel code tu as, quelle est la logique métier et quels accords ont été pris auparavant. Plus il a de mémoire, moins il risque de faire fausse route.

Les Skills et les subagents sont ta méthodologie sous forme de code. Si le bon flux de travail git est intégré dans un Skill, aucun subagent n’exécutera git reset --hard sans confirmation.

Tout cela forme le Context Engineering. Gère le contexte avant le prompt, pas pendant. Pour en savoir plus, lis Qu’est-ce que le Context Engineering.

L’annulation est la dernière ligne de défense. Plan Mode + CLAUDE.md + Second Brain + Skills sont les quatre premières. Quand ils sont en place, l’annulation devient rare et rapide. Quand ils ne le sont pas, elle devient un rituel quotidien.

L’annulation commence là où la planification s’arrête.

Accéder à Ailoot.