# Claude Code supprime l’historique après 30 jours : comment le sauvegarder > Où sont stockées les sessions de Claude Code, comment configurer cleanupPeriodDays et organiser une archive externe avec rsync, launchd ou cron. Source: https://ailoot.ai/blog/fr/claude-code-history-30-days/ Canonical: https://ailoot.ai/blog/fr/claude-code-history-30-days/ Language: fr Publisher: Ailoot (https://ailoot.ai/) Translation: guide-056 Revision: sha256-0c15ba971d23f28729117837c08f127f22a926381f1e7cf987498dcb4fbd017e Pour obtenir de l’aide sur l’utilisation du service, consultez la [documentation Ailoot](https://ailoot.ai/docs/). ## Claude Code efface-t-il vraiment l’historique de vos sessions ?
À retenir Oui. Chaque fois que Claude Code démarre, il supprime les fichiers de session datant de plus de 30 jours. Le paramètre `cleanupPeriodDays` dans `~/.claude/settings.json` en est responsable ; sa valeur par défaut est `30`. La suppression a lieu sans avertissement, sans demander votre consentement et sans possibilité de récupérer les fichiers.
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 ?
À retenir L’historique de chaque session est stocké dans `~/.claude/projects//.jsonl`. Le nom du dossier correspond au chemin absolu du répertoire de travail où vous avez lancé Claude Code, les barres obliques étant remplacées par des tirets. Le fichier `.jsonl` contient toute la conversation, ligne par ligne : vos prompts, les réponses du modèle, les appels d’outils et les modifications de fichiers. C’est précisément cette mémoire que le nettoyage supprime.
Retrouver votre historique est facile. Ouvrez un terminal et affichez le contenu du dossier : ```bash 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 : ```bash 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 »](https://ailoot.ai/blog/fr/claude-memory-claude-md-auto-memory/). ## Pourquoi Anthropic supprime-t-il les transcriptions après 30 jours ?
À retenir Anthropic invoque la confidentialité et la sécurité. Les fichiers de session sont stockés en texte brut sur le disque et peuvent contenir du code source, des mots de passe et des clés API. Les conserver indéfiniment présente un risque : si un ordinateur portable est volé ou si quelqu’un accède au disque, cette personne récupère toutes ces données sensibles. La durée de 30 jours vise à trouver un équilibre entre « reprendre un travail récent » et « ne pas garder des secrets sur le disque plus longtemps que nécessaire ».
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 ?
À retenir Le nettoyage détermine ce qu’il faut supprimer en fonction de la date de modification du fichier (mtime). Il ne vérifie pas l’activité réelle la plus récente d’une session. Tout processus qui touche un fichier `.jsonl` — synchronisation cloud, rsync, éditeur ou script — peut modifier sa mtime et faire passer une session récente pour une session ancienne. Au prochain démarrage de Claude Code, la session sera considérée comme ancienne et supprimée. Le paradoxe : une tentative irréfléchie de sauvegarder l’historique dans le dossier géré accélère sa disparition.
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 ?
À retenir Un seul paramètre. Ouvrez `~/.claude/settings.json` et donnez une valeur élevée à `cleanupPeriodDays`, par exemple `3650` (dix ans). En pratique, cela désactive la suppression automatique : rien ne dépassera cette limite. Important : ce paramètre protège uniquement ce qui n’a pas encore été supprimé. Il est impossible de restaurer l’historique déjà effacé par le nettoyage. Il faut donc agir dès maintenant, avant de perdre une autre session.
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 : ```json { "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 : ```bash 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 »](https://ailoot.ai/blog/fr/claude-code-safe-overnight-setup/). 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 ?
À retenir Copiez les sessions dans une archive située HORS de `~/.claude/projects/`, où le nettoyage ne s’applique pas. Un simple `rsync -a` vers un répertoire distinct une fois par jour suffit : les nouveaux fichiers sont ajoutés et les anciens restent. Comme l’archive se trouve à l’extérieur, ni `cleanupPeriodDays` ni le bug de mtime ne l’affectent. Automatisez l’exécution avec launchd (macOS) ou cron (Linux), et votre historique s’accumulera tout seul.
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é : ```bash 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 : ```bash 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 Label com.example.claudearchive ProgramArguments /usr/bin/rsync -a /Users/YOUR_NAME/.claude/projects/ /Users/YOUR_NAME/claude-history-archive/ StartInterval 86400 ``` 4. Chargez l’agent pour qu’il s’exécute en arrière-plan : ```bash launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist ``` Sous Linux, une seule ligne dans la crontab (`crontab -e`) suffit : ```bash 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 ?
À retenir Placez l’archive sous git pour obtenir une base de données versionnée et entièrement consultable de toutes vos sessions. Lancez `git init` dans le dossier d’archive, puis exécutez chaque jour `git add -A && git commit` pour conserver l’historique des modifications et vous protéger contre les écrasements accidentels. Vous pouvez rechercher d’anciennes sessions avec grep et en extraire du contenu structuré avec jq, puisque `.jsonl` est du JSON délimité par des lignes. L’archive devient ainsi un outil pratique.
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 : ```bash 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é : ```bash 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) : ```bash 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 »](https://ailoot.ai/blog/fr/where-claude-code-tokens-go/). ## Peut-on récupérer des sessions déjà supprimées ?
À retenir Il n’existe aucune méthode intégrée. Claude Code ne place pas les fichiers supprimés dans la Corbeille et ne conserve aucune possibilité de retour en arrière ; le fichier est définitivement effacé. La seule chance réside dans des copies externes effectuées AVANT la suppression : un instantané Time Machine sur macOS, l’historique des versions OneDrive ou Dropbox, ou une sauvegarde manuelle. En l’absence de telles copies, la session est perdue. Voilà pourquoi la protection doit être mise en place à l’avance, avant qu’il y ait quoi que ce soit à perdre.
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 ?
À retenir Pour la plupart des personnes, la meilleure option est `3650` (dix ans, ce qui désactive de fait la suppression), avec une archive externe automatique. Gardez la valeur par défaut `30` uniquement si vous n’avez pas besoin d’historique et qu’il est plus important pour vous de ne pas conserver de secrets sur le disque. La valeur `365` constitue un compromis raisonnable, avec un nettoyage annuel. Autre possibilité : ne pas enregistrer d’historique du tout, en utilisant la variable d’environnement `CLAUDE_CODE_SKIP_PROMPT_HISTORY` ou l’option `--no-session-persistence`, mais cela répond à l’objectif opposé.
Un seul paramètre, mais plusieurs usages possibles. Comparez les options et choisissez celle qui correspond à votre situation : | Valeur | Fonctionnement | Pour qui ? | |----|----|----| | `30` (par défaut) | Supprime au démarrage les sessions datant de plus de 30 jours | Vous n’avez pas besoin d’historique ; éviter de stocker des données sensibles sur le disque est plus important | | `365` | Conserve un an d’historique, puis le nettoie une fois par an | Vous avez besoin d’un historique récent, mais pas d’une archive indéfinie | | `3650` | Désactive de fait la suppression | Vous voulez tout conserver + une archive externe (recommandé) | | `CLAUDE_CODE_SKIP_PROMPT_HISTORY` | N’enregistre aucun historique sur le disque | Confidentialité maximale ; vous n’avez pas besoin d’historique du tout | 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 »](https://ailoot.ai/blog/fr/claude-code-data-access-safety/). ## Que faire aujourd’hui : liste de contrôle
À retenir Ces étapes réduisent les pertes : prolongez la conservation avec `cleanupPeriodDays: 3650`, copiez les sessions hors de `~/.claude/projects/` et versionnez l’archive. Seuls les fichiers copiés avec succès échappent au nettoyage. Un rythme quotidien réussi laisse jusqu’à un jour de changements non archivés ; les exécutions manquées ou ratées augmentent cette fenêtre. Une copie sur le même disque ne protège pas d’une panne de celui-ci.
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.
### Sources - [Documentation Claude Code - Paramètres de settings.json (cleanupPeriodDays)](https://code.claude.com/docs/en/settings) - [Documentation Claude Code - Nouveautés](https://code.claude.com/docs/en/whats-new)
Découvrez [Ailoot](https://ailoot.ai/). ## Questions fréquentes : Claude Code supprime l’historique après 30 jours : comment le sauvegarder ### Une archive quotidienne garantit-elle de ne perdre aucune session ? Non. Elle protège du nettoyage les fichiers copiés avec succès. Même avec des exécutions quotidiennes réussies, jusqu’à une journée récente peut manquer ; les échecs élargissent cette fenêtre. Une copie sur le même disque peut être perdue avec l’original. ### Comment vérifier que l’archive est utilisable ? Vérifiez les copies planifiées, inspectez une session récente et restaurez périodiquement un échantillon dans un dossier temporaire distinct. Testez aussi une sauvegarde indépendante pour couvrir la perte du disque ou de l’appareil. ## Ailoot · L’entreprise et son portefeuille de projets Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI. L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois. Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.