Hey — sharing a related use case from a downstream user running gbrain as a multi-agent shared brain via Zeabur, in case it helps future readers.

Same bug class, different transport. We hit the silent default-to-default symptom on a multi-source brain (canonical source nikke-memory, federated setup) but for the stdio MCP transport rather than HTTP bearer. Our v0.42.8.0 src/mcp/server.ts:42 already reads process.env.GBRAIN_SOURCE, so the stdio side is technically covered — the underlying issue for us was that the env var was simply not being set in the subprocess at all (openab spawns agents with inherit_env = [], and the [mcp_servers.gbrain].environment block in our ~/.grok/config.toml wasn't being honored by the Grok MCP client). Same blind-spot shape, different layer.

3-layer defense that worked for us (all on the calling side, no gbrain patch needed):

1. Wrapper that hard-codes the env — /home/agent/bin/gbrain:

   #!/bin/sh
   export HOME=/home/agent
   export PATH="/home/agent/.bun/bin:$PATH"
   : "${GBRAIN_SOURCE:=nikke-memory}"
   export GBRAIN_SOURCE
   exec /home/agent/.bun/bin/gbrain "$@"

   POSIX default-substitution := means even a clean parent env (env -i) gets the right value. Defense in depth: doesn't rely on the MCP client correctly threading [mcp_servers.gbrain].environment to subprocess.

2. Grok config.toml explicit env block — ~/.grok/config.toml:

   [mcp_servers.gbrain]
   command = "/home/agent/bin/gbrain"
   args = ["serve"]
   enabled = true
   
   [mcp_servers.gbrain.environment]
   GBRAIN_SOURCE = "nikke-memory"

3. ~/.gbrain-source = nikke-memory dotfile — CLI fallback for sanity, since the MCP stdio transport in our version (v0.42.8.0 src/mcp/server.ts:42) does NOT consult the dotfile the way the CLI 6-tier core/source-resolver.ts does. This is the only real gap on the stdio side, and it's the analog of your fix: legacy bearer tokens respect GBRAIN_SOURCE env for sourceId #1648 fix for the stdio path. A 2-line patch calling resolveSourceId(engine, explicit=null, cwd=process.cwd()) from server.ts:42 would close it; we'd love a follow-up for it.

End-to-end verification (the gold-standard proof for routing): the real Grok MCP call returned an error whose body contained the string (source=nikke-memory) — printed by src/core/operations.ts:549 from ctx.sourceId, which mcp/server.ts:42 set from process.env.GBRAIN_SOURCE. The error message itself is the proof that the env plumbing through the entire Grok → openab → wrapper → gbrain chain is correct.

Two adjacent observations for v0.42.8.0 (independent of your PR, FYI):

1. The new content-sanity gate (v0.42.8.0 src/core/import-file.ts:469 assessContentSanity) hard-blocks minimal test slugs (e.g. ops/test/...) and surfaces as Page not found: <slug> (source=...) from _upsertChunksOnce (the page INSERT never durably commits, so the chunk SELECT returns 0 rows). Both CLI and MCP fail identically. It looks like a routing bug at first glance but isn't — the actual cause is the gate. Surfacing the gate verdict explicitly (e.g. ContentSanityBlocked with the assessContentSanity reason) would save a lot of debug time for downstream users.

2. Your second commit (feat(put_page): add GBRAIN_TRUSTED_REMOTE env override for auto_link/auto_timeline) is directly relevant for our case. We have a single-user trusted deployment behind Zeabur internal DNS; every MCP call is internal, so the security-skip on auto_link/auto_timeline is pure cost for us. Will pick up the opt-in once the PR lands.

Reference: I documented our full 3-layer pattern in ops/diagnostics/sakura-gbrain-mcp-source-routing-hardening-2026-06-03 (will be ingested into our gbrain via the team sync worker). Cross-linking to PR #1648 from there.

Thanks for the fix — looking forward to it landing.