Warum sich Claude-Code so stabil anfühlt: Das Design des lokalen Speichers eines Entwicklers

Claude Code ist in letzter Zeit überall zu finden. Entwickler nutzen ihn, um Funktionen schneller bereitzustellen, Arbeitsabläufe zu automatisieren und Prototypen von Agenten zu entwickeln, die in echten Projekten tatsächlich funktionieren. Noch überraschender ist, wie viele Nicht-Programmierer ebenfalls mitmachen - sie erstellen Tools, verkabeln Aufgaben und erhalten nützliche Ergebnisse, ohne sich großartig einarbeiten zu müssen. Es ist selten, dass sich ein KI-Codierungstool so schnell über so viele verschiedene Qualifikationsstufen hinweg verbreitet.

Was aber wirklich auffällt, ist die Stabilität des Systems. Claude Code merkt sich, was in den verschiedenen Sitzungen passiert ist, überlebt Abstürze, ohne dass der Fortschritt verloren geht, und verhält sich eher wie ein lokales Entwicklungswerkzeug als eine Chat-Schnittstelle. Diese Zuverlässigkeit ergibt sich aus der Art und Weise, wie es die lokale Speicherung handhabt.

Anstatt Ihre Coding-Sitzung wie einen temporären Chat zu behandeln, liest und schreibt Claude Code echte Dateien, speichert den Projektstatus auf der Festplatte und zeichnet jeden Arbeitsschritt des Agenten auf. Sitzungen können fortgesetzt, überprüft oder zurückgesetzt werden, ohne dass man sich Gedanken machen muss, und jedes Projekt bleibt sauber isoliert - so werden die Probleme der gegenseitigen Verunreinigung vermieden, die bei vielen Agententools auftreten.

In diesem Beitrag werfen wir einen genaueren Blick auf die Speicherarchitektur, die hinter dieser Stabilität steht, und warum sie eine so große Rolle dabei spielt, dass sich Claude Code für die tägliche Entwicklung praktisch anfühlt.

Herausforderungen, mit denen jeder lokale KI-Codierassistent konfrontiert ist

Bevor wir erläutern, wie Claude Code an die Speicherung herangeht, wollen wir einen Blick auf die üblichen Probleme werfen, mit denen lokale KI-Codierungswerkzeuge zu kämpfen haben. Diese treten natürlich auf, wenn ein Assistent direkt auf Ihrem Dateisystem arbeitet und den Status über die Zeit behält.

1. Projektdaten werden in verschiedenen Arbeitsbereichen vermischt.

Die meisten Entwickler wechseln im Laufe des Tages zwischen mehreren Repos hin und her. Wenn ein Assistent den Status von einem Projekt zum anderen überträgt, wird es schwieriger, sein Verhalten zu verstehen, und es ist leichter, falsche Annahmen zu treffen. Jedes Projekt braucht einen eigenen, sauberen, isolierten Bereich für Status und Historie.

2. Abstürze können zu Datenverlusten führen.

Während einer Coding-Sitzung produziert ein Assistent einen stetigen Strom nützlicher Daten - Dateibearbeitungen, Tool-Aufrufe, Zwischenschritte. Wenn diese Daten nicht sofort gespeichert werden, können sie bei einem Absturz oder erzwungenen Neustart verloren gehen. Ein zuverlässiges System schreibt wichtige Daten auf die Festplatte, sobald sie erstellt wurden, damit die Arbeit nicht unerwartet verloren geht.

3. Es ist nicht immer klar, was der Agent tatsächlich getan hat.

Eine typische Sitzung umfasst viele kleine Aktionen. Ohne eine klare, geordnete Aufzeichnung dieser Aktionen ist es schwierig, nachzuvollziehen, wie der Assistent zu einem bestimmten Ergebnis gekommen ist, oder den Schritt zu finden, bei dem etwas schief gelaufen ist. Eine vollständige Historie macht die Fehlersuche und -behebung wesentlich einfacher.

4. Das Rückgängigmachen von Fehlern ist zu aufwändig.

Manchmal nimmt der Assistent Änderungen vor, die nicht ganz funktionieren. Wenn Sie keine eingebaute Möglichkeit haben, diese Änderungen rückgängig zu machen, müssen Sie am Ende manuell nach Änderungen im Projektarchiv suchen. Das System sollte automatisch verfolgen, was sich geändert hat, so dass Sie es sauber und ohne zusätzliche Arbeit rückgängig machen können.

5. Verschiedene Projekte brauchen verschiedene Einstellungen.

Lokale Umgebungen variieren. Einige Projekte erfordern spezielle Berechtigungen, Werkzeuge oder Verzeichnisregeln, andere haben eigene Skripte oder Arbeitsabläufe. Ein Assistent muss diese Unterschiede respektieren und projektspezifische Einstellungen zulassen, während sein Kernverhalten konsistent bleibt.

Die Speicherdesignprinzipien von Claude Code

Das Speicherdesign von Claude Code basiert auf vier einfachen Ideen. Sie mögen einfach erscheinen, aber zusammen lösen sie die praktischen Probleme, die auftreten, wenn ein KI-Assistent direkt auf Ihrem Rechner und über mehrere Projekte hinweg arbeitet.

1. Jedes Projekt erhält seinen eigenen Speicher.

Claude Code bindet alle Sitzungsdaten an das Projektverzeichnis, zu dem sie gehören. Das bedeutet, dass Unterhaltungen, Bearbeitungen und Protokolle bei dem Projekt bleiben, aus dem sie stammen, und nicht in andere Projekte gelangen. Durch die getrennte Speicherung ist das Verhalten des Assistenten leichter zu verstehen und es ist einfach, Daten für ein bestimmtes Repo zu prüfen oder zu löschen.

2. Die Daten werden sofort auf der Festplatte gespeichert.

Anstatt Interaktionsdaten im Speicher zu halten, schreibt Claude Code sie auf die Festplatte, sobald sie erstellt wurden. Jedes Ereignis - Nachricht, Werkzeugaufruf oder Statusaktualisierung - wird als neuer Eintrag angehängt. Wenn das Programm abstürzt oder unerwartet geschlossen wird, ist fast alles noch vorhanden. Mit diesem Ansatz bleiben die Sitzungen dauerhaft erhalten, ohne dass die Komplexität zu groß wird.

3. Jede Aktion hat einen eindeutigen Platz in der Historie.

Claude Code verknüpft jede Nachricht und jede Werkzeugaktion mit der vorhergehenden und bildet so eine vollständige Sequenz. Diese geordnete Historie macht es möglich, den Verlauf einer Sitzung zu überprüfen und die Schritte nachzuvollziehen, die zu einem bestimmten Ergebnis geführt haben. Für die Entwickler erleichtert diese Art der Rückverfolgung die Fehlersuche und das Verständnis des Agentenverhaltens erheblich.

4. Code-Änderungen sind leicht rückgängig zu machen.

Bevor der Assistent eine Datei aktualisiert, speichert Claude Code einen Snapshot des vorherigen Zustands. Wenn sich die Änderung als falsch herausstellt, können Sie die frühere Version wiederherstellen, ohne sich durch das Repo zu wühlen oder zu raten, was sich geändert hat. Dieses einfache Sicherheitsnetz macht KI-gesteuerte Bearbeitungen weit weniger riskant.

Lokales Speicherlayout von Claude Code

Claude Code speichert alle lokalen Daten an einem einzigen Ort: Ihrem Home-Verzeichnis. Dadurch bleibt das System vorhersehbar und es ist einfacher, es bei Bedarf zu überprüfen, zu debuggen oder zu bereinigen. Das Speicherlayout ist um zwei Hauptkomponenten herum aufgebaut: eine kleine globale Konfigurationsdatei und ein größeres Datenverzeichnis, in dem der gesamte Projektstatus gespeichert wird.

Zwei Kernkomponenten:

• ~/.claude.jsonSpeichert die globale Konfiguration und Verknüpfungen, einschließlich Projektzuordnungen, MCP-Servereinstellungen und zuletzt verwendete Eingabeaufforderungen.

• ~/.claude/Das Hauptdatenverzeichnis, in dem Claude Code Unterhaltungen, Projektsitzungen, Berechtigungen, Plugins, Fertigkeiten, den Verlauf und zugehörige Laufzeitdaten speichert.

Schauen wir uns nun diese beiden Kernkomponenten genauer an.

(1) Globale Konfiguration: ~/.claude.json

Diese Datei fungiert eher als Index denn als Datenspeicher. Sie zeichnet auf, an welchen Projekten Sie gearbeitet haben, welche Werkzeuge mit den einzelnen Projekten verbunden sind und welche Prompts Sie zuletzt verwendet haben. Die Konversationsdaten selbst werden hier nicht gespeichert.

{
  "projects": {
    "/Users/xxx/my-project": {
      "mcpServers": {
        "jarvis-tasks": {
          "type": "stdio",
          "command": "python",
          "args": ["/path/to/run_mcp.py"]
        }
      }
    }
  },
  "recentPrompts": [
    "Fix the bug in auth module",
    "Add unit tests"
  ]
}

(2) Hauptdatenverzeichnis: ~/.claude/

