Montagmorgen. Du öffnest Claude Code zu einem komplexen Bug, den du am Freitag liegengelassen hast. Claude erinnert sich an nichts. Du erklärst den Kontext neu, beschreibst die Architektur erneut, listest noch einmal auf, was bereits versucht wurde. Fünfzehn Minuten verloren, bevor du dort weitermachen kannst, wo du aufgehört hast.

Genau dieses Problem löst das Sitzungsgedächtnis — und OpenClaw hat es als erstes gelöst.

Was ist OpenClaw?

OpenClaw ist ein Open-Source-Framework für Claude Code. Sein Ziel: Claude von einem gedächtnislosen Assistenten in einen persistenten autonomen Agenten zu verwandeln, der sich merkt, was er getan hat, was entschieden wurde und was noch zu tun bleibt.

OpenClaw funktioniert ausschließlich mit Markdown und Python, ohne Datenbank, ohne externe Abhängigkeiten. Seine Philosophie: Flache Dateien, die versionierbar und von Menschen lesbar sind, sind das beste Langzeitgedächtnis.

Die Gedächtnisarchitektur beruht auf drei Ebenen: - Sofortgedächtnis — der in der aktuellen Sitzung geladene Kontext - Tages-Logs — was heute (und gestern) passiert ist - Langzeitgedächtnis — dauerhafte Fakten, komprimiert und aktuell gehalten

Ich habe diese Architektur für meine Claude Code-Projekte angepasst: ein Stop-Hook, der nach jedem Austausch automatisch läuft, zwei Markdown-Dateien pro Projekt (long_memory.md + ein Log pro Tag), und zwei Skills zum Laden und Konsolidieren des Gedächtnisses. So funktioniert es — und so richtest du es ein.

Warum das ein echter Mehrwert gegenüber dem Standard-Claude ist

Claude Code hat zwar ein natives automatisches Gedächtnis — aber es hat zwei wichtige Einschränkungen:

Die CLAUDE.md ist eine andere Lösung, aber sie ist eine Datei mit statischen Regeln — kein Aktivitätsjournal. Sie protokolliert nicht, was getan wurde, welche Probleme aufgetaucht sind, noch welche Entscheidungen während der Sitzung getroffen wurden.

Das Sitzungsgedächtnis schließt diese Lücke: Es erfasst automatisch, bei jedem Austausch, was passiert ist. Ohne dass du daran denken musst.

Architektur

Das System basiert auf zwei Arten von Markdown-Dateien, einem Stop-Hook und einem Haiku-Modell, das die Extraktion übernimmt.

Dateistruktur

projet/
  memory_sessions/
    long_memory.md          ← Langzeitgedächtnis (permanentes Kompendium)
    logs/
      2026-03-22.md         ← Tages-Log, strukturiert nach Abschnitten
      2026-03-21.md
      archives/             ← Logs > 30 Tage
      .debug/               ← Haiku-Roh-JSON (gitignored)

In einem Multi-Projekt-Workspace hat jedes Unterprojekt sein eigenes memory_sessions/-Verzeichnis — das Gedächtnis von cmms_doc vermischt sich nicht mit dem von competitors.

Vorlage 1 — Das Tages-Log (logs/2026-03-22.md)

Eine Datei pro Tag, strukturiert in feste Abschnitte. Haiku fügt bei jedem Austausch neue Einträge hinzu — ohne jemals zu duplizieren, was bereits vorhanden ist.

# Log session — 2026-03-22

## Kontext
- Umbau des Sitzungsgedächtnis-Systems für den Workspace PRODUCT_AGENTS.

## Ziel
- Das neue strukturierte JSON-Format testen, das Haiku zurückgibt.

## Gefundene Probleme
- Transcript-Extraktion schlug fehl: tool_result-Nachrichten wurden falsch gefiltert.

## Gewonnene Erkenntnisse
- Das Transcript JSONL enthält viele Nachrichten mit leerem Inhalt (tool_use, thinking) — nach `content[].type == "text"` filtern.

