[Bug]: Updating the managed Antigravity runtime from 1.4.5 to the native CLI 1.5.x signs Linux instances out when no keyring is usable

Abierto
  • ¿Algo no está bien?
#36,033 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
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
linux, typescript
Área
authentication, backend

Línea de trabajo

Start with the managed-runtime update flow in apps/server and the existing auth support in apps/server/src/provider/antigravityAuthSupport.ts; trace how the profile's antigravity-acp directory is handled before the native CLI's first launch. Reproduce with a Linux profile containing acp_token.json but no antigravity-oauth-token. Done means the update preserves sign-in or explicitly marks the instance signed out and explains why.

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: #34327 (after the move to the native CLI, the usage probe still reads the old acp_token.json; that is the same storage split with a different symptom), #35409 (the migration to the native CLI; its smoke test was macOS only). Signing in again afterwards is its own bug: #36034.

Area

apps/server

Steps to reproduce
  1. On a Linux x64 server with no usable Secret Service keyring, sign an Antigravity instance in with Google (oauth-personal) while the managed 1.4.5 runtime is active. "No usable keyring" covers a headless server, and also a desktop whose login keyring stays locked. Because T3 launches that runtime with AGY_ACP_FORCE_FILE_STORAGE=1 (apps/server/src/provider/antigravityAuthSupport.ts:225), the token lands in <profile>/antigravity-acp/acp_token.json.
  2. Update the managed runtime: Settings → Providers → Antigravity → Update Antigravity, or provider.install.start. This installs the native CLI 1.5.8.
  3. Let T3's post-install model refresh run, or start a new Antigravity session.
Expected behavior

The instance stays signed in, as #35409 describes: "Existing login and conversation history stay in the same profile." The docs only warn "You may need to sign in again after migration". When a new sign-in is needed, T3 should say so as soon as the update finishes.

Actual behavior

  • 1.5.8 does not find the old sign-in. It tries the keyring (5 s timeout, twice), then falls back to its own file store, finds nothing, and starts a browser sign-in:

    ACP authenticate: methodId="oauth-personal"
Keyring LoadStoredToken timed out after 5s, falling back to file storage
Using file-based token storage because a keyring timeout was recorded within the last 1h0m0s
... You are not logged into Antigravity.
Opening browser for ACP sign-in (method=consumer, redirect=http://localhost:<port>/auth/callback)
authenticate("oauth-personal") failed: Sign-in was cancelled. (code -32800)   # when T3 gave up, 90 s later

  • The two runtimes use different token files in the same directory.

    • 1.5.8 reads <gemini-dir>/antigravity-acp/antigravity-oauth-token and never opens acp_token.json. Its first-run step ("Attempting migration from AppDataDir <profile>/antigravity-acp … Migration complete") does not carry the token over.
    • I confirmed this on a scratch profile by running the public 1.5.8 linux-x64 build as antigravity acp --gemini-dir <scratch> --app-data-dir antigravity-acp under strace, with a dummy acp_token.json in place. It opened antigravity-oauth-token (ENOENT) and never touched acp_token.json.
    • 1.5.8 also ignores AGY_ACP_FORCE_FILE_STORAGE (as noted in #34327).

  • Every instance on the managed runtime is signed out at once, because they all switch to the new runtime together.

  • T3 keeps showing the instance as signed in. The post-install refresh fails after 90 s with "Antigravity model refresh timed out. Try again or check Google sign-in.", while auth.status stays authenticated and status stays ready. Each new session then waits about 90 s at authenticate. The cause is in the sign-in issue (#36034): T3 cannot see 1.5.x's sign-in request.

  • Windows kept its sign-in after the same update. There the 1.5.8 log shows keyringAuth: loaded token … ChainedAuth: authenticated via keyring, because the older runtime had also stored the token in Credential Manager. A Linux host with a working, unlocked keyring may behave like Windows; I did not test that case.

Impact

Blocks work completely

Version or commit

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

Environment

Ubuntu x64 VM running the standalone T3 server as a service. GNOME login keyring present but locked. Google personal sign-in (oauth-personal). Windows 11 x64 desktop for comparison.

Logs or stack traces
# 1.5.8 on a scratch profile (strace -e openat), dummy acp_token.json present beside it
openat(AT_FDCWD, "<gemini-dir>/antigravity-acp/antigravity-oauth-token", O_RDONLY|O_CLOEXEC) = -1 ENOENT
openat(AT_FDCWD, "<xdg-config>/antigravity/credential-user-scope", O_RDONLY|O_CLOEXEC) = -1 ENOENT
# no openat of acp_token.json

Suggested direction: before the first launch of a native CLI on a profile that still has acp_token.json and no antigravity-oauth-token, have T3 carry the stored sign-in over. If that isn't possible, mark the instance signed out as part of the update and say why. The docs line "You may need to sign in again after migration" would then name the case: Linux hosts without a usable keyring.

Workaround

Sign in again. In-app Sign in cannot finish with 1.5.x on such a host (#36034), so it has to be the CLI's own terminal login against the instance's profile:

<managed antigravity binary> acp --login --gemini-dir <profile> --app-data-dir antigravity-acp

It prints a Google link that redirects to https://antigravity.google/oauth-callback and asks for the code shown there. I haven't yet confirmed that T3 picks up a sign-in made this way, but both use the same app-data directory. Alternatively, hold Linux hosts 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.