Auto Memory dans Claude Code

Problème: Tu as ton CLAUDE.md en place avec les règles du projet, mais Claude continue de demander les mêmes choses sur les commandes de build, les conventions de test, et les bizarreries de débogage. Les instructions couvrent ce que tu veux que Claude fasse. Elles oublient ce que Claude a déjà appris sur ton repo.

Victoire rapide: Vérifie si auto memory est déjà actif. Dans n'importe quelle session Claude Code, lance /memory. Un sélecteur s'ouvre montrant tes fichiers CLAUDE.md et un bouton auto-memory. Le bouton est activé par défaut, ce qui veut dire que Claude a discrètement pris des notes de projet pour toi.

# Find your project's auto memory directory
ls ~/.claude/projects/

Tu vois des répertoires listés? Claude a des notes qui t'attendent. Continue à lire pour apprendre ce qui va dedans, comment travailler avec, et comment ils cohabitent avec ton système CLAUDE.md. Si tes fichiers de mémoire semblent gonflés après beaucoup de sessions, regarde Auto Dream, la fonction de consolidation qui nettoie et réorganise ce qu'Auto Memory écrit.

Ce qu'est réellement Auto Memory

Auto memory est un dossier persistant où Claude enregistre ses apprentissages, patterns, et insights pendant qu'il travaille. Voici la distinction clé: CLAUDE.md, ce sont tes instructions à Claude. MEMORY.md, ce sont les notes de Claude à lui-même sur ton projet.

CLAUDE.md, c'est où tu écris des trucs comme "utilise pnpm, pas npm" ou "écris les tests avant le code." Auto memory, c'est où Claude note ses propres observations: "la commande de build est pnpm build, les tests vivent dans __tests__/, l'API utilise Express avec middleware dans src/middleware/."

Ne confonds pas ça avec Session Memory, qui stocke des résumés au niveau conversation pour le rappel inter-sessions. Auto memory travaille un niveau plus profond. Il détient des connaissances de projet durables qui restent, peu importe quelle conversation les a créées.

Trois systèmes de mémoire, côte à côte

Claude Code fait tourner maintenant trois systèmes de mémoire séparés. Savoir lequel utiliser t'évite de faire le même travail deux fois ou de choisir le mauvais outil.

La meilleure config fait tourner les trois ensemble. CLAUDE.md pose les règles. Auto memory enregistre ce que Claude apprend en chemin. Session Memory garde le fil entre les sessions.

Où vivent les fichiers

Chaque projet obtient son propre dossier de mémoire, ancré à la racine du repo git:

~/.claude/projects/<project>/memory/
├── MEMORY.md          # Main index, loaded every session
├── debugging.md       # Detailed debugging patterns
├── api-conventions.md # API design decisions
└── ...                # Any topic files Claude creates

Deux détails de stockage qui valent le coup d'être connus:

• La racine du repo git, c'est ce qui définit le chemin du projet. Chaque sous-répertoire à l'intérieur du même repo partage un dossier de mémoire. Lance Claude depuis src/api/ et tu tombes sur la même mémoire qu'en lançant depuis la racine du repo.
• Les git worktrees ont chacun leur propre dossier. C'est voulu. Des worktrees différents détiennent généralement des branches différentes dans des états différents.
• En dehors d'un repo git, le répertoire de travail joue le rôle de la racine du repo.

Ce qui est noté

Pendant que Claude travaille sur ton projet, il classe les notes sous quelques catégories:

Patterns de projet: commandes de build, conventions de test, choix de style de code. Lance ta suite de tests une fois et Claude enregistre la commande plus les flags spéciaux dont il avait besoin.

Insights de débogage: corrections pour les bugs délicats et les racines d'erreur courantes. Tu passes du temps à traquer un problème CORS ou un nœud de config webpack? Claude écrit la solution.

Notes d'architecture: fichiers clés, comment les modules sont reliés, abstractions importantes. Claude cartographie le territoire une fois pour ne pas avoir à redécouvrir ton layout à chaque session.

Tes préférences: comment tu communiques, tes habitudes de workflow, tes choix d'outils. Claude remarque les patterns sur lesquels tu t'appuies.

MEMORY.md fonctionne comme un index court. Quand les notes s'accumulent, Claude déplace le détail dans des fichiers thématiques comme debugging.md ou patterns.md. Ça garde le fichier principal sous 200 lignes, vu que seules les 200 premières lignes se chargent au démarrage.

Comment l'utiliser

Laisse-le juste tourner

Le chemin le plus facile: laisse-le tranquille. Auto memory est activé par défaut. Claude lit et écrit les fichiers de mémoire en arrière-plan pendant que tu travailles. Tu le remarques pendant les sessions quand Claude touche des fichiers dans le dossier mémoire.

Sauvegarde quelque chose de spécifique

Dis directement à Claude quoi stocker:

"remember that we use pnpm, not npm"
"save to memory that the API tests require a local Redis instance"
"note that the staging environment uses port 3001"

Claude balance ça dans le bon fichier de mémoire tout de suite.

