Claude Code supprime l’historique après 30 jours : comment le sauvegarder

Pour obtenir de l’aide sur l’utilisation du service, consultez la documentation Ailoot.

Claude Code efface-t-il vraiment l’historique de vos sessions ?#

Vous ouvrez Claude Code pour reprendre une session d’il y a deux mois… et elle a disparu. Le fichier a été complètement effacé du disque. Ce n’est ni un dysfonctionnement ni un bug rare : c’est ainsi que fonctionne le mécanisme de nettoyage par défaut.

Un seul paramètre contrôle le nettoyage : cleanupPeriodDays. Sa valeur par défaut est 30. Chaque fois que Claude Code démarre, il parcourt le dossier d’historique et supprime tout ce qui est plus ancien que cette durée. Ce paramètre n’était même pas présent dans mon fichier ~/.claude/settings.json : c’est donc la valeur par défaut qui s’appliquait, et certaines de mes anciennes sessions avaient déjà disparu.

Plusieurs rapports de bugs à ce sujet sont ouverts dans le dépôt d’Anthropic, et aucun n’a été corrigé.

Où Claude Code stocke-t-il l’historique des sessions ?#

Retrouver votre historique est facile. Ouvrez un terminal et affichez le contenu du dossier :

ls ~/.claude/projects/

Chaque sous-dossier correspond à un projet distinct. Son nom encode le chemin : par exemple, un projet situé dans /Users/alex/dev/shop devient le dossier -Users-alex-dev-shop. Il contient les fichiers de session :

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← une session = un fichier
# a91b7d40-....jsonl

Chaque fichier .jsonl est un journal organisé ligne par ligne : une ligne correspond à un événement de session. Il contient bien plus que le texte de la conversation. Il renferme la logique derrière vos décisions : pourquoi vous avez choisi une structure de base de données particulière, quelles options vous avez écartées, où Claude s’est trompé et comment vous avez corrigé son erreur.

En substance, c’est le journal de développement d’un projet. C’est pourquoi sa perte est douloureuse : vous ne perdez pas une « conversation », mais le contexte que vous avez accumulé pendant des semaines. J’ai expliqué la structure de ce contexte dans le guide « Claude Memory vs. CLAUDE.md ».

Pourquoi Anthropic supprime-t-il les transcriptions après 30 jours ?#

La suppression a une raison d’être, qu’il vaut mieux comprendre avant de tout désactiver. Une transcription est du texte brut. Si Claude a lu un fichier .env pendant une session, inséré une clé dans une commande ou si vous avez collé un mot de passe dans un prompt, tout cela s’est retrouvé en texte brut dans le fichier .jsonl. Plus un tel fichier reste longtemps sur le disque, plus le risque qu’il finisse par fuiter augmente.

Anthropic l’explique clairement : les transcriptions peuvent contenir du code source, des identifiants et d’autres informations sensibles. Les conserver sur le disque plus longtemps que nécessaire crée un véritable risque pour la confidentialité. La période de 30 jours a été choisie comme compromis.

Les objections de la communauté portent sur trois points : la suppression est silencieuse (aucun avertissement à la configuration ou au démarrage), le consentement n’est pas demandé (personne ne vous pose la question) et aucune récupération n’est possible (la Corbeille n’est pas utilisée et il n’existe pas de retour en arrière). Dans l’issue #59248, les développeurs demandent une seule chose : rendre le nettoyage équitable, avec un avertissement, une période de récupération et une durée par défaut moins agressive.

Pourquoi un script de sauvegarde peut-il déclencher lui-même la suppression ?#

C’est la partie la plus délicate, et elle piège les personnes qui essaient de protéger leurs données elles-mêmes. Le nettoyage examine la mtime, l’horodatage de la dernière modification du fichier. Il suppose que la mtime indique la dernière fois que vous avez travaillé dans la session. En pratique, n’importe quoi peut modifier cette valeur : un client de synchronisation Dropbox ou iCloud, rsync, un antivirus, un indexeur ou votre propre script de sauvegarde.

Voici le piège. Vous décidez de sauvegarder votre historique et configurez la synchronisation cloud de ~/.claude/projects/. À un moment donné, le service de synchronisation réécrit un fichier et règle sa mtime sur une date antérieure (cela peut arriver lors d’une restauration depuis une copie cloud). Au démarrage, Claude Code voit un fichier « ancien » et le supprime. Vous vouliez le sauvegarder, mais vous avez accéléré sa suppression.

