Annuler et récupérer une modification
Pour annuler la dernière action de Claude Code dans la session en cours, le menu de points de reprise ouvert par /rewind précède désormais Git, qui reste nécessaire pour tout ce que ce système ne suit pas : une modification faite par une commande bash, l'édition d'un sous-agent en arrière-plan, ou un fichier lié par un lien symbolique ou physique.
Annuler la dernière modification de Claude Code dans la session en cours ne passe plus, en premier lieu, par Git. Le menu de points de reprise, ouvert par /rewind ou un double appui sur Échap quand la ligne de saisie est vide, propose trois choix distincts : restaurer le code et la conversation, la conversation seule, ou le code seul, jusqu'à un instant antérieur de la même session. Demander en langage naturel à Claude Code d'annuler sa dernière modification déclenche ce même mécanisme. Ce chemin coûte moins cher qu'un détour par Git pour une action encore fraîche : pas de commit à retrouver, pas de branche à recréer, seulement un retour immédiat dans la même session.
Ce que le système de points de reprise ne suit pas
La documentation officielle borne elle même sa portée : ce système n'est pas un remplacement du contrôle de version, et pour un historique permanent ou le travail à plusieurs, elle recommande de continuer à utiliser Git, pour les commits, les branches et l'historique de long terme. Trois limites concrètes s'y ajoutent, chacune correspondant à un travail que Claude Code n'a pas fait lui même avec ses propres outils d'édition. Les modifications faites par une commande bash, rm, mv ou cp, ne sont pas suivies : seules les éditions passées par les outils d'édition de fichiers de Claude le sont. Les éditions faites par un sous-agent en arrière-plan échappent aussi à la restauration. Un fichier lié par un lien symbolique ou un lien physique est ignoré lors d'une restauration.
Git reste l'outil pour ce que les points de reprise ignorent
git restore retire une modification non validée du répertoire de travail. git reflog retrouve toute position antérieure de HEAD, y compris un commit qui semble perdu après un mauvais reset.
git reflog
# affiche chaque position de HEAD, la plus récente en tête
git branch securite <hachage-retrouve>
# récrée une branche depuis un état retrouvé, sans toucher à la branche en cours
Recréer une branche depuis un hachage retrouvé dans le reflog reste préférable à un git reset --hard : le reset écrase l'état courant, la branche de sécurité le conserve à côté sans rien perdre. Vérifier le reflog coûte une commande, un reset mal ciblé peut coûter tout un après midi de travail à retrouver à la main. Cette même distinction entre un retour en arrière et un effacement définitif se retrouve, appliquée à une conversation entière plutôt qu'à un fichier, dans boucles, contexte pollué et redémarrage.
De la modification indésirable à la branche de sécurité
Un développeur constate qu'une modification appliquée par Claude Code cinq minutes plus tôt casse un test. Il ouvre le menu de points de reprise avec un double appui sur Échap et sélectionne l'option qui restaure le code seul, jusqu'à l'instant précédant cette modification.
Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.
Ce que cela établit : Le développeur a utilisé le menu de points de reprise pour restaurer le code à un instant antérieur à la modification suspecte, sans passer par une commande Git.
Ce que cela n’établit pas : Cela n'établit pas que la modification annulée était la cause réelle de l'échec du test, ni que ce même retour en arrière aurait fonctionné si la modification avait été faite par une commande bash plutôt que par un outil d'édition de Claude.
Les trois calibrages faux les plus courants
- Trop large Le menu de points de reprise restaure désormais n'importe quelle modification faite pendant la session, quelle qu'en soit l'origine.
- Trop étroit Cette restauration ne prouve rien puisqu'elle n'a porté que sur le code et pas sur la conversation.
- À côté Cette situation montre que le test cassé avait été écrit avant la modification appliquée par Claude Code.
- Le menu de points de reprise, ouvert par /rewind ou un double Échap, restaure le code et la conversation, la conversation seule, ou le code seul, jusqu'à un instant antérieur de la même session.
- La documentation officielle présente ce système comme un complément à Git, pas un remplacement, pour l'historique permanent et le travail à plusieurs.
- Les modifications faites par une commande bash comme rm, mv ou cp, les éditions d'un sous-agent en arrière-plan, et les fichiers liés par un lien symbolique ou physique échappent tous à une restauration par points de reprise.
- git restore retire une modification non validée du répertoire de travail, git reflog retrouve toute position antérieure de HEAD, y compris un commit apparemment perdu.
- Recréer une branche depuis un hachage retrouvé dans le reflog conserve l'état courant à côté, alors qu'un git reset --hard l'écrase.
Avant tout git reset --hard sur votre dépôt, lancez git reflog, repérez le hachage de l'état que vous voulez garder, et créez une branche de sécurité depuis ce hachage avant de continuer.
Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.
- Claude Code, points de reprise, rewind, portée et limites face à Git consultée le 2026-09-02
- Git, documentation officielle de la commande restore consultée le 2026-09-02
- Git, documentation officielle de la commande reflog consultée le 2026-09-02