Der saubere Startpunkt ist weg: Claude Codes Gedächtnis und das Problem autonomer Workflows

Der alte Vertrag war einfach: Jede LLM-Session startet bei null.

Du gibst einen System-Prompt. Du gibst Anweisungen. Du gibst Kontext. Das ist die Eingabe. Aus dieser Eingabe, begrenzt durch die inhärente Zufälligkeit des Modells, kommt eine Ausgabe. Denselben Prompt hundert Mal ausführen — du bekommst ungefähr dasselbe Ergebnis. Nicht identisch (LLMs sind probabilistisch), aber konsistent genug, um Systeme darauf aufzubauen. Die fünf Prozent unerwarteten Outputs bleiben in der jeweiligen Session und sterben mit ihr.

Das gilt nicht mehr.

Claude Code hat Auto-Memory eingeführt. Es beobachtet deine Sessions. Es speichert Dinge, die es für wichtig hält — Build-Befehle, Debugging-Erkenntnisse, Code-Style-Präferenzen, Muster, die es beobachtet hat. Die nächste Session lädt diese Notizen automatisch. Die übernächste auch. Und die danach.

Für interaktiven Einsatz — ein Entwickler, der mit dem Tool sitzt, Ausgaben liest und selbst urteilt — ist das wahrscheinlich okay. Der Agent wirkt schlauer. Er fragt nicht zweimal dasselbe. Er weiß schon, dass du pnpm statt npm bevorzugst.

Für autonome Workflows ist es ein ganz anderes Problem.

Was Auto-Memory wirklich macht

Claude Code speichert Memory-Dateien in ~/.claude/projects/<project>/memory/. Es gibt eine MEMORY.md-Einstiegsdatei — ein kompakter Index — und optionale Themendateien wie debugging.md oder api-conventions.md. Die ersten 200 Zeilen von MEMORY.md werden am Anfang jeder Unterhaltung geladen.

Zweihundert Zeilen, die du nicht geschrieben hast, sind jetzt Teil deines effektiven System-Prompts.

Claude entscheidet, was dort reinkommt. Nicht du. Wenn es auf etwas stößt, das es für erhaltenswert hält — eine Korrektur, die du gegeben hast, eine Präferenz, die es beobachtet hat, ein Architekturmuster, das es abgeleitet hat — schreibt es eine Notiz für sich selbst. Vielleicht siehst du „Writing memory” im Interface. Vielleicht schaust du gerade nicht hin. In einer automatisierten Pipeline schaust du garantiert nicht hin.

Auto-Memory ist standardmäßig aktiviert. Du kannst es per Projekt mit autoMemoryEnabled: false in den Projekteinstellungen deaktivieren, oder global mit CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. Aber Opt-out setzt voraus, dass du weißt, dass du opt-outen musst.

Das versehentliche Injektionsproblem

Hier ist das Szenario, das mich beschäftigt.

Du nutzt Claude Code interaktiv. Du debuggst etwas Frustrierendes. Du sagst, halb genervt: „Überspring die Integrationstests erstmal, die sind zu langsam.” Das Problem ist gelöst. Gut.

Das war eine Debugging-Abkürzung. Keine Policy. Nichts, das du dauerhaft gespeichert haben wolltest.

Aber Claude fand das nützlich. Es hat sich notiert: User möchte Integrationstests wegen Geschwindigkeit überspringen. Jetzt startet jede Session, jede Aufgabe, jeder automatisierte Lauf mit diesem Kontext fest eingebettet. Du weißt es nicht. Die Tests laufen weiterhin nicht. Du fragst dich, warum deine Pipeline auf einmal schneller ist.

Das ist nicht hypothetisch. Das ist, was passiert, wenn ein System auf Hilfsbereitschaft statt auf Vorhersagbarkeit optimiert. Der Agent versucht wirklich, dir besser zu dienen. Er dient nur einer Version von dir, die nicht mehr deiner aktuellen Absicht entspricht.

Mit dem alten System hat /reset bedeutet: ich starte bei null. Das stimmt nicht mehr. Reset löscht die Unterhaltung — die Memory-Dateien bleiben unberührt.

Die Falle autonomer Workflows

