Files
Atish PatelandClaude Opus 4.8 e77fdcb085 feat(desktop): support Goose's native Google Gemini provider
Goose drives Gemini through its own `google` provider (native
`streamGenerateContent`, `x-goog-api-key`), authenticated with
GOOGLE_API_KEY — distinct from buzz-agent's OpenAI-compatible `gemini`
provider (GEMINI_API_KEY). Offer `google` (labelled "Google Gemini") in
the provider picker for the Goose runtime only, and make Goose readiness
require GOOGLE_API_KEY for it.

- agentConfigOptions.tsx: GOOSE_ONLY_PROVIDER_IDS = {google}; add google
  to the provider list, credential config, KNOWN_LLM_PROVIDER_IDS, and
  providerRequiresExplicitModel. Picker/credential gating is symmetric —
  gemini is buzz-agent-only, google is goose-only — and a persisted value
  still renders via the `(current)` tail.
- readiness.rs: goose `google` requires GOOGLE_API_KEY from the env layer
  only. Goose keeps the key in its own secret store, never in
  config.yaml, so the file config cannot silence it. buzz-agent is
  unchanged.
- config_bridge/goose.rs: verify the persisted `active_provider: google`
  + `providers.google.model` path parses to provider/model and never
  surfaces GOOGLE_API_KEY from the file.
- readiness_tests.rs: the accumulated `mod tests` stays extracted here
  (agent_models precedent) so readiness.rs remains under the default
  file-size ceiling; check-file-sizes.mjs override retargeted.

No silent GEMINI_API_KEY->GOOGLE_API_KEY migration — the two contracts
stay independent.

Co-authored-by: Atish Patel <atish@squareup.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Atish Patel <atish@squareup.com>
2026-07-19 22:48:19 -05:00
..