Antigravity works perfectly on your home Wi-Fi, but the moment you plug into the office network you get "Sign in failed" or "Network error: unable to reach Gemini API." If you are not the person who runs the corporate firewall, this can feel impossible to debug. I once lost half a day to this at a client site, and the checklist below is what finally got me moving again.
Proxy and firewall issues are tricky because very different root causes produce nearly identical symptoms. Changing settings at random usually makes things worse — I have seen people disable TLS verification to "make it work," only to find that the real problem was a missing allowlist entry that re-surfaced two days later. The fastest path forward is to figure out which layer is failing before you touch anything else, then apply the minimum change that actually fixes it.
Start By Reading the Actual Logs
The UI usually just shows "Sign in failed," which tells you nothing about whether it is a proxy, a certificate, or a blocked domain. You need the underlying log.
macOS / Linux:
# Antigravity is Electron-based, so its logs live here:
tail -f ~/Library/Logs/Antigravity/main.log # macOS
tail -f ~/.config/Antigravity/logs/main.log # LinuxWindows (PowerShell):
Get-Content "$env:APPDATA\Antigravity\logs\main.log" -Wait -Tail 100Keep that tail running, then launch Antigravity and trigger sign-in. The exact error code narrows the problem down almost instantly:
ETIMEDOUT/ECONNREFUSED— proxy not configured, or the firewall is silently dropping packetsunable to verify the first certificate/self signed certificate in certificate chain— corporate SSL inspection (MITM-style proxy)HTTP 407 Proxy Authentication Required— the proxy wants credentialsHTTP 403 Forbiddenongenerativelanguage.googleapis.com— domain is blocked on the allowlist
Do not try to solve this from "Sign in failed" alone. Treat the log line as the real error message, and match it against the sections below. If the log shows multiple error codes in sequence (very common — a proxy failure can cascade into a certificate failure), always tackle the first one that appears.
Routing Through an HTTP Proxy
Most enterprise networks force all traffic through a proxy. Antigravity's built-in network client normally respects system proxy settings, but for reliability I always set the environment variables explicitly. That way you know the values the runtime actually sees, not the values the OS claims are active.
# Add these to ~/.zshrc or ~/.bashrc
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.example.com"
# Launch Antigravity from the shell so the variables are inherited
/Applications/Antigravity.app/Contents/MacOS/AntigravityIf the proxy requires authentication, embed credentials with user:pass@. Any special characters (@, #, :) must be percent-encoded, or parsing will silently fail. Silent failures here are painful — the URL parses, the request goes out, it just never authenticates.
export HTTPS_PROXY="http://user:p%40ss@proxy.example.com:8080"One detail people miss: always include localhost and 127.0.0.1 in NO_PROXY. Otherwise traffic to your local MCP servers or dev servers gets shipped through the corporate proxy, and you end up debugging a phantom "cannot reach localhost" problem. I have seen this kill an entire afternoon. If you are running MCP, the MCP connection troubleshooting guide covers those failures in more depth.
A quick verification step I run after changing these variables: open a new terminal, run env | grep -i proxy to confirm the values propagated, then launch Antigravity from that same terminal. Launching from the Dock or Start Menu will not pick up shell-level exports.
Handling SSL Inspection and Self-Signed Certificates
Many enterprise networks run a TLS interception product such as Zscaler, Netskope, or a homegrown CA. From Antigravity's perspective, generativelanguage.googleapis.com no longer presents Google's certificate — it presents the corporate CA's version, and certificate validation fails.
The fix is to trust the corporate CA in both the OS trust store and the runtime Antigravity embeds. Trusting it at the OS level is not always enough, because Node.js-based runtimes sometimes ignore the system store and rely only on a bundled certificate file.
# Trust the corporate CA on macOS
sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain ~/Downloads/corporate-root-ca.pem
# Tell the Electron/Node runtime inside Antigravity where to find it
export NODE_EXTRA_CA_CERTS="$HOME/.ssl/corporate-root-ca.pem"On Windows, import the certificate into "Trusted Root Certification Authorities" via certmgr.msc, and set NODE_EXTRA_CA_CERTS as a user environment variable. On Linux, add the CA to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates, then still set NODE_EXTRA_CA_CERTS for safety.
I know the tempting shortcut is NODE_TLS_REJECT_UNAUTHORIZED=0, but please do not leave that on. It disables all certificate validation, which means your API keys and code diffs are effectively readable by anyone sitting on the path — not a hypothetical risk when you are on an untrusted network. Use it locally for a one-time confirmation only, then remove it once you have identified the real cause.
When Specific Domains Are Blocked
If proxy and certificates are both fine but only certain API calls fail, the problem is usually a missing entry on the firewall allowlist. Share this list with your network administrator so they can add the domains:
antigravity.google— auth and product surfacesaccounts.google.com/oauth2.googleapis.com— Google sign-ingenerativelanguage.googleapis.com— the Gemini API itself*.googleusercontent.com— avatars and static assetsstorage.googleapis.com— model and asset delivery
Ask specifically for FQDN-based allowlisting rather than IP allowlisting. Google's API endpoints rotate IPs constantly, so IP-based rules break again within days. If your security team insists on IP ranges, point them at Google's published IP ranges documentation and ask for automated sync — otherwise you will be back in the same conversation in 72 hours.
curl is a fast way to confirm reachability one domain at a time:
# Can we reach the Gemini API through the proxy?
curl -x "$HTTPS_PROXY" -I https://generativelanguage.googleapis.com/
# A healthy response is something like HTTP/2 404. Any response other than
# a timeout means the path is open; 401/403 still counts as "reached."If you get curl: (56) or a timeout, the network layer is still broken and no amount of app-level tweaking will help. The fix belongs on the network side. Bring the curl -v output to your network team — it shows exactly where the connection died, which saves everyone from the "works on my machine" debate.
When Only Sign-In Is Broken
Sometimes proxy, certificate, and domains are all correct, yet OAuth still fails. This is common on corporate accounts behind SSO (Okta, Azure AD). The browser-side redirect never makes it back to Antigravity, and you get stuck on a blank page after approving the prompt.
A few things to check:
- Is your default browser forced to Edge (or similar) where corporate policy blocks the redirect or extension handoff?
- Is loopback traffic to
localhost:9004blocked by the firewall? That is where the OAuth callback lands — some endpoint protection tools block loopback by default. - Is your Google Workspace admin holding the Antigravity OAuth scopes in "pending approval"?
The last one you cannot fix yourself. Ask your Workspace admin to allowlist Antigravity (the Google Developer OAuth client) in the admin console, and to confirm the requested scopes are approved for your user group. If any of that resonates, the sign-in and account error guide covers the same territory from the account side.
PAC Files and Runtime Verification
If your organisation distributes its proxy via a PAC file (a URL like http://wpad.example.com/wpad.dat), Antigravity can technically auto-discover it through the OS, but I have had much better luck short-circuiting that and setting HTTPS_PROXY directly after inspecting the PAC file myself.
Fetch the PAC file, open it in a text editor, and find the branch that matches generativelanguage.googleapis.com. Whatever proxy and port it returns is what you should set explicitly in your shell. It removes an entire class of "the OS says yes, the app says no" mismatches.
Once you have the settings in place, verify from inside the same environment Antigravity will run in:
# Confirm Antigravity can see your proxy variables
env | grep -iE "proxy|node_extra_ca"
# Test the full chain: your shell → proxy → Gemini API
curl -v -x "$HTTPS_PROXY" \
--cacert "$NODE_EXTRA_CA_CERTS" \
https://generativelanguage.googleapis.com/ 2>&1 | head -30If curl succeeds here but Antigravity still fails, the remaining variable is almost always the app launch context — restart Antigravity from the same terminal, not from the Dock or Start Menu. Spending 30 seconds on this verification loop saves most people hours of cargo-culting environment variables.
Closing Thoughts
Corporate-network problems always give in if you triage them in the right order. The single most useful thing you can do today is: open the log with tail -f, trigger sign-in once, and write down the first error code you see. Once you know whether it is ETIMEDOUT or self signed certificate, you know which section of this guide to come back to — and when you talk to your infrastructure team, a specific error code turns a vague complaint into a five-minute fix.