Ich arbeite auf zwei Rechnern: einem MacBook Air M4 und einem Windows-PC im Büro. Claude Code läuft auf beiden. Das Problem: was ich auf dem Mac erarbeitet habe, weiß Windows nicht. Und umgekehrt. Jede Session beginnt bei null. Kein Kontext, keine Geschichte, keine Erinnerung daran, was wir gestern entschieden haben. Ich habe das wochenlang akzeptiert. Dann habe ich es gelöst.
Die Lösung ist ein selbst gehosteter MCP Memory Server auf meinem Hetzner-Cloudserver, deployed über Coolify, erreichbar von jedem Gerät, auf dem Claude Code läuft. Dieser Artikel erklärt, warum das notwendig war, wie ich es umgesetzt habe, wo es gehakt hat und was es mir konkret bringt.
Das eigentliche Problem mit Claude Codes „Gedächtnis“
Claude Code hat ein Gedächtnis, aber es ist lokal und fragmentiert. Es gibt CLAUDE.md-Dateien, die auf Projektebene oder im User-Homeverzeichnis liegen und Claude Code Kontext geben. Das funktioniert gut, solange du auf einem einzigen Rechner arbeitest.
Ich arbeite nicht auf einem einzigen Rechner.
Mein Arbeitsalltag sieht so aus: Morgens am PC, nachmittags am Mac, abends vielleicht remote über den Mac mini im Büro. Das ist kein Randfall, das ist Realität für viele Menschen, die nicht im Büro an einem fixen Platz sitzen. Und für Claude Code ist jeder dieser Rechner eine terra incognita.
Zur Klarheit, weil die Begriffe oft durcheinandergeraten: CLAUDE.md ist eine statische Textdatei, die Claude Code beim Start einliest. Sie gibt Claude Code projektspezifischen Kontext, ähnlich wie ein Briefing-Dokument. Der MCP Memory Server ist dagegen ein aktives Tool, das Claude Code während einer Session aufrufen kann, um Informationen persistent zu speichern und wieder abzurufen, und zwar als strukturierten Knowledge Graph mit Entities und Relations. Das klingt komplizierter als es ist.
Warum Obsidian nicht die Antwort war
Mein erster Gedanke war: ich deploye Obsidian auf Coolify, zeige das Vault dem MCP Memory Server, fertig. Ich nutze Obsidian sowieso intensiv, mein KI-Assistent VINCI ist daran angebunden, warum also nicht auch Claude Code?
Weil es das Problem nicht löst.
Obsidian remote über Coolify gibt mir einen Browser-Zugang zum Vault über noVNC. Das ist eine Lösung für einen anderen Use Case: ich will Obsidian von einem Gerät ohne Obsidian-Installation nutzen. Was ich will, ist etwas anderes: ich will, dass Claude Code auf jedem meiner Rechner auf dieselbe Wissensbasis zugreifen kann, ohne dass ich jedes Mal manuell Dateien synchronisieren oder Kontext neu einfügen muss.
Der richtige Ansatz ist ein MCP Memory Server, der als HTTP-Endpoint im Netz verfügbar ist. Claude Code verbindet sich damit wie mit einem Webservice. Der Knowledge Graph liegt zentral auf dem Server, nicht lokal auf einem der Rechner.
Was ein MCP Memory Server ist und wie er funktioniert
Das Model Context Protocol (MCP) ist ein offenes Protokoll von Anthropic, über das Claude Code externe Tools anbinden kann. Dateisystem, GitHub, Notion, Google Calendar: all das läuft über MCP. Der offizielle Memory Server von Anthropic und dem MCP-Projekt ist @modelcontextprotocol/server-memory. Er speichert einen Knowledge Graph in einer JSON-Datei und stellt neun Tools bereit: Entities erstellen, Beobachtungen hinzufügen, Relationen anlegen, den Graph lesen, nach Nodes suchen und Daten wieder löschen.
Normalerweise läuft dieser Server lokal, kommuniziert über stdio und ist damit an genau einen Rechner gebunden. Der Trick ist, ihn über einen HTTP-Transport ins Netz zu stellen. Dann kann jeder Claude Code Client, der die URL kennt, auf denselben Graph zugreifen.
Als HTTP-Wrapper setze ich supergateway ein, ein Node.js-Tool das stdio-basierte MCP Server als HTTP-Endpoint verfügbar macht. Der Memory Server läuft als Docker-Container auf meinem Hetzner-Cloudserver, Coolify übernimmt das Deployment und die SSL-Terminierung über Traefik.
Der Workshop: Schritt für Schritt zum eigenen Memory Server
Was du brauchst: einen Server mit Coolify (oder Docker-Zugang), eine Domain, und Claude Code auf mindestens einem Gerät.
Schritt 1: Das Dockerfile
Erstelle ein neues Dockerfile mit diesem Inhalt:
FROM node:20-alpine
WORKDIR /app
RUN npm install -g @modelcontextprotocol/server-memory supergateway
RUN mkdir -p /data
ENV MEMORY_FILE_PATH=/data/memory.json
EXPOSE 8080
CMD ["supergateway", "--stdio", "npx @modelcontextprotocol/server-memory", \
"--port", "8080", "--host", "0.0.0.0", \
"--outputTransport", "streamableHttp"]
Der entscheidende Parameter ist --outputTransport streamableHttp. Dazu gleich mehr, warum das wichtig ist.
Schritt 2: Coolify-Deployment
In Coolify legst du einen neuen Service an, wählst „Dockerfile“ als Quelle und fügst den Dockerfile-Inhalt ein. Port 8080, deine gewünschte Domain (bei mir memory-mcp.promptrocker.at). Dann der wichtige Teil: unter „Storages“ ein Volume Mount anlegen.
- Name:
mcp-memory-data - Source Path:
/opt/mcp-memory - Destination Path:
/data
Das ist der Persistenz-Layer. Ohne dieses Volume verlierst du bei jedem Container-Neustart alles, was Claude Code jemals gespeichert hat. Die JSON-Datei mit dem Knowledge Graph landet auf deinem Server, nicht im Container.
Coolify erstellt das Verzeichnis auf dem Host-System automatisch, falls es nicht existiert. Deploy klicken, warten, fertig.
Schritt 3: Verbindung testen
Rufe https://deine-domain.at/mcp im Browser auf. Du siehst keinen Inhalt, die Seite lädt scheinbar endlos. Das ist korrekt: Streamable HTTP hält die Verbindung offen und wartet auf Requests. Kein Fehler, kein leerer Screen aus Versehen, sondern das erwartete Verhalten.
Schritt 4: Claude Code konfigurieren
Auf dem Mac öffnest du das Terminal und führst aus:
claude mcp add memory --transport http https://deine-domain.at/mcp
Auf Windows in PowerShell:
claude mcp add memory --transport http https://deine-domain.at/mcp
Danach claude mcp list eingeben. Du solltest sehen: memory: https://deine-domain.at/mcp (HTTP) - ✓ Connected.
Claude Code neu starten. In einer Session eingeben: /mcp. Wenn memory · ✔ connected · 9 tools erscheint, läuft alles.
Wo es gehakt hat: die ehrliche Version
Ich erzähle das nicht, um mich schlauer zu wirken, als der Weg war. Es hat an mehreren Stellen nicht sofort funktioniert.
Problem 1: SSE statt Streamable HTTP
Mein erster Anlauf nutzte SSE (Server-Sent Events) als Transport. Das ist der ältere Standard, den viele MCP-Tutorials zeigen. Der Memory Server ist damit zwar erreichbar, aber er crasht bei der zweiten Verbindung. Die Fehlermeldung: Already connected to a transport. Call close() before connecting to a new transport.
Das Problem liegt in der Architektur: SSE erstellt bei jeder Client-Verbindung eine neue Instanz, aber der Memory Server unterstützt nur eine gleichzeitige Verbindung. Streamable HTTP löst das sauber. Der Fix war eine einzige Zeile im Dockerfile (--outputTransport streamableHttp) und die Anpassung der URL von /sse auf /mcp.
Problem 2: Globale vs. projekt-spezifische Config
claude mcp add schreibt den Server-Eintrag standardmäßig in den lokalen Kontext, also projektspezifisch in ~/.claude.json unter dem aktuellen Verzeichnis. Auf Windows landete der Eintrag deshalb in einem Projekt-Block, nicht global. Die Desktop App hat ihn dort nicht gefunden.
Fix: den Eintrag manuell mit einem Node.js-Einzeiler auf die globale Top-Level-Ebene der ~/.claude.json schreiben:
node -e "
const fs = require('fs');
const p = require('os').homedir() + '/.claude.json';
const c = JSON.parse(fs.readFileSync(p, 'utf8'));
c.mcpServers = c.mcpServers || {};
c.mcpServers.memory = { type: 'http', url: 'https://deine-domain.at/mcp' };
fs.writeFileSync(p, JSON.stringify(c, null, 2));
console.log('Done.');
"
Problem 3: Die Windows Desktop App und eine neue Session
Selbst nach dem globalen Config-Eintrag hat die Windows Desktop App den Memory Server im Code-Mode zunächst nicht gefunden. Die CLI (claude mcp list) zeigte ihn als connected, die App in der laufenden Session nicht.
Die Lösung war simpel und etwas unbefriedigend: eine komplett neue Session öffnen. Nicht nur die App neu starten, sondern ein neues Projekt-Verzeichnis in Claude Code öffnen. In der frischen Session war der Memory Server sofort verfügbar und connected.
Als Bonus habe ich den Server zusätzlich als claude.ai Connector eingetragen (claude.ai →Anpassen → Konnektoren). Das war nicht notwendig für Claude Code, bringt aber einen unerwarteten Nebeneffekt: der Memory Server ist damit auch in meinen claude.ai-Chats im Browser verfügbar. Claude kann dort denselben Knowledge Graph lesen und beschreiben. Das hatte ich nicht geplant, nehme es aber gerne mit.
Was jetzt wirklich funktioniert
Ich beobachte das in der täglichen Arbeit als KI-Berater mit EPU und KMU in Österreich: Werkzeuge, die im Alltag unsichtbar funktionieren, sind die, die sich durchsetzen. Der Memory Server ist so ein Werkzeug geworden.
Am Anfang einer Session sage ich Claude Code: „Read everything from memory and give me a summary.“ Innerhalb von Sekunden weiß Claude Code, woran wir zuletzt gearbeitet haben, welche Entscheidungen getroffen wurden, was noch offen ist. Am Ende einer produktiven Session: „Store a summary of what we built and decided today.“ Fertig.
Der Knowledge Graph, der sich über die vergangenen Wochen aufgebaut hat, enthält mittlerweile Entities zu meinen laufenden Projekten, ihren Versionen, Architekturentscheidungen, offenen Tasks, Deployment-Infos und Workflow-Konventionen. Über 14 Entities mit 22 Relations, die sich gegenseitig referenzieren. Wenn ich auf Windows an VINCI Windows arbeite und dann am Mac an VINCI Mac weitermache, weiß Claude Code auf dem Mac, was Windows zuletzt gespeichert hat.
Das klingt nach wenig. Es ist mehr als es klingt.
Das eigentliche Problem war nie, dass Claude Code nicht intelligent genug wäre. Das Problem war, dass ich ihm bei jeder Session denselben Kontext neu erklären musste. Projektname, aktueller Stand, letzte Entscheidung, welche Dateien wir letzte Woche umgebaut haben. Dieses mentale Overhead ist weg.
Was das kostet und was es bringt
Die Infrastruktur-Kosten sind marginal. Der Container braucht kaum RAM, läuft stabil auf dem kleinsten Hetzner-Cloudserver, und Coolify übernimmt SSL und Deployment ohne zusätzlichen Aufwand. Die JSON-Datei mit dem gesamten Knowledge Graph ist nach Wochen aktiver Nutzung einige Kilobyte groß.
Was es bringt, ist schwerer zu quantifizieren, aber ich versuche es trotzdem: ich spare pro Tag schätzungsweise 10 bis 20 Minuten Kontext-Briefing. Hochgerechnet auf eine Arbeitswoche sind das zwischen einer und zwei Stunden, in denen ich Claude Code nicht erkläre, wer ich bin und was ich vorhabe, sondern direkt arbeite. Für jemanden, der täglich mit Claude Code arbeitet und zwischen Rechnern wechselt, ist das keine Kleinigkeit.
Fragen zum Claude Code Memory Server
Der Server läuft hinter HTTPS. Wer die URL kennt, kann theoretisch auf den Graph zugreifen. Wer das verhindern will, aktiviert Basic Auth in Coolify oder beschränkt den Zugriff auf Tailscale. Für meinen Use Case reicht HTTPS mit einer nicht-erratbaren Subdomain.
Claude Code befüllt den Graph nur, wenn du ihn explizit darum bittest. Es gibt keine automatische Speicherung. Das ist bewusst so: du entscheidest, welche Information dauerhaft relevant ist und welche nicht.
Ja, wenn du den Server als claude.ai Connector einträgst. Dann hat auch der Chat im Browser Zugriff auf deinen Knowledge Graph. Ich habe das eingebaut, war ursprünglich nicht geplant, ist aber praktisch.
Nichts, solange das Volume korrekt gemountet ist. Die memory.json liegt auf dem Host-Server, nicht im Container. Neustarts sind non-destruktiv.