claude-mem sync-hub
Live sinds 29 juli 2026. Alle drie de Macs delen hun claude-mem-geheugen via een eigen hub op vakwark.ai. Geen cmem.ai, geen abonnement, geen derde partij die het geheugen vasthoudt.
Lokaal-first blijft het uitgangspunt: elke machine houdt zijn eigen volledige SQLite en zoekt daarin. De hub deelt alleen nieuwe wijzigingen. Valt de hub weg, dan werkt elke machine gewoon door.
Waarom
Vóór 29 juli liep het geheugen op drie plekken uit elkaar. De M4 en de Mini kenden het werk tot 23 juli; op de M5 stonden 3.507 observaties die zij misten, verspreid over álle lopende projecten. Een ontbrekende herinnering meldt zich niet: je krijgt een antwoord dat net iets minder goed is en merkt nooit waarom.
Handmatig gelijktrekken werkte, maar alleen als je eraan dacht. Dat gat groeide stil.
De vier onderdelen
| Worker | Hostnaam | Rol |
|---|---|---|
sync-hub |
sync.vakwark.ai | het geordende op-logboek per gebruiker (Durable Object + SQLite). Gevendorde upstream-code, alleen de config is eigen |
cmem-sync-verify |
sync-verify.vakwark.ai | token naar gebruiker. Eigen code, geen database. Zonder deze Worker laat de hub niemand binnen |
cmem-sync-projector |
sync-projector.vakwark.ai | valideert elke pagina (hash, volgnummers, protocol) en slaat bewust niets op. Geen tweede kopie van het geheugen in de cloud |
cmem-sync-alerts |
sync-alerts.vakwark.ai | vertaalt het Discord-webhookformaat van de hub naar Telegram (SpotBot) |
Alle vier staan op workers_dev:false en preview_urls:false: uitsluitend bereikbaar via
de eigen hostnaam.
- KV-namespace
AUTH_CACHE:43415db2562945929aed402822e2a7c3 - Durable Object namespace
SyncHub:d4e14e8862ad4f52829e76750a25400d(het account heeft er drie; de andere twee horen bijmarketing-doctor) - Crons op de hub:
*/5 * * * *control-plane-probe op verify,7 * * * *kostenwatchdog
De drie machines
| Machine | worker-poort | rol |
|---|---|---|
| M5 | 37703 | hoofdmachine, leidende database |
| M4 | 37777 | |
| Mac mini | 37701 |
De worker-poort is uid-afgeleid (37700 + uid % 100) en dus per machine anders.
Nooit hardcoden, altijd uit ~/.claude-mem/settings.json lezen.
Aanzetten is drie sleutels in dat bestand plus een herstart van de worker:
CLAUDE_MEM_CLOUD_SYNC_HUB_URL, CLAUDE_MEM_CLOUD_SYNC_USER_ID,
CLAUDE_MEM_CLOUD_SYNC_TOKEN. Uitzetten is dezelfde drie leegmaken en herstarten; de
data stond en staat altijd al lokaal. Dat is meteen de complete uitweg.
Worker herstarten op afstand
De worker draait op bun, niet op node (bun:sqlite), en staat niet op de PATH in een
niet-interactieve ssh-sessie:
ssh m4 'pkill -f "worker-service"; sleep 1; export PATH="$HOME/.bun/bin:/opt/homebrew/bin:$PATH"; cd ~; nohup bun ~/.claude/plugins/marketplaces/thedotmack/plugin/scripts/worker-service.cjs > ~/.claude-mem/logs/worker-manual.log 2>&1 &'
Op de M5 staat het script onder ~/.claude/plugins/cache/thedotmack/claude-mem/13.12.4/scripts/.
Bewaking
Elke vijf minuten slaat de hub zijn eigen portier aan met een expres ongeldig token. Komt daar geen 401 of 403 met een JSON-antwoord uit, dan is dat een storing en gaat er een bericht naar Telegram. Dit vangt de stille uitval: een portier die er nog lijkt te staan maar niemand meer binnenlaat.
Elk uur vraagt de kostenwatchdog aan Cloudflare hoeveel de hub verbruikt heeft. Boven de eerste drempel volgt een bericht, boven de tweede trekt hij zelf de noodrem (weigert websockets, waardoor de opslag niet wakker blijft; versturen en ophalen blijven werken).
Drempels, getoetst aan de echte meting van het piekuur op 29 juli (1.296 verzoeken, 4,16 GB-s, 5.219.405 gelezen regels, 72.746 geschreven regels):
| Meting | Waarschuwing | Noodrem |
|---|---|---|
| Verzoeken per uur | 10.000 | 100.000 |
| Rekentijd (GB-s) | 25 | 450 |
| Geschreven regels per uur | 200.000 | 1.000.000 |
| Gelezen regels per uur | 20.000.000 | 100.000.000 |
Het token hiervoor (sync-hub-watchdog-analytics-read) mag uitsluitend
Account Analytics Read. Bewust niet het full-access deploy-token: dat hoort niet als
secret in een Worker die vanaf internet bereikbaar is.
Aandachtspunten
- Een machine synct alleen als de worker draait. En de worker draait als je op die machine met Claude Code werkt; de plugin start hem via een hook. Handmatig starten overleeft geen slaapstand of afgesloten sessie (op 30-07 lag de worker op de mini er daardoor weer uit). Dit verklaart ook wat we op 29-07 zagen: M4 en mini stonden na uren stilstand nog op wijziging 2 terwijl de hub op 11.690 stond, en liepen binnen seconden bij zodra er lokaal iets gebeurde. In de praktijk is dat prima: je krijgt de data precies wanneer je de machine gebruikt. Wil je dat een machine óók bijwerkt terwijl je er niet op werkt, dan is een launchd-agent nodig. Bewust niet gedaan: de plugin beheert de worker-levenscyclus zelf en een tweede starter geeft dubbele workers (dat gaf eerder zombie-processen).
- 92 rijen in quarantaine op de M5: oude rijen uit januari en februari met een leeg
project-veld. De controleur weigert ze in plaats van rommel door te laten. Geen datagat: die inhoud staat al op de andere machines. - De hub kijkt alleen vooruit. Historie van vóór de migratie van 28 juli reist er nooit doorheen. De eenmalige gelijktrekking is op 29 juli gedaan.
- Dit is geen backup. Verwijder je lokaal iets, dan reist dat mee. Het backupscript blijft het vangnet.
- Versie-lockstep: bij elke claude-mem-update die sync raakt moet de hub opnieuw gevendord en gedeployed worden, anders valt sync stil (luid, met een 503).
Bronnen
- Code, runbook en volledige procedures:
~/Documents/claude-mem/self-hosted-sync/ - Plan en besluiten:
~/Documents/claude-mem/plan/ - Secrets: Vaultwarden, map Noaber.ai, item "claude-mem self-hosted sync — secrets"