Parcours et édite

Pendant n'importe quelle session, lance /memory pour ouvrir le sélecteur de fichiers de mémoire. Ça liste tous les fichiers de mémoire (CLAUDE.md, auto memory, config locale) et te laisse ouvrir n'importe lequel dans ton éditeur système.

Tu peux aussi les lire depuis le shell:

# List all memory files for a project
ls ~/.claude/projects/<project>/memory/
 
# Read the main memory index
cat ~/.claude/projects/<project>/memory/MEMORY.md
 
# Read a specific topic file
cat ~/.claude/projects/<project>/memory/debugging.md

Ce sont des fichiers markdown simples. Édite-les quand tu veux. Supprime les entrées qui ont vieilli. Réorganise à mesure que le projet grandit.

Configuration et contrôle

Auto memory est livré activé par défaut. Voici chaque bouton que tu peux tourner:

Basculer par session

Lance /memory et retourne le bouton auto-memory. Le moyen le plus rapide de l'activer ou désactiver pour ton workflow actuel.

Tue-le pour tous les projets

Balance ça dans tes paramètres utilisateur:

// ~/.claude/settings.json
{ "autoMemoryEnabled": false }

Tue-le pour un projet

Balance ça dans les paramètres du projet:

// .claude/settings.json
{ "autoMemoryEnabled": false }

Override par variable d'environnement

CLAUDE_CODE_DISABLE_AUTO_MEMORY bat tous les autres paramètres. C'est le bon choix pour les pipelines CI, l'automatisation, et les déploiements gérés:

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1  # Force off
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=0  # Force on

Ça passe outre à la fois le bouton /memory et settings.json, donc ça fonctionne comme un kill switch dur.

Quand utiliser quoi

Trois systèmes de mémoire, un cadre de décision:

Utilise CLAUDE.md quand tu veux des règles dures. Standards de codage, décisions d'architecture, commandes requises, conventions d'équipe. CLAUDE.md se charge en entier au démarrage et se positionne en haute priorité. Si tu veux qu'un pattern soit suivi à chaque fois, il va ici.

Utilise auto memory quand tu veux que Claude capte les choses au fur et à mesure. Les patterns qui émergent pendant le vrai travail, les corrections de débogage, les préférences discrètes. Tu n'as pas besoin de tout planifier à l'avance.

Utilise Session Memory quand tu as besoin de continuité de conversation. Session Memory garde le fil de ce que tu as discuté et décidé dans chaque session. C'est la couche "qu'est-ce qu'on a fait hier".

Utilise le répertoire rules quand ton CLAUDE.md a dépassé un fichier. Divise tes instructions en fichiers ciblés sous .claude/rules/ pour une structure plus propre sans perdre la priorité.

Le chevauchement est voulu. Auto memory capte les choses que tu as oublié de mettre dans CLAUDE.md. Session Memory porte le contexte que les notes au niveau projet ne peuvent pas. Empile-les et tu obtiens une mémoire en couches couvrant règles, connaissances de projet, et historique de conversation.

Bonnes pratiques

Garde MEMORY.md sous 200 lignes. Seules les 200 premières lignes se chargent au démarrage. Claude reçoit l'instruction de rester concis en poussant le détail dans des fichiers thématiques. Si tu édites à la main, respecte la même limite.

Révise tes fichiers de mémoire de temps en temps. Comme toutes les notes, elles vieillissent. Après un gros refacto ou changement d'architecture, survole les fichiers et supprime ce qui n'est plus vrai.

Ne double pas entre CLAUDE.md et auto memory. Si quelque chose doit être une règle, mets-le dans CLAUDE.md. Si c'est un pattern qui pourrait changer, laisse auto memory le porter.

Sauvegarde explicitement les trucs critiques. Quand tu craques un bug méchant ou verrouilles une grosse décision d'architecture, dis à Claude de le retenir. Ne parie pas sur Claude pour tout attraper tout seul.

Désactive auto memory en CI. L'automatisation n'a pas besoin que Claude empile des notes sur ta box de build. Mets CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 dans ta config CI.

Paire-le avec l'ingénierie de contexte. Auto memory est une couche d'une plus grande stratégie d'ingénierie de contexte. Plus tu mets de soin dans ce que Claude sait au démarrage, plus chaque session te renvoie.

Prochaines étapes

• Configure ton système de mémoire CLAUDE.md pour des instructions de projet persistantes
• Comprends Session Memory pour la continuité de conversation inter-sessions
• Apprends les stratégies de gestion de contexte pour travailler dans les limites de tokens
• Explore le répertoire rules pour des instructions de projet modulaires
• Lis sur l'ingénierie de contexte pour des systèmes de mémoire AI en production

Auto memory comble le fossé entre ce que tu dis à Claude et ce que Claude comprend par lui-même. CLAUDE.md possède les règles "fais-le comme ça". Auto memory possède la connaissance "j'ai remarqué ça sur ton projet". Fais-les tourner ensemble et tu t'expliques moins et tu livres plus.