#63 Gemini OAuth onboarding: manual trust prompt blocks first headless execution

[Anonymous]

Originally created by: kumaakh

Summary

When provisioning a remote fleet member (macOS) to use Gemini CLI with OAuth personal auth, the first headless gemini -p invocation hangs indefinitely waiting for a first-time trust/consent prompt. This is not an error — once the user manually accepts the trust message interactively, subsequent headless calls work correctly.

What was copied to make OAuth work

The following files were copied from the PM's local machine (C:\Users\akhil\.gemini\) to the remote member (~/.gemini/) via send_files + execute_command:

File	Purpose
oauth_creds.json	OAuth access token + id_token (Google account)
google_accounts.json	Active account pointer ({"active": "akhil.kumar@gmail.com", "old": []})
settings.json	Must contain {"security": {"auth": {"selectedType": "oauth-personal"}}} — without this, the CLI ignores OAuth creds and falls back to API key or hangs

Additionally:

• Cleared GEMINI_API_KEY from the member's encryptedEnvVars in the fleet registry (it was overriding OAuth)
• Removed GEMINI_API_KEY exports from ~/.zshrc, ~/.bash_profile, ~/.bashrc on the remote member

Confirmed working

After copying the above files, the member showed:

Signed in with Google: akhil.kumar@gmail.com
Plan: Gemini Code Assist in Google One AI Ultra

Problem

The gemini CLI displays a first-time trust/consent prompt on the very first non-interactive invocation. This prompt cannot be answered programmatically — it requires the user to open a terminal on the remote machine and run gemini once manually to accept it.

Until this is done, all execute_prompt calls to that member hang and eventually time out (no error, just silence).

Impact

• New Gemini member onboarding requires a manual step on the remote machine
• Fleet server has no way to detect or surface this hang — it just times out
• oauth_creds.json access tokens expire in ~1 hour; refresh_token is not present in the file, so tokens need to be re-copied periodically (or the refresh_token mechanism needs investigation)

Ideas to resolve

1. Document in onboarding.md: add a step "run gemini -p hello interactively once on the remote machine to accept trust prompts"
2. Detect the hang: fleet server could check if the CLI produces no output after N seconds and surface a specific error message suggesting the trust prompt issue
3. Pre-seed trust acceptance: investigate if there's a config file or flag (e.g. --yes or a trust registry file in ~/.gemini/) that pre-accepts consent
4. Refresh token handling: investigate whether gemini auth or the OAuth flow can produce a refresh_token so credentials don't need to be re-copied hourly

Related

• [#62] (multi-provider OAuth + API key support in fleet)

[Anonymous]

Originally posted by: kumaakh

Technical direction:

1. Document the manual step in skills/fleet/onboarding.md (Gemini OAuth section): add an explicit step — 'After copying OAuth credentials to the remote member, SSH in and run gemini -p hello interactively once to accept the trust/consent prompt. All subsequent headless calls will work after this.' This is the immediate fix.

2. Detect the hang: in src/tools/execute-prompt.ts, if the member is Gemini and produces no stdout within a configurable timeout (e.g. 30s from start), surface a specific diagnostic: 'Gemini member may be waiting for interactive trust prompt — SSH to the member and run gemini -p hello interactively once.'

3. Pre-seed trust: investigate ~/.gemini/ for any config file that pre-accepts consent (e.g. a rusted: true field in settings.json). If found, add to the OAuth credentials copy step in provision_llm_auth.

4. Refresh token: the 1-hour OAuth token expiry is a separate operational pain. Investigate whether gemini auth refresh exists or whether the OAuth flow in provision_llm_auth can be updated to request offline access (which includes a refresh token).