Une seule conclusion s’impose : la sauvegarde doit se trouver en dehors de ~/.claude/projects/. Le nettoyage n’agit qu’à l’intérieur de ce dossier. Une copie stockée ailleurs échappe à son action. C’est sur ce principe que je vais construire la solution.

Comment arrêter immédiatement la suppression de l’historique ?#

Arrêtez la suppression en trois étapes :

1. Ouvrez le fichier de paramètres : ~/.claude/settings.json (s’il n’existe pas, créez-le).
2. Ajoutez le paramètre cleanupPeriodDays avec une valeur élevée :

{
  "cleanupPeriodDays": 3650
}

3. Enregistrez le fichier. Le paramètre prendra effet au prochain démarrage de Claude Code.

La valeur 3650 correspond à dix ans : en pratique, la suppression ne se produira plus. Si vous souhaitez conserver le nettoyage tout en disposant de davantage de temps, définissez la valeur sur 365 (un an) ; seules les sessions datant de plus d’un an disparaîtront alors. Vous pouvez vérifier que le paramètre a été pris en compte avec cette commande :

grep cleanupPeriodDays ~/.claude/settings.json

Une réserve facile à manquer : prolonger la période ne restaure PAS ce qui a déjà été supprimé. Le nettoyage s’exécute au démarrage, et tout ce qui a été effacé lors des exécutions précédentes a définitivement disparu. C’est pourquoi il faut commencer par définir ce paramètre : il prévient les pertes futures, mais ne ramène pas ce qui a déjà été effacé. Pour éviter de perdre l’historique de Claude Code ainsi que votre projet à cause d’une commande accidentelle, consultez le guide « Comment configurer Claude Code pour qu’il ne casse pas votre projet ».

L’historique de vos sessions fait partie du second cerveau de votre projet : il contient une logique de décision que vous n’avez consignée nulle part ailleurs. cleanupPeriodDays préserve les fichiers, mais ne les transforme pas en système permettant de retrouver ce dont vous aurez besoin dans six mois.

Comment archiver automatiquement l’historique hors du dossier de nettoyage ?#

L’idée est simple : laissez Claude Code faire ce qu’il veut de son dossier, tout en conservant une archive distincte ailleurs. Elle échappe à ce nettoyage, mais reste exposée aux pannes de disque, suppressions accidentelles et échecs de copie. Voici comment la configurer :

1. Créez un dossier d’archive en dehors du répertoire géré :

mkdir -p ~/claude-history-archive

2. Copiez-y votre historique actuel. L’option -a préserve la structure et les horodatages ; --ignore-existing laisse intacts les fichiers déjà copiés :

rsync -a ~/.claude/projects/ ~/claude-history-archive/

3. Automatisez l’exécution une fois par jour. Sur macOS, utilisez launchd. Créez le fichier ~/Library/LaunchAgents/com.example.claudearchive.plist :

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.claudearchive</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/rsync</string>
    <string>-a</string>
    <string>/Users/YOUR_NAME/.claude/projects/</string>
    <string>/Users/YOUR_NAME/claude-history-archive/</string>
  </array>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

4. Chargez l’agent pour qu’il s’exécute en arrière-plan :

launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist

Sous Linux, une seule ligne dans la crontab (crontab -e) suffit :

0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/

Pourquoi cette méthode fonctionne-t-elle alors que la synchronisation de la section précédente échoue ? L’archive se trouve HORS de ~/.claude/projects/, donc le nettoyage ne peut pas la voir. La copie se fait dans un seul sens (du dossier actif vers l’archive), et nous ne modifions pas la mtime des fichiers actifs : le bug de mtime ne se produit donc pas. Même si Claude Code supprime demain une session de son propre dossier, sa copie restera dans l’archive.

Comment transformer l’archive de vos sessions en second cerveau consultable ?#

Accumuler des fichiers ne suffit pas : il faut pouvoir y accéder. Deux étapes transforment l’archive en un outil fonctionnel.

Premièrement, gérez les versions avec git. Initialisez un dépôt dans le dossier d’archive :

cd ~/claude-history-archive
git init
git add -A && git commit -m "Premier instantané de l'historique Claude Code"