## Geleistete Arbeit
- Neuschreiben des Transcript-Parsers in memory-session.sh.
- Hinzufügen des .debug/-Verzeichnisses zur Inspektion des Haiku-Roh-JSON.

## Getroffene Entscheidungen
- `claude` von `/tmp` aus aufrufen, damit das CLAUDE.md des Projekts nicht stört.

## Zu beobachten
- Validieren, dass die Skill-Erkennung nach dem Patch funktioniert.

## Abgeschlossen
- ✅ Validieren, dass die Skill-Erkennung nach dem Patch funktioniert.

Jeder Abschnitt hat eine klar definierte Aufgabe. Der Abschnitt Abgeschlossen übernimmt die erledigten Punkte aus „Zu beobachten" — ausgelöst, wenn du OK-done an Claude sendest.

Vorlage 2 — Das Langzeitgedächtnis (long_memory.md)

Ein permanentes Kompendium, begrenzt auf 300 Zeilen. Das ist kein Log — es ist das, was Haiku als dauerhaft einstuft: technische Fakten, Geschäftsregeln, strukturelle Entscheidungen.

# Langzeitgedächtnis — cmms_doc

## 2026-03-09
- Der Hook memory-session.sh muss `claude` von /tmp aus aufrufen (nicht vom Projekt), um die Injektion des Host-CLAUDE.md in die Haiku-Antwort zu vermeiden.
- Gewähltes Zwischenformat: strukturiertes JSON nach Abschnitten → Python formatiert das Markdown.
- Deduplizierung durch Haiku, der das bestehende Log vor dem Schreiben erneut liest.

Wenn long_memory.md die 300-Zeilen-Grenze überschreitet, konsolidiert der Skill /memory_promotion die ältesten Einträge und archiviert sie.

Der Mechanismus: Das Tages-Log speist das Langzeitgedächtnis

Austausch mit Claude
    ↓
Haiku analysiert: Was gehört ins heutige Log?
    ↓
Tages-Log aktualisiert (Abschnitte werden ergänzt, Deduplizierung)
    ↓
Dauerhafte Erkenntnis entdeckt → long_memory.md aktualisiert
    ↓
/memory_promotion (wöchentlich/monatlich) → archiviert alte Logs,
    konsolidiert long_memory.md wenn > 300 Zeilen

Der Hook-Ablauf (vereinfachte Version)

Das zentrale Auslöseelement ist ein Stop-Hook — ein Shell-Skript, das Claude Code automatisch am Ende jedes Gesprächszugs ausführt.

Claude antwortet
    ↓
Stop-Hook ausgelöst (settings.json)
    ↓
[Anti-Schleife] stop_hook_active = true ? → exit 0
    ↓
Transcript JSONL parsen → letzten Mensch- und Assistenten-Austausch extrahieren
    ↓
Bestehende Tages-Logs lesen (um Duplikate zu vermeiden)
    ↓
Haiku von /tmp aus mit strukturiertem Prompt aufrufen
    ↓
Haiku gibt JSON nach Abschnitten zurück (Ziel, Probleme, Arbeit…)
    ↓
Python führt alles ins Tages-Markdown-Log zusammen
    ↓
exit 0

Die Anti-Schleife braucht eine Erklärung: Wenn der Hook claude aufruft, beendet sich dieser Aufruf und löst den Stop-Hook erneut aus. Claude Code injiziert dann stop_hook_active: true in das JSON-stdin. Der Hook erkennt dieses Flag als erstes und beendet sich sofort, ohne weitere Verarbeitung.

Warum claude von /tmp aus aufrufen? Wenn der Hook aus dem Projektverzeichnis heraus läuft, wird das CLAUDE.md des Projekts in den Kontext von Haiku injiziert. Ergebnis: Haiku befolgt deine Geschäftsregeln, statt reines JSON zurückzugeben. Der Aufruf von /tmp neutralisiert diesen Effekt.

So richtest du das System ein

1. Die Gedächtnis-Skills

Zwei Skills ergänzen den Hook:

• /memory_load [Projekt] — zu Beginn der Sitzung aufrufen. Liest long_memory.md + die Logs von heute und gestern. Zeigt eine konsolidierte Zusammenfassung. Das Laden ist manuell — das Gedächtnis wird automatisch gespeichert, lädt sich aber nicht von selbst neu.
• /memory_promotion [Projekt] — konsolidiert aktuelle Logs in long_memory.md und archiviert Logs, die älter als 30 Tage sind. Manuell auszuführen, einmal pro Woche oder Monat je nach Aktivität.

Die Skills sind Markdown-Dateien in .claude/skills/{Name}/SKILL.md. Claude Code erkennt sie als /Name-Befehle.

2. Den Stop-Hook einbinden

Der Stop-Hook wird in .claude/settings.json deklariert:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/memory-session.sh" }
        ]
      }
    ]
  }
}

Wann wird der Stop-Hook ausgelöst? Claude Code löst Stop am Ende jedes Zugs aus — also nach jeder vollständigen Antwort von Claude, egal ob einfach (ein Satz) oder komplex (mit Werkzeugaufrufen). Das ist etwas anderes als das Ende der Sitzung: Der Hook läuft nach jedem Austausch, nicht nur wenn du Claude Code schließt.

3. Die Projektliste anpassen

Im Hook listet eine Variable PROJECT_PATHS die Gedächtnis-Verzeichnisse jedes Unterprojekts auf:

PROJECT_PATHS = {
    "root": "memory_sessions",
    "cmms_doc": "projects/cmms_doc/memory_sessions",
    "competitors": "projects/competitors/memory_sessions",
}

Haiku analysiert den Austausch und stellt fest, welche Projekte betroffen sind — und schreibt dann in die richtigen Dateien.

4. Kosten

Haiku 4.5 wird bewusst gewählt: schnell (~1-2 Sekunden) und kostengünstig. Bei intensiver Nutzung von 20 Austauschen pro Tag bleiben die Kosten unter 1 $/Monat. Das ist verschwindend gering für das, was es bringt.

Was sich konkret ändert

Mit diesem System in Betrieb:

• Wiederaufnahme nach dem Wochenende: /memory_load zu Beginn der Sitzung → Claude kennt den Stand des Bugs, die getroffenen Entscheidungen, was noch zu tun war.
• Multi-Projekt: Jedes Unterprojekt hat sein eigenes Gedächtnis. Erst an cmms_doc, dann an competitors arbeiten in derselben Sitzung → die Logs sind getrennt.
• Nachvollziehbarkeit: Die Geschichte der technischen Entscheidungen liegt im Repo. git log memory_sessions/ erzählt die Entwicklung des Projekts.
• Portabilität: Das Repo auf einem anderen Rechner klonen — das Gedächtnis ist dabei.

Haupteinschränkung

/memory_load ist manuell. Das Gedächtnis wird am Ende jedes Zugs automatisch gespeichert, lädt sich aber beim Start einer neuen Sitzung nicht von selbst. Du musst daran denken, /memory_load zu Beginn der Sitzung aufzurufen, um davon zu profitieren.

Das ist eine bewusste Entscheidung — automatisches Laden würde riskieren, den Kontext kurzer oder projektfremder Sitzungen zu belasten.

Anhänge

Die vollständige technische Spezifikation (vollständiger Hook-Code, JSON-Format, Implementierungsentscheidungen, bekannte Bugs) ist als Anhang verfügbar:

→ spec_session_memory.md

Konkretes Beispiel — echtes Tages-Log: Die folgende Datei ist das Sitzungslog, das automatisch an dem Tag generiert wurde, an dem dieser Artikel verfasst wurde. Es zeigt, was das System bei jedem Austausch tatsächlich erfasst: Kontext, geleistete Arbeit, getroffene Entscheidungen, offene Punkte.

→ session-log-exemple.md

Mehr dazu

Von der einzelnen Datei zum Kontextsystem: Warum das Gedächtnis eines LLM nicht in ein einziges Dokument passt Eine Datei, ein paar Direktiven, und Claude erledigt den Rest — wie ich 500 E-Mails mühelos strukturiert habe