Gemini 0.63.0 auth loop fix for headless keyring: Sume key from env

Gemini CLI 0.63.0 fixed an infinite auth loop from a headless keyring. In CI, keep Sume's key in an environment variable and one header, not a keyring.

4 min readSume
All posts

Use an API key from an environment variable for Sume in headless Gemini runs, because an OAuth sign-in needs a browser and a credential store. The v0.63.0 release notes list the fix "prevent infinite auth loop from file contention, headless keyring, and supervisor state drops", and the same release lists "enable autonomous plan execution in non-interactive mode". A non-interactive run with a key in a header has no interactive step to loop on.

What the release says

The Gemini facts come from the v0.63.0 release notes (read 2026-10-07). The Sume facts come from the OAuth page and Authentication.

Which one for CI

The table compares the two ways to authenticate with Sume's hosted MCP.

OAuth or API key for an unattended run (read 2026-10-07)
QuestionOAuthAPI key
Needs a browser consentYesNo
Needs stored tokens between runsYesNo; read the key from the environment
Tools visiblemcp:read shows read-only tools; Write is opt-inFull hosted tool set
Spend controlWallet and admissionWallet and admission
Header formatBearer token from the clientAuthorization: Bearer or x-api-key, one only

Guard the unattended run

An API key puts spend in the hands of a script, so give a non-interactive run a short list of allowed steps. Have it call generation_admission_preview or send dry_run=true, set max_spend_usd, and send an idempotency_key built from your own job id.

Where the key lives

Keep the key in the secret store of your CI system and map it to an environment variable. Do not commit it to a settings file. If the key shows up in logs or chat history, rotate it in the dashboard.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume