[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

Aberta
  • Algo errado?
#36,033 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
linux, typescript
Domínio
authentication, backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
24.8k
Forks
6.4k
Merge médio
59min
PRs com merge (30d)
418

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de pingdotgg/t3code

Todas as issues de pingdotgg/t3code

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.