Claude Code jenseits von CLAUDE.md: Memory, Hooks, MCP und Worktrees

CLAUDE.md ist der Einstieg. Wer damit arbeitet – etwa wie in CLAUDE.md im Alltag beschrieben –, hat verstanden, wie man Claude Code Projektregeln gibt: Tech-Stack, Naming Conventions, Guardrails. Aber Claude Code hat in den letzten Monaten Features bekommen, die weit darüber hinausgehen: persistentes Gedächtnis, automatisierte Hooks, isolierte Worktrees und externe Tool-Anbindung über MCP. Die meisten davon laufen im Hintergrund und werden kaum dokumentiert.

Dieser Artikel zeigt, was diese Features tun, wie sie zusammenspielen und wo sie den Workflow konkret verändern.

Auto Memory: Claude schreibt sich selbst Notizen

Das Problem

Jede Claude-Code-Session beginnt mit einem leeren Context Window. CLAUDE.md liefert die Grundregeln, aber alles, was Claude während der Arbeit lernt – welche Build-Befehle funktionieren, welche Patterns im Projekt gelten, welche Debugging-Erkenntnisse wichtig sind – geht beim Schließen der Session verloren. In der nächsten Session wiederholt sich das Einlernen.

Wie Auto Memory funktioniert

Auto Memory löst das, indem Claude sich selbst Notizen schreibt. Nicht nach jeder Session, sondern wenn Claude entscheidet, dass eine Erkenntnis in zukünftigen Sessions nützlich wäre.

Die Notizen landen in einem Verzeichnis unter ~/.claude/projects/<projekt>/memory/:

MEMORY.md ist der Einstiegspunkt. Die ersten 200 Zeilen werden bei jeder Session automatisch in den Kontext geladen. Detaillierte Notizen lagert Claude in separate Themen-Dateien aus, die bei Bedarf gelesen werden.

Was gespeichert wird

Typische Einträge in Auto Memory:

• Build-Befehle: „pnpm build schlägt fehl, wenn Env-Variablen fehlen – erst cp .env.example .env ausführen”
• Debugging-Erkenntnisse: „Hot Reload greift nicht bei Config-Änderungen – Dev-Server muss neu gestartet werden”
• Architektur-Entscheidungen: „Dark Surface Color ist slate-800, nicht gray-900”
• Stilregeln: „Überschriften ohne Doppelpunkt, Fließtext statt Stichpunkte in Einleitungen”
• Workflow-Präferenzen: „Feature-Branches immer mit Prefix feat/, Bugfixes mit fix/”

CLAUDE.md vs. Auto Memory

Die beiden Systeme ergänzen sich – ähnlich wie bei sessionübergreifenden KI-Regeln allgemein: CLAUDE.md sagt Claude, wie es arbeiten soll. Auto Memory merkt sich, was es dabei gelernt hat.

In der Praxis

Du kannst Claude jederzeit bitten, etwas zu merken: „Merke dir, dass wir immer bun statt npm verwenden.” Claude schreibt das in die Memory-Dateien. Umgekehrt kannst du mit /memory sehen, was Claude sich gemerkt hat, Dateien öffnen und bearbeiten. Alles ist plain Markdown.

Wo Auto Memory den Unterschied macht

Der eigentliche Wert zeigt sich erst nach einigen Wochen. In den ersten Sessions speichert Claude vor allem Offensichtliches – Build-Befehle, Dateipfade, Tool-Versionen. Das ist nützlich, aber nicht transformativ. Interessant wird es, wenn sich projektspezifische Muster ansammeln: Welche Abhängigkeiten brechen regelmäßig, welche Konventionen werden immer wieder vergessen, welche Workarounds haben sich bewährt.

In Projekten mit wiederkehrenden Aufgaben – Blog-Systeme, Monorepos, Deployment-Pipelines – spart das spürbar Zeit. Claude wiederholt nicht mehr dieselben Fehler und fragt nicht mehr nach Dingen, die es letzte Woche schon gelernt hat. Statt jede Session bei null anzufangen, baut sie auf dem auf, was vorher funktioniert hat.

