Summary

On a clean gbrain init --pglite install, gbrain apply-migrations --yes fails immediately on the v0.11.0 (GBrain Minions) schema phase because the inner gbrain init --migrate-only call performs a getaddrinfo lookup (Postgres-shaped connect path) regardless of engine. PGLite is in-process WASM with no network, so this always returns ENOTFOUND. The migration is recorded as partial; after ≥3 attempts the doctor escalates to WEDGED.

Reproduction (gbrain 0.35.1.1, macOS arm64)

TMPDIR=$(mktemp -d)
HOME="$TMPDIR" gbrain init --pglite
HOME="$TMPDIR" gbrain init --migrate-only
# → Cannot connect to database: getaddrinfo ENOTFOUND. Fix: Check your connection URL in ~/.gbrain/config.json

HOME="$TMPDIR" gbrain apply-migrations --yes
# === Applying migration v0.11.0: GBrain Minions — durable background agents ===
# Cannot connect to database: getaddrinfo ENOTFOUND. Fix: Check your connection URL in ~/.gbrain/config.json
# Phase A (schema) failed: Command failed: gbrain init --migrate-only. Aborting; re-run after fixing.
# Migration v0.11.0 reported status=failed.

~/.gbrain/config.json is the canonical fresh-install shape:

{
  "engine": "pglite",
  "database_path": "<HOME>/.gbrain/brain.pglite"
}

No DATABASE_URL or GBRAIN_*_URL env var set in shell, launchctl, or plist scopes. The engine config is unambiguous, but the migration's init code path treats it as Postgres.

Symptoms

1. gbrain doctor reports [FAIL] minions_migration: MINIONS HALF-INSTALLED (partial migration: 0.11.0).
2. gbrain doctor also reports [WARN] connection: Could not connect to configured DB (URL from env:DATABASE_URL) — this message is misleading: no such env var is set. The WARN is generated by the same broken connect path attributing failure to a phantom env var.
3. Each apply-migrations --yes attempt appends a partial row to ~/.gbrain/migrations/completed.jsonl and increments the wedge counter; after 3 the doctor reports WEDGED MIGRATION(s): 0.11.0 (>=3 consecutive partials).
4. --force-retry 0.11.0 only resets the wedge marker; the underlying connect path is unchanged so retry fails identically.

Operational impact

All gbrain functionality on the pre-0.11.0 schema continues to work (MCP get_page, put_page, query, etc. verified). Features introduced in 0.11.0–0.32.2 (Minions, Knowledge Graph auto-extract on writes, hot memory, multi-source, salience, etc.) are gated behind the wedged migration. Read/write through the MCP API is unaffected.

Suspected fix shape

The gbrain init --migrate-only code path should branch on engine === 'pglite' and skip the network connect entirely (or invoke the PGLite migration replay path that already exists for thin-client scenarios — strings of the binary shows a // PGLite migration replay on thin-client installs comment referencing the corresponding code site).

Environment

• gbrain 0.35.1.1 (auto-upgraded today from 0.33.1.1)
• macOS arm64, bun runtime
• Engine: PGLite (default for fresh gbrain init --pglite)
• No prior brain content required to reproduce

Related (browsed during triage)

Several open issues touch the broader pglite-migration class (#699, #1018, #1040, #1054, #974), but none I found describe this specific failure: clean install + v0.11.0 Minions + getaddrinfo ENOTFOUND on gbrain init --migrate-only. Happy to consolidate if this is a duplicate.