Hé Jamal, goedendag! Hier Conductor met een korte update over die gBrain-migratie van gisteravond, 30 juli. Even helder samenvatten wat er precies aan de hand was, hoe we het hebben opgelost, en hoe de status nu is. Geen zorgen, alles draait weer als een zonnetje.
Stel je voor, al onze bots – Sjakie, Paco, Coco, Lenovo, en ikzelf – delen één groot, gezamenlijk geheugen: gBrain. Dat geheugen woonde tot voor kort in een soort digitale opslagkast genaamd PGLite, en die stond op de MacBook. Nu is het zo dat de nieuwste versie van macOS, Tahoe, niet zo vriendelijk was voor PGLite. Het geheugen begon instabiel te worden en crashte zelfs. De oplossing? Verhuizen! We hebben gBrain daarom overgezet naar een veel stevigere opslagkast, PostgreSQL, en die draait nu lekker stabiel op de Mac Mini, die altijd aanstaat. Dat is een flinke upgrade voor de stabiliteit.
Tijdens die verhuizing kwamen we twee hobbels tegen. Ten eerste, toen we alle 'geheugen-bladzijdes' – dat zijn er zo'n 758 – wilden overzetten, bleken 46 daarvan een verkeerd label te hebben. Ze werden overgeslagen. Maar geen paniek, we hebben die labels handmatig hersteld door de bestanden terug te zetten naar hun originele namen, en alles is alsnog succesvol overgezet, honderd procent compleet.
De tweede hobbel was iets specifieker: nadat het geheugen succesvol was verhuisd, bleken alle 'sleutelkaarten' – de inlogtokens die de bots gebruiken om bij gBrain te komen – niet meer te werken. Die stonden namelijk apart opgeslagen in de oude database en waren niet automatisch meegekomen met de pagina's. Dit betekende dat, hoewel het brein zelf intact was, de bots er niet meer bij konden. Maar ook dat hebben we opgelost: voor elke bot, inclusief Sjakie, Paco, Coco, Lenovo en mijzelf, hebben we een gloednieuwe sleutelkaart aangemaakt en veilig geïnstalleerd. Alle bots hebben weer toegang en draaien naar behoren.
Jij hebt hier trouwens ook een belangrijke rol in gespeeld, Jamal! Je hebt me geholpen met cruciale sudo-commando's om de firewall op de Mac Mini te fixen, en je hebt bij elke risicovolle stap toestemming gegeven voor de import en omzetting. Ook heb je de Lenovo-pc thuis aangezet toen die nodig was. Super bedankt daarvoor! Om je gerust te stellen: de inhoud van de 758 pagina's zelf is nooit aangeraakt. Alleen de 'opslagplaats' is veranderd. Ook andere machines of bots die gBrain niet gebruiken zijn met rust gelaten.
Dus, de kern is: gBrain is veilig en stabiel verhuisd naar een robuustere omgeving op de Mac Mini. Alle bots hebben weer volledige toegang en functioneren zoals ze moeten. Er zijn nog een paar kleine puntjes voor de toekomst – zoals een kleine bug in het exportscript die we een keer structureel moeten oplossen en wat andere losse eindjes die geen directe relatie hebben met deze migratie – maar de gBrain-migratie zelf is een feit en succesvol afgerond. Mocht je vragen hebben, dan hoor ik het graag. Voor nu: een fijne dag!
titel: gBrain-migratie 30 juli 2026 — wat er kapot was en hoe het is opgelost
datum: 2026-07-30
Wie deed dit werk: twee sessies op Jamals Mac, na elkaar. Eerst een verkennende sessie van 16:43-17:04 (vermoedelijk met Ludo Baauw), die het probleem correct diagnosticeerde maar zelf stopte toen ze een parallelle sessie ontdekte. Daarna heeft Conductor (deze sessie, vanaf 19:45) de daadwerkelijke migratie afgerond.
Tijdvenster: verkenning 16:43-17:04, uitvoering circa 19:45 tot 22:33 vanavond.
Alle bots (Sjakie, Paco, Coco, Lenovo, Conductor) delen één gezamenlijk geheugen: gBrain. Dat geheugen stond in een opslagvorm (PGLite) op de MacBook, die niet meer stabiel werkte op de nieuwste macOS-versie (Tahoe/26.x). We hebben het geheugen daarom overgezet naar een steviger opslagvorm (PostgreSQL) op de Mac Mini, die altijd aanstaat.
Onderweg gingen twee dingen niet in één keer goed: 46 van de 758 geheugen-bladzijdes hadden een verkeerd bestandslabel en werden overgeslagen, en na het omzetten bleken alle "sleutelkaarten" (inlogtokens) van de bots niet meer te werken omdat die apart in de oude database stonden en niet automatisch meekwamen. Beide zijn hersteld.
Recept voor de volgende keer dit gebeurt: "gBrain crasht op PGLite door een macOS-update → migreer naar Postgres op een altijd-aan machine, volgens de officiële troubleshooting-stappen in gBrain's eigen docs/INSTALL.md."
Een aparte Claude Code-sessie op Jamals Mac onderzocht hetzelfde probleem, met deze vragen (letterlijk):
1. (16:43) "Wat is de combinatie tussen gBrain en Supabase, draait dit lokaal of remote? Staat Mnemosyne lokaal of remote?"
2. (16:47) "Check via Tailscale naar de Mac Mini"
3. (16:51) "gBrain beter via Postgres op Supabase?"
4. (16:52) "Ja"
5. (16:56) "Doe eerst de proef, alleen stap 1-3 op de Mac Mini"
Bevindingen (correct): gBrain draaide lokaal op de MacBook via PGLite — dat was het probleem. Mnemosyne draaide al gezond op de Mac Mini via Tailscale. Advies: gBrain net als Mnemosyne naar de Mac Mini verhuizen, niet naar Supabase (bewust afgewezen bij de eerste uitrol op 3-7-2026).
Aanpak (onvolledig): gbrain correct geïnstalleerd op de Mac Mini (juiste bron: github.com/garrytan/gbrain, niet het gelijknamige npm-package), versies gematcht, en het PGLite-databasebestand (186MB) via rsync gekopieerd — zonder de opslag-engine zelf te vervangen. Deze aanpak had de macOS/PGLite-crash niet blijvend opgelost, want die zit in de software, niet in de bestandslocatie.
Waarom deze sessie stopte: ze merkte zelf op dat er een tweede sessie tegelijk aan hetzelfde onderwerp werkte (herkenbaar aan bot-taal als "ik heb Sjakie en Coco's .claude.json bekeken"), met een ander, grondiger plan (echte Postgres-migratie). Om niet dwars door dat werk heen te bouwen, stopte de sessie zichzelf op 17:04 en gaf de ruimte aan de aanpak hieronder.
De lokale gBrain-CLI op de MacBook startte niet meer. Root cause: een bekende PGLite/WASM-crash op macOS 26.3+ (Tahoe), gedocumenteerd in gBrain's eigen docs/INSTALL.md als tijdelijke bug, met een officiële workaround: overstappen naar native PostgreSQL.
Alle 758 pagina's van het levende brein zijn geëxporteerd als platte markdown-bestanden (via de nog draaiende HTTP-server, met paginering omdat de server maximaal 100 resultaten per aanvraag teruggeeft).
PostgreSQL + pgvector geïnstalleerd op de Mac Mini (100.85.165.3), bereikbaar alleen via het besloten Tailscale-netwerk (niet het publieke internet). Een macOS-firewallregel blokkeerde eerst het echte dataverkeer (de verbinding léék te werken maar leverde niks op) — dat is met Jamals hulp (sudo op zijn eigen machine) gefixt.
Import afgebroken na 270 van de 758 bestanden door een tijdslimiet. Geen dataverlies: elke pagina wordt los weggeschreven, dus de eerste 266 stonden al veilig (4 werden om een goede reden overgeslagen).
Import hervat voor de resterende bestanden. Kwam uit op 712 van de 758 — 46 bestanden werden overgeslagen met de melding "frontmatter-slug komt niet overeen met bestandsnaam".
Oorzaak: het exportscript had bestandsnamen "platgeslagen" (/ vervangen door _, bijvoorbeeld agents/kimi → agents_kimi.md), maar de originele slug in de bestandsinhoud bleef ongewijzigd staan. Daardoor kwamen bestandsnaam en inhoud niet meer overeen.
De 46 bestanden zijn teruggezet in hun juiste mapstructuur (bijvoorbeeld agents_kimi.md → agents/kimi.md), zodat ze weer hun originele identiteit hadden. Daarna opnieuw geïmporteerd: 758 van de 758 pagina's, 100% embeddings, 0 missend.
Tijdens het testen is een wachtwoord voor de nieuwe database per ongeluk zichtbaar geworden in eigen tooluitvoer (een bug in een maskeer-poging, geen inbraak). Dat wachtwoord is direct gerouleerd naar een nieuwe, willekeurige waarde — veilig opgeslagen in de macOS-sleutelhanger (Keychain), nergens in platte tekst bewaard. De oude waarde is daarna waardeloos.
Het configuratiebestand van de live gBrain-server (~/.gbrain/config.json) is aangepast van PGLite naar Postgres, met een backup van de oude versie. De server (nl.haarvisie.gbrain-http) is herstart en bevestigd bevonden op Postgres, met 758 pagina's, 100% embeddings — getest via de echte gezondheidscontrole van de server, niet alleen aangenomen.
Na de omzetting bleek dat elke bot een eigen inlogtoken had om bij gBrain te komen — en die tokens stonden zelf óók in de (oude) database, dus zijn ze niet meegekomen bij het overzetten van alleen de pagina's. Gevolg: alle bots (inclusief Conductor zelf) waren de toegang kwijt, ook al was de data zelf intact.
Voor elke bot is een nieuw token aangemaakt en veilig weggezet — via SSH naar Mac-machines (Sjakie, Coco) en via SSH + PowerShell naar Windows-machines (Paco, Lenovo). Elk token is apart getest tegen de live server, niet alleen aangenomen dat het zou werken.
| Bot | Machine | Status |
|---|---|---|
| Conductor | MacBook | ✅ nieuw token, getest |
| Sjakie | Mac Mini (sjakie-woonkamer) | ✅ nieuw token, getest |
| Paco | Windows Spanje (paco-spanje) | ✅ nieuw token, getest |
| Coco | Mac Mini (coco-veranda) | ✅ nieuw token, getest |
| Lenovo | Windows thuis | ✅ nieuw token, getest (stond eerst uit, later opnieuw aangezet door Jamal) |
| Kimi | Windows Spanje (paco-spanje, zelfde machine als Paco) | ✅ nieuw token, getest — pas later ontdekt (eerst per abuis gezegd dat Kimi geen koppeling had) |
gbrain-export.py (die / vervangt door _ zonder de frontmatter mee te passen) kan bij een volgende export weer dezelfde 46 fout opleveren. Niet urgent, wel een keer oppakken.aiforjamal (een Linux/AWS-machine op Tailscale, 100.119.195.32) — onbekend bij mij, Jamal navragen wat dit is.claude doctor — de auto-update-melding die al een tijd op het scherm stond, bewust uitgesteld tot na deze migratie. Nu aan de beurt.gbrain doctor --json → "Connected, 758 pages", "100% coverage, 0 missing", schema-versie 122 (nieuwste){"status":"ok","engine":"postgres"}