Wo es an Grenzen stößt

Auto Memory ist kein Selbstläufer. Einige Punkte, die im Alltag auffallen:

Veraltete Einträge. Claude aktualisiert Memory-Dateien nicht automatisch, wenn sich das Projekt ändert. Ein gespeicherter Build-Befehl, der vor drei Wochen funktioniert hat, kann nach einem Tooling-Wechsel falsch sein. Wer Memory nutzt, sollte gelegentlich die Dateien durchsehen und Überholtes löschen.

Falsche Schlüsse. Claude speichert manchmal Beobachtungen als Regeln, die nur in einem bestimmten Kontext galten. Ein Debugging-Workaround, der für einen spezifischen Bug funktioniert hat, wird als generelle Lösung abgelegt. Das merkt man erst, wenn Claude den Workaround an der falschen Stelle anwendet.

Context-Window-Kosten. Die ersten 200 Zeilen von MEMORY.md werden bei jeder Session geladen – ob relevant oder nicht. Ein aufgeblähtes Memory-File frisst Context, der für die eigentliche Aufgabe fehlt. Kurze, präzise Einträge sind besser als ausführliche Notizen.

Kein Ersatz für CLAUDE.md. Memory eignet sich für Erkenntnisse, die Claude bei der Arbeit entdeckt. Architekturentscheidungen, Coding-Standards oder Team-Konventionen gehören weiterhin in CLAUDE.md – dort sind sie versioniert, reviewbar und für alle sichtbar.

Kein projektübergreifendes Wissen. Memory lebt unter ~/.claude/projects/<projekt>/memory/ – strikt pro Repository. Was Claude in Projekt A über Tailwind v4 lernt, weiß es in Projekt B nicht. Dabei gibt es durchaus eine User-Level-Ebene: ~/.claude/CLAUDE.md gilt für alle Projekte, und ~/.claude/settings.json definiert globale Hooks und MCP-Server. Aber Auto Memory hat kein Pendant dazu. Wer projektübergreifende Erkenntnisse teilen will, muss sie manuell in die globale CLAUDE.md übertragen – oder mit einem SessionStart-Hook nachhelfen, der gemeinsame Notizen einliest.

Compacting: Wenn der Kontext voll wird

Das Problem

Claude Code arbeitet mit einem begrenzten Context Window. Je länger eine Session läuft – mehr Dateien gelesen, mehr Code geschrieben, mehr Tool-Aufrufe –, desto voller wird der Kontext. Irgendwann ist die Grenze erreicht, und Claude kann keine neuen Informationen mehr aufnehmen.

Wie Compacting funktioniert

Compacting löst das automatisch. Wenn der Input eine Schwelle überschreitet – typischerweise bei 50.000 bis 150.000 Tokens, je nach Konfiguration –, fasst Claude ältere Nachrichten zu einer komprimierten Zusammenfassung zusammen. Die Zusammenfassung ersetzt die ursprünglichen Nachrichten, und die Session läuft mit freiem Kontext weiter.

Das passiert im Hintergrund. Du siehst eine kurze Meldung „Compacting completed”, und die Arbeit geht nahtlos weiter. Claude behält die wesentlichen Informationen – welche Dateien geändert wurden, welche Entscheidungen getroffen wurden, was der aktuelle Stand ist – und verwirft Details, die für den weiteren Verlauf nicht mehr relevant sind.

Was dabei verloren geht

Compacting ist eine Komprimierung, kein perfektes Gedächtnis. Einige Dinge gehen dabei verloren:

Exakte Formulierungen. Claude erinnert sich an die Essenz einer Anweisung, nicht an den genauen Wortlaut. Wenn du in Minute 5 gesagt hast „verwende immer const statt let”, steht das nach dem Compacting als zusammengefasste Regel in der Zusammenfassung – oder gar nicht, wenn Claude es als nicht wesentlich einstuft.

