Si tu utilises Claude Code dans VS Code, tu as probablement pris un réflexe simple : « je retrouverai cette discussion dans Past Conversations ». Sauf que sur certaines versions, l’historique peut se dégrader tout seul : titres qui disparaissent, titres qui ne matchent plus la conversation, sessions qui se ressemblent toutes. Et là, tu ne perds pas juste du confort. Tu perds du contexte. Du vrai temps. Parfois des décisions techniques.
Le plus énervant, c’est que ce n’est pas un gros crash. C’est un bug de qualité de vie qui te donne l’impression que tout va bien… jusqu’au jour où tu cherches « la conversation où on a fixé l’architecture » et que tu tombes sur dix titres inutiles.
Pourquoi les titres se corrompent : un scan “brut” sur ~64 KB de JSONL
La cause racine, d’après l’analyse partagée par la communauté, est assez terre-à-terre. Les conversations sont enregistrées dans des fichiers .jsonl (JSON Lines). Et pour retrouver le customTitle d’une session, l’extension ne reconstruit pas proprement l’état en relisant tout le fichier. Elle ferait plutôt une recherche de chaîne dans une fenêtre limitée aux derniers ~64 KB du fichier.
Ce choix est compréhensible côté perf (lire moins, aller plus vite). Mais ça crée des effets de bord méchants dès que la conversation grossit, ou dès que plusieurs occurrences de champs proches apparaissent dans ce morceau de texte. Tu te retrouves avec un système où le “titre affiché” n’est plus une donnée fiable, mais un résultat fragile d’un parsing approximatif sur un extrait.
Dit autrement : ton historique ressemble à une base de données, mais il se comporte parfois comme un log qu’on grep à la va-vite.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Les 3 modes de panne que tu vas voir (et qui te font perdre du temps)
Le premier mode de panne, c’est l’éviction. Ta conversation devient longue. Le champ qui contient le titre n’est plus dans les derniers ~64 KB du fichier. Résultat : le titre “n’existe plus” du point de vue de l’UI, alors qu’il est peut-être toujours dans le fichier, plus haut.
Le deuxième, c’est la contamination. Si le mécanisme de recherche accroche un mauvais bout de texte (ou une occurrence d’un champ similaire), tu peux voir un titre venant d’ailleurs. C’est particulièrement vicieux, parce que ça te donne une fausse confiance : tu cliques sur un titre “logique”… et tu n’atterris pas dans la bonne conversation.
Le troisième, c’est la collision ou l’incohérence progressive : plusieurs sessions finissent par avoir des titres identiques, tronqués, ou décalés. Et là, ton historique devient une liste de doublons. Tu as toujours les conversations, techniquement, mais tu n’as plus d’index humain pour naviguer dedans.
Pourquoi c’est un vrai problème (pas juste un bug “cosmétique”)
Quand on bosse avec un agent, l’historique sert de mémoire externe. On y met des arbitrages, des extraits de config, des commandes qui ont marché, des explications de bugs… bref, les choses que tu ne veux pas redécouvrir deux jours plus tard.
Si le titre saute, tu peux encore retrouver la session en fouillant. Mais dans la vraie vie, tu ne fouilles pas. Tu passes à autre chose, tu refais, tu te dis que « tant pis ». C’est exactement comme un outil de notes qui perd ses titres : tu continues à écrire, mais tu arrêtes de relire. Et à ce stade, l’historique n’a plus de valeur.
Mitigations immédiates : garder des sessions “courtes” (et arrêter de nourrir le bug)
Je ne vais pas te vendre une “solution” magique si l’extension a un bug structurel. Par contre tu peux réduire les chances de te faire avoir.
Le levier le plus efficace, c’est de limiter la taille de chaque conversation. En pratique, ça veut dire : ouvrir une nouvelle session quand tu changes vraiment de sujet, éviter de coller des énormes dumps (logs gigantesques, fichiers entiers, JSON monstrueux), et arrêter de laisser une session vivre pendant des jours “par confort”. C’est tentant, mais c’est le meilleur moyen de pousser le titre hors de la fenêtre des ~64 KB.
Autre point très terre-à-terre : si tu t’appuies sur les titres custom (ou auto), fais-le tôt. Si tu attends la fin d’une session déjà longue pour compter sur le titre comme repère, tu joues avec un index qui peut devenir instable.
Et si tu as une option côté extension pour désactiver certaines mécaniques de titrage automatique, ou limiter ce qui est stocké/affiché, ça vaut le coup de tester. Pas parce que ça “répare” tout, mais parce que moins tu as de logique fragile autour du titre, moins tu as d’incohérences. Je préfère un titre basique mais stable, qu’un titre “smart” qui se mélange.
Le bon réflexe : considérer ces JSONL comme des logs, et les sauvegarder
Le changement de mentalité qui fait gagner du temps : ton historique Claude Code dans VS Code, c’est une donnée locale. Donc c’est une donnée qui peut être corrompue, effacée, ou rendue inutilisable par une mise à jour. Et par défaut, tu n’as pas forcément de stratégie de sauvegarde, contrairement à ton repo Git.
Je te conseille d’assumer que c’est un dossier “à backuper” au même niveau que ~/.ssh ou certaines configs. Pas pour tout garder éternellement, mais pour éviter le jour où tu perds un mois de conversations utiles, ou le jour où tu changes de machine et tu réalises que rien n’est portable.
Tu peux déjà faire un backup simple en copiant le dossier de stockage de l’extension. Le chemin exact dépend de ton OS et de l’emplacement VS Code, mais typiquement c’est dans un globalStorage sous le profil utilisateur. Si tu ne sais pas où c’est, le plus fiable est de chercher les fichiers .jsonl liés à Claude Code dans le répertoire utilisateur de VS Code.
# Exemple d’approche (à adapter) : trouver des fichiers .jsonl liés à Claude Code
# Sur macOS / Linux, tu peux partir de ton HOME.
cd ~
# Attention: ça peut être un peu long selon ton disque.
find . -type f -name "*.jsonl" 2>/dev/null | grep -i "claude\|anthropic\|claude-code" | head -n 50
Une fois que tu as identifié le dossier, un backup régulier peut être aussi bête qu’une copie horodatée. Le point important, c’est de le faire souvent (quotidien, ou à chaque fin de journée si tu utilises l’outil en continu), et de le stocker quelque part qui survit à une réinstall.
# Backup horodaté (exemple) vers un dossier de sauvegarde local
# Remplace CLAUDE_DIR par le bon chemin.
CLAUDE_DIR="$HOME/Library/Application Support/Code/User/globalStorage/..."
BACKUP_DIR="$HOME/Backups/claude-code"
mkdir -p "$BACKUP_DIR"
ts=$(date +"%Y-%m-%d_%H%M")
cp -a "$CLAUDE_DIR" "$BACKUP_DIR/claude-code_$ts"
Si tu bosses sur des sujets sensibles, ne fais pas l’erreur classique de balancer ça en vrac dans un Drive non chiffré. Ces conversations contiennent souvent des bouts de code, des URLs internes, des extraits de config, parfois pire. Mets au minimum un chiffrement côté fichier (age, GPG, 7z chiffré), ou un stockage déjà chiffré de bout en bout.
Portabilité : rendre l’historique exploitable même si l’UI part en fumée
Le vrai but, ce n’est pas juste de “sauver des fichiers”. C’est de pouvoir retrouver de l’info quand l’interface Past Conversations devient bruitée.
Mon approche pragmatique : j’essaie de garder un naming humain en parallèle de l’UI. Quand une conversation aboutit à une décision, je la résume ailleurs (dans le repo, ou dans un dossier de notes du projet). Pas une dissertation. Un petit mémo : « pourquoi on a choisi X », « quelle commande a débloqué Y », « quel piège éviter ». Le jour où l’UI perd les titres, je ne suis pas bloqué.
Et si tu veux aller plus loin, tu peux te faire une mini “portabilité” à la main : exporter ponctuellement en Markdown (si ton outil le permet), ou recopier les messages vraiment importants dans une note versionnée. Ça paraît old school, mais ça marche. Et surtout, ça évite le piège mental « c’est bon, c’est dans l’historique ».
Enfin, avoir un index local, ça change tout. Même si le titre est corrompu, le contenu, lui, reste souvent cherchable. Un simple ripgrep sur le dossier de logs te retrouve une fonction, un nom de table, une phrase-clé.
Le check “données clients” : ce qui ne devrait jamais finir dans ces logs
Là je vais être un peu sec, parce que j’ai déjà vu des gens se tirer une balle dans le pied. Les historiques d’agents, ce sont des journaux de travail. Donc on y colle naturellement des secrets et des données. Et ensuite on fait un backup, parfois on le synchronise, parfois on l’envoie à un collègue pour “regarde ce que l’agent a répondu”. Mauvaise pente.
Ce que j’évite systématiquement de coller tel quel : des clés API, des tokens de session, des cookies, des dumps de base contenant des emails/téléphones, des fichiers de config avec secrets, des URLs d’admin avec paramètres. Si j’ai besoin d’un exemple, je le redacte. Ça prend 30 secondes, et ça évite des regrets.
Et si tu bosses en presta ou avec des contraintes contractuelles, rappelle-toi un truc : même si c’est “local”, ce sont des données du projet. Donc ça mérite le même niveau de soin que tes logs applicatifs ou ton dossier .env.
Mon avis : traite ton historique comme un outil, pas comme une promesse
Les agents dans l’IDE, c’est génial quand ça marche. Mais il y a encore plein de zones “pas industrielles”, surtout dès qu’on touche au stockage local, au multi-session, aux petites features de confort. Ce bug de titres est typiquement le genre de détail qui ne bloque personne… mais qui te coûte cher à l’échelle d’un mois.
Si tu veux une règle simple : ne construis pas ton workflow sur l’idée que l’historique sera toujours propre. Fais en sorte que les décisions importantes existent ailleurs. Et tant que le bug n’est pas corrigé proprement, garde des sessions plus courtes et backupe les fichiers. C’est basique. C’est un peu chiant. Mais ça évite le jour où tu te retrouves à scroller des conversations “sans noms” en te demandant où est passée la bonne.
