[Bug]: Antigravity Sign in cannot finish with the native CLI 1.5.x: T3 never receives its Google link ("has not reached Google after 30 seconds")

Start at apps/server/src/provider/antigravityAuthSupport.ts, where parseAntigravityAuthorizationUrl (about lines 509-525) and the stderr handler (about lines 621-622) reject the 1.5.x link shape, then at AntigravityAuth.ts (lines 37, 44, 302) for the 30-second hint and AntigravityDriver.ts (lines 517, 527-529) for the 90-second refresh timeout. Reproducing needs the Antigravity CLI 1.5.x and a headless host. Done means the sign-in path either surfaces a usable link or marks the instance as needing sign-in, and the fix needs maintainer agreement on the approach.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Related, not duplicates: #29039 (closed; the same "Broken IPv6" hint, but there the runtime hung at startup), #9624 (older runtime), #36033 (the 1.4.5 → 1.5.x update signs Linux instances out, which is how I ended up needing this sign-in).

Area

apps/server

Steps to reproduce

1. Use the managed Antigravity CLI 1.5.8 on a server where the T3 client's browser is not on the server machine. Here that is a Linux VM running the standalone T3 service, reached from another computer.
2. Settings → Providers → Antigravity → Sign in with Google on an instance that has no stored sign-in.
3. Wait.

Expected behavior

T3 shows a Google sign-in link that I can open on the device I'm using and finish, as it does with the 1.4.5 runtime ("Open the Google sign-in link. If you are remote, paste the redirect URL here.").

Actual behavior

In-app Sign in never gets a link. After 30 s T3 shows:

Antigravity has not reached Google after 30 seconds. Check this machine's network connection. Broken IPv6 is a common cause.

The flow then times out. The network was fine: every Google endpoint the runtime uses answered over IPv4 in under 0.15 s, and the host has no IPv6 route.

I drove each runtime the way T3 launches it: T3's environment (including its BROWSER helper), acp --gemini-dir <profile> --app-data-dir antigravity-acp, then ACP initialize and authenticate {methodId: "oauth-personal"}. Each run used a scratch profile, and every browser opener on PATH was replaced by a shim that only logs.

Runtime	What authenticate does	Can T3 use it?
1.4.5, DISPLAY set	Within 4 s it calls T3's BROWSER helper, so stderr gets __T3_ANTIGRAVITY_AUTH_URL__"https://accounts.google.com/o/oauth2/v2/auth?…&redirect_uri=http://127.0.0.1:<port>/…"	Yes
1.5.8, DISPLAY set	Ignores BROWSER and runs xdg-open "https://accounts.google.com/o/oauth2/auth?access_type=offline&…&code_challenge_method=S256&…&redirect_uri=http%3A%2F%2Flocalhost%3A<port>%2Fauth%2Fcallback&…" on the server's own display. Prints nothing on stdout or stderr.	No. T3 never sees a link, and the browser opens on a screen nobody is watching.
1.5.8, no DISPLAY	Fails within about 10 s with -32603 "No browser is available here (no graphical display is available to open a browser). Run agy acp --login in a terminal on this machine, then retry; or use a Gemini API key."	No. T3 shows a generic sign-in failure.

Even if T3 intercepted the 1.5.x link, it would reject it:

• The parser expects the 1.4.5 link shape. parseAntigravityAuthorizationUrl (apps/server/src/provider/antigravityAuthSupport.ts:509-525) requires the path /o/oauth2/v2/auth and a redirect_uri matching ^http://127\.0\.0\.1:<port>/$. 1.5.x uses /o/oauth2/auth with http://localhost:<port>/auth/callback.
• Rejected links are dropped silently. The stderr handler discards any link that fails that check (:621-622).
• The 30-second hint measures only "no link received". It starts once initialize answers (apps/server/src/provider/AntigravityAuth.ts:37, :44, :302) and checks no network. Its IPv6 wording fits the old Python runtime, not the Go CLI.

Background launches wait 90 s, and the instance still shows as signed in. This happens when a model refresh (after an update, or from Refresh provider status) or a new session reaches authenticate on an instance without a stored sign-in:

• With a display: 1.5.x opens a browser on the server and waits. refreshModels times out after 90 s (AntigravityDriver.ts:517).
• Without a display: 1.5.x returns the -32603 error above.
• Neither is treated as "sign-in required". Only -32000 or T3's own sign-in message count (antigravityAuthSupport.ts:166-171, AntigravityDriver.ts:527-529). The instance keeps auth.status: "authenticated" and status: "ready", and each session start waits about 90 s.

Impact

Blocks work completely

Version or commit

0.1.10-nightly.20261113.4616 (main @ 0b0a61a01f has the same code). Managed Antigravity CLI 1.5.8 (1.5.8-4602374149505024/linux-x64); 1.4.5 (agy_acp_server 1.4.5) for comparison.

Environment

Ubuntu x64 VM, standalone T3 server run as a service, reached from other computers. The service environment has DISPLAY set to a local X session nobody watches. Google personal sign-in (oauth-personal).

Logs or stack traces

# 1.5.8 runtime log, two in-app sign-in attempts from T3
ACP authenticate: methodId="oauth-personal" meta=map[]
Opening browser for ACP sign-in (method=consumer, redirect=http://localhost:<port>/auth/callback)
authenticate("oauth-personal") failed: Sign-in was cancelled. (code -32800)   # ~5 min later, when T3 gave up

Suggested direction:

• Use the CLI's own headless login for in-app sign-in on 1.5.x. <agy> acp --login --gemini-dir <profile> --app-data-dir antigravity-acp prints Open this link in a browser to log in with Google: and a link whose redirect_uri is https://antigravity.google/oauth-callback. Google's page there shows a code, and the CLI reads that code, or the landing URL, from stdin. That works when the browser is on another device. T3 could show the link and write the pasted code to stdin, much like its current "paste the redirect URL" step.
• Stop background 1.5.x launches from opening a browser on the server. Treat its "No browser is available here" error as sign-in required, so the instance shows "Sign in" instead of staying ready.
• Drop the IPv6 wording from the 30-second hint for 1.5.x.

Workaround

Run the same acp --login command in a terminal on the server against the instance's profile directory, or keep the host on 1.4.5.