Das Verzeichnis ~/.claude/ ist der Ort, an dem der größte Teil des lokalen Zustands von Claude Code gespeichert wird. Seine Struktur spiegelt einige zentrale Design-Ideen wider: Projektisolierung, sofortige Persistenz und sichere Wiederherstellung nach Fehlern.

~/.claude/
├── settings.json                    # Global settings (permissions, plugins, cleanup intervals)
├── settings.local.json              # Local settings (machine-specific, not committed to Git)
├── history.jsonl                    # Command history
│
├── projects/                        # 📁 Session data (organized by project, core directory)
│   └── -Users-xxx-project/          # Path-encoded project directory
│       ├── {session-id}.jsonl       # Primary session data (JSONL format)
│       └── agent-{agentId}.jsonl    # Sub-agent session data
│
├── session-env/                     # Session environment variables
│   └── {session-id}/                # Isolated by session ID
│
├── skills/                          # 📁 User-level skills (globally available)
│   └── mac-mail/
│       └── SKILL.md
│
├── plugins/                         # 📁 Plugin management
│   ├── config.json                  # Global plugin configuration
│   ├── installed_plugins.json       # List of installed plugins
│   ├── known_marketplaces.json      # Marketplace source configuration
│   ├── cache/                       # Plugin cache
│   └── marketplaces/
│       └── anthropic-agent-skills/
│           ├── .claude-plugin/
│           │   └── marketplace.json
│           └── skills/
│               ├── pdf/
│               ├── docx/
│               └── frontend-design/
│
├── todos/                           # Task list storage
│   └── {session-id}-*.json          # Session-linked task files
│
├── file-history/                    # File edit history (stored by content hash)
│   └── {content-hash}/              # Hash-named backup directory
│
├── shell-snapshots/                 # Shell state snapshots
├── plans/                           # Plan Mode storage
├── local/                           # Local tools / node_modules
│   └── claude                       # Claude CLI executable
│   └── node_modules/                # Local dependencies
│
├── statsig/                         # Feature flag cache
├── telemetry/                       # Telemetry data
└── debug/                           # Debug logs

Dieses Layout ist absichtlich einfach: Alles, was Claude Code erzeugt, befindet sich in einem Verzeichnis, das nach Projekt und Sitzung geordnet ist. Es gibt keine versteckten Zustände, die in Ihrem System verstreut sind, und es ist einfach, sie zu überprüfen oder zu bereinigen, wenn es nötig ist.

Wie Claude Code die Konfiguration verwaltet

Das Konfigurationssystem von Claude Code basiert auf einer einfachen Idee: Das Standardverhalten soll über alle Maschinen hinweg konsistent bleiben, aber die einzelnen Umgebungen und Projekte sollen dennoch die Möglichkeit haben, das anzupassen, was sie benötigen. Um dies zu erreichen, verwendet Claude Code ein dreischichtiges Konfigurationsmodell. Wenn dieselbe Einstellung an mehreren Stellen vorkommt, gewinnt immer die spezifischere Ebene.

Die drei Konfigurationsebenen

Claude Code lädt die Konfiguration in der folgenden Reihenfolge, von der niedrigsten zur höchsten Priorität:

┌─────────────────────────────────────────┐
│    Project-level configuration          │  Highest priority
│    project/.claude/settings.json        │  Project-specific, overrides other configs
├─────────────────────────────────────────┤
│    Local configuration                  │  Machine-specific, not version-controlled
│    ~/.claude/settings.local.json        │  Overrides global configuration
├─────────────────────────────────────────┤
│    Global configuration                 │  Lowest priority
│    ~/.claude/settings.json              │  Base default configuration
└─────────────────────────────────────────┘

Sie können sich das so vorstellen, dass Sie mit globalen Standardeinstellungen beginnen, dann maschinenspezifische Anpassungen vornehmen und schließlich projektspezifische Regeln anwenden.

Im Folgenden werden wir jede Konfigurationsebene im Detail durchgehen.

(1) Globale Konfiguration: ~/.claude/settings.json

Die globale Konfiguration legt das Standardverhalten für Claude Code in allen Projekten fest. Hier legen Sie die grundlegenden Berechtigungen fest, aktivieren Plugins und konfigurieren das Bereinigungsverhalten.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Read(**)", "Bash(npm:*)"],
    "deny": ["Bash(rm -rf:*)"],
    "ask": ["Edit", "Write"]
  },
  "enabledPlugins": {
    "document-skills@anthropic-agent-skills": true
  },
  "cleanupPeriodDays": 30
}

(2) Lokale Konfiguration: ~/.claude/settings.local.json