Verworfene Ansätze. Wenn du drei verschiedene Lösungen diskutiert und dich für eine entschieden hast, verschwinden die verworfenen Alternativen aus dem Kontext. Das ist meistens richtig, kann aber ein Problem sein, wenn du später darauf zurückkommen willst.

Nuancen in der Diskussion. „Mach es so, aber nur wenn X zutrifft” wird möglicherweise zu „Mach es so” komprimiert. Bedingungen und Einschränkungen sind die ersten Opfer der Zusammenfassung.

Compacting und Auto Memory

Die beiden Features ergänzen sich direkt: Auto Memory rettet Erkenntnisse vor dem Compacting. Was Claude in MEMORY.md schreibt, überlebt jede Komprimierung, weil es als Datei existiert, nicht als Konversationsverlauf. Deshalb speichert Claude wichtige Erkenntnisse idealerweise in Memory, bevor sie durch Compacting verloren gehen.

Der PreCompact-Hook (siehe nächster Abschnitt) ermöglicht es, vor jeder Komprimierung automatisch Aktionen auszuführen – etwa wichtige Kontextinformationen in eine Datei zu schreiben oder den aktuellen Stand zu dokumentieren.

Hooks: Automatisierung an jeder Stelle

Was Hooks sind

Hooks sind Shell-Befehle, HTTP-Endpoints oder LLM-Prompts, die automatisch an definierten Punkten im Claude-Code-Lifecycle ausgeführt werden. Sie laufen, bevor oder nachdem Claude ein Tool nutzt, wenn eine Session startet oder endet, oder wenn bestimmte Events eintreten.

Die Konfiguration liegt in .claude/settings.json oder .claude/settings.local.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $FILEPATH"
          }
        ]
      }
    ]
  }
}

Dieses Beispiel formatiert jede Datei automatisch nach dem Schreiben oder Editieren.

Verfügbare Events

Praktische Einsätze

Destruktive Befehle blockieren: Ein PreToolUse-Hook auf Bash, der rm -rf erkennt und mit Exit-Code 2 blockiert. Claude sieht die Fehlermeldung und wählt einen anderen Weg.

Auto-Lint nach jeder Änderung: Ein PostToolUse-Hook auf Write und Edit, der ESLint oder Prettier ausführt. Jede Datei, die Claude anfasst, ist automatisch formatiert – ohne dass du es in den Prompt schreiben musst.

Commit-Validierung: Ein PreToolUse-Hook auf Bash mit Matcher für git commit, der prüft, ob Tests grün sind, bevor der Commit durchgeht.

Logging: Ein PostToolUse-Hook, der jeden Tool-Call mit Zeitstempel und Parametern in eine Log-Datei schreibt – nützlich für Audits oder Debugging.

Worktrees: Isolierte Arbeitskopien

Das Problem

Wenn Claude an einer Aufgabe arbeitet, verändert es Dateien in deinem Arbeitsverzeichnis. Parallele Aufgaben oder explorative Änderungen können dabei mit deiner aktuellen Arbeit kollidieren.

Wie Worktrees funktionieren

Git Worktrees sind separate Arbeitskopien desselben Repositories mit eigenem Branch. Claude Code nutzt dieses Git-Feature, um isolierte Umgebungen zu schaffen.

Du startest eine Session mit claude --worktree (oder -w), und Claude erstellt eine separate Arbeitskopie in .claude/worktrees/ mit einem neuen Branch basierend auf HEAD. Alle Änderungen passieren dort, nicht in deinem Hauptverzeichnis.

Beim Beenden der Session wirst du gefragt, ob du die Worktree behalten oder entfernen willst. Wenn Claude keine Änderungen gemacht hat, wird sie automatisch aufgeräumt.

Subagents mit Worktree-Isolation

Besonders nützlich wird das bei Subagents. In der Subagent-Definition setzt du isolation: "worktree", und der Subagent bekommt automatisch seine eigene Arbeitskopie:

---
name: experimental-refactor
description: Tries risky refactoring in isolation
isolation: worktree
tools: Read, Edit, Write, Bash
---

