Aller au contenu
Mastering Claude

Accueil / Quand ça déraille

Quand ça déraille9 minApplication
Fenêtre de terminal avec une invite de commande et une boucle de quatre étapes : lire, décider, agir, vérifierClaude Code
Voie 4, module 5 sur 5, leçon 2 sur 7

Annuler et récupérer une modification

Pour annuler la dernière modification de Claude Code dans la session en cours, ouvrez le menu de points de reprise avec /rewind plutôt que de passer d'abord par Git. Git reste l'outil pour ce que ces points ignorent : les modifications faites par une commande bash, les éditions d'un sous-agent en arrière-plan et les fichiers liés.

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

Un cas récent : sed -i

Depuis octobre 2026, sed -i suit l'invite Bash standard et s'exécute tel quel, au lieu d'afficher un aperçu simulé d'édition de fichier. Comme les autres modifications faites par Bash, il n'est plus restauré par /rewind : une édition passée par le shell se récupère avec Git, pas avec les points de reprise.

Figure 1

De la modification indésirable à la branche de sécurité

01
Modification indésirable
Un correctif récent de Claude Code doit être annulé, en code, en conversation, ou les deux.
02
Points de reprise d'abord
/rewind ou un double Échap ouvre le menu et restaure jusqu'à un instant antérieur de la même session.
03
Limite atteinte
Une commande bash, une édition de sous-agent en arrière-plan, ou un fichier lié échappe à cette restauration.
04
Reflog consulté
git reflog retrouve la position de HEAD antérieure à la modification, même après un commit apparemment perdu.
05
Branche de sécurité
Une branche recréée depuis ce hachage conserve l'état courant à côté, sans l'écraser par un reset destructif.
La séquence place le menu de points de reprise avant Git pour la dernière action de la session, puis bascule vers Git pour tout ce que ce menu ne suit pas.
Calibrez vous-même

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 qu’il faut retenir
  • 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.
  • Depuis octobre 2026, sed -i s'exécute comme toute commande Bash et n'est plus restauré par /rewind, qui ne défait pas les éditions faites par le shell.
  • 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.
À faire maintenant

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.

Vérifier à la source

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.