Die lokale Konfiguration ist spezifisch für einen einzelnen Rechner. Sie ist nicht dafür gedacht, gemeinsam genutzt oder in die Versionskontrolle eingecheckt zu werden. Daher ist sie ein guter Ort für API-Schlüssel, lokale Tools oder umgebungsspezifische Berechtigungen.

{
  "permissions": {
    "allow": ["Bash(git:*)", "Bash(docker:*)"]
  },
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-xxx"
  }
}

(3) Konfiguration auf Projektebene: project/.claude/settings.json

Die Konfiguration auf Projektebene gilt nur für ein einzelnes Projekt und hat die höchste Priorität. Hier legen Sie Regeln fest, die immer gelten sollen, wenn Sie in diesem Repository arbeiten.

{
  "permissions": {
    "allow": ["Bash(pytest:*)"]
  }
}

Nachdem die Konfigurationsebenen definiert sind, stellt sich nun die Frage , wie Claude Code die Konfiguration und die Berechtigungen zur Laufzeit auflöst.

Claude Code wendet die Konfiguration in drei Ebenen an: Zunächst werden globale Standardeinstellungen verwendet, dann werden maschinenspezifische Überschreibungen angewendet und schließlich werden projektspezifische Regeln angewendet. Wenn die gleiche Einstellung an mehreren Stellen vorkommt, hat die spezifischste Konfiguration Vorrang.

Die Berechtigungen folgen einer festen Bewertungsreihenfolge:

1. verweigern - sperrt immer

2. ask - erfordert eine Bestätigung

3. allow - wird automatisch ausgeführt

4. default - gilt nur, wenn keine Regel passt

Auf diese Weise bleibt das System standardmäßig sicher, während es Projekten und einzelnen Maschinen die nötige Flexibilität bietet.

Sitzungsspeicherung: Wie Claude Code die wichtigsten Interaktionsdaten speichert

In Claude Code sind Sitzungen die zentrale Dateneinheit. Eine Sitzung erfasst die gesamte Interaktion zwischen dem Benutzer und der KI, einschließlich der Konversation selbst, der Werkzeugaufrufe, der Dateiänderungen und des zugehörigen Kontexts. Die Art und Weise, wie Sessions gespeichert werden, hat einen direkten Einfluss auf die Zuverlässigkeit, Fehlersuchbarkeit und allgemeine Sicherheit des Systems.

Sitzungsdaten für jedes Projekt getrennt halten

Sobald die Sitzungen definiert sind, stellt sich die Frage, wie Claude Code sie so speichert, dass die Daten organisiert und isoliert bleiben.

Claude Code isoliert die Sitzungsdaten nach Projekten. Die Sitzungen jedes Projekts werden in einem Verzeichnis gespeichert, das sich aus dem Dateipfad des Projekts ergibt.

Der Speicherpfad folgt diesem Muster:

~/.claude/projects/ + path-encoded project directory

Um einen gültigen Verzeichnisnamen zu erstellen, werden Sonderzeichen wie /, Leerzeichen und ~ durch - ersetzt.

Ein Beispiel:

/Users/bill/My Project → -Users-bill-My-Project

Dieser Ansatz stellt sicher, dass Sitzungsdaten aus verschiedenen Projekten nicht vermischt werden und projektspezifisch verwaltet oder entfernt werden können.

Warum werden Sitzungen im JSONL-Format gespeichert?

Claude Code speichert Sitzungsdaten mit JSONL (JSON Lines) anstelle von Standard-JSON.

In einer herkömmlichen JSON-Datei werden alle Nachrichten in einer großen Struktur gebündelt, was bedeutet, dass die gesamte Datei bei jeder Änderung gelesen und neu geschrieben werden muss. Im Gegensatz dazu wird bei JSONL jede Meldung als eigene Zeile in der Datei gespeichert. Eine Zeile entspricht einer Nachricht, ohne äußere Hülle.

Aspekt	Standard-JSON	JSONL (JSON-Zeilen)
Wie die Daten gespeichert werden	Eine große Struktur	Eine Nachricht pro Zeile
Wann werden die Daten gespeichert?	Normalerweise am Ende	Unmittelbar, pro Nachricht
Auswirkungen eines Absturzes	Ganze Datei kann abbrechen	Nur letzte Zeile betroffen
Schreiben neuer Daten	Gesamte Datei neu schreiben	Anhängen einer Zeile
Speicherverbrauch	Alles laden	Zeile für Zeile lesen

JSONL funktioniert in mehreren wichtigen Punkten besser:

• Sofortiges Speichern: Jede Nachricht wird auf die Festplatte geschrieben, sobald sie erzeugt wurde, anstatt auf das Ende der Sitzung zu warten.

