Hey team,
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-paover 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 :
*
- 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.exeoften 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
pendingfolder clears the corrupted download states so the app doesn’t loop trying to apply a broken patch.