Das Problem potenziert sich, wenn du von interaktivem Einsatz zu autonomem Betrieb übergehst.

Stell dir vor, du hast einen Claude-Code-Workflow, der automatisch läuft. Nächtliche Pipeline. CI-Trigger. Geplante Aufgabe. Derselbe Prompt, dieselben Anweisungen, hundert Mal über Wochen.

Läufe eins bis fünfzig funktionieren genau wie erwartet. Lauf einundfünfzig verhält sich anders. Nicht katastrophal. Subtil. Er trifft in einer unklaren Situation eine andere Entscheidung. Er lässt einen Schritt aus, den er bisher zuverlässig ausgeführt hat. Er fügt etwas hinzu, das vorher nicht da war.

Warum? Weil irgendwo zwischen Lauf 47 und 50 etwas in einer interaktiven Session passiert ist. Jemand hat dem Agenten eine Korrektur gegeben. Claude hat entschieden, dass diese Korrektur es wert ist, behalten zu werden. Die Memory-Datei wurde aktualisiert. Jetzt startet Lauf 51 aus einem leicht anderen Kontext als Lauf 1.

Derselbe Prompt. Ein anderes Ergebnis. Und der Grund ist unsichtbar, es sei denn, du weißt, dass du ~/.claude/projects/<project>/memory/MEMORY.md prüfen musst.

LLMs waren nie vollständig deterministisch. Das ist okay — die begrenzte Zufälligkeit eines stabilen Ausgangskontexts lässt sich managen. Aber Memory verwandelt diese begrenzte Zufälligkeit in angesammelten Zustand. Der unerwartete Output von Lauf 47 ist nicht mehr eigenständig. Er kann persistieren, sich ausbreiten und eskalieren.

Fünf Prozent unerwartete Outputs über hundert Läufe: handhabbar. Fünf Prozent, die in Memory schreiben und jeden nachfolgenden Lauf beeinflussen können: eine andere Problemklasse.

Warum interaktive Nutzer das nicht bemerken

Wenn du mit dem Tool sitzt, urteilst du laufend mit. Der Agent macht etwas Seltsames? Du merkst es. Du korrigierst es. Diese Korrektur kann zu Memory werden — genau das Problem — aber du weißt zumindest, dass etwas passiert ist.

Im autonomen Modus gibt es diese Korrekturschleife nicht. Kein Mensch beobachtet Lauf 93. Wenn der Agent sich unerwartet verhält, besteht der Output entweder die nachgelagerte Prüfung oder nicht. Niemand fragt: „Hat die Memory-Datei das verursacht?”

Die Lücke in der Nachvollziehbarkeit ist real. In einer interaktiven Session ist unerwartetes Verhalten sichtbar. In einer automatisierten Pipeline sieht unerwartetes Verhalten einfach wie Output aus.

Der Konsistenztest, den du nicht mehr machen kannst

Der fundamentale Sanity-Check für ein LLM-gestütztes System lautet: Nochmal ausführen und schauen, ob du dasselbe Ergebnis bekommst. Nicht identisch — so funktionieren probabilistische Systeme nicht. Aber statistisch ähnliches Verhalten über viele Läufe. Zehn Läufe, zehn ähnliche Outputs — dann hast du ein konsistentes System. Wenn die Verteilung über Zeit driftet, hat sich etwas verändert.

Mit statischem Kontext — System-Prompt, CLAUDE.md-Dateien, explizite Anweisungen — weißt du genau, was sich geändert hat. Du kontrollierst den Ausgangszustand. Wenn das Verhalten driftet, schaust du, was du geändert hast.

Mit Auto-Memory kann sich der Ausgangszustand unter dir verschieben. Zwischen Lauf 50 und 51 hat niemand den System-Prompt bearbeitet. Niemand hat die CLAUDE.md-Dateien angefasst. Aber der effektive Kontext hat sich verschoben, weil Claude in einer Session, die du nicht beobachtet hast, eine Notiz für sich selbst geschrieben hat.

Dein System sieht unverändert aus. Sein Verhalten ist anders. Das Diff liegt in einer Datei, von der du nicht wusstest, dass du sie prüfen musst.

