fix(server): Antigravity sign-in no longer blames the network while the runtime starts#30079

Problem

On Windows, every Antigravity Google sign-in shows "Antigravity has not reached Google after 30 seconds. Check this machine's network connection. Broken IPv6 is a common cause." The network is fine. The runtime simply has not finished starting yet.

AntigravityAuth.runSignIn started the 30-second hint timer before it spawned the ACP runtime. agy_acp_server.exe is a one-file bundle that unpacks itself (about 1.2 GB into TEMP) on every launch. On Windows that takes close to a minute before the runtime answers initialize, so the hint always fires first. The comment above NO_RESPONSE_HINT_MS assumes a healthy agent shows the link "within seconds", which only holds after initialize.

Reproduction: Windows 11, T3 Code desktop 0.1.6, Antigravity runtime 1.1.1 (the pinned release). Press Sign in under Antigravity in Settings and wait. The IPv6 hint appears at 30 s. The Google link only arrives after the runtime finishes starting (about 60 s after the click).

Change

runSignIn now creates the runtime, awaits runtime.initialize(), and only then forks the 30-second hint. AcpSessionRuntime memoizes initialize, and start() reuses it, so no extra ACP request is sent. The hint now measures the time spent waiting on Google, which is what its message describes. The 5-minute overall timeout is unchanged.

Tests: the fake runtime in AntigravityAuth.test.ts now memoizes initialize and has start() reuse it, like the real runtime. That makes one event-order assertion include "initialize". A new test holds initialize open for 60 s and checks that the hint stays hidden. It then checks that the hint still appears exactly 30 s after initialize returns.

Scope and approval

This is a small, focused fix for an obvious bug, so I'm submitting it without a prior issue. A user-facing diagnostic blames the user's network for a delay that comes from the runtime's own startup. The fix moves where an existing timer starts, in one function, and changes no copy, settings, UI, or product behavior.

Verification

• Established the problem from T3's server trace (server.trace.ndjson) during a real sign-in on the environment above: AntigravityAuth.runSignIn started at 17:12:33.185, and the ACP initialize span ran from 17:12:34.455 to 17:13:30, i.e. 56 s before the runtime answered. A second manual launch of the same agy_acp_server.exe with T3's environment (GEMINI_HOME, TEMP, AGY_ACP_FORCE_FILE_STORAGE=1) gave: spawned 17:14:34, first stderr 17:15:26, initialize answered 17:15:28. authenticate printed the Google link in the same second, so the startup delay came before any network request.
• Regression test: vp test run apps/server/src/provider/AntigravityAuth.test.ts
  • Without the AntigravityAuth.ts change: the new test fails with AssertionError: expected true to be false at the 60-second check (the hint was already shown while initialize was still pending). 17 others pass.
  • With the change: 18/18 pass.
• tsc --noEmit for apps/server, vp lint and vp fmt --check on the changed files are clean. The pre-commit hook (fmt, lint, knip:check) passed.
• Not checked: I did not build a packaged desktop app to watch the Settings message end to end. I did not measure runtime startup on macOS or Linux, where unpacking is likely faster; the fix does not depend on the platform.

Done with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code