Auto Memory in Claude Code

Problem: Deine CLAUDE.md steht mit Projekt-Regeln, aber Claude fragt immer wieder das Gleiche über Build-Befehle, Test-Konventionen und komische Debug-Eigenheiten. Anweisungen decken ab, was du willst, dass Claude macht. Sie verpassen, was Claude schon über dein Repo gelernt hat.

Quick Win: Schau nach, ob Auto Memory schon läuft. In jeder Claude Code Session führst du /memory aus. Ein Auswahlmenü öffnet sich mit deinen CLAUDE.md Dateien und einem Auto-Memory-Toggle. Der Toggle ist standardmäßig an, das heißt Claude hat still für dich Projekt-Notizen gemacht.

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

Siehst du Verzeichnisse? Claude hat Notizen für dich. Lies weiter, um zu lernen, was reinkommt, wie du damit arbeitest und wie sie neben deinem CLAUDE.md System stehen. Wenn deine Memory-Dateien nach vielen Sessions aufgebläht wirken, schau dir Auto Dream an, das Konsolidierungs-Feature, das aufräumt und reorganisiert, was Auto Memory schreibt.

Was Auto Memory wirklich ist

Auto Memory ist ein persistenter Ordner, wo Claude Gelerntes, Muster und Einsichten loggt, während es arbeitet. Hier ist die wichtige Trennung: CLAUDE.md ist deine Anweisung an Claude. MEMORY.md ist Claudes Notiz an sich selbst über dein Projekt.

CLAUDE.md ist, wo du Sachen schreibst wie "nutze pnpm, nicht npm" oder "schreib Tests vor Code." Auto Memory ist, wo Claude seine eigenen Beobachtungen notiert: "Build-Befehl ist pnpm build, Tests liegen in __tests__/, API nutzt Express mit Middleware in src/middleware/."

Verwechsle das nicht mit Session Memory, das Konversations-Zusammenfassungen für Cross-Session-Erinnerung speichert. Auto Memory arbeitet eine Ebene tiefer. Es hält dauerhaftes Projekt-Wissen, das bleibt, egal welche Konversation es erstellt hat.

Drei Memory-Systeme nebeneinander

Claude Code führt jetzt drei separate Memory-Systeme. Wissen, welches du nutzen sollst, spart dir, dieselbe Arbeit zweimal zu machen oder das falsche Tool zu wählen.

Das beste Setup läuft mit allen drei zusammen. CLAUDE.md legt die Regeln fest. Auto Memory zeichnet auf, was Claude unterwegs lernt. Session Memory hält den Faden zwischen Sessions.

Wo die Dateien liegen

Jedes Projekt bekommt seinen eigenen Memory-Ordner, verankert an der Git-Repo-Root:

~/.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

Ein paar Speicher-Details, die du wissen solltest:

• Die Git-Repo-Root definiert den Projekt-Pfad. Jedes Unterverzeichnis im selben Repo teilt einen Memory-Ordner. Führst du Claude von src/api/ aus, triffst du dasselbe Memory wie vom Repo-Root.
• Git-Worktrees bekommen jeweils ihren eigenen Ordner. Das ist Absicht. Verschiedene Worktrees halten meist verschiedene Branches in verschiedenen Zuständen.
• Außerhalb eines Git-Repos spielt das Working-Directory die Rolle der Repo-Root.

Was aufgeschrieben wird

Während Claude an deinem Projekt arbeitet, legt es Notizen unter ein paar Kategorien ab:

Projekt-Muster: Build-Befehle, Test-Konventionen, Code-Style-Entscheidungen. Führst du deine Test-Suite einmal aus und Claude zeichnet den Befehl plus spezielle Flags auf, die es brauchte.

Debug-Einsichten: Fixes für knifflige Bugs und häufige Error-Ursachen. Verbringst du Zeit mit einem CORS-Problem oder einem Webpack-Config-Knoten? Claude schreibt die Lösung auf.

Architektur-Notizen: Schlüssel-Dateien, wie Module sich zueinander verhalten, wichtige Abstraktionen. Claude kartiert das Terrain einmal, sodass es nicht jede Session dein Layout neu entdecken muss.

Deine Präferenzen: Wie du kommunizierst, deine Workflow-Gewohnheiten, deine Tool-Wahl. Claude bemerkt die Muster, auf die du setzt.

MEMORY.md funktioniert als kurzer Index. Wenn Notizen sich stapeln, verschiebt Claude die Details in Themen-Dateien wie debugging.md oder patterns.md. Das hält die Haupt-Datei unter 200 Zeilen, da nur die ersten 200 Zeilen beim Start laden.

Wie du es nutzt

Einfach laufen lassen

Der einfachste Weg: lass es in Ruhe. Auto Memory ist standardmäßig an. Claude liest und schreibt Memory-Dateien im Hintergrund, während du arbeitest. Du merkst es während Sessions, wenn Claude Dateien im Memory-Ordner berührt.

Etwas Bestimmtes speichern

Sag Claude direkt, was es speichern soll:

"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 lässt diese sofort in die richtige Memory-Datei fallen.

Durchsuchen und Bearbeiten

Während jeder Session führst du /memory aus, um den Memory-Datei-Auswähler zu öffnen. Das listet jede Memory-Datei (CLAUDE.md, Auto Memory, lokale Config) und lässt dich jede in deinem System-Editor öffnen.

Du kannst sie auch von der Shell lesen:

# 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

Das sind einfache Markdown-Dateien. Bearbeite sie wann du willst. Lösche Einträge, die veraltet sind. Reorganisiere, wenn das Projekt wächst.

Konfiguration und Kontrolle

Auto Memory läuft standardmäßig an. Hier ist jeder Regler, den du drehen kannst:

Pro-Session-Toggle

Führe /memory aus und klappe den Auto-Memory-Toggle um. Schnellster Weg, es für deinen aktuellen Workflow an oder aus zu schalten.

Für jedes Projekt killen

Leg das in deine User-Settings:

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

Für ein Projekt killen

Leg das in die Projekt-Settings:

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

Environment-Variable-Override

CLAUDE_CODE_DISABLE_AUTO_MEMORY schlägt jede andere Einstellung. Das ist die richtige Wahl für CI-Pipelines, Automation und verwaltete Deployments:

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

Das überstimmt sowohl den /memory Toggle als auch settings.json, also funktioniert es als harter Kill-Switch.

Wann du was nutzen solltest

Drei Memory-Systeme, ein Entscheidungs-Framework:

Nutze CLAUDE.md wenn du harte Regeln willst. Coding-Standards, Architektur-Calls, benötigte Befehle, Team-Konventionen. CLAUDE.md lädt komplett beim Start und sitzt auf hoher Priorität. Wenn du willst, dass ein Muster jedes Mal befolgt wird, kommt es hierhin.

Nutze Auto Memory wenn du willst, dass Claude Dinge aufgreift, wie es läuft. Muster, die während echter Arbeit auftauchen, Debug-Fixes, stille Präferenzen. Du musst nicht alles im Voraus planen.

Nutze Session Memory wenn du Konversations-Kontinuität brauchst. Session Memory hält den Faden dessen, was du in jeder Session besprochen und entschieden hast. Es ist die "Was haben wir gestern gemacht"-Schicht.

Nutze das Rules-Directory wenn deine CLAUDE.md aus einer Datei herausgewachsen ist. Teile deine Anweisungen in fokussierte Dateien unter .claude/rules/ für sauberere Struktur ohne Prioritäts-Verlust.

Die Überlappung ist Absicht. Auto Memory greift die Dinge auf, die du vergessen hast, in CLAUDE.md zu packen. Session Memory trägt den Kontext, den Projekt-Level-Notizen nicht können. Staple sie und du bekommst geschichtetes Memory, das Regeln, Projekt-Wissen und Konversations-Historie abdeckt.

Best Practices

Halte MEMORY.md unter 200 Zeilen. Nur die ersten 200 Zeilen laden beim Start. Claude ist angewiesen, prägnant zu bleiben, indem es Details in Themen-Dateien schiebt. Wenn du von Hand bearbeitest, respektiere dieselbe Grenze.

Schau deine Memory-Dateien ab und zu durch. Wie alle Notizen, sie veralten. Nach einem großen Refactor oder Architektur-Shift, überflieg die Dateien und lösche, was nicht mehr stimmt.

Dupliziere nicht zwischen CLAUDE.md und Auto Memory. Wenn etwas eine Regel sein muss, pack es in CLAUDE.md. Wenn es ein Muster ist, das sich verschieben könnte, lass Auto Memory es tragen.

Speichere das Kritische explizit. Wenn du einen fiesen Bug knackst oder einen großen Architektur-Call festlegst, sag Claude, es soll sich daran erinnern. Wette nicht darauf, dass Claude alles allein erwischt.

Schalte Auto Memory in CI aus. Automation braucht nicht, dass Claude Notizen über deine Build-Box stapelt. Setze CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 in deiner CI-Config.

Paar es mit Context-Engineering. Auto Memory ist eine Schicht einer größeren Context-Engineering-Strategie. Je mehr Sorgfalt du in das steckst, was Claude beim Start weiß, desto mehr gibt jede Session zurück.

Nächste Schritte

• Richte dein CLAUDE.md Memory-System für persistente Projekt-Anweisungen ein
• Verstehe Session Memory für Cross-Session-Konversations-Kontinuität
• Lerne Context-Management-Strategien, um innerhalb von Token-Limits zu arbeiten
• Erkunde das Rules-Directory für modulare Projekt-Anweisungen
• Lies über Context-Engineering für Produktions-AI-Memory-Systeme

Auto Memory schließt die Lücke zwischen dem, was du Claude sagst, und dem, was Claude selbst herausfindet. CLAUDE.md besitzt die "Mach es so"-Regeln. Auto Memory besitzt das "Ich hab das über dein Projekt bemerkt"-Wissen. Führe sie zusammen und du erklärst dich weniger und shippst mehr.