Was du dagegen tun kannst

Das ist kein Argument gegen das Feature. Für interaktive Entwicklung ist persistenter Kontext echter Mehrwert. Ein Agent, der deine Präferenzen lernt, sich deine Debugging-Muster merkt, nicht zweimal dieselbe Frage stellt — das ist wertvoll, wenn du selbst in der Schleife bist.

Das Problem ist dasselbe, das überall im Agentic Engineering auftaucht: Features, die für interaktiven Einsatz entworfen wurden, übertragen sich nicht automatisch auf autonomen Betrieb. Wenn du Systeme baust, die ohne menschliche Aufsicht laufen, wird Vorhersagbarkeit zur wichtigeren Anforderung als Hilfsbereitschaft.

Für autonome Pipelines: Auto-Memory explizit deaktivieren. autoMemoryEnabled: false in die Projekteinstellungen, oder CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 in die Umgebung setzen. Nicht auf den Standard verlassen. Das ist operative Konfiguration, die dein Pipeline-Setup bestimmen sollte — nicht etwas, das du im Nachhinein entdeckst.

Für interaktiven Einsatz mit automatisierten Folgeschritten: MEMORY.md wie eine kritische Konfigurationsdatei behandeln. Regelmäßig prüfen. Wissen, was drin steht, bevor du an Automatisierung übergibst. /memory aufrufen und wirklich lesen, was dort steht — nicht nur um zu bestätigen, dass nichts falsch ist, sondern um zu verstehen, was dein Agent über deine Präferenzen glaubt.

Für gemeinsame Workflows: Wenn mehrere Personen Claude Code im selben Projekt nutzen, tragen alle zum selben Memory-Verzeichnis bei. Die Debugging-Abkürzung eines Entwicklers wird zum persistenten Kontext für alle. Das ist entweder hilfreiche Koordination oder stille Kontamination — je nachdem, ob jemand hinschaut.

Für Konsistenztests: Wenn dein Workflow vorhersagbares Verhalten über viele Läufe braucht, ist die Memory-Datei jetzt Teil deines Test-Setups. Eine saubere Testumgebung bedeutet einen sauberen Memory-Zustand — was heißt, ihn zwischen Testläufen explizit zu verwalten und zurückzusetzen.

Die größere Frage

Memory gehört zu einer Kategorie von KI-Features, die Kontrolle gegen Bequemlichkeit tauschen — auf eine Art, die leicht zu unterschätzen ist.

Die Features selbst sind gut. Das Problem ist nicht die Fähigkeit — es ist die Annahme, die im Default steckt. „Standardmäßig an, User kann opt-outen” ist ein vernünftiges Design für ein Produktivitätstool. Für das Fundament eines autonomen Systems ist es eine Schwachstelle.

Beim sauberen Startpunkt ging es nie darum, alles zu vergessen. Es ging darum, zu wissen, womit du beginnst. Ein System-Prompt ist explizit. CLAUDE.md-Dateien sind explizit. Sogar die unvollkommenen, manuell gepflegten Memory-Dateien, die ich für Cairn gebaut habe, sind explizit — ich weiß, was drin steht, weil ich sie geschrieben habe. (Die Architektur dahinter ist in Three-Tier Memory dokumentiert, und was passiert, wenn man sie unkontrolliert wachsen lässt, steht in The Memory Bloat Crisis.)

Auto-Memory ist implizit. Claude entscheidet, was gespeichert wird. Du entscheidest, ob du es prüfst. Im interaktiven Einsatz ist diese Asymmetrie okay — du merkst, wenn etwas nicht stimmt. Im autonomen Betrieb nicht.

Hol dir den sauberen Startpunkt bewusst zurück. Nicht weil Memory eine schlechte Idee ist. Sondern weil du in agentischen Systemen, die ohne dich laufen, wissen musst, was dein Agent weiß — und im Moment, mit standardmäßig aktiviertem Auto-Memory, weißt du das vielleicht nicht. (Das Gesamtbild, wie autonome Agenten auf unerwartete Arten driften können, behandelt Safe Sandbox for AI Agents — inklusive der harten Grenzen, die weiche Einschränkungen nicht ersetzen können.)