Reprendre, revenir en arrière, ne rien perdre
Rouvrir une conversation fermée, la faire repartir d'un point antérieur, et savoir en deux questions lequel des deux fils te rattrape — celui de la session, ou celui que tu as posé toi-même avant de lancer.
Sommaire
- Ce qui se passe vraiment
- Ce que rouvrir ne te rend pas
- Ce qu’on fait
- Rouvrir
- Nommer, sinon tu ne retrouveras rien
- Rembobiner
- Dupliquer plutôt que choisir
- Ce que ça ne fait pas
- Deux questions, et tu sais lequel des deux fils te rattrape
- Ce que le fil ne garde pas éternellement
- « Ne rien perdre » a deux modes d’échec
- Et ce que ça ne remplace pas
- Où c’est écrit
- Le point de bascule
- Vérifier que c’est passé
Vendredi soir, tu fermes ton portable au milieu d’une tâche. Lundi matin, tu rouvres : plus de fil, plus de contexte, et l’impression d’avoir à tout reprendre à zéro.
Ou alors c’est l’autre scène. Il vient de toucher à six fichiers, quelque chose ne marche plus, et tu ne sais même pas lequel des six regarder.
Les deux ne se règlent pas du même geste, mais elles reposent sur le même mécanisme : deux fils déroulés derrière toi, déjà présents sur ta machine, que personne ne t’a montrés. Le travail de cette leçon, c’est de savoir lequel des deux répond — et de reconnaître les cas où aucun ne répond.
Ce qui se passe vraiment
Un mot avant le reste, parce que toute la leçon repose dessus. L’outil, ici, c’est le programme : Claude Code. Ses outils d’édition de fichiers sont les instruments avec lesquels il écrit dans ton code — un moyen parmi plusieurs qu’il a de modifier ton dossier, pas le seul. Les deux ne se confondent pas, et c’est cette différence qui décide de ce que tu pourras défaire.
Deux fils sont déroulés pendant que tu travailles, et ils ne suivent pas le même chemin.
- Le premier, c’est la conversation elle-même. Elle s’écrit sur ton disque au fur et à mesure. C’est ce qui rend une session réouvrable des jours plus tard : une conversation liée au dossier courant, avec sa propre fenêtre de contexte, le plan de travail de la leçon 3.
- Le second, c’est ton code. Avant chaque message que tu envoies, l’outil photographie l’état de tes fichiers : c’est le point de restauration (checkpoint à l’écran et dans la documentation), déjà croisé en leçon 2. Un message envoyé, un point posé — la liste des points, ce sont tes propres messages, dans l’ordre.
Les deux fils sont rangés ensemble, et c’est ce qui rend la chose utile : tu peux rembobiner une session que tu as reprise trois jours plus tard. Fermer le terminal ne coupe pas le fil.
Ce que rouvrir ne te rend pas
Le fichier de session garde tout : chaque message, chaque appel d’outil, chaque résultat. C’est ce qui rend possible de rembobiner après une reprise.
Mais ne compte pas sur la reprise pour rendre à Claude ce qu’il avait déjà perdu vendredi. Une session longue peut t’être rendue résumée (le détail est plus bas), et ce que la compaction avait retiré du plan de travail avant que tu fermes le portable n’a aucune raison de revenir lundi ; la leçon 3 l’a posé. Rouvrir te rend le fil, pas les consignes. Ce à quoi tu tiens, tu le réécris là où il est relu à chaque session : c’est la leçon 6, et les deux gestes ne se concurrencent pas.
À retenir — le fil du code ne passe pas par les portes dérobées. Ce qu’il suit, ce sont uniquement les modifications faites par ses outils d’édition de fichiers. Une commande (
rm,mv,cp) n’est pas dessus, et ça vaut d’abord pour les commandes que Claude lance lui-même pendant le tour : ta suite de tests qui régénère des fichiers, un script de build, un formateur qui repasse sur tout le dossier. Tu n’as rien tapé, tu n’as rien vu passer, et le retour en arrière ne les défera pas.
Ce qu’on fait
Rien à installer. Trois précisions de cette leçon dépendent de ta version : claude --version
te la donne depuis ton terminal, /status l’affiche depuis l’intérieur.
Rouvrir
claude --continue # depuis le dossier du projet : rouvre la plus récente (alias : -c)
claude --resume # ouvre le sélecteur et te laisse choisir
claude --resume mon-nom # rouvre directement une session que tu as nommée
--continue regarde le dossier d’où tu la lances : lancée ailleurs, elle ne trouve rien,
et ça ne veut pas dire que ta session est perdue. --resume mon-nom reprend directement quand
un seul nom correspond ; si plusieurs correspondent, tu retombes sur le sélecteur avec le nom
déjà tapé dans la recherche. Depuis une session ouverte, /resume bascule vers une autre
conversation.
Dans le sélecteur, trois touches suffisent : Espace prévisualise sans ouvrir, Ctrl+R
renomme la ligne surlignée, / filtre la liste. N’importe quel autre caractère aussi.
Et quand ta session n’est pas dans la liste, dans l’ordre où il faut y penser :
- Le sélecteur est cadré sur ton worktree courant. Le terme est passé en leçon 6.
Ctrl+Wélargit à tous les worktrees du dépôt, et cette touche ne s’affiche que dans un dépôt qui en a plusieurs ;Ctrl+Aélargit à tous les projets de la machine. C’est la première cause à écarter, et elle deviendra la tienne le jour où tu travailleras en worktrees — le sujet de la leçon 14. - Deux familles n’y figurent jamais. Les sessions lancées en mode non interactif
(
claude -p, sans conversation à l’écran ; c’est le nom actuel de ce que d’anciens tutoriels appellent headless mode, leçon 4) restent reprenables en passant leur identifiant àclaude --resume— à condition de l’avoir noté au lancement, le sélecteur ne te le donnera pas. Et celles dont le tout premier message était une commande/loopn’y sont pas non plus.
Nommer, sinon tu ne retrouveras rien
Au bout de deux semaines, un sélecteur de sessions ressemble à un dossier de captures d’écran : tout se ressemble, rien ne se retrouve. Trois moments, trois gestes :
claude --name refonte-auth # au lancement d'une session neuve (alias : -n)
En cours de route, /rename fait la même chose. Et pour les cinquante sessions anonymes qui
traînent déjà dans ton sélecteur, Ctrl+R sur la ligne surlignée : c’est le seul moyen de les
rattraper après coup.
Attention à ce qui ressemble à un nom sans en être un. Le nom affiché par défaut (ton
dossier suivi de deux caractères) et le titre généré automatiquement ne sont pas des
poignées de reprise : claude --resume <nom>, /resume <nom> et la recherche du sélecteur
ne reconnaissent que les noms que tu as posés toi-même.
Rembobiner
/rewind
Deux fois Échap, quand la zone de saisie est vide, ouvre le même menu ; les alias
/checkpoint et /undo y mènent aussi. Le menu liste chaque message que tu as envoyé pendant
la session : tu choisis le point, puis l’action.
Piège — le double
Échapn’ouvre le menu que si la zone de saisie est vide. S’il y a du texte dedans, il efface ton brouillon à la place. Ton texte n’est pas perdu pour autant : il part dans l’historique de saisie, et la flèche du haut le rappelle. Le geste sûr, dans tous les cas, c’est de taper/rewind.
Six entrées dans le terminal, et elles ne font pas trois fois la même chose. Depuis l’extension d’éditeur, le menu n’est pas le même : trois actions, sous d’autres libellés, dont deux dupliquent la conversation (Fork) au lieu de la rembobiner. Prendre « Fork conversation and rewind code » pour « Restore code and conversation », c’est croire qu’on a rembobiné ce qu’on vient de dupliquer.
| Ce que propose le menu | Ce que ça fait |
|---|---|
| Restore code and conversation | rembobine les deux |
| Restore conversation | rembobine les messages, garde le code dans son état actuel |
| Restore code | remet les fichiers dans l’état d’avant, garde toute la conversation |
| Summarize from here | résume la conversation à partir de ce point vers l’avant |
| Summarize up to here | résume ce qui précède ce point, laisse les messages suivants intacts |
| Never mind | retour à la liste, rien n’est fait |
Après une restauration de conversation, ton message d’origine revient dans la zone de saisie, prêt à être renvoyé ou reformulé. C’est le geste central de la leçon : tu ne recommences pas, tu reformules au bon endroit.
Trois choses que le tableau ne dit pas :
- les deux options de restauration du code n’apparaissent pas toujours. Elles ne sont proposées que si le point choisi a des modifications de fichiers suivies à annuler. Un menu qui n’offre que les autres lignes n’est pas cassé — il n’y a rien à défaire de ce côté-là ;
- les deux lignes « Summarize » ne reviennent pas en arrière, elles font de la place. Un
/compactciblé, et la compaction est le sujet de la leçon 3. Elles ne touchent à aucun fichier de ton disque, et les messages d’origine restent enregistrés dans la session ; - annuler une restauration n’est proposé nulle part. La documentation ne décrit aucun retour arrière du retour arrière. Si tu restaures depuis le mauvais point, les corrections que tu avais faites toi-même entre les deux (celles qui touchent un fichier de la session, donc capturées) ne sont rattrapées par rien, sinon par ton travail enregistré. C’est pour cette raison que la documentation, qui encourage par ailleurs à tenter des choses risquées puisqu’on peut rembobiner, range le rembobinage comme un dépannage à l’échelle d’une session, pas comme une sauvegarde.
Et si tu as vidé la conversation par erreur avec /clear : tant que tu n’as ni quitté
l’outil ni repris une autre session, une entrée supplémentaire apparaît en haut du menu,
libellée /resume <session-id> (previous session). Elle demande une version 2.1.191 ou plus
récente ; sinon, passe par /resume et choisis la session précédente dans la liste.
Dupliquer plutôt que choisir
Il arrive qu’on ne veuille pas revenir en arrière, mais essayer autre chose sans perdre ce qu’on a.
/branch essai-sans-cache
La conversation en cours est copiée jusqu’à ce point et tu bascules dans la copie ; l’originale
reste intacte sur le disque et dans le sélecteur, et tu y reviens par /resume.
Le dégât que ça t’évite : si tu rouvres la même session dans deux terminaux sans dupliquer, les messages des deux s’entremêlent dans un seul fil. Rien ne bloque, rien ne prévient.
Ce que ça ne fait pas
Deux questions, et tu sais lequel des deux fils te rattrape
La leçon 2 t’a donné la liste des trous. Ce qui manque, c’est de savoir trancher en situation, quand quelque chose vient de casser et que tu n’as pas envie de relire une page de documentation. Deux questions, dans cet ordre :
- Est-ce que ce sont ses outils d’édition de fichiers qui ont écrit ? Si le fichier a été touché par une commande (la sienne ou la tienne), non. Si tu l’as modifié toi-même en dehors de l’outil, ou depuis une autre session ouverte en parallèle, normalement non plus — sauf si la session a elle-même édité ce fichier-là : il est alors suivi, et restaurer écrase ta correction avec l’état d’avant.
- Est-ce que ça s’est passé sous tes yeux, pendant ton tour ? Ce qui tourne en arrière-plan édite bien avec les mêmes outils, mais en dehors des points de ta session : un subagent (un ouvrier isolé qui travaille à part et ne rend qu’un résumé), une relecture automatique lancée avec correction.
Deux « oui » : le rembobinage le défait. Un seul « non » : pour défaire, c’est git, et rien d’autre.
Une exception ne suit ni l’une ni l’autre, parce qu’elle est physique : les liens. Symboliques ou physiques, ces fichiers-là sont sautés pendant une restauration et gardent leur contenu actuel. Cas très courants dès le premier jour : une configuration liée par un gestionnaire de fichiers personnels, des fichiers posés en lien physique par un gestionnaire de paquets.
Ce que l’avertissement ne te dit pas. Tu vois passer un Restored the code, but skipped N files : un compte, pas les chemins. Deux moyens de les obtenir, et le second marche après coup :
- activer le journal de débogage avant la restauration — au lancement avec
claude --debug, ou avec/debugen cours de session ; il nomme chaque chemin sauté ; - sur macOS ou Linux, chercher les liens toi-même :
find . -type lpour les liens symboliques,find . -type f -links +1pour les liens physiques.
Les liens ne sont d’ailleurs pas la seule cause de saut : un fichier dont le répertoire a changé depuis le point de restauration, ou dont la sauvegarde ne peut pas être lue de façon sûre, est sauté aussi. Et un conseil de la documentation qui vaut d’être suivi à la lettre : si un fichier sauté est un lien que tu n’as pas créé volontairement, va inspecter ce chemin — quelque chose a remplacé ce fichier après le point de restauration. Avant la version 2.1.216, ce paragraphe ne décrivait pas ton écran : le rewind écrivait et supprimait à travers les liens sans signaler de restauration partielle.
Ce que le fil ne garde pas éternellement
- Le plafond porte sur les copies de fichiers, pas sur tes messages. Les copies ne sont conservées que pour les cent points les plus récents d’une session. Au-delà, la liste de tes messages reste et le menu s’ouvre toujours, mais la restauration du code n’est plus possible pour ces points-là.
- Trente jours est un défaut, pas une horloge. Les points disparaissent avec les sessions au
terme d’une durée de rétention réglable —
cleanupPeriodDays. Le ménage se met en pause plutôt que de supprimer au hasard quand cette durée ne peut pas être déterminée de façon sûre : un fichier de réglages illisible, par exemple. - Et pendant ces trente jours, tout est sur ton disque en clair. C’est ce qui rend la reprise
possible : la conversation est écrite telle quelle sous
~/.claude/projects/, sans chiffrement. Donc tout ce qu’il a lu y est aussi — y compris, si tu l’as laissé les lire, les fichiers d’identifiants que la leçon 8 t’apprendra à lui interdire. C’est la deuxième raison de poser ce refus de lecture, et la moins évidente : il ne protège pas seulement l’instant, il évite que le contenu se recopie dans un journal qui, lui, reste un mois. - Le rembobinage du code peut être coupé. C’est un réglage,
fileCheckpointingEnabled, visible dans/configsous le libellé « Rewind code (checkpoints) » ; et une variable d’environnement,CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING, le neutralise par-dessus. Sur une machine que tu n’as pas configurée seul,/configest l’endroit où vérifier avant de compter dessus.
Une boîte de dialogue peut faire partir ce journal, et elle ne ressemble pas à ça. De temps en temps, l’outil demande « How is Claude doing this session? ». Répondre à cette question-là n’envoie que ta note, rien d’autre — même en fermant la boîte. Mais une seconde question peut suivre, distincte, qui demande si Anthropic peut regarder la transcription de ta session. C’est celle-là qui engage quelque chose, et ses trois réponses ne coûtent pas la même chose :
- Yes téléverse la transcription de la session, celle des subagents, et le journal brut lu depuis ton disque. Les formes connues de clés d’API sont caviardées avant l’envoi — mais « le code source, le contenu des fichiers et le reste de la conversation partent tels quels ». Conservation : jusqu’à six mois.
- No refuse pour cette fois.
- Don’t ask again refuse et fait disparaître la question des sessions suivantes.
Rien de tout ça n’est un piège : c’est écrit, et le caviardage existe. Mais c’est une boîte qui apparaît en fin de session, quand tu es en train de partir, et dont le premier bouton envoie le contenu de tes fichiers. Ça vaut de le savoir avant de la voir, plutôt qu’après l’avoir cliquée.
Une reprise restaure la conversation, appels d’outils et résultats compris. Elle restaure aussi l’essentiel de l’état de la session : le modèle sur lequel elle tournait, et le mode d’autorisation. Ce qui ne revient pas :
- les options passées au lancement d’origine : configuration de services extérieurs, fichier de réglages, dossiers ajoutés à la volée. Rien ne te rappellera ce que tu avais passé trois jours plus tôt, et la parade est de ne pas s’en remettre à la ligne de commande — les fichiers de réglages standards, eux, sont relus à chaque lancement ;
- les tâches lancées en arrière-plan et les surveillances : elles ne redémarrent pas ;
- deux modes d’autorisation sur six :
planetbypassPermissionsne sont jamais restaurés (auto, lui, ne revient que si ton compte y a toujours droit).
Et c’est dans ce sens-là que ça mord, à l’inverse de ce qu’on suppose : plan est le mode
le plus prudent des six. Il lit, il propose, il n’écrit pas. Tu termines vendredi en mode plan,
tu rouvres lundi, et la session ne repart pas en lecture seule : elle repart dans le mode où
une session neuve démarrerait chez toi, qui est le plus souvent le mode automatique sur les
offres Pro, Max et Team. Regarde ton mode avant de le laisser travailler — lequel exactement, et
pourquoi ça change tout, c’est la leçon 8.
Une dernière chose que rouvrir peut te retirer. Sur une offre Pro ou Max, quand tu reprends une session inactive depuis plus d’une heure environ et dépassant 100 000 tokens, un dialogue s’ouvre avant ton premier message et propose trois façons de continuer : remplacer l’historique par un résumé — augmenté de tes échanges les plus récents et de cinq fichiers lus récemment, mais ce que le résumé laisse de côté n’est plus dans le contexte de Claude ; charger la conversation telle quelle ; ou « Don’t ask me again », qui charge telle quelle et ne repose plus jamais la question. C’est exactement le scénario du lundi matin, et la troisième option vaut pour toutes tes reprises suivantes.
« Ne rien perdre » a deux modes d’échec
Le titre de cette leçon promet beaucoup. Deux situations documentées le démentent.
L’écriture du fil peut échouer — disque plein, quota dépassé, système de fichiers en lecture seule. Un avertissement persistant s’affiche alors sous ta zone de saisie, avec le code d’erreur qui nomme la cause ; il se lève tout seul à la première écriture réussie. Mais les messages envoyés pendant ce temps peuvent manquer à la reprise. Et avant la version 2.1.217, l’échec était silencieux : une reprise amputée était le premier signe.
L’enregistrement peut être coupé entièrement, et deux variables d’environnement le font. L’avertissement, sous la zone de saisie là aussi, te dit laquelle :
CLAUDE_CODE_SKIP_PROMPT_HISTORYest un renoncement volontaire, prévu pour les sessions jetables lancées par script. Elle peut aussi t’arriver par un profil shell ou un script de lancement sans que tu l’aies voulu. Réparation : la retirer de l’environnement qui lanceclaude, puis démarrer une nouvelle session ;CLAUDE_CODE_CHILD_SESSIONest un marqueur que l’outil pose dans les processus qu’il lance lui-même, pour ne pas remplir ton sélecteur des sessions qu’il a ouvertes. Si tu le vois dans une session que tu as lancée toi-même, c’est qu’il a fui par un intermédiaire de longue durée — un terminal, une sessionscreen, un lanceur. La réparation n’est pas la même : redémarre avecCLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1, puis débarrasse du marqueur le terminal ou le lanceur fautif.
Dans les deux cas, rien n’est sauvé rétroactivement : ce qui a été dit avant la réparation n’existe nulle part.
Et ce que ça ne remplace pas
Rien de ce qui part vers l’extérieur n’est rembobinable : base de données, service distant, déploiement. Pour tout ce qui précède, la réponse de la documentation officielle est littéralement d’utiliser git : elle intitule elle-même une section « ce n’est pas un remplacement du contrôle de version ».
Concrètement, ce sont les gestes de la leçon 2, et tu les as déjà : enregistrer ton travail
avant de lancer, puis git restore --staged --worktree . pour annuler ce qui a été modifié.
Les deux drapeaux ne sont pas de la coquetterie : sans eux, la commande restaure depuis
l’index, donc elle ne défait pas ce qu’un git add lancé en chemin y a déjà mis — et un agent
en lance. Le fil sert au dépannage
immédiat, à l’échelle d’une session ; l’historique durable et le travail à plusieurs, c’est
autre chose, et c’est la leçon 14.
Si ton projet n’est pas sous git, la leçon 2 t’a donné le filet du jour : une copie du dossier ailleurs, faite avant de lancer. Tant que tu ne l’as pas faite, cette leçon-ci ne t’autorise à oser que sur ce que le fil couvre — ses éditions à lui, sous tes yeux. Tout le reste est sans retour, et ce n’est pas une figure de style.
Où c’est écrit
- Checkpointing — les points de restauration, le menu de rewind et ses limites ;
- Sessions — reprendre, nommer, dupliquer, ce qu’une reprise restaure, et le dialogue de reprise résumée ;
- Erreurs — les fichiers sautés pendant une restauration, et les avertissements d’enregistrement ;
- Usage des données — ce qui est conservé, combien de temps, ce que la boîte de fin de session envoie quand on répond oui, et ce qui change selon l’offre ; c’est la page à relire de temps en temps, parce que c’est celle qui bouge ;
- Le dossier
~/.claude— la durée de rétention et ce que le ménage supprime ; - Réglages et variables d’environnement — de quoi couper le rembobinage ou l’enregistrement.
Liens vers les pages anglaises, pour la raison donnée en leçon 4 : remplace /en/ par /fr/ si
tu préfères le français, en sachant que la traduction est en retard et emploie un autre
vocabulaire.
Ce que cette leçon ajoute à ces pages : les deux questions qui te disent, en situation, lequel des deux fils te rattrape ; la liste rassemblée de ce qui rend la promesse fausse (coupures, plafonds, reprise résumée), qu’aucune page ne réunit ; et l’arbitrage pour qui n’a pas encore git, que la documentation n’a aucune raison de faire.
Le point de bascule
Tu as basculé le jour où, avant de tenter quelque chose de risqué, tu ne te demandes plus « est-ce que je vais pouvoir revenir en arrière ? » mais « par quel fil je reviens : celui de la session, ou celui que j’ai posé moi-même avant de lancer ? ». Les deux questions se ressemblent ; seule la seconde a une réponse.
Vérifier que c’est passé
Tu lui as demandé de renommer trois fichiers. Il l'a fait sous tes yeux, pendant ton tour, en lançant `mv`. Tu changes d'avis : rewind ou git ?
Git. La première des deux questions suffit à trancher, et « sous tes yeux » ne rattrape rien ici : ce ne sont pas ses outils d’édition de fichiers qui ont écrit, c’est une commande. Le fil du code ne suit que les éditions passées par ses outils. La seconde question (pendant ton tour ou en arrière-plan) ne se pose que si la première a répondu oui.
Tu rouvres lundi la session de vendredi, que tu avais laissée en mode plan. Un dialogue s'ouvre avant que tu aies tapé quoi que ce soit, et une fois dedans, le mode affiché n'est pas celui de vendredi. Anormal ?
Non, les deux sont documentés. Le dialogue apparaît sur une offre Pro ou Max quand la session
reprise est inactive depuis plus d’une heure environ et dépasse 100 000 tokens : une de ses
options remplace l’historique par un résumé, et celle qui s’appelle « Don’t ask me again »
s’applique à toutes tes reprises suivantes. Quant au mode, plan et bypassPermissions ne sont
jamais restaurés — et c’est le sens qui surprend : plan est le mode qui n’écrit pas, donc ta
session ne repart pas en lecture seule. Regarde ton mode avant de le laisser travailler,
c’est la leçon 8.
Tu ouvres le sélecteur et la session d'hier n'y est pas. Avant de conclure qu'elle est perdue, tu vérifies quoi ?
D’abord le cadrage : par défaut, le sélecteur ne montre que le worktree courant. Ctrl+W élargit
à tous les worktrees du dépôt (la touche ne s’affiche que si le dépôt en a plusieurs), Ctrl+A
à tous les projets de la machine. Ensuite le dossier : claude --continue ne regarde que celui
d’où tu la lances.
Restent deux familles qui n’apparaissent jamais dans la liste — les sessions lancées en mode non
interactif, qui se reprennent par leur identifiant, et celles dont le premier message était une
commande /loop.
Ces principes, appliqués à votre code.
Le parcours donne les principes et les déclencheurs. Le reste — la configuration réelle, les scripts, l'adaptation à votre projet — se travaille ensemble.