feat: self-contained API keys (read from gbrain's own config, not just env)

[vinsew]

Summary

Today src/core/embedding.ts and src/core/search/expansion.ts call new OpenAI() / new Anthropic() with no arguments, which makes the SDKs read OPENAI_API_KEY / ANTHROPIC_API_KEY from the process's env. That puts the burden on every caller — shells, cron jobs, agent subprocess tools, daemons, containers — to propagate those env vars correctly.

When a caller's subprocess env doesn't have them (common for launchd-spawned daemons, agent terminal tools with env sanitization, or any subprocess without explicit env forwarding), the caller silently gets empty results from gbrain query / gbrain embed because the SDK falls back to anonymous API calls that fail with 401 (then throw, then get caught by gbrain's retry/fallback logic, then return "No results").

The debugging experience is painful: the user sees "No results" in their agent's output, assumes the brain is empty, doesn't realize the subprocess env is missing keys. I hit this personally running gbrain query from a launchd-managed agent's terminal tool — the .zshrc-sourced keys were in my interactive shell but not in the daemon's env, and there's no surface-level error telling you that.

The existing schema is almost there — just unconnected

GBrainConfig (src/core/config.ts:10-16) already defines openai_api_key and anthropic_api_key fields, and saveConfig() writes them to ~/.gbrain/config.json with 0600 perms. But none of the runtime code actually reads those fields — the config is populated but never consulted. This PR just connects the wiring.

Also fixed: loadConfig() was silently dropping ANTHROPIC_API_KEY from the env merge (only OPENAI_API_KEY was being merged on line 43). Minor but present bug.

Fix

Three small changes:

1. config.ts: merge ANTHROPIC_API_KEY env var into loaded config alongside OPENAI_API_KEY (was silently dropped).

2. embedding.ts: read openai_api_key from loadConfig() and pass to new OpenAI({ apiKey }). Falls back to new OpenAI() (SDK env-default) when config has no key — preserves current behavior for users who rely on env vars.

3. expansion.ts: same pattern for Anthropic.

Precedence preserved from existing code: env var > config file (because loadConfig() merges env over file). Users who want to override per-process still can.

Usage for callers (new capability)

One-time setup:

# Edit gbrain's own config file
$ vim ~/.gbrain/config.json
# or via a helper (could add \`gbrain config set openai_api_key sk-...\` in follow-up PR)

Then from any caller — no env vars needed:

gbrain query \"...\"      # just works
gbrain embed --stale    # just works

Especially valuable for:

• Cron jobs under launchd/systemd (don't inherit shell env)
• Agent terminal tools with env sanitization (e.g. sandbox policies)
• Subprocess calls from Python/Node agents that don't forward env
• Docker containers without -e OPENAI_API_KEY passthrough

Impact

• 4 files changed, +82 / -3 lines
• Zero behavior change for users who already have env vars set
• New capability: callers without env vars in their subprocess context now work if keys are in ~/.gbrain/config.json
• Config file storage is 0600-permissioned (already done by saveConfig)

Test plan

• 4 new tests in test/config.test.ts:
  • OPENAI_API_KEY env merges into config
  • ANTHROPIC_API_KEY env merges into config (regression — was missing)
  • Both together
  • Both absent when neither source provides them
• All 12 config tests pass (8 existing + 4 new)
• Full bun test suite: no new regressions (the 4 pre-existing PGLiteEngine failures are unrelated and exist on master)

Context

Fourth in a series of PRs from real-user setup on a Chinese-speaking deployment: #114 (chunker CJK), #115 (slugify CJK), #119 (sync CJK via core.quotepath), and now this one (key portability). Each addresses a distinct anti-pattern surfaced by running gbrain outside the "English-speaker, interactive-shell, env-vars-in-.zshrc" default assumption.

This PR is the only one that's a feature, not a bug fix — but it makes gbrain meaningfully more embeddable as the knowledge backbone for cron-driven agents and daemons, which is the direction the SKILLPACK itself advocates.

[Qodo-Free-For-OSS]

Hi, embedding.ts/expansion.ts now depend on loadConfig() to supply API keys, but loadConfig() always reads ~/.gbrain/config.json via os.homedir() and ignores the GBRAIN_HOME override used elsewhere. In environments that set GBRAIN_HOME (tests, Docker, multi-tenant), config-file keys won’t be found and SDKs will be instantiated without apiKey.

Severity: action required | Category: correctness

How to fix: Make loadConfig honor GBRAIN_HOME

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

loadConfig() ignores process.env.GBRAIN_HOME even though configDir()/configPath() support it. New code paths (embedding/query expansion/hybrid gating) now rely on loadConfig() for API keys, so keys stored under GBRAIN_HOME won’t be discovered.

Issue Context

• configDir()/configPath() support GBRAIN_HOME, but loadConfig() uses getConfigPath() which calls homedir() directly.
• This breaks sandboxing and makes tests read from the real user home.

Fix Focus Areas

• src/core/config.ts[22-25]
• src/core/config.ts[45-50]
• src/core/config.ts[90-100]

Suggested approach

• Remove getConfigDir/getConfigPath duplication and have loadConfig() + saveConfig() read/write via configPath().
• Or update getConfigDir() to honor GBRAIN_HOME the same way configDir() does, and then use that consistently.

We noticed a couple of other issues in this PR as well - happy to share if helpful.

---

Qodo code review - free for open-source.

[vinsew]

Closing — work absorbed into v0.32.0 (#810) via the new Recipe.resolveAuth abstraction, which is a much cleaner solution than my 3-spot wiring patch. Thanks for the pickup, @garrytan!