providers command bypasses canonical gateway config

[zsimovanforgeops]

Summary

gbrain providers builds gateway configuration separately from the rest of the CLI instead of using buildGatewayConfig(). On v0.42.58.0 this means provider diagnostics can ignore file-plane API keys and can behave differently from the real configured gateway path. The explicit providers test --model override also drops configured provider base URLs.

This is especially visible when a launcher injects an empty provider environment variable: buildGatewayConfig() correctly filters the empty value and preserves the configured key, while the providers command does not use that ownership seam.

Affected version

• v0.42.58.0
• commit a25209bbb2bacf1b88e06fd5282b27f1bf4a3e7a

Reproduction

1. Put a valid Anthropic key and native base URL in the GBrain config plane.
2. Run from an environment where ANTHROPIC_API_KEY is unset or injected as an empty string.
3. Run:

gbrain providers test --touchpoint chat --model anthropic:claude-sonnet-4-6

src/commands/providers.ts currently constructs gateway config manually:

• configureFromEnv() copies model/base URL fields plus raw process.env, but does not map file-plane API keys.
• The --model test override passes only the model/dimensions plus raw process.env, dropping the configured key and configured base URL.

The result can disagree with the real CLI path that uses buildGatewayConfig().

Expected behavior

Provider listing/testing should use the same gateway configuration ownership seam as normal CLI execution. providers test --model should override only the requested model and embedding dimensions; credentials, base URLs, fallback config, and empty-env handling should continue to come from buildGatewayConfig().

Proposed fix

• Route configureFromEnv() through buildGatewayConfig(loadConfig() ?? { engine: 'pglite' }) so the command still works before gbrain init.
• Add a pure buildProviderTestGatewayConfig() helper that starts from the canonical config and changes only the tested model/dimensions.
• Add a regression test using the repository's withEnv() helper to prove an empty ANTHROPIC_API_KEY does not clobber the configured key and that configured base URLs survive the override.

Verification

On a clean branch based directly on v0.42.58.0:

bun test test/providers.test.ts test/ai/build-gateway-config.test.ts
21 pass, 0 fail

The repository verification suite is 30/31 on the untouched baseline and on the patch. The one pre-existing failure is unrelated: test/e2e/openclaw-plugin-load-real.test.ts:281 resolves an undeclared parent openclaw/plugin-sdk type that lacks registerContextEngine.

An apply-ready two-file patch/commit is available.

[alexputici]

Corroborating, and adding the CLI-boot half of the same seam (v0.42.57; verified unchanged at v0.42.58.0 / a25209b — the #1249 empty-string fix touched buildGatewayConfig but none of this): providers list computes STATUS purely from process.env (formatRecipeTable, providers.ts:61,77; envReady :47-51) — a zeroentropy key that has lived in config.json since v0.37 reports ✗ missing in env-scrubbed shells while the gateway itself runs fine.

Two adjacent gaps that arguably belong to the same fix:

1. google/voyage have no config.json slot at all — GBrainConfig (config.ts:32-43) defines only openai/anthropic/zeroentropy_api_key, and buildGatewayConfig folds only those three (build-gateway-config.ts:28-36). Env-only providers force operators into shell plumbing for keys.
2. CLI and daemons see different keys by construction: the generated daemon wrappers source the user's shell profile (autopilot.ts:1129-1139) while the bare CLI sources nothing at boot — so the same command behaves differently interactive vs daemonized.

Suggested shape: providers list/test resolve through buildGatewayConfig; add config slots (or one documented key file the CLI sources at boot) for the env-only providers.