Antigravity shows "Needs attention: Google account access is not checked yet" after a server process restart, even when already signed in #10110

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (provider/antigravity)

What happened

Antigravity continuously shows "Needs attention · Antigravity is installed. Google account access is not checked yet." As soon as I press "Sign in with Google" it works, but I've had to do this repeatedly, at random intervals, on two separate always-on installs (a desktop app talking to a local server, and a t3 serve daemon on a remote VPS), while the server stays up the whole time from my perspective.

Diagnosis

• The message is the AUTH_UNCHECKED_MESSAGE constant (apps/server/src/provider/Layers/AntigravityProvider.ts:36-38), used as the fallback message in checkProvider (same file, ~lines 197-204) whenever auth.status is neither authenticated nor unauthenticated, alongside status: "warning".
• The web UI's getProviderSummary (apps/web/src/components/settings/providerStatus.ts:57-63) renders any status === "warning" as "Needs attention" and just displays provider.message as the detail line. The auth.status === "unknown" condition is decided entirely server-side — the client is a faithful mirror, not where the bug lives.
• auth.status starts as "unknown" in the provider's initial in-memory state (AntigravityProvider.ts:147, built via a fresh SubscriptionRef.make at :158). It is written to "authenticated" in exactly one place (AntigravityProvider.ts:281, inside onSessionStarted), reached by two callers: a real ACP chat session starting (AntigravityDriver.ts:304), or completion of an interactive Google sign-in (AntigravityAuth.ts:282 → AntigravityDriver.ts:228 → onSessionStarted).
• The periodic background health-check probe (checkProvider, AntigravityProvider.ts:168-232) only calls runtime.initialize() (wired in AntigravityDriver.ts:257-273), never .start(), and only reads draft.auth.status (:197) — it can never itself set or restore authenticated.
• No provider auth state is persisted anywhere (no DB row, no file, no IPC field) across a server process restart: makeAntigravityProvider always builds a fresh SubscriptionRef (AntigravityProvider.ts:158), and the service launcher's handoff payload carries only {protocol, childVersion, update} (serviceLauncher.ts:400-404) — no runtime state.
• On the daemon install, service-launcher.mjs performs zero-downtime updates by spawning a brand-new t3 serve child and terminating the old one (#handleUpdateRequest/#beginTrial, serviceLauncher.ts ~lines 453-509, #spawnChild ~lines 405-408) — a genuinely fresh Node process. Confirmed live: the launcher had been running 20h55m while its current t3 serve child was only 34 minutes old, with three different nightly runtimes present under the runtime directory within the same 24-hour window.
• On the desktop install, the server runs as an Electron-managed child process instead of under service-launcher.mjs; the restart mechanism differs, but the same underlying defect applies — any restart of that process rebuilds the Antigravity provider from scratch with auth.status: "unknown".
• Because nightly builds ship every few hours, this happens often. Antigravity then shows "Needs attention" until a new session or sign-in click runs onSessionStarted again — which appears to work instantly only because the underlying antigravity CLI already holds valid cached Google credentials; the click is not performing a real re-authentication.
• continueThreadsAfterServerUpdate (consumed by reconcileProviderSessions, serverRuntimeStartup.ts:470-484) can incidentally resume a session across a restart and heal this side effect, which plausibly explains why the symptom is intermittent rather than guaranteed on every single restart.
• Ruled out: the "Provider health check interval" setting. Disabling it entirely (set to 0) on one install did not stop the symptom from recurring, consistent with the probe never being able to set authenticated in the first place.

Steps to reproduce

1. Enable the Antigravity provider (oauth-personal), sign in, and use it once so status shows "Authenticated".
2. Trigger a server process restart: on a t3 serve daemon install this happens automatically via the service launcher's zero-downtime update handoff whenever a newer nightly is available; it can also be forced by restarting the t3 serve process directly.
3. Without starting a new Antigravity session, open Settings → Providers. Antigravity shows "Needs attention — Antigravity is installed. Google account access is not checked yet." despite Google sign-in still being valid.
4. Click "Sign in with Google" (or start any task using Antigravity) — status returns to "Authenticated" instantly, until the next restart.

Version or commit

0.0.39-nightly.20260905.1286 (reproduced on two separate installs on this same version)

Environment

macOS 25.6.0 arm64 (T3 Code desktop app) and a Linux VPS running t3 serve under service-launcher.mjs. Node v26.0.0.

Logs or stack traces

$ ps -o pid,etime,cmd -p <service-launcher-pid>
    PID     ELAPSED CMD
 <pid>    20:55:12 node .../service-launcher.mjs
$ ps -o pid,etime,cmd -p <t3-serve-pid>
    PID     ELAPSED CMD
 <pid>       34:19 node .../t3/dist/bin.mjs serve

(the actual server process is ~35x younger than its own supervisor, despite the machine and supervisor never having gone down; three separate nightly runtimes were present under the runtime directory within the same 24 hours)

Related issues

#9650 (Antigravity health checks leave large _MEI folders) confirms the same "disposable per-interval ACP probe" design elsewhere in this provider. Different symptom, not a duplicate.

Workaround

None available at the config level. The provider-health-check-interval setting does not affect this — confirmed by disabling it entirely on one install without the symptom stopping. No reliable user-side workaround beyond re-clicking sign-in after it flaps.

Filed by

claude (opus-5) via t3 triage