HUXBERRY

Infrastructure Review

G-Brain Installation Review

A review of the gbrain knowledge-brain deployment, how it's being used, how to wire it into your AI tools, and how (and whether) it ingests email, CRM, and NetSuite.

Prepared for Nish Faria Date 1 June 2026 System gbrain v0.41.26.0 @ brain.huxapps.com Status Built & healthy · underused

Executive summary

The brain is built and healthy — but almost nothing reads from it

Your skills bypass gbrain entirely. The /query, /ingest, and /lint skills read raw markdown files from the Obsidian vault. They never call the brain's semantic search.
Your Mac clients aren't wired. Codex points at a wrapper script that does not exist, and Claude Code's gbrain MCP is unauthenticated — only the authenticate tool is exposed.
It ingests exactly one thing: your wikis. There is no live email, CRM, or NetSuite ingestion — and gbrain ships no NetSuite or Odoo connector at all.

Net effect: you built a brain, then kept reading the filing cabinet. The retrieval-quality win (hybrid keyword + vector + knowledge-graph) is sitting unused on your interactive tools. Everything below is fixable; none of it is broken architecture.

01 — Installation

What's deployed, and how healthy it is

gbrain v0.41.26.0 runs in Docker on vps2 (Hetzner) as gbrain-http + gbrain-postgres (pgvector), fronted by brain.huxapps.com through a Cloudflare Tunnel. The /admin path sits behind Cloudflare Access + Google SSO; /mcp behind OAuth 2.1. Its internal enrichment LLM runs through a loopback Codex bridge (your ChatGPT subscription), so marginal cost is roughly $1–5/month (embeddings only).

Locked architectural principle

The wikis are the system of record; gbrain is a search projection, never the source of truth. Everything flows wikis → git → brain, never the reverse. Keep this in mind for every recommendation below.

Live health (queried on vps2, 1 June 2026)

413

Real wiki pages

822

Embeddings

221

KG links

Integrations configured

Total page count is 775 — that includes 362 pages in the inert legacy default corpus (pre-v0.17, never synced, harmless). The 413 figure is the real, searchable wiki content across 9 sources.

Sources

Source	Pages	Last sync
products	196	2026-05-28
company-context	95	2026-05-29
vps-architecture	40	2026-05-31
odoo-implementation	22	2026-05-28
systems-handbook	18	2026-05-31
lead-gen	17	2026-05-28
training	10	2026-05-28
assets	9	2026-05-28
suppliers	6	2026-05-28	low — expected ~75
default (legacy)	362	never	inert

Red flags worth your attention

Things to verify or fix

suppliers shows 6 pages — your design doc expected ~75; company-context is 95 vs ~156. Worth confirming those repos synced fully (could be a restructure, could be a partial sync).
Sync recency: only the 3 wikis edited since install show timestamps after 2026-05-28. Consistent with incremental sync skipping unchanged repos — but combined with the suppliers number, confirm the hourly wikis-sync → gbrain sync timer is firing.
Codex wrapper missing: ~/.local/bin/gbrain-mcp-nish-admin doesn't exist, yet ~/.codex/config.toml references it → Codex's gbrain MCP is dead.
Claude Code unauthenticated: the global gbrain HTTP MCP needs a one-time browser OAuth (/mcp → gbrain → authenticate).

02 — Usage

How it's been used (and why "30 days" doesn't apply yet)

The brain was installed 2026-05-28 — four days ago, so there's no 30-day history. In its first few days:

Ingestion works. 413 wiki pages, 822 embeddings; systems-handbook was added 5-29 and re-synced 5-31. The intake side is healthy.
The only real consumer is Hermes on vps2 (local stdio MCP, "brain-first" instruction) — but Hermes' Claude calls were 401-broken for much of this window from repeated OAuth-token deaths, so even that usage is shaky. The autopilot enrichment loop runs in the background.
From your Mac: effectively zero. Claude Code MCP unauthenticated, Codex wrapper missing, no gbrain calls in shell history, and the wiki skills don't call it.

