You open Antigravity, talk to the agent, and get nothing back. You check the logs and find a single line: self-signed certificate in chain, or unable to verify the first certificate. The other day, working from a co-working space while traveling, this was the very first wall I hit. Everything ran fine at home, but the moment my network changed, connections to the model — and only those — started failing.
Here is the short version. This error is almost never a bug in Antigravity itself. It means there is a middlebox between you and Google's servers that terminates TLS, inspects the traffic, and re-establishes the connection — a corporate proxy, a cloud gateway like ZScaler, or your antivirus's HTTPS scanning feature. These devices inject their own certificate mid-stream, and the Node.js runtime bundled inside Antigravity decides it doesn't recognize that certificate, so it refuses the connection.
As an indie developer shipping apps since 2014 — and someone who does art work around the world, hopping between café and hotel networks — certificate errors like this are practically a travel companion. Here is the diagnostic sequence I actually use, starting from how to reproduce it.
Read the symptom correctly first
This problem shows up under several different messages. The common ones:
Error: self-signed certificate in chainunable to verify the first certificateUNABLE_TO_GET_ISSUER_CERT_LOCALLYrequest to https://... failed, reason: ... certificate
Different wording, same event: the certificate chain could not be traced all the way back to a trusted root. The key signal is that this symptom is network-dependent. If it never happens on your home line but appears the moment you join your office or a specific Wi-Fi, the cause is almost certainly TLS inspection somewhere on the path.
As a first step, run this from a terminal on the same network:
node -e "require('https').get('https://generativelanguage.googleapis.com', r => console.log(r.statusCode)).on('error', e => console.error(e.code, e.message))"If this returns a SELF_SIGNED_CERT_IN_CHAIN-style error, then certificate verification is failing at the Node.js layer, not inside Antigravity. Antigravity uses a Node-based runtime internally, so this result directly explains its behavior.
Why a "valid" certificate gets rejected
To inspect encrypted traffic, a corporate proxy or security suite terminates TLS, then presents a certificate it re-signed with its own root CA. If that CA is installed in your OS certificate store, your browser works without complaint.
The catch is that Node.js does not fully consult the OS certificate store — it uses its own bundled list of root certificates. That is exactly why the browser succeeds while Antigravity alone fails. The certificate isn't broken; Antigravity simply was never told about that CA.
Fix 1: Tell Node about the CA it should trust (recommended)
The cleanest fix is not to disable verification but to explicitly hand Antigravity the CA your company or device uses. Node.js has an environment variable, NODE_EXTRA_CA_CERTS, that appends a PEM file you point it at to the default root set.
First, obtain the CA certificate (extension .pem or .crt) from your IT department, or export it from the OS store — Keychain Access on macOS, Certificate Manager on Windows.
Then launch Antigravity in a way that actually inherits the environment variable. Launching from the GUI sometimes ignores variables set in your shell, so starting from a terminal is the reliable path.
On macOS:
export NODE_EXTRA_CA_CERTS="$HOME/certs/corporate-ca.pem"
open -a "Antigravity"On Windows (PowerShell):
$env:NODE_EXTRA_CA_CERTS = "C:\certs\corporate-ca.pem"
Start-Process "Antigravity"If you want it to apply even when launching from the GUI shortcut, use launchctl setenv on macOS or a System environment variable on Windows.
# macOS: pass the variable to GUI apps too
launchctl setenv NODE_EXTRA_CA_CERTS "$HOME/certs/corporate-ca.pem"
# After this, log out and back in, or fully restart AntigravityIf you need to trust several CAs, concatenate the PEM blocks into a single file and all of them become trusted at once.
Fix 2: Route through the proxy correctly
Even with the certificate resolved, in environments where you can only reach the outside world through a proxy, packets won't reach the destination at all. Set the standard proxy environment variables:
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
# Don't proxy internal hosts or localhost
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"One caution here: the proxy variables and NODE_EXTRA_CA_CERTS are often both required at the same time. Fixing only one side — "the proxy works but the cert is rejected," or "the cert is loaded but I can't get out through the proxy" — won't restore the connection. I lost a full day early on because I set only the proxy and assumed I was done. Think of them as two wheels of the same cart.
What not to do
Search around and you'll find NODE_TLS_REJECT_UNAUTHORIZED=0, which disables verification entirely. It does make the error vanish, but it means turning off TLS verification across the board, leaving you exposed to man-in-the-middle attacks. It's fine for a quick diagnostic, but don't leave it in your day-to-day setup. Rather than removing verification, teach Node the correct CA — keep that direction and you stay safe.
Prevention
If you move between networks often, keep a single PEM file of the CAs you trust and register it permanently via launchctl setenv (macOS) or a System environment variable (Windows), so you don't scramble every time the line changes. I work from cafés a lot, so I run a quick check on home, co-working, and mobile connections once each, and keep notes on the spots that tend to trip me up. Set it up carefully just once, and Antigravity comes up the same way no matter where you are.
Once the connection is back, run the one-liner from Fix 1 again and confirm you get a 200 before returning to real work. If this shortens the detour for anyone stuck on the same certificate error, I'll be glad.