It is the middle of a productive afternoon. You hand a task to an Antigravity agent, the chat panel briefly flashes, and then the only thing on the screen is a red Failed to fetch. The cursor blinks, no tokens stream in, and you have no idea whether the problem is your machine, your office network, or Google's backend. I have been shipping iOS and Android apps as a solo developer since 2014, and traveling between cities means I run into this exact scenario more than I would like — hotel Wi-Fi, tethered SIMs, corporate guest networks. The order in which I check things has converged over the years, so this article walks through that order, from the most common cause to the most obscure.
If you simply restart Antigravity, the same error tends to come back the next morning. Peeling the layers off from the top is the fastest cure when an IDE bundles together a half dozen cloud calls, as Antigravity does.
Start by asking "how far did the request travel?"
Failed to fetch is a deliberately generic error thrown by the browser-style runtime that powers Antigravity's chat UI. The fastest way to scope the problem is to think along two axes: did the packet leave my machine, and where on the path did it die?
Open the developer tools first (Help → Toggle Developer Tools or Ctrl+Shift+I / Cmd+Opt+I), keep the Network tab open, then trigger the failure. The status code immediately tells you which third you are in:
(failed)or empty status: the packet never made it out. Local firewall, VPN, or proxy is the most likely culprit407 / 502 / 504: an in-path device (corporate proxy, SSL inspector) is interrupting you401 / 403or429: the request reached Google but was rejected — authentication or quota
This single minute of triage cuts the suspect surface by two-thirds. I now reach for it before I reach for the restart button.
Cause 1: Stale auth tokens
The most common cause, and the easiest to overlook, is an expired session. Antigravity caches Google account tokens locally, and a long machine sleep, a switch to another browser using the same account, or even a Google security policy refresh can quietly invalidate them.
Run through this:
- Open the command palette (
Ctrl+Shift+PorCmd+Shift+P) - Run
Antigravity: Sign Out - Run
Antigravity: Sign In - Complete the OAuth flow in the browser that pops up
If the browser never opens, or the callback URL hangs at localhost, another process is occupying the local callback port (Docker, a Rails dev server, and Next.js dev servers are common offenders). Check before retrying.
# macOS / Linux: see what's holding the callback port
lsof -i :8765
# Expected output (empty is good; if a row appears, kill that process)
# COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
# node 23456 user 18u IPv6 0xabc 0t0 TCP localhost:8765 (LISTEN)
# Windows (PowerShell)
# Get-NetTCPConnection -LocalPort 8765 | Select-Object OwningProcessIn my own usage, eight times out of ten the "broken hotel Wi-Fi" turns out to simply be a stale token. Sign-out / sign-in restores it.
Cause 2: Corporate proxy, VPN, or SSL inspection
This is the chunkiest layer to peel. If the failure starts the moment you flip on the company VPN, or if it works on cafe Wi-Fi but not in the office, then a corporate proxy or SSL inspection appliance (ZScaler, Netskope, Cisco Umbrella) is almost certainly intercepting the TLS handshake to Google APIs.
Set the proxy explicitly. The GUI under Settings → Network works, but I prefer to check this into the repo so the whole team gets the same behavior.
// .antigravity/settings.json (place at the repo root)
{
"http.proxy": "http://proxy.example.local:8080",
"http.proxyStrictSSL": false,
"http.proxyAuthorization": null,
"http.systemCertificates": true,
// Bypass internal hosts and localhost
"http.noProxy": [
"localhost",
"127.0.0.1",
"*.internal.example.local"
]
}Be deliberate about flipping http.proxyStrictSSL to false. If your corporate root certificate is already in the OS trust store, leave it true. Setting it to false and finding that the connection works is a signal that the certificate is missing — the right next move is to ask IT to push the root cert, not to keep strictSSL off forever. I have made that mistake on a deadline; the long-term cost was higher than the few hours saved.
Cause 3: DNS resolution failures
If the browser can reach google.com but Antigravity cannot, suspect DNS. Antigravity talks to *.googleapis.com and aiplatform.googleapis.com specifically. If those hostnames do not resolve, you get Failed to fetch.
Use nslookup (or dig) to check:
# Confirm the actual API hostname resolves
nslookup aiplatform.googleapis.com
# Expected output
# Server: 192.168.1.1
# Address: 192.168.1.1#53
# Non-authoritative answer:
# Name: aiplatform.googleapis.com
# Address: 142.250.196.138
# Force a known-good resolver (Cloudflare example)
# macOS: networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
# Linux: add `nameserver 1.1.1.1` to /etc/resolv.confIf nothing comes back, the upstream DNS on your Wi-Fi router or mobile carrier is misbehaving. After I started pinning Cloudflare's 1.1.1.1 on my devices for mobile work, the random "Failed to fetch" on the road dropped to almost zero.
Cause 4: Model-side rate limits and quotas
If the Network tab shows 429 Too Many Requests, the issue is not the network at all — it is the quota. This often hits right after a runaway agent burst-calls a tool dozens of times.
Quick mitigations:
- Lower
Settings → AI → Concurrencyto 1 or 2 (the default of 4 is fast but burns quota quickly) - Stop every other agent in the same session
Workspace → Trust → Reloadto clear cached failure state
Long term you may want to file for a higher quota, but for solo developer workloads waiting five to ten minutes is usually enough to recover. Running Antigravity alongside the maintenance load of a 50M+ install app catalog has taught me that fewer concurrent agents often produce a faster perceived experience.
Cause 5: Antivirus quietly swallowing the request
On Windows, ESET, Trend Micro, and Symantec are recurring suspects. Their "Web protection" / "TLS inspection" features transparently rewrite outbound TLS, and Antigravity's API calls do not survive the rewrite.
The cleanest test is to disable Web protection (only) for five minutes and see if the error stops. If it does, add Antigravity's executable to the AV exception list:
- Windows:
%LOCALAPPDATA%\Programs\Antigravity\Antigravity.exe - macOS:
/Applications/Antigravity.app/Contents/MacOS/Antigravity
Adjacent issues that often appear together
When network errors hit, nearby symptoms tend to follow. If any of these surface in the same window of time, you are likely chasing a single root cause:
- MCP connection failures in Antigravity — diagnosing the chain — TLS issues on the MCP server side overlap heavily with chat-side failures
- Configuring Antigravity behind corporate proxies and firewalls — proxy detail companion piece
- Practical .antigravityignore patterns — a different lever: shrink the request payload itself
Last resort: rotate the user cache
If none of the above moves the needle, rename the user cache directory and restart Antigravity. I have seen corrupt cache files quietly prevent the auth cookies from being written.
# macOS
mv ~/Library/Application\ Support/Antigravity/Cache ~/Library/Application\ Support/Antigravity/Cache.bak
mv ~/Library/Application\ Support/Antigravity/Code\ Cache ~/Library/Application\ Support/Antigravity/Code\ Cache.bak
# Windows
# Rename %APPDATA%\Antigravity\Cache to Cache.bakIf the failure does not return after the rename, leave the backup in place for three days and then delete it. That has been my standard recovery move for two years.
If you have walked all five causes and the error still stands, the next step is to capture a Wireshark trace of the TLS handshake to aiplatform.googleapis.com:443 together with your network team. Before getting there, try the Network tab and the Sign Out → Sign In cycle today — it costs you a minute and resolves the majority of cases. Thank you for reading; I hope this saves another developer the afternoon I lost the first time around.