Bottom line: the brain is populated but barely queried. The semantic-retrieval advantage hasn't reached your day-to-day AI tools because the plumbing and the skills both point elsewhere.

03 — Making your AI use it

How to point Claude & Codex at gbrain

Two layers: fix the plumbing, then retarget the skills.

Layer A — wire the clients (one-time)

Codex CLI: recreate ~/.local/bin/gbrain-mcp-nish-admin — a wrapper that exports GBRAIN_REMOTE_CLIENT_SECRET (your config stores it as a __USE_ENV_…__ placeholder, pulled from 1Password / Agent Vault) and runs gbrain serve --mcp-only. The missing wrapper is the entire reason Codex's brain access is dead.
Claude Code (Mac): run /mcp → gbrain → authenticate and complete the browser login once. Then mcp__gbrain__query / search light up.

Layer B — retarget the skills

Today wiki-query/SKILL.md Step 1 literally says "Read the wiki's wiki/index.md … Read those pages." Change it to query the brain first, fall back to files:

New Step 1

Call mcp__gbrain__query with source_id: "__all__" for cross-wiki questions, or source_id: "<wiki>" when the wiki is known. Use the returned pages + citations. Only fall back to reading wiki/index.md and grepping files if the brain is unreachable or returns nothing.

The __all__ scoping convention is already documented in Wikis/CLAUDE.md — the skills just don't follow it. Keep /ingest and /lint as file-authoring (wikis stay the source of truth); after an ingest, the brain picks it up on the hourly sync, or you can trigger it immediately with gbrain remote ping. A one-line steer in CLAUDE.md — "For company knowledge, query gbrain (semantic) rather than grepping the vault" — locks the habit in.

04 — Auto-ingestion

Email, CRM & NetSuite: what actually flows in

Today, the brain's only live intake is the wiki Git repos, pulled hourly and synced into Postgres. Nothing else flows in automatically.

The indirect path that already exists

Your Hermes agents (huxberrypm Gmail intake, Meet ingestion, nhc scrapers, assetops) write markdown into a wiki's raw/inbox/, which becomes brain content on the next sync. So email and meeting data reach the brain only if a Hermes job or you ingest it into a wiki first. This keeps the "wikis = source of truth" principle intact.

gbrain's native "senses" (available, none enabled)

gbrain ships installable ingest recipes — markdown files with a deterministic collector + agent enrichment. The catalog is consumer-oriented:

Sense	Source	Status
email-to-brain	Gmail (via ClawVisor gateway or Google OAuth)	available · not set up
calendar-to-brain	Google Calendar	available · not set up
meeting-sync	Circleback transcripts	available · not set up
x-to-brain	Twitter / X	available · not set up
NetSuite / Odoo (CRM)	—	no native sense exists

Your two options for CRM & NetSuite

A — Route through Hermes → wiki (matches your locked architecture): a Hermes job queries Odoo / NetSuite, writes markdown to a wiki inbox, sync ingests it.
B — Author a custom sense recipe (odoo-to-brain / netsuite-to-brain): same pattern as email-to-brain — a collector (Odoo XML-RPC / NetSuite SuiteQL) → digest → agent enrichment, validated with gbrain integrations test <file>. This is a build, not a toggle.

Recommended next steps

What to action, in order

Fix the Mac clients — recreate the Codex wrapper and complete the Claude Code gbrain auth, so both tools can actually query the brain.
Retarget the wiki skills — edit /query (and adjust /ingest, /lint) to call gbrain with __all__ scoping first, fall back to files. Reversible.
Check sync health — investigate the suppliers / company-context page-count gaps and confirm the hourly sync timer on vps2 is firing.
Plan email / CRM / NetSuite ingestion — decide between enabling native senses and/or building a custom odoo-to-brain / netsuite-to-brain recipe vs. the Hermes→wiki route, before building anything.