Claude Code hat Amnesie - wie ContextWolf das heilt
Claude Code ist das Tool, das ich jeden Tag nutze. Das Problem: Es vergisst. Session endet, Kontext weg. Die Architektur-Entscheidung von letzter Woche, der Bug vom letzten Monat - beim nächsten Start alles gelöscht. ContextWolf ist meine Antwort - ein Nebenprojekt, das als schnelle Lösung für mich selbst anfing und in 6 Monaten zu 184 Commits, einem fast-tödlichen
mv-Befehl und einer Air-Gap-Release-Strategie gewachsen ist. Jetzt Open Source auf GitHub.DarkWolfCave.de
Das Problem: Kein Gedächtnis zwischen Sessions
Wer Claude Code produktiv nutzt, kennt das Muster. Du erklärst in Session A, warum ihr Session Cookies statt JWTs verwendet. Session B, zwei Wochen später: Claude schlägt dir JWTs vor. Du erklärst es nochmal.
Das ist kein Bug. LLMs haben kein persistentes Gedächtnis zwischen Sessions - jede neue Konversation startet mit einem leeren Kontext.
Seit Anfang 2026 gibt es in Claude Code ein eingebautes Auto-Memory: Claude schreibt sich selbst Notizen in Markdown-Dateien, die bei der nächsten Session wieder geladen werden. Das hilft - bis zu einem bestimmten Punkt. Die ersten 200 Zeilen (oder 25 KB, was zuerst eintrifft) werden geladen, der Rest ignoriert. Semantische Suche gibt es nicht. Cross-Projekt auch nicht.
Ich habe diesen Weg selbst ausgereizt. In einem meiner Projekte hatte ich irgendwann Hunderte Markdown-Dateien als “Gedächtnis” angelegt - Session Summaries, Architektur-Entscheidungen, Debugging-Logs, sogar eigene Regeln in CLAUDE.md, die immer länger wurden. Claude kann das alles lesen, klar. Aber jede dieser Dateien kostet Tokens, füllt das Kontextfenster mit Informationen, die zu 90 % gerade nicht relevant sind - und die wirklich wichtige Entscheidung von vor drei Monaten geht trotzdem unter, weil sie irgendwo in Datei 247 von 400 steht.
Ich brauchte etwas Besseres - nicht als Produkt, nicht als Open-Source-Projekt, sondern als Werkzeug für meinen eigenen Alltag.
Du wirst hier einen groben Überblick finden.
Allerdings biete ich dir auch noch etwas mehr Support an:
- Du benötigst persönlichen Support
- Du möchtest von Beginn an Unterstützung bei deinem Projekt
- Du möchtest ein hier vorgestelltes Plugin durch mich installieren und einrichten lassen
- Du würdest gerne ein von mir erstelltes Script etwas mehr an deine Bedürfnisse anpassen
Für diese Punkte und noch einiges mehr habe ich einen limitierten VIP-Tarif eingerichtet.
Falls der Tarif gerade nicht verfügbar ist, kontaktiere mich auf Discord!
vibe-scribe und der Wahnsinnstag
ContextWolf war nie als Projekt geplant. Es fing an als ein Skript, das ich brauchte, weil mir Claude Code zum dritten Mal denselben Vorschlag machte, den wir zwei Wochen vorher verworfen hatten. Die erste Version hieß vibe-scribe - klingt nach einer App für Singer-Songwriter, nicht nach Developer-Tool. Aber der Name spielte keine Rolle, weil das Ding nur für mich war.
V1 existierte irgendwann im Sommer 2025 ohne Git, ohne Dokumentation. Am 23.09.2025 kam V2 mit FTS5-Volltext-Suche und einer sauberen SQLite-Struktur - zum ersten Mal das Gefühl, ein echtes Werkzeug in der Hand zu haben.
Einen Tag später folgte der Tag, der alles andere übertrifft.
24.09.2025, 07:43 Uhr. Erster Git-Commit: “feat: Context Manager V2.1 - Production Ready.”
18:20 Uhr desselben Tages. V2.4.1.
| Zeit | Version | Was dazukam |
|---|---|---|
| 07:43 | V2.1 | Production Ready |
| 08:05 | V2.2 | Token-Tracking für Context Window Monitoring |
| 16:34 | V2.3 | Duplicate Detection + Time-Travel Search + Delete |
| 18:01 | V2.4.0 | AI-Instructions System |
| 18:20 | V2.4.1 | commit-info Command, JSON-Formatting Fix |
Elf Stunden, fünf Versionen, keine kleinen Patches. Einen Tag später: V3.0.0 mit komplettem Refactoring zu einer modularen Clean Architecture - vier Schichten, sauber getrennt.
Das 23-Megabyte-Mystery
Im Oktober 2025 wurde aus vibe-scribe der Name context-manager. Der Rename lief durch - aber der MCP-Server startete danach nicht mehr. Kein offensichtlicher Fehler, kein hilfreicher Log.
Nach langem Suchen fand ich die Ursache an einer unerwarteten Stelle: ~/.claude.json - eine 23 Megabyte große History/Cache-Datei - enthielt noch den alten Pfad zum MCP-Binary. Nicht der erste Kandidat bei der Fehlersuche. Aber der richtige.
CM-Eintrag direkt danach:
“First successful push to Gitea wolf server. Achievement unlocked! 🐺“
Von SQLite zu PostgreSQL - Schmerz, nicht Philosophie
Im November 2025 kam die PostgreSQL-Migration. Nicht aus architektonischen Überzeugungen, sondern aus diesem Fehler:
MCP Server 1 (PID 35394) ──┐
├──> ~/.context/global.db [LOCKED]
MCP Server 2 (PID 68376) ──┘ ❌ Timeout nach 30 SekundenZwei parallele MCP-Server-Instanzen, eine SQLite-Datei. SQLite hat kein MVCC - wenn zwei Prozesse gleichzeitig schreiben wollen, wartet einer. 30 Sekunden lang.
PostgreSQL hat MVCC. Problem gelöst. Ab V4.3.0 läuft alles auf dem eigenen Server. 39 MCP Tools wurden auf 15 eingedampft, später sinnvoll auf über 30 aufgestockt.
Der Tag, an dem das Tool sich fast selbst gelöscht hat
V5 war so gut wie fertig. Letzter Schritt vor dem Release: den Ordner von context-manager nach context-wolf umbenennen. Sollte eine Sache von zwei Sekunden sein.
mv context-manager context-wolfDas Ergebnis: context-wolf/context-manager/ - der alte Ordner war als Unterordner gelandet, nicht umbenannt. Also der nächste Versuch: mv context-manager/* context-wolf/. Sah gut aus. War es nicht. Denn * in zsh matcht keine Dotfiles - .git, .venv, .claude blieben im alten Ordner zurück. Den habe ich dann aufgeräumt. Und damit 184 Commits Git-History, die komplette Python-Umgebung und alle Claude-Konfigurationen gleich mit.
Das Mac-Backup war zum Glück aktuell. Die Lektion daraus:
# Repo-Inhalt ohne .git kopieren - IMMER so umbenennen!
rsync -av --exclude='.git/' context-manager/ context-wolf/Das erste, was ich danach gemacht habe: einen CM-Eintrag mit der Warnung speichern. Das Tool, das gerade fast gestorben wäre, hat seinen eigenen Beinahe-Tod dokumentiert.
Die Air-Gap-Strategie für den Public Release
Der mv-Vorfall war lösbar. Das nächste Problem nicht so leicht: 6 Monate Git-History auf dem privaten Gitea-Server, durchzogen von Informationen, die nicht auf GitHub gehören. IPs: 192.168.x.x. Interne Servernamen. Lokale Mac-Pfade.
Ein einfaches Mirror auf GitHub hätte meine halbe Homelab-Infrastruktur offengelegt. Die Lösung ist ein Release-Skript (gh-release.sh), das drei Dinge tut:
- Secret-Scan: gitleaks prüft alle tracked Files auf Leaks - bevor irgendetwas gepusht wird
- Squash-Merge: Alle internen Commits werden in einen Orphan-Branch
publiczusammengefasst - keine Commit-History, keine privaten Infos - Temporärer Remote: GitHub wird als Remote hinzugefügt,
publicalsmaingepusht, Remote sofort wieder entfernt
Keine IPs, keine Servernamen, keine privaten Pfade im öffentlichen Repository. Wer selbst ein Homelab-Projekt veröffentlichen will - das Problem ist real, und blind auf GitHub spiegeln ist keine Option.
Drei Namen, ein Tool
Wenn ein Projekt über Monate organisch wächst, sammelt es Identitäten. Erst hieß es vibe-scribe, dann context-manager, jetzt context-wolf. Jeder Rename hat Spuren hinterlassen: Im Terminal tippe ich seit einem halben Jahr cm - das umzugewöhnen würde bedeuten, Dutzende Skripte, Hooks und Muscle Memory zu brechen. In ~/.claude.json steht context-manager als MCP-Key - das zu ändern würde bei jedem bestehenden Setup die Konfiguration kaputtmachen.
Also trägt das Tool jetzt drei Namen gleichzeitig. context-wolf ist der offizielle Package-Name für alles Neue. cm bleibt der CLI-Befehl. context-manager bleibt der MCP-Key. Das ist nicht elegant, aber es ist die ehrliche Lösung - Kompatibilität geht vor Konsistenz.
Was ContextWolf heute kann - und was public ist
Kern-Funktionen:
context_save()- Entscheidungen, Bugs, Features mit Typ und Projekt-Zuordnung speicherncontext_search()- Volltext-Suche über alle Einträge, alle Projektenote_save()/note_show()- Längere Referenzdokumente als Notizentodo_add()/todo_start()/todo_done()- Task-Tracking direkt im Toolinfra_list_hosts()- Infrastruktur-Übersicht für alle Server
Technisch:
- PostgreSQL mit Volltextsuche (
ts_rank_cd) - Semantische Suche per pgvector + lokales ONNX-Modell (
all-MiniLM-L6-v2, ~90 MB) - Über 30 MCP Tools - Claude Code lädt nur die Tool-Namen beim Session-Start (356 Tokens). Die vollen Schemas werden erst geladen, wenn ein Tool tatsächlich gebraucht wird. Gemessen mit der Anthropic Token Counting API: der Overhead ist vernachlässigbar
- Performance: Suche bleibt in meiner DB mit über 7.000 Einträgen unter 1 ms (du startest bei 0)
- Läuft vollständig auf eigener Infrastruktur - keine externen API-Calls, kein Cloud-Lock-in
Über 30 MCP Tools klingen nach Token-Problem. Jedes Tool hat einen Namen, eine Beschreibung und ein JSON-Schema mit allen Parametern. Bei der direkten Claude API landet das alles im Kontextfenster - bei jedem einzelnen Request. Ich habe es gemessen.
Anthropic bietet eine kostenlose Token Counting API an (/v1/messages/count_tokens). Der Endpoint gibt die exakte Token-Anzahl eines Requests zurück, ohne ihn auszuführen. Drei Messungen: Baseline ohne Tools, dann mit allen Tool-Schemas auf einmal, dann mit den Tool-Namen so wie Claude Code sie tatsächlich lädt.
| Messung | Tokens |
|---|---|
| Baseline (kein Tool) | 10 |
| Alle Tool-Schemas (volle Definitionen) | 3.923 |
| Nur Tool-Namen (deferred, wie Claude Code es macht) | 356 |
Der Unterschied ist Tool Search. Claude Code lädt beim Session-Start nicht die vollen Schemas, sondern nur die Namen. Die Definition eines Tools wird erst nachgeladen, wenn Claude es tatsächlich braucht. 356 statt knapp 4.000 Tokens - 93 % Einsparung, ohne dass ich irgendetwas konfigurieren musste.
Bei einem Kontextfenster von einer Million Tokens (Opus) sind 356 Tokens 0,04 %. Bei Sonnet mit 200K sind es 0,18 %. In beiden Fällen: nicht relevant. Die Frage “Haben wir zu viele Tools?” hat sich damit erledigt.
💡 Tipp:
context_search("authentication")findet auch Einträge, die nur “JWT”, “login” oder “OAuth” enthalten - ohne dass du den exakten Begriff kennen musst. Das ist der größte Unterschied zu Keyword-Suche über Markdown-Dateien.
Lange war ContextWolf ein reines Werkzeug für mich - gebaut, weil ich es brauchte, gewachsen, weil jede Woche ein neues Problem auftauchte. Dass daraus ein Open-Source-Release werden würde, stand nie im Plan. Bis mir von mehreren Seiten - aus dem Bekanntenkreis, aus KI-Communities - geraten wurde, das Ding zu veröffentlichen und einen Kurs daraus zu machen.
Der Plan sieht jetzt so aus: CLI + MCP-Server sind frei - MIT-Lizenz, GitHub, für jeden nutzbar. Die GUI wird kostenpflichtig angeboten. Beides zusammen gibt es als Kurs in der Wolf Academy - vom Setup bis zur produktiven Nutzung.
Die Installation ist ein Dreizeiler:
git clone https://github.com/DarkWolfCave/context-wolf.git
cd context-wolf && cp .env.example .env # POSTGRES_PASSWORD eintragen
bash setup.shDas setup.sh startet den PostgreSQL-Container per Docker Compose, legt die lokalen Configs an und registriert den MCP-Server in Claude Code.
ℹ️ Hinweis: Das Tool setzt PostgreSQL voraus. Wer kein eigenes Setup hat, kann mit einer lokalen PostgreSQL-Instanz starten - die README erklärt beide Wege.
Was mich an diesem Projekt am meisten beschäftigt
Für die V5-Release-Strategie habe ich mit Gemini gearbeitet - Namensfindung, Open-Core-Entscheidung, README-Struktur. Dass ich KI-Tools für Strategie und Entwicklung parallel nutze, ist mittlerweile normal. Den Code hat Claude geschrieben. Das Tool, das dabei entstanden ist, gibt Claude ein persistentes Gedächtnis.
Zwei KIs koordiniert, um einer dritten ein Gedächtnis zu geben. Wer sich fragt, wie sich Claude Code im Vergleich zu anderen KI-Tools schlägt - es ist das Tool, das ich produktiv einsetze. ContextWolf macht es erst richtig nutzbar.
Dabei hat das Tool jeden Schritt selbst dokumentiert - den mv-Desaster als CM-Eintrag #7699, die strategischen Entscheidungen als #7146, den Release als #7698. Alle über 7.000 Einträge in meiner Datenbank wurden mit dem Tool gesammelt, das diese Datenbank verwaltet.
Im November 2025 habe ich in meinen Projekten aufgehört, Session Summaries in Markdown-Dateien zu schreiben. CM-Eintrag #4302: “Keine Session Summaries mehr erstellen - dafür ist Context Manager da!” Das Tool hatte seinen Vorgänger überflüssig gemacht.
V5 wurde mit dem Tool entwickelt, das V5 ist. Und wenn ich das schreibe, nutze ich gerade das Tool, über das ich schreibe, um diesen Artikel zu strukturieren.
Falls das für dich genauso seltsam klingt wie für mich - willkommen im Club.
Das Repository ist jetzt live: github.com/DarkWolfCave/context-wolf. Installation, Dokumentation und Setup-Anleitung stehen in der README. Feedback, Issues und PRs sind willkommen.
Den Kurs dazu - vom Setup bis zur produktiven Nutzung mit CLI und GUI - gibt es in Vorbereitung für die Wolf Academy. Wer Bescheid wissen will wenn er live geht: einfach unten in den Newsletter eintragen.
Mehr zum Thema KI-Tools und Claude Code:
Kommentare