Du bist ein Refactoring-Spezialist. Arbeite in deiner isolierten
Worktree und probiere den Umbau aus. Wenn es funktioniert, werden
die Änderungen übernommen.

Das ermöglicht paralleles Arbeiten: Mehrere Subagents können gleichzeitig an verschiedenen Aufgaben arbeiten, ohne sich gegenseitig in die Quere zu kommen. Jeder arbeitet auf seinem eigenen Branch.

Wann Worktrees sinnvoll sind

• Explorative Änderungen: „Probier mal aus, ob wir die Auth-Middleware umbauen können” – ohne Risiko für den aktuellen Stand
• Parallele Subagents: Drei Agents recherchieren gleichzeitig in verschiedenen Modulen und machen dabei Änderungen
• Feature-Prototypen: Schnell etwas ausprobieren, ohne den Hauptbranch zu verschmutzen

MCP: Externe Tools anbinden

Was MCP ist

Model Context Protocol (MCP) ist ein offener Standard, über den Claude Code mit externen Tools kommuniziert – wie Code Execution mit MCP zeigt, kann das auch die Kosten drastisch senken. Statt alles über Bash-Befehle oder eingebaute Tools zu machen, kann Claude über MCP-Server auf spezialisierte Dienste zugreifen – Datenbanken, APIs, Design-Tools, Projektmanagement.

Konfiguration

MCP-Server werden in .claude/settings.json konfiguriert:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "..."
      }
    }
  }
}

Nach der Konfiguration stehen die Tools des MCP-Servers Claude automatisch zur Verfügung. Claude erkennt anhand der Tool-Beschreibungen, wann welches Tool relevant ist, und nutzt es selbstständig.

Praxisbeispiele

GitHub: Issues lesen, PRs erstellen, Reviews abrufen – ohne die Bash zu bemühen. Claude nutzt die GitHub-API direkt über den MCP-Server.

Datenbanken: Ein MCP-Server für PostgreSQL oder SQLite ermöglicht Datenbankabfragen direkt im Kontext. Claude kann Schema inspizieren, Queries schreiben und Ergebnisse analysieren.

Design-Tools: In diesem Projekt nutzen wir einen MCP-Server für .pen-Dateien (Pencil), der Claude direkten Zugriff auf Design-Dokumente gibt – Nodes lesen, Layouts prüfen, Designs erstellen.

Slack, Notion, Linear: MCP-Server für Projektmanagement-Tools ermöglichen es Claude, Tickets zu lesen, Statusupdates zu schreiben oder Dokumentation abzurufen – alles im Kontext der aktuellen Entwicklungsarbeit.

MCP für Subagents

Subagents können eigene MCP-Server mitbringen. Ein Datenbank-Analyst-Subagent bekommt den PostgreSQL-MCP-Server, ein Design-Review-Subagent den Figma-Server. Jeder Agent hat Zugriff auf genau die externen Tools, die er braucht.

User-Level: Was projektübergreifend gilt

Neben der Projekt-Konfiguration in CLAUDE.md und .claude/settings.json gibt es eine Ebene darüber, die oft übersehen wird: die User-Level-Konfiguration im Home-Verzeichnis.

~/.claude/CLAUDE.md

Diese Datei funktioniert wie die Projekt-CLAUDE.md, gilt aber für alle Projekte. Was hier steht, wird in jeder Session geladen – egal, in welchem Repository du arbeitest.

Typische Inhalte:

• Persönliche Präferenzen: „Verwende immer TypeScript strict mode”, „Bevorzuge funktionale Patterns gegenüber Klassen”
• Tool-Vorlieben: „Nutze bun statt npm”, „Formatiere mit Biome statt Prettier”
• Kommunikationsstil: „Antworte auf Deutsch”, „Keine Emojis in Code-Kommentaren”
• Allgemeine Coding-Standards: Naming Conventions, Error-Handling-Patterns, Test-Strategien

Der Unterschied zur Projekt-CLAUDE.md: Hier geht es um dich als Entwickler, nicht um das Projekt. Was in der User-Level-Datei steht, ist nicht versioniert und nicht für das Team sichtbar.

