There Was an Unexpected issue setting up your account in Antigravity with Fix

Google Antigravity
1

Many Users having issues majorly uncertain crash of antigravity frequently crashing and frequently logging out making the users data distrusted and frustrated.

After the v2.0.0 update, the IDE completely stopped working for me (chat, completions, and agents are dead). I spent today digging into the local processes and found the root cause: the release binary is pointing to your internal staging server instead of production.

Here is a breakdown of the issue and the sanitized logs.

The Core Issue

The language_server.exe process is being launched with the --cloud_code_endpoint flag set to https://daily-cloudcode-pa.googleapis.com instead of the standard cloudcode-pa.googleapis.com.

Because it is hitting the daily/staging endpoint with production OAuth tokens, Google’s backend rejects the connection and force-closes the TCP socket.

From main.log (around line 67):

Plaintext

Spawning: ...language_server.exe --standalone --override_ide_name antigravity
--override_ide_version 2.0.0
--cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com
--enable_sidecars

Downstream Impact & Network Failures

The server keeps trying to hit this staging endpoint every ~25-30 seconds. Here is the sequence from language_server.log:

Plaintext

13:10:29  WaitForReady failed: context deadline exceeded 
13:11:36  Cache(loadCodeAssistResponse): failed
          Cache(userInfo): failed
13:14:49  wsarecv: An existing connection was forcibly closed by the remote host.
13:15:29  Brief attempt at the PRODUCTION endpoint (cloudcode-pa.googleapis.com)
13:15:32  Immediately switched BACK to staging (daily-cloudcode-pa)
13:15:33  wsarecv again on fetchUserInfo

The wsarecv error occurs because the staging server kills the connection. Since the initial auth fails, loadCodeAssist, fetchUserInfo, and fetchAvailableModels all fail downstream.

Environment & State (Sanitized)

  • OS: Windows 11 x64

  • Version: Antigravity v2.0.0

  • Process: language_server.exe (Hovering around 223 MB private memory)

  • Network: 6 active TCP connections going to daily-cloudcode-pa over IPv6, all resulting in connection resets.

The Fix / Workaround

This appears to be fixed in v2.0.1 (released May 19), but the auto-updater is failing for some users (mine downloaded the update twice to %LOCALAPPDATA%\antigravity-updater\pending\ but never actually applied it).

For anyone else stuck: manually download v2.0.1 and reinstall to clear the daily- flag.

*Note: I have full memory dumps, TCP captures, and thread dumps available if the dev team needs them for triage. I’ve excluded raw IPs, tokens, and system paths here for privacy, but let me know if you need the raw files sent securely.
OR could also try running these script in powershell :
*

  1. Forcefully kill the buggy IDE and the runaway Go background binary

Write-Host “Stopping all hanging Antigravity processes…” -ForegroundColor Cyan
Get-Process Antigravity, language_server -ErrorAction SilentlyContinue | Stop-Process -Force

2. Obliterate the 700+ junk XML temp files generated by the failed retry loops

Write-Host “Purging junk XML artifacts from the polling loops…” -ForegroundColor Cyan
Get-ChildItem -Path “$env:LOCALAPPDATA\Temp” -Filter “xml_file (*).xml” -ErrorAction SilentlyContinue | Remove-Item -Force

3. Clear out the broken, stale update downloader cache

Write-Host “Clearing stuck auto-updater cache…” -ForegroundColor Cyan
if (Test-Path “$env:LOCALAPPDATA\antigravity-updater”) {
Remove-Item -Recurse -Force “$env:LOCALAPPDATA\antigravity-updater*” -ErrorAction SilentlyContinue
}

Write-Host “Cleanup complete! Your system is ready for a clean manual install of v2.0.1.” -ForegroundColor Green

Why this is needed for affected users:

  • Stops the Leak: Even if you close the IDE window, language_server.exe often stays active in the background as a zombie process, continuously chewing up private memory.

  • Reclaims Disk Space: The script safely targets only the specifically patterned trace files (xml_file (*).xml) inside the system Temp directory without messing with any other app data.

  • Resets the Updater: Wiping the pending folder clears the corrupted download states so the app doesn’t loop trying to apply a broken patch.