[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
4. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   Fresh triage on main b5a226e49c: this reports an account-verification failure, not an exploitable vulnerability. Checked all 947 open issues for Antigravity, unverified accounts, account verification and 403 titles; no matching duplicate found. #17508 fails during sign-in, whereas this report completes sign-in and fails on the first turn.

   Reproduction is blocked: this environment has no unverified Google test account, so the reported sign-in → models load → first-turn 403 sequence was not run. No runtime reproduction or fix is claimed. Routing to Julius for account-backed reproduction and review of the per-instance sign-in/verification flow; the issue remains open.
5. systemsssx commented on Oct 27, 2026

   

   systemsssx

   on Oct 27, 2026

   More actions

   This matches the verification gate layer specifically, and it is worth separating it from sign-in and from the location gate, because each has a different fix:

   1. Sign-in (OAuth) can complete for accounts that later fail -- success here proves nothing about the next two gates.
   2. Account verification returns 403 ... VALIDATION_REQUIRED with a �alidation_url in the response details. Opening that URL in a browser already signed into the same Google account and completing the phone/identity verification clears it. Until then the first real model call fails with exactly "Verify your account to continue".
   3. Only after 1+2 does the per-request location gate (source IP) come into play.

   So the UX fix you describe is right: on the 403, detect VALIDATION_REQUIRED / validation_url, surface it to the user and retry after verification. Tools that did this recently (e.g. magpie v0.1.304, pi-ai-style parsing) ended up doing the same thing.

   I documented this funnel (client eligibility flag -> Google account VALIDATION_REQUIRED -> source-IP location, plus proxy/TUN pitfalls) while debugging my own setup: https://systemsssx.github.io/antigravity-blog/ -- Chinese, my own unofficial notes, corrections welcome.