[Bug]: Antigravity unverified Google account passes sign-in, then fails first turn with raw 403 "Verify your account to continue" #16078

Activity

1. arhammahajan

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
2. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the clear repro and the multi-account note, @arhammahajan. This looks like a real gap, and I don't see a duplicate of it.

   What I found

   • Sign-in is treated as finished once the Antigravity ACP process starts and models load. AntigravityAuth publishes the authenticated state after runtime.start(), and Refresh provider status only restarts that process and republishes the catalog. Neither step asks Google whether the account still has a verification hold.
   • OAuth and the model list can succeed while the first session/prompt cannot, which matches your report: the instance looks signed in, Gemini 3.8 Flash (High) is selectable, and the turn dies with request failed (code 403): Verify your account to continue.
   • That 403 is Google's account-level VALIDATION_REQUIRED response from the Cloud Code API, not a failed T3 sign-in. The standalone agy CLI prints a one-time validation_url that opens the phone/QR page. The ACP server we run (agy_acp_server_1.1.1) only returns the flattened sentence in your screenshot. T3 never sees the URL, and nothing maps this text into a verification action. Sign-in only rewrites SUBSCRIPTION_REQUIRED. Antigravity also has no prompt-failure mapper, unlike Grok and the registry agents.
   • Verifying in a separate agy session and retrying here works because the hold is on the Google account. Each Antigravity instance is its own account, so each one needs that step. T3's sign-in is separate from the CLI on purpose (docs/user/providers-antigravity.md).
   • Provider-failure redaction currently strips query strings, and a validation_url is entirely in the query, so passing the raw error through would not be enough on its own. Bumping the agent (1.3.0 is proposed in feat(server): bump Antigravity ACP agent to 1.3.0 #15746) does not add this by itself.

   Likely fix area

   • Recognize this 403 and surface a clearer message that the Google account still has to be verified in agy, per instance.
   • If a newer ACP server starts returning validation_url, show that URL in-app (and avoid stripping the query string for that path).
   • Longer-term options around an in-app phone/QR flow would need a maintainer call, since this error today does not include the URL and we'd be careful about adding a second Google verification client next to the official agent.

   Workaround until then: verify that Google account in agy, then send the message again in T3. Repeat for each instance.

   A maintainer will decide on the fix direction.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026