• Absturzsicher: Wenn das Programm abstürzt, kann nur die letzte unvollendete Nachricht verloren gehen. Alles, was davor geschrieben wurde, bleibt intakt.

• Schnelles Anhängen: Neue Nachrichten werden an das Ende der Datei angehängt, ohne dass vorhandene Daten gelesen oder überschrieben werden müssen.

• Geringer Speicherbedarf: Sitzungsdateien können Zeile für Zeile gelesen werden, so dass nicht die gesamte Datei in den Speicher geladen werden muss.

Eine vereinfachte JSONL-Sitzungsdatei sieht wie folgt aus:

{"type":"user","message":{"role":"user","content":"Hello"},"timestamp":"2026-01-05T10:00:00Z"}
{"type":"assistant","message":{"role":"assistant","content":[{"type":"text","text":"Hi!"}]}}
{"type":"user","message":{"role":"user","content":"Help me fix this bug"}}

Session-Nachrichtentypen

Eine Sitzungsdatei zeichnet alles auf, was während einer Interaktion mit Claude Code geschieht. Um dies übersichtlich zu tun, verwendet sie verschiedene Nachrichtentypen für verschiedene Arten von Ereignissen.

• Benutzernachrichten stellen neue Eingaben dar, die in das System gelangen. Dazu gehören nicht nur die Eingaben des Benutzers, sondern auch die von Werkzeugen zurückgegebenen Ergebnisse, z. B. die Ausgabe eines Shell-Befehls. Aus der Sicht der KI sind beides Eingaben, auf die sie reagieren muss.

• Assistentenmeldungen halten fest, was Claude daraufhin tut. Diese Nachrichten enthalten die Überlegungen der KI, den von ihr erzeugten Text und alle Werkzeuge, die sie zu verwenden beschließt. Sie zeichnen auch Nutzungsdetails auf, wie z. B. die Anzahl der Token, um ein vollständiges Bild der Interaktion zu erhalten.

• Schnappschüsse der Dateigeschichte sind Sicherheitskontrollpunkte, die erstellt werden, bevor Claude eine Datei ändert. Indem der ursprüngliche Dateistatus zuerst gespeichert wird, ermöglicht Claude Code es, Änderungen rückgängig zu machen, falls etwas schief geht.

• Zusammenfassungen bieten einen knappen Überblick über die Sitzung und sind mit dem Endergebnis verknüpft. Sie erleichtern das Verständnis einer Sitzung, ohne dass jeder Schritt noch einmal durchgespielt werden muss.

Zusammen zeichnen diese Nachrichtentypen nicht nur das Gespräch auf, sondern die gesamte Abfolge der Aktionen und Auswirkungen, die während einer Sitzung auftreten.

Um dies zu verdeutlichen, sehen wir uns spezifische Beispiele für Benutzernachrichten und Assistentenmeldungen an.

(1) Beispiel für Benutzernachrichten:

{
  "type": "user",
  "uuid": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "parentUuid": null,
  "sessionId": "e5d52290-e2c1-41d6-8e97-371401502fdf",
  "timestamp": "2026-01-05T10:00:00.000Z",
  "message": {
    "role": "user",
    "content": "Analyze the architecture of this project"
  },
  "cwd": "/Users/xxx/project",
  "gitBranch": "main",
  "version": "2.0.76"
}

(2) Beispiel für Assistentenmeldungen:

{
  "type": "assistant",
  "uuid": "e684816e-f476-424d-92e3-1fe404f13212",
  "parentUuid": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "message": {
    "role": "assistant",
    "model": "claude-opus-4-5-20251101",
    "content": [
      {
        "type": "thinking",
        "thinking": "The user wants to understand the project architecture, so I need to check the directory structure first..."
      },
      {
        "type": "text",
        "text": "Let me take a look at the project structure first."
      },
      {
        "type": "tool_use",
        "id": "toolu_01ABC",
        "name": "Bash",
        "input": {"command": "ls -la"}
      }
    ],
    "usage": {
      "input_tokens": 1500,
      "output_tokens": 200,
      "cache_read_input_tokens": 50000
    }
  }
}

Wie Sitzungsnachrichten verknüpft werden

Claude Code speichert Sitzungsnachrichten nicht als isolierte Einträge. Stattdessen werden sie miteinander verknüpft, um eine klare Ereigniskette zu bilden. Jede Nachricht enthält einen eindeutigen Bezeichner (uuid) und einen Verweis auf die Nachricht, die vor ihr kam (parentUuid). So kann man nicht nur sehen, was passiert ist, sondern auch, warum es passiert ist.

Eine Sitzung beginnt mit einer Benutzernachricht, mit der die Kette beginnt. Jede Antwort von Claude verweist zurück auf die Nachricht, die sie ausgelöst hat. Werkzeugaufrufe und ihre Ausgaben werden auf die gleiche Weise hinzugefügt, wobei jeder Schritt mit dem vorhergehenden verknüpft ist. Wenn die Sitzung endet, wird eine Zusammenfassung an die letzte Nachricht angehängt.

Da jeder Schritt miteinander verknüpft ist, kann Claude Code die gesamte Abfolge der Aktionen wiedergeben und nachvollziehen, wie ein Ergebnis zustande gekommen ist, was die Fehlersuche und Analyse erheblich erleichtert.

Einfaches Rückgängigmachen von Code-Änderungen mit Datei-Snapshots

KI-generierte Änderungen sind nicht immer korrekt, und manchmal gehen sie in die völlig falsche Richtung. Um diese Änderungen sicher zu machen, verwendet Claude Code ein einfaches Schnappschusssystem, mit dem Sie Änderungen rückgängig machen können, ohne sich durch Diffs wühlen oder Dateien manuell bereinigen zu müssen.

Die Idee ist einfach: Bevor Claude Code eine Datei ändert, speichert es eine Kopie des ursprünglichen Inhalts. Stellt sich heraus, dass die Änderung ein Fehler war, kann das System die vorherige Version sofort wiederherstellen.

Was ist ein Snapshot der Dateigeschichte?

Ein Dateihistorien-Snapshot ist ein Prüfpunkt, der vor der Änderung von Dateien erstellt wird. Er zeichnet den ursprünglichen Inhalt jeder Datei auf, die Claude gerade bearbeiten will. Diese Snapshots dienen als Datenquelle für Rückgängigmachungs- und Rollback-Vorgänge.

Wenn ein Benutzer eine Nachricht sendet, die möglicherweise Dateien ändert, erstellt Claude Code einen leeren Snapshot für diese Nachricht. Vor der Bearbeitung sichert das System den ursprünglichen Inhalt jeder Zieldatei im Snapshot und wendet die Änderungen dann direkt auf der Festplatte an. Wenn der Benutzer die Rückgängigmachung auslöst, stellt Claude Code den gesicherten Inhalt wieder her und überschreibt die geänderten Dateien.

In der Praxis sieht der Lebenszyklus einer rückgängig zu machenden Bearbeitung wie folgt aus:

1. Benutzer sendet eine NachrichtClaudeCode erstellt einen neuen, leeren file-history-snapshot Datensatz.

2. Claude bereitet sich auf die Änderung von Dateien vorDasSystem erkennt, welche Dateien bearbeitet werden sollen und sichert deren ursprünglichen Inhalt in trackedFileBackups.

3. Claude führt die Bearbeitung ausBearbeitungs-und Schreibvorgänge werden durchgeführt, und der geänderte Inhalt wird auf die Festplatte geschrieben.

4. Benutzer löst Rückgängigmachen ausDerBenutzer drückt Esc + Esc und signalisiert damit, dass die Änderungen rückgängig gemacht werden sollen.

5. Der ursprüngliche Inhalt wird wiederhergestelltClaudeCode liest den gespeicherten Inhalt von trackedFileBackups und überschreibt die aktuellen Dateien, wodurch die Rückgängigmachung abgeschlossen wird.

Warum Rückgängigmachen funktioniert: Schnappschüsse speichern die alte Version

Das Rückgängigmachen in Claude Code funktioniert, weil das System den ursprünglichen Dateiinhalt speichert, bevor eine Bearbeitung erfolgt.

Anstatt zu versuchen, Änderungen im Nachhinein rückgängig zu machen, wählt Claude Code einen einfacheren Ansatz: Es kopiert die Datei so, wie sie vor der Änderung existierte, und speichert diese Kopie in trackedFileBackups. Wenn der Benutzer die Rückgängigmachung auslöst, stellt das System diese gespeicherte Version wieder her und überschreibt die bearbeitete Datei.

Das folgende Diagramm zeigt diesen Ablauf Schritt für Schritt:

┌─────────────────────────┐
│    before edit,  app.py │
│    print("old")         │───────→  Backed up into snapshot trackedFileBackups
└─────────────────────────┘
↓
┌──────────────────────────┐
│   After Claude edits     │
│    print(“new”)          │───────→  Written to disk (overwrites the original file)
└──────────────────────────┘
↓
┌──────────────────────────┐
│    User triggers undo    │
│    Press   Esc + Esc     │───────→ Restore “old” content to disk from snapshot
└──────────────────────────┘

Wie ein File-History-Snapshot intern aussieht

Der Snapshot selbst wird als strukturierter Datensatz gespeichert. Er enthält Metadaten über die Benutzernachricht, den Zeitpunkt des Schnappschusses und - was besonders wichtig ist - eine Zuordnung der Dateien zu ihrem ursprünglichen Inhalt.

Das folgende Beispiel zeigt einen einzelnen file-history-snapshot -Datensatz, der erstellt wurde, bevor Claude eine Datei bearbeitet hat. Jeder Eintrag in trackedFileBackups speichert den Inhalt einer Datei vor der Bearbeitung, der später bei einer Rückgängigmachung zur Wiederherstellung der Datei verwendet wird.

{
  "type": "file-history-snapshot",
  "messageId": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "snapshot": {
    "messageId": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
    "trackedFileBackups": {
      "/path/to/file1.py": "Original file content\ndef hello():\n    print('old')",
      "/path/to/file2.js": "// Original content..."
    },
    "timestamp": "2026-01-05T10:00:00.000Z"
  },
  "isSnapshotUpdate": false
}

Wo Schnappschüsse gespeichert werden und wie lange sie aufbewahrt werden

• Wo Snapshot-Metadaten gespeichert werden: Snapshot-Datensätze sind an eine bestimmte Sitzung gebunden und werden als JSONL-Dateien unter~/.claude/projects/-path-to-project/{session-id}.jsonl gespeichert.

• Wo die ursprünglichen Dateiinhalte gesichert werden: Der Inhalt jeder Datei vor der Bearbeitung wird getrennt nach Inhaltshash unter~/.claude/file-history/{content-hash}/ gespeichert.

• Wie lange Snapshots standardmäßig aufbewahrt werden: Snapshot-Daten werden für 30 Tage aufbewahrt, entsprechend der globalen Einstellung cleanupPeriodDays.

• So ändern Sie die Aufbewahrungsdauer: Die Anzahl der Aufbewahrungstage kann über das Feld cleanupPeriodDays in ~/.claude/settings.json angepasst werden.

Verwandte Befehle

Befehl / Aktion	Beschreibung
Esc + Esc	Rückgängig machen der letzten Dateibearbeitung (am häufigsten verwendet)
/Rückspulen	Zu einem zuvor festgelegten Prüfpunkt (Schnappschuss) zurückkehren
/diff	Unterschiede zwischen der aktuellen Datei und der Schnappschusssicherung anzeigen

Andere wichtige Verzeichnisse

(1) plugins/ - Plugin-Verwaltung

Im Verzeichnis plugins/ werden Add-ons gespeichert, die Claude Code zusätzliche Fähigkeiten verleihen.

In diesem Verzeichnis wird gespeichert, welche Plugins installiert sind, woher sie stammen und welche zusätzlichen Fähigkeiten diese Plugins bieten. Es speichert auch lokale Kopien von heruntergeladenen Plugins, so dass sie nicht erneut geholt werden müssen.

~/.claude/plugins/
├── config.json
│   Global plugin configuration (e.g., enable/disable rules)
├── installed_plugins.json
│   List of installed plugins (including version and status)
├── known_marketplaces.json
│   Plugin marketplace source configuration (e.g., Anthropic official marketplace)
├── cache/
│   Plugin download cache (avoids repeated downloads)
└── marketplaces/
    Marketplace source storage
    └── anthropic-agent-skills/
        Official plugin marketplace
        ├── .claude-plugin/
        │   └── marketplace.json
        │       Marketplace metadata
        └── skills/
            Skills provided by the marketplace
            ├── pdf/
            │   PDF-related skills
            ├── docx/
            │   Word document processing skills
            └── frontend-design/
                Frontend design skills

(2) skills/ - Wo Skills gespeichert und angewendet werden

In Claude Code ist ein Skill eine kleine, wiederverwendbare Fähigkeit, die Claude hilft, eine bestimmte Aufgabe auszuführen, wie z.B. die Arbeit mit PDFs, das Bearbeiten von Dokumenten oder das Befolgen eines Coding-Workflows.

Nicht alle Fähigkeiten sind überall verfügbar. Einige gelten global, während andere auf ein einzelnes Projekt beschränkt sind oder durch ein Plugin bereitgestellt werden. Claude Code speichert Fertigkeiten an verschiedenen Orten, um zu steuern, wo jede Fertigkeit verwendet werden kann.

Die nachstehende Hierarchie zeigt, wie die Skills nach Umfang gestaffelt sind, von global verfügbaren Skills bis hin zu projektspezifischen und durch Plugins bereitgestellten Skills.

Ebene	Speicherort	Beschreibung
Benutzer	~/.claude/skills/	Global verfügbar, zugänglich für alle Projekte
Projekt	projekt/.claude/skills/	Nur für das aktuelle Projekt verfügbar, projektspezifische Anpassungen
Plugin	~/.claude/plugins/marketplaces/*/skills/	Wird mit Plugins installiert, abhängig vom Plugin-Aktivierungsstatus

(3) todos/ - Speicherung von Aufgabenlisten

Das Verzeichnis todos/ speichert Aufgabenlisten, die Claude erstellt, um die Arbeit während einer Konversation zu verfolgen, z. B. zu erledigende Schritte, in Arbeit befindliche Elemente und abgeschlossene Aufgaben.

Die Aufgabenlisten werden als JSON-Dateien unter~/.claude/todos/{session-id}-*.json gespeichert. Jeder Dateiname enthält die Sitzungs-ID, die die Aufgabenliste mit einer bestimmten Konversation verknüpft.

Der Inhalt dieser Dateien stammt aus dem Tool TodoWrite und enthält grundlegende Aufgabeninformationen wie die Aufgabenbeschreibung, den aktuellen Status, die Priorität und zugehörige Metadaten.

(4) local/ - Lokale Laufzeit und Werkzeuge

Das Verzeichnis local/ enthält die Kerndateien, die Claude Code zur Ausführung auf Ihrem Rechner benötigt.

Dazu gehören die ausführbare Befehlszeile claude und das Verzeichnis node_modules/, das die Laufzeitabhängigkeiten des Programms enthält. Da diese Komponenten lokal gehalten werden, kann Claude Code unabhängig laufen, ohne auf externe Dienste oder systemweite Installationen angewiesen zu sein.

（5）Zusätzliche unterstützende Verzeichnisse

• shell-snapshots/: Speichert Schnappschüsse des Shell-Sitzungsstatus (z. B. aktuelles Verzeichnis und Umgebungsvariablen) und ermöglicht so ein Rollback von Shell-Operationen.

• plans/: Speichert Ausführungspläne, die vom Plan-Modus generiert werden (z. B. schrittweise Aufschlüsselungen von mehrstufigen Programmieraufgaben).

• statsig/: Zwischenspeichern von Merkmalskonfigurationen (z. B. ob neue Merkmale aktiviert sind), um wiederholte Anfragen zu vermeiden.

• telemetry/: Speichert anonyme Telemetriedaten (z. B. die Häufigkeit der Nutzung von Funktionen) zur Produktoptimierung.

• debug/: Speichert Debug-Protokolle (einschließlich Fehlerstapel und Ausführungsspuren) zur Unterstützung der Fehlerbehebung.

Schlussfolgerung

Nachdem ich mich damit beschäftigt habe, wie Claude Code alles lokal speichert und verwaltet, wird das Bild ziemlich klar: Das Tool fühlt sich stabil an, weil die Grundlage solide ist. Nichts Ausgefallenes - nur durchdachte Technik. Jedes Projekt hat seinen eigenen Bereich, jede Aktion wird schriftlich festgehalten, und Dateibearbeitungen werden gesichert, bevor sich etwas ändert. Es ist die Art von Design, die in aller Ruhe ihre Arbeit erledigt und Ihnen die Möglichkeit gibt, sich auf Ihre Arbeit zu konzentrieren.

Was mir besonders gefällt, ist, dass hier nichts Mystisches vor sich geht. Claude Code funktioniert gut, weil die Grundlagen richtig gemacht sind. Wenn Sie jemals versucht haben, einen Agenten zu entwickeln, der echte Dateien berührt, wissen Sie, wie leicht die Dinge auseinanderfallen können - Zustände werden vermischt, Abstürze machen den Fortschritt zunichte, und Rückgängigmachen wird zum Ratespiel. Claude Code vermeidet all das mit einem Speichermodell, das einfach, konsistent und schwer zu knacken ist.

Für Teams, die lokale oder On-Premise-KI-Agenten entwickeln, insbesondere in sicheren Umgebungen, zeigt dieser Ansatz, wie starke Speicherung und Persistenz KI-Tools zuverlässig und praktisch für die tägliche Entwicklung machen.

Wenn Sie lokale oder vor Ort installierte KI-Agenten entwickeln und detaillierter über Speicherarchitektur, Sitzungsdesign oder sicheres Rollback diskutieren möchten, können Sie unserem Slack-Kanal beitreten oder über die Milvus-Sprechstunde ein 20-minütiges Einzelgespräch buchen, um eine persönliche Beratung zu erhalten.