[pending] gemini worker/verifier unusable headless on this host (Gemini CLI auth) -- revisit later

[jasonhnd]

Tracking only (pending, low priority; revisit later).

The gemini provider is registered but unusable headless on the current host: the Gemini CLI prompts for interactive auth / fails (observed exit 55) when run non-interactively, so it cannot act as a worker or verifier here. This is a Gemini CLI / host-environment auth limitation, NOT a loopcoder defect. The docs already label gemini experimental/unverified end-to-end.

Under attestation hard-fail this fails closed correctly: a gemini run that produces no model/usage cannot pass AttestationRecord.Validate(), so the worker opens no PR and the verifier returns needs-human -- gemini's breakage is surfaced, not hidden.

To revisit later (no action now)

• Establish non-interactive Gemini CLI auth on the host.
• Verify a real gemini worker dispatch end-to-end: model/effort/usage parse, attestation valid, PR opened with the attestation header.
• Verify a real gemini loopreview end-to-end (read-only, structured verdict, attestation valid).

No loopcoder code change is expected; this is an environment/auth task plus end-to-end verification. Parked pending host auth.

[jasonhnd]

Update (2026-06-28): root cause is now upstream, not just a host auth quirk.

The old Gemini CLI (@google/gemini-cli v0.45.2) personal OAuth / Code Assist free tier is now rejected server-side by Google. Any non-interactive call returns:

IneligibleTierError: This client is no longer supported for Gemini Code Assist for individuals. To continue using Gemini, please migrate to the Antigravity suite of products (https://antigravity.google).

exit 55 (exit 1 on the read-only verifier path). This is account/client-level, NOT a parameter or local-auth-file issue, verified by:

• The same command gemini --prompt ... --yolo -m gemini-3.5-flash returned a real response (exit 0), then ~20 min later the same day returned exit 55 IneligibleTier.
• Three different arg combos (with/without -m, read-only env, --extensions) all returned IneligibleTier.
• Repairing the (separately corrupt) ~/.gemini/oauth_creds.json fixed the JSON but did NOT change the server rejection.

So this is what "the Gemini CLI changed" means: Google is migrating individuals off the old CLI onto Antigravity (CLI binary agy).

Antigravity (agy v1.0.13) headless status on this host: keyring silent auth works and Gemini 3.5 Flash actually runs and responds, but --print headless stdout is broken on Windows. It mis-converts the transcript URI file:///C:/Users/... to POSIX /Users/... (drops the C: drive), the transcript write fails, and stdout returns empty (exit 0). The response does land in ~/.gemini/antigravity-cli/conversations/<id>.db (SQLite, protobuf payload), recoverable by side-channel but schema-fragile. agy is a closed prebuilt binary, so the bug cannot be patched in source.

Decision: mark the gemini worker upstream-deprecated, pending Antigravity maturity. The only clean headless path to Gemini would be a GEMINI_API_KEY (AI Studio / generativelanguage endpoint, bypassing Code Assist), untested here. Verified workers codex (gpt-5.5) + claude remain sufficient. loopreview correctly fail-closed to needs-human with a complete incomplete-attestation finding, so the attestation guardrail behaved as designed.