[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

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.

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.