UPDATE — root cause found (matches another report in this forum), but it’s a server-side resync, not a one-time local corruption
Version: Antigravity 1.107.0 (15487b3041e65228cae24980a3f796c905ef582c, 2026-04-16)
OS: Windows 11 (10.0.26200), x64
Hardware: 12th Gen Intel i5-12450H, 16GB RAM
Issue
Antigravity freezes (“window not responding”) repeatedly, starting within 15-20 seconds of launch. This happens even on a completely blank window with no project/workspace opened, and persists after a full reset of user data.
What I’ve already ruled out (tested individually)
- GPU/Electron rendering: tested with --disable-gpu, --disable-gpu-compositing, --disable-software-rasterizer, --use-gl=swiftshader — freeze persists identically
- Extensions: tested with --disable-extensions — freeze persists
- Auto-updater: disabled via update.mode: none in settings.json, confirmed in logs (update#setState disabled) — freeze persists
- Specific project/workspace: freeze happens on multiple different projects AND on a blank window with no folder opened
- Corrupted cache/state: fully reset globalStorage and workspaceStorage (renamed to force clean recreation) — freeze returns identically within the same session
- Telemetry: disabled via telemetry.telemetryLevel: off — freeze persists
- Antivirus interference: Windows Defender real-time protection already disabled
- Git worktree config mismatch (repositoryformatversion/extensions.worktreeConfig): scanned all local repos, no match found
- Local language-server data (~/.gemini/antigravity: brain, conversations, config.json): fully wiped, freeze persists; config.json contains no model override, so it’s not a local setting issue
- Updating to the latest 2.3.1/IDE 1.1.3 build: made things worse, not better — lost access to all existing conversations/projects after the Agent Manager/IDE split, had to roll back to 1.107.0
- Model: currently on the default/stable model, not Gemini 3.6 Flash, so a model switch isn’t a required trigger on my end
Root cause (confirmed)
Same as reported elsewhere in this forum: a corrupted antigravityUnifiedStateSync.userStatus entry in %APPDATA%\Antigravity\User\globalStorage\state.vscdb (ItemTable) sends the agent panel into an infinite preact re-render loop on the main thread:
at PJr (workbench.desktop.main.js:3270:49337)
at Array.sort (<anonymous>)
at Z_t (workbench.desktop.main.js:3270:39240)
Deleting the poisoned keys fixes it immediately:
sqlite3 "%APPDATA%\Antigravity\User\globalStorage\state.vscdb" "DELETE FROM ItemTable WHERE key IN ('antigravityUnifiedStateSync.userStatus','antigravityUnifiedStateSync.theme','antigravityUnifiedStateSync.sidebarWorkspaces'); VACUUM;"
But it’s only a temporary patch. ~12 hours after cleaning it, I checked the DB again and userStatus, theme, and sidebarWorkspaces were all back, despite never being recreated locally by me. That means the corrupted state is getting pushed back down through account sync from the server — not sitting in a stale local cache. Any local fix will only hold until the next sync.
New symptom since the resync: freezes are now shorter and usually self-recover (2-14s instead of permanent), but afterward the Agent Manager panel gets stuck in an infinite “Agent Loading” spinner that never completes, even after several minutes. The editor tab still opens files fine, but the agent side is unusable.
Workaround I’m using: a script that kills the process, re-runs the DELETE + VACUUM, and relaunches before every session. It shortens the freeze but doesn’t fix the Agent Loading hang, and has to be re-run constantly since the server keeps re-injecting the bad state.
Question
Since this is clearly server-side re-injection and not just a one-time local cache bug, could someone from the Antigravity team check whatever service is populating userStatus for affected accounts? A local DB fix can’t hold permanently if the server keeps sending the same corrupted payload back down. Happy to share full trace logs or account details privately if useful.