Ajoutez git add -A && git commit à la même exécution quotidienne que rsync. Vous disposez maintenant d’un historique des versions : vous pouvez voir ce qui est apparu et quand, et annuler un écrasement accidentel à l’aide d’une seule commande.

Deuxièmement, effectuez des recherches. Les fichiers .jsonl sont du JSON délimité par des lignes, vous pouvez donc utiliser les outils habituels. Trouvez les sessions où un sujet particulier a été abordé :

grep -rl "migration de base de données" ~/claude-history-archive/

Extrayez uniquement le texte de vos prompts d’une session (avec jq, puisqu’il s’agit de JSON) :

jq -r 'select(.type=="user") | .message.content' session.jsonl

À ce stade, l’historique de vos sessions devient le second cerveau du projet : une base de données où vous pouvez retrouver en quelques secondes « comment nous avons pris cette décision en mars ». Pour une explication distincte de la façon dont le contexte évolue pendant une session et de sa gestion, consultez « Où vont les tokens dans Claude Code ».

Peut-on récupérer des sessions déjà supprimées ?#

La réponse honnête : probablement pas. Claude Code n’a aucune fonction de récupération, aucune Corbeille et aucun journal d’annulation pour les transcriptions supprimées. Le fichier disparaît simplement du disque.

Il existe une possibilité : les sauvegardes système, si elles ont été activées à l’avance :

1. macOS Time Machine — si un instantané a sauvegardé ~/.claude/projects/ avant la suppression, vous pouvez récupérer le fichier dans la sauvegarde correspondant à la date voulue.
2. Historique des versions OneDrive / Dropbox — si le dossier était synchronisé avec la gestion des versions activée, cherchez le fichier dans l’historique des versions du cloud (mais gardez à l’esprit le piège de mtime : la synchronisation peut aussi avoir déclenché la suppression).
3. Copies manuelles — tout rsync/cp que vous avez exécuté manuellement vers un emplacement extérieur au dossier géré.

Si aucune de ces copies n’existait, la session est perdue. Et ce n’est pas rare : l’auteur d’un bug dans le dépôt d’Anthropic a vu 26 de ses 38 enregistrements corrompus, soit des mois de travail. La seule protection fiable est celle mise en place AVANT la perte. Configurez cleanupPeriodDays et l’archivage automatique aujourd’hui, tant qu’il reste encore quelque chose à sauvegarder.

Quelle valeur choisir pour cleanupPeriodDays ?#

Un seul paramètre, mais plusieurs usages possibles. Comparez les options et choisissez celle qui correspond à votre situation :

Une réserve importante concernant la sécurité : si vous définissez 3650 et conservez tout, vous acceptez de stocker sur le disque des transcriptions pouvant contenir des clés et du code. C’est un compromis délibéré entre la commodité de l’archive et le risque. Réduisez ce risque : conservez l’archive sur un disque chiffré (FileVault sur macOS), ne la placez pas dans un cloud public et ne la committez pas dans un dépôt git public. J’ai préparé un guide distinct sur les données susceptibles de fuiter par l’intermédiaire de Claude Code : « Sécurité des données dans Claude Code ».

Que faire aujourd’hui : liste de contrôle#

Mettez la protection en place étape par étape :

1. Définissez cleanupPeriodDays: 3650 dans ~/.claude/settings.json : la suppression est arrêtée.
2. Créez ~/claude-history-archive en dehors du dossier géré et lancez le premier rsync -a.
3. Programmez une exécution quotidienne avec launchd (macOS) ou cron (Linux).
4. Initialisez git dans l’archive et ajoutez git add -A && git commit à la même exécution.
5. Vérifiez que l’archive se trouve sur un disque chiffré et qu’elle n’est pas synchronisée avec un cloud public.
6. Vérifiez la réussite de chaque copie planifiée, inspectez une session récente et restaurez périodiquement un échantillon dans un dossier temporaire distinct pour vérifier sa lisibilité.
7. Pour couvrir la perte de l’appareil ou du disque, gardez aussi une sauvegarde indépendante avec des droits adaptés et testez sa restauration. Git sur le même disque n’est pas une sauvegarde indépendante.

L’historique des sessions n’est qu’une couche du contexte qui rend Claude fiable.

Découvrez Ailoot.