[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

Ouverte
  • Quelque chose ne va pas ?
#36,033 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
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
linux, typescript
Domaine
authentication, backend

Piste de recherche

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.

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: #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.

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.