Memory-Hooks: vier Eintraege in settings.json und ich vergesse keine Session mehr

Memory hatte ich seit Februar im Daily Driver. Aber halb. Sessions starten ja von selbst sobald ich `claude` tippe, das laeuft. Das Problem war immer das Ende. Ctrl-D, Tab zu, naechste Aufgabe, und `nex_session_end` blieb haengen. Beim Compact mittendrin genauso. Bis vor zwei Wochen hatte ich von 47 Sessions ungefaehr 18 die mit einem sauberen Summary in der Datenbank landeten. Der Rest war abgeschnitten. Seit Claude Code 2.1.118 gibt es den `type: "mcp_tool"` Hook. Ich erzaehl dir was passiert wenn man vier davon in die settings.json packt und zwei Wochen damit lebt. ## Was die Bash-Wrapper-Ära kaputt gemacht hat Vorher hatte ich einen Stop-Hook der ein Bash-Script aufrief, das wiederum den MCP via Stdin pingte. Drei Indirektionen, jede mit eigenem Timeout-Verhalten. Wenn der Server kalt war, brach das Script bei 5 Sekunden ab, der MCP-Call lief intern weiter ins Leere, und ich hatte zwar einen "Hook fired" Log aber keine Session in der DB. Das ist der Punkt wo `mcp_tool` Hooks gewinnen. Claude Code spricht den MCP-Server direkt an, über die schon offene Stdio-Verbindung. Kein Subprozess, kein zusaetzlicher Auth-Handshake. Wenn ich `timeout: 30` setze, gilt das für den echten Tool-Call, nicht für irgendeine Bash-Wrapper-Maskerade. ## Die vier Hooks die ich jetzt fahre Erster Hook, Stop. Wenn die Session endet, feuert `nex_summarize` und danach `nex_session_end`. Beide idempotent, doppelt aufrufen ist NOOP. In zwei Wochen sind 47 von 47 Sessions sauber in `nex_sessions` gelandet. Vorher 18, jetzt 47. Das macht die Memory-Suche schlagartig brauchbar weil keine Luecken mehr im Verlauf sind. Zweiter Hook, PreCompact. Das war für mich die eigentliche Entdeckung. Wenn Claude Code mittendrin komprimiert, war frueher der ganze Zwischenstand weg, weil mein Stop-Hook erst beim echten Session-Ende feuerte. Jetzt schiesst `nex_summarize` vor der Kompaktierung einen Snapshot in die DB. In zwei Wochen 11 mal gefeuert. Elf Sessions die ich sonst halbiert verloren haette. Dritter Hook, UserPromptSubmit. Bei jedem Prompt ein `nex_search` mit dem Prompt als Query, Limit 5. Das fuettert die naechste Antwort mit `additionalContext`, ohne dass ich an `nex_search` denken muss. Median-Latenz auf meinem warmen Server: 380 Millisekunden. Cold start war einmal bei 4.2 Sekunden, dann nie wieder. Vierter Hook, SubagentStop. Wenn ich einen Task spawne und der Subagent ein langes Research-Output zurueckwirft, schreibt `nex_learn` mit `category: "research"` und `confidence: 0.6` rein. Der Gatekeeper dedupliziert über Trigram-Aehnlichkeit. In zwei Wochen 23 Subagent-Reports, davon 4 als Duplikate erkannt und uebersprungen, 19 echt eingespeist. Was zusammen bedeutet: ich klicke nichts mehr. Memory laeuft im Hintergrund. ## Zwei Sachen die ich falsch gemacht hab Erstens. Ich hatte UserPromptSubmit anfangs mit einem `if`-Filter konfiguriert, damit nur bei Trigger-Phrasen wie "haben wir schon" oder "was wissen wir über" gesucht wird. `if`-Filters funktionieren nicht auf UserPromptSubmit, nur auf Tool-Events. Stand 30 Minuten vor einer leeren Memory-Recall obwohl der Hook im Log feuerte. Loesung: entweder den Filter rausnehmen und auf jeden Prompt suchen (kostet ein paar Tool-Calls extra), oder den alten Bash-Wrapper `memory-first-check.sh` lassen der die Keyword-Filterung selbst macht. Ich hab Variante eins genommen. 380ms pro Prompt sind okay. Zweitens. PreCompact und Stop riefen anfangs beide `nex_summarize` UND `nex_session_end`. Wenn die Session erst komprimiert wurde und dann irgendwann endete, war die Session schon vor dem Stop-Hook geschlossen. `nex_session_end` ist idempotent, also kein Crash, aber der zweite Aufruf hat das Summary nochmal ueberschrieben mit dem Compact-Stand statt dem End-Stand. Eine Stunde Suche bis ich kapiert hab dass die Hook-Reihenfolge in `hooks` ein Array ist, nicht eine Menge. Fix: PreCompact ruft nur noch `nex_summarize`, nicht `nex_session_end`. Session bleibt offen bis Stop sie schliesst. ## Was du vor dem Copy-Paste pruefen solltest Drei Sachen. Erstens dein Memory-Endpoint. Bei mir ist das `memory.studiomeyer.io`, bei dir vielleicht eine lokale Instanz oder eine andere SaaS. Der `server`-Key im Hook muss zum Namen in `~/.claude.json` unter `mcpServers` matchen. Vertippt und nichts feuert. Zweitens das Timeout. Default ist meines Wissens 60 Sekunden in 2.1.118. Bei `nex_summarize` reichen 30, bei `nex_search` reichen 10. Lower setzen heisst, dass dir bei kaltem Server der Hook abbricht, das ist OK für einen Read-Call, weniger OK für einen Write. Drittens DSGVO. Die Hooks schiessen Session-Inhalte in deine Memory-Instanz. Wenn du SM-Memory als Multi-Tenant SaaS nutzt: alle Daten sind tenant-isoliert, kein Cross-Tenant-Leak, du kannst deinen Tenant jederzeit über das Dashboard loeschen. Wenn du selber hostest: Datenhoheit liegt bei dir, dann ist es eh deine Verantwortung. Im Zweifel das settings.json-Snippet in den Team-Slack oder den Lead schicken bevor du committest. ## Was als naechstes Wenn du die vier Hooks live hast und sehen willst was sie wirklich tun, schau ins Dashboard unter "Sessions" und "Learnings". Bei mir gehen jetzt durchschnittlich 3.4 Sessions pro Tag rein, jede mit Summary, viele mit Subagent-Learnings dahinter. Das ist die Datenmenge die ich vorher nie zusammenbekommen hab weil zu viel im Ctrl-D verloren ging. Wenn du noch ganz am Anfang stehst und nicht weisst was Memory überhaupt ist, fang mit Lesson 4-1 an (/levels/4/warum-memory). Wenn du den allgemeinen Hook-Mechanismus verstehen willst, lies Lesson 4-10 (/levels/4/mcp-tool-hooks). Und wenn du das gleiche Pattern für CRM oder GEO bauen willst, gibt es das Playbook hooks-gegen-halluzinationen (/playbooks/hooks-gegen-halluzinationen) als naechsten Schritt. Offizielle Anthropic-Doku zu allen Hook-Events: https://code.claude.com/docs/en/hooks. Da steht auch was die Substitution-Variables wie `${session_id}` und `${last_assistant_message}` machen, falls du eigene Bundles bauen willst.