Antigravity permanently freezes at every launch

Google Antigravity
1

Hey I had a really bad freeze today doing nothing more than trying to drag and drop a jpg into a conversation. I pointed Claude at it and this is their report. It’s a pretty horrible bug

Antigravity permanently freezes at every launch — corrupted userStatus state entry causes infinite render loop (full forensic writeup + recovery steps)

Build: Antigravity 1.23.2 (VS Code base 1.107.0, commit 15487b3041e65228cae24980a3f796c905ef582c)
OS: Windows 10 Pro 10.0.19045
Severity: App completely unusable — window freezes within ~20–60 s of every launch, survives reboots, and none of the usual remedies (cache clear, GPU flags, --disable-extensions, reinstall-adjacent steps) help.

Summary

After a drag-and-drop image upload into the agent panel hung mid-flight (the “Upload To Agent” overlay dimmed the app and never dismissed), Antigravity became permanently unbootable: every launch, the workbench window goes “not responding” within ~20–60 seconds, occasionally recovers for a few seconds, then freezes again, with one renderer core pegged at 100 % and memory climbing ~50 MB/min indefinitely.

Root cause (established by bisection, see below): a corrupted/pathological antigravityUnifiedStateSync.userStatus entry cached in %APPDATA%\Antigravity\User\globalStorage\state.vscdb (ItemTable). When the agent UI consumes it, the preact-based panel enters an infinite re-render loop — the unresponsive-window stack samples show the renderer perpetually inside preact’s render-queue drain:

at PJr (workbench.desktop.main.js:3270:49337)   // preact rerenderQueue sort comparator: (t,e)=>t.__v.__b-e.__v.__b
at Array.sort (<anonymous>)
at Z_t (workbench.desktop.main.js:3270:39240)   // preact process()/enqueueRender

plus IPC buffer-assembly frames (Uint8Array.set → oW.concat → y7o protocol writer), i.e. the panel keeps receiving/re-rendering state forever. Identical stack in every session, ~14 samples per unresponsive episode, logged by the built-in watchdog in main.log.

What did NOT fix it (all verified, each followed by a monitored relaunch)

  • Reboot of the PC
  • --disable-gpu --disable-gpu-compositing
  • Clearing Cache, Code Cache, GPUCache, Session Storage, Service Worker, DawnGraphiteCache, DawnWebGPUCache
  • Clearing Local Storage and WebStorage
  • --disable-extensions
  • Booting fully offline (--proxy-server=127.0.0.1:1 + proxy env vars) — still froze, because the poisoned copy is cached locally in state.vscdb
  • Removing the language server’s entire data dir (~\.gemini\antigravity: brain, conversations, implicit, everything)
  • Removing the per-workspace editor-restore state (memento/workbench.parts.editor)
  • Deleting the agent-restore keys antigravityUnifiedStateSync.agentManagerWindow / .trajectorySummaries / .artifactReview

What DID fix it

With the app closed, deleting the synced-state cache keys from the global state DB:

sqlite3 "%APPDATA%\Antigravity\User\globalStorage\state.vscdb"
DELETE FROM ItemTable WHERE key IN (
  'antigravityUnifiedStateSync.userStatus',
  'antigravityUnifiedStateSync.theme',
  'antigravityUnifiedStateSync.sidebarWorkspaces'
);
VACUUM;

Next launch: instant, permanent recovery. Both windows responsive, no watchdog events, login and subsequent server re-sync all fine. (userStatus is the load-bearing one; the other two were removed in the same pass.)

Corroborating evidence: the only clean boots during the entire incident were ones with a freshly-created (signed-out) state.vscdb — i.e. no cached userStatus. Every boot with the cached blob froze, online or offline.

Timeline / trigger

  1. ~14:48 — dropped a normal JPG (a few MB, from a mapped network drive Z:\) onto the agent conversation. The “Upload To Agent” overlay appeared, dimmed the app, and never dismissed; app locked.
  2. 15:16 onward — every relaunch (10+ attempts across ~90 min) froze with the identical stack above. main.log shows CodeWindow: detected unresponsive → occasional recovered from unresponsive → re-freeze, every session.
  3. Notably, the conversation itself was NOT corrupted — after recovery it opens fine and contains no trace of the photo. Only the cached account/status blob was poisoned.

Why this deserves attention

  1. A single bad cache row should not brick the app. The agent panel’s state consumption has no validation/error-boundary; one malformed userStatus payload puts the workbench (not just the panel) into an unrecoverable render loop at every boot.
  2. The failure is invisible to users. Nothing in the UI indicates why the app is frozen; the watchdog data lands in main.log where no ordinary user will look. Every standard remedy (caches, GPU flags, extensions, reinstall) fails, because the poison lives in state.vscdb, which survives all of them.
  3. The upload flow that triggered it needs hardening too — a modal overlay that can wedge open over a stalled file upload (from a network drive in this case) left the app in the state that produced the corruption in the first place.

Suggested fixes: schema-validate / try-catch state entries from unifiedStateSync before handing them to the UI (drop + refetch on parse failure); add an error boundary around the agent panel so it can’t take the workbench render loop down with it; make the Upload To Agent overlay cancellable/timeout-able.

Happy to provide the full main.log unresponsive samples or the quarantined state.vscdb (minus auth tokens) on request.

2

correction: the source drive is local, not a network share — but the file path contains multiple # characters (Z:##WORK###WORKINPROGRESS…), which may be the actual upload-flow trigger.

3

Is there a way to fix it on Linux?