[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")

Ouverte
  • Quelque chose ne va pas ?
#36,034 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
linux, node.js, typescript
Domaine
authentication, backend, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
24.8k
Forks
6.4k
Merge moyen
59 min
PR mergées (30 j)
418

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de pingdotgg/t3code

Toutes les issues de pingdotgg/t3code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.