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

Abierto
  • ¿Algo no está bien?
#36,034 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
linux, node.js, typescript
Área
authentication, backend, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
59 min
PR fusionados (30 d)
418

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.