~/.claude/settings.json

Die globale Settings-Datei definiert Hooks, MCP-Server und Permissions, die in jedem Projekt gelten:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $FILEPATH"
          }
        ]
      }
    ]
  },
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Ein Prettier-Hook, der hier definiert ist, formatiert in jedem Projekt. Ein GitHub-MCP-Server steht überall zur Verfügung. Das spart Konfiguration, hat aber einen Haken: Projektspezifische Settings in .claude/settings.json überschreiben die globalen nicht – sie werden zusammengeführt. Bei Konflikten zwischen globalem und lokalem Hook gewinnt der spezifischere.

Was fehlt

Die User-Level-Ebene deckt Instruktionen (CLAUDE.md) und Konfiguration (settings.json) ab. Was fehlt, ist ein User-Level-Pendant zu Auto Memory. Erkenntnisse, die Claude in einem Projekt gewinnt und die projektübergreifend nützlich wären – etwa „Tailwind v4 braucht @import statt @tailwind” – bleiben im jeweiligen Projekt-Memory eingesperrt. Wer solches Wissen teilen will, muss es manuell in die globale ~/.claude/CLAUDE.md übertragen.

Wie die Schichten zusammenspielen

Claude Code hat inzwischen mehrere Schichten, die zusammen ein konfigurierbares System ergeben:

Ganz oben steht die User-Level-Konfiguration: ~/.claude/CLAUDE.md enthält Instruktionen, die für alle Projekte gelten – persönliche Coding-Präferenzen, bevorzugte Tools, Konventionen, die projektunabhängig sind. ~/.claude/settings.json definiert globale Hooks, MCP-Server und Permissions. Was hier konfiguriert ist, greift überall, ohne dass du es pro Projekt wiederholen musst.

Darunter folgt die Projektebene: CLAUDE.md definiert die Team-Regeln und wird ins Repository eingecheckt. CLAUDE.local.md erlaubt persönliche Abweichungen, die nicht ins Git gehören. Rules in .claude/rules/ machen Instruktionen modular und pfadspezifisch – eine Regel für *.test.ts-Dateien, eine andere für src/api/**. Skills sind Workflows, die nur bei Bedarf geladen werden und kein Context Window verschwenden.

Auto Memory baut über die Zeit ein Wissensarchiv auf, das Claude bei der Arbeit entdeckt hat – allerdings nur pro Projekt, nicht auf User-Level. Compacting sorgt dafür, dass lange Sessions nicht am Context Window scheitern, indem ältere Nachrichten automatisch komprimiert werden. Hooks erzwingen Verhalten, das über Instruktionen nicht zuverlässig steuerbar ist. MCP-Server erweitern die Fähigkeiten um externe Tools. Worktrees schaffen isolierte Umgebungen für parallele und explorative Arbeit.

Was davon den Alltag verändert

Nicht alles davon ist für jeden relevant. Die Reihenfolge, in der sich die Features lohnen:

Sofort nützlich: Auto Memory. Einmal aktivieren, vergessen. Claude wird über Wochen besser, ohne dass du etwas tust.

Nützlich ab dem ersten Projekt: Hooks. Ein PostToolUse-Hook für Prettier oder ESLint spart pro Tag dutzende manuelle Formatierungen. Ein PreToolUse-Hook gegen destruktive Befehle gibt Sicherheit.

Nützlich für komplexe Projekte: MCP-Server. Sobald du regelmäßig zwischen Code, Datenbank und externen APIs wechselst, spart die direkte Integration Zeit und Kontextwechsel.

Nützlich für Teams und parallele Arbeit: Worktrees. Wenn du Subagents parallel arbeiten lässt oder explorative Änderungen isolieren willst, sind Worktrees die sauberste Lösung.

Die Features bauen aufeinander auf, aber keines setzt ein anderes voraus. Du kannst mit Auto Memory anfangen und den Rest bei Bedarf dazunehmen. Das Gute: Alles ist plain Config in JSON und Markdown. Kein Lock-in, kein proprietäres Format, alles versionierbar.