Claude Code kann sich Dinge merken. Korrekturen, Konventionen, Projekt-Kontext landen dann in Memory-Files unter ~/.claude/projects/<projektpfad>/memory/. Das ist gut. Das Problem: dieses Wissen lebt in einer Datei in deinem App-Home-Verzeichnis. Wenn dein Mac stirbt, ist es weg. Wenn eine falsche Generalisierung dort landet, bleibt sie für immer. Und du kannst Tage später nicht mehr rekonstruieren, was die KI da eigentlich aufgenommen hat.
Ich habe das eine Weile so hingenommen. Bis ich gemerkt habe: Memory ist nicht Cache. Memory ist Wissen.
Wie das eigentlich angefangen hat
Mein Configs-Repo gibt es seit dem 22. Juli 2025. Ich war einer der frühen Nutzer von Claude Code, und plötzlich war ich konfrontiert mit sehr vielen neuen Setup-Dateien, die jede Woche dazukamen. Parallel bekam auch Claude Desktop laufend neue Möglichkeiten, oft über versteckte Systemdateien, die niemand wirklich auf dem Schirm hatte.
Was mich schnell gestört hat: ich saß abends vor einer Config und konnte nicht mehr rekonstruieren, warum sie so aussah, wie sie aussah. Vor allem dann nicht, wenn die KI sie selbst umgeschrieben hatte. Das war der eigentliche Auslöser. Eine KI, die ihre eigene Konfiguration editiert, ohne dass ich nachvollziehen kann, was sie geändert hat, fühlt sich auf Dauer nicht gut an.
Also habe ich angefangen, die wichtigen Dateien in ein privates Git-Repo zu legen. Erst nur ein paar Settings, dann VS Code, dann Claude-Code-spezifische Sachen. Über die Monate ist daraus ein ziemlich vollständiges Setup-Snapshot meines Rechners geworden.

Als Claude Code Memory eingeführt hat, war für mich klar: das gehört da auch rein. Die Frage, die mich umgetrieben hat, war: was, wenn die KI versehentlich etwas falsch dokumentiert oder einen Eintrag löscht, der eigentlich noch gebraucht wird? Ich wollte, dass das jederzeit rekonstruierbar ist. Memory ist seit dem 20. April 2026 im Repo. Vier Befehle, ein Symlink zurück. Claude liest und schreibt weiter am gleichen Pfad. Git protokolliert den Rest.
Was sich verändert hat
Ich bin nicht für die vier Effekte unten gestartet. Ich bin für ein Backup gestartet. Den Rest habe ich erst nach und nach bemerkt.
Der Audit-Trail über git log ist der Effekt, den ich am häufigsten nutze. Wenn die KI eine Config in meinem Auftrag umgeschrieben hat — Claude editiert nichts auf eigene Faust, aber sehr wohl, wenn du es bittest oder einen Workflow eingerichtet hast, der das persistiert — sehe ich genau, was sich geändert hat. Das ersetzt eine Menge Detektivarbeit, wenn die KI sich plötzlich anders verhält.

Rollback bei falschen Generalisierungen war anfangs Theorie. Bis es zum ersten Mal nötig war. Ein Memory-Eintrag, der eine zu breite Lehre aus einem Einzelfall gemacht hatte, war mit git checkout in zehn Sekunden weg. Ohne Versionierung hätte ich rätseln müssen, was genau ich da rausschneide.
Backup-Resilienz brauche ich, weil ~/.claude/ ein App-Home ist. Ein Beta-Update, das den Ordner zurücksetzt, ein versehentliches rm, ein Disk-Crash: alles plausible Wege, Monate an Setup zu verlieren. Mit dem Repo als Wahrheitsquelle ist die Wiederherstellung trivial. Plus: ich habe das Repo auf einem privaten Remote, also auch eine geschützte Kopie außerhalb meines Rechners. Im Notfall habe ich eine Sicherung von meinem Claude-Setup inklusive allem Wichtigen drum herum, und kann mit meiner Arbeit relativ unproblematisch wieder loslegen.
Der vierte Effekt ist der, den ich am wenigsten erwartet habe. Dadurch dass die KI selbst Lese-Zugriff auf das Repo hat, kann sie ihren eigenen Verlauf nachschlagen. Wenn etwas kaputtgeht oder ich eine alte Entscheidung verstehen will, ist die KI mein Fix-Buddy. Sie lebt mit dem Rechner mit, sie sieht, was sich verändert hat, sie kann mitdebuggen statt blind zu raten. Das ist ein Hebel, den ich anfangs nicht im Blick hatte und der heute fast der wichtigste ist.
Die eigentliche Einsicht
Der Trick ist nicht der Symlink. Der Trick ist die Umetikettierung.
Die meisten behandeln ~/.claude/ wie App-State. Browser, IDEs, Package-Manager haben ähnliche Verzeichnisse, und der Reflex sagt: lass die in Ruhe, das ist Cache, das wird regeneriert. Bei Browser-Cache stimmt das. Bei einer KI, die ihre eigene Konfiguration und ihre eigenen Lehren in diesen Dateien ablegt — auf deinen Wunsch, aber trotzdem materiell — stimmt es nicht. Diese Dateien dokumentieren Verhalten und Intentionen, sie regenerieren sich nicht von allein, und sie sind so wichtig wie der Code daneben. Sobald du sie als Code begreifst, gelten alle Standard-Argumente für Versionierung.
Was du wissen solltest, wenn du das nachbauen willst
Das Repo bleibt privat. Was genau du darin schützt, ist deine Entscheidung. Ich schreibe das hier nicht als Checkliste auf.
Die zweite Sache ist Erwartungshaltung. Das ist kein vollständiges System-Backup. Wenn dein Mac stirbt, hast du dein Claude-Setup zurück, aber nicht den Rest deines Rechners. Und Configs, die maschinen-spezifische Pfade enthalten, brauchen bei einem Umzug ohnehin manuelle Hand. Der Repo ist für mich eine Wissensquelle und ein Sicherheitsnetz, kein Ersatz für ein richtiges System-Backup.
Was ich daraus mitgenommen habe
Der wahre Wert hat sich erst mit dem Wachstum des Repos gezeigt. Anfangs war es ein Backup. Heute ist es eine Wissensdatenbank über mein Setup, die sowohl ich als auch die KI nutzen können. Das war keine bewusste Entscheidung, das ist passiert.
Manche Workflow-Pattern offenbaren ihren Wert erst, wenn man sie eine Weile gelebt hat. Diese hier war so eine.