Summary
Antigravity IDE consistently becomes unresponsive ~10–17 seconds after Google sign-in completes, every launch, with no error surfaced to the user. Fully reproducible on a completely clean install and profile.
Environment
- Antigravity build: 1.107.0 (ideVersion 1.23.2)
- Commit: 15487b3041e65228cae24980a3f796c905ef582c
- OS: Ubuntu, kernel 6.8.0-136-generic, x86_64
- Install method: official APT repo (us-central1-apt.pkg.dev, antigravity-debian)
- GPU: Nvidia (VA-API warns “Should skip nVidia device named: nvidia-drm”)
Steps to reproduce
- Fresh install via APT (or fully purged + reinstalled existing install)
- Launch
antigravity(also reproduces with--disable-gpu) - Sign in with Google account
- Within ~10–17 seconds of sign-in completing, window becomes unresponsive (“The window is not responding” dialog)
What’s been ruled out
- GPU/rendering: reproduces identically with
--disable-gpu - Corrupted local profile: reproduces on a brand-new
--user-data-dirprofile with no prior state - Corrupted cache: reproduces after wiping
CachedData,CachedProfilesData,globalStorage/google.antigravity - Stale model preference:
antigravityUnifiedStateSync.modelPreferenceskey instate.vscdbwas empty; deleting it made no difference - Network reachability: confirmed working (curl to update endpoint succeeds cleanly, TLS handshake fine, HTTP 200)
- Full purge + clean reinstall:
apt remove --purge, deleted~/.config/Antigravityand~/.antigravityentirely, reinstalled from scratch — still reproduces identically
Crash signature (from main.log, consistent across every run)
CodeWindow: detected unresponsive
CodeWindow unresponsive samples:
at PJr (workbench.desktop.main.js:3270:49337)
at Array.sort (<anonymous>)
at Z_t (workbench.desktop.main.js:3270:39240)
<1>
at WHl (workbench.desktop.main.js:3210:35784)
at hs (workbench.desktop.main.js:3210:34638)
at o2n.Kb (workbench.desktop.main.js:5143:84827)
at o2n.setSelectedModel (workbench.desktop.main.js:5143:75156)
at ... (workbench.desktop.main.js:4956:34820)
at Etn (workbench.desktop.main.js:3270:52997)
at Array.forEach (<anonymous>)
Freeze consistently occurs inside setSelectedModel, triggered during/after an Array.sort, right after the model list is fetched.
Relevant timeline (ls-main.log / cloudcode.log, one representative run)
12:11:32.421 Auth state: uninitialized
12:11:32.502 Auth state: validatingLogin
12:11:36.340 POST cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
12:11:37.671 POST daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
12:11:43.434 Auth state: signedIn
12:11:44.853 POST daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
12:11:46.002 POST daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
12:11:49.581 CodeWindow: detected unresponsive <-- no further log lines before this
Note the pattern: first call hits production cloudcode-pa.googleapis.com, all subsequent calls hit daily-cloudcode-pa.googleapis.com (pre-release/ canary endpoint). No error, quota message, or non-2xx status is ever logged by the client — the language server logs only outgoing request traceIds, no response codes are visible client-side.
Also seen consistently at startup (does not appear related, but noting for completeness):
Failed to set Cloud Code URL on Language Server: Language server client has not been initialized!
On the one run where --disable-gpu was combined with a completely fresh --user-data-dir, the app successfully reached the “Welcome to Antigravity” onboarding screen rather than freezing — the only run so far that got past this point, though onboarding was not completed further to confirm full stability.
Request
This looks like either (a) a client-side bug in how setSelectedModel processes the response from fetchAvailableModels — particularly given the mixed production/daily-canary endpoint routing — or (b) a malformed/oversized response from the daily-cloudcode-pa.googleapis.com endpoint for this account. Would appreciate guidance on which, and whether pinning to the production endpoint only is possible as a workaround.