[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

Đang mở
  • Có gì không ổn?
#36,033 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
linux, typescript
Lĩnh vực
authentication, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
59 phút
Pull request đã merge (30 ngày)
418

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.