Running Antigravity Behind a Proxy — Connection Design for Corporate Networks, SSL Inspection, and Hotel Wi-Fi

Baseline Proxy Settings — Why settings.json and Environment Variables Must Both Be Set

The Antigravity application itself (the Chromium layer) reads settings.json and the OS proxy configuration. Start there.

// settings.json — the three basic proxy settings
{
  // Replace with the proxy value your company distributes
  "http.proxy": "http://proxy.example.com:8080",
 
  // I make settings.json the single source of truth to avoid double management
  "http.proxySupport": "override",
 
  // Keep certificate verification ON (the next section explains why)
  "http.proxyStrictSSL": true
}

Meanwhile, the tools the agent spawns as child processes — git, npm, curl — never read settings.json. They only read environment variables. When completion works but the agent's tool execution keeps failing, this is almost always the hole.

# ~/.zshenv — proxy settings for CLI tools and child processes
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="$HTTPS_PROXY"
# Some tools still read only the lowercase variants, so define both
export https_proxy="$HTTPS_PROXY"
export http_proxy="$HTTP_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

There is a macOS-specific trap here. GUI apps launched from the Dock or Spotlight do not read your shell's configuration files. The classic symptom — it works when launched from a terminal, goes silent when launched from the Dock — is exactly this. I lost a few days to "it worked yesterday but not today" before realizing the difference was simply how I had launched the app.

To make environment variables reach GUI launches as well, use launchctl.

# Make the variables visible to Dock/Spotlight launches of Antigravity — macOS
launchctl setenv HTTPS_PROXY "http://proxy.example.com:8080"
launchctl setenv HTTP_PROXY  "http://proxy.example.com:8080"
launchctl setenv NO_PROXY    "localhost,127.0.0.1,::1"
# Takes effect only after a full quit and relaunch (Cmd+Q, then reopen)

You might wonder whether one of the two — settings.json or environment variables — would be enough. I always set both. A state where the IDE connects but every agent tool call dies, or the reverse, costs far more diagnostic time than a clean total failure ever does.

SSL-Inspecting Proxies — Add Trust Instead of Disabling Verification

If the issuer in check (3) turned out to be a corporate CA, you will see errors like self signed certificate in certificate chain or UNABLE_TO_VERIFY_LEAF_SIGNATURE until you deal with it. The fastest band-aid is "http.proxyStrictSSL": false — and I am firmly against making that permanent.

The reason is simple: what Antigravity sends to the model API is your source code. Disabling verification means you can no longer tell who is decrypting that traffic. As a way of trusting only your company's proxy, it is far too blunt — the same setting will happily trust a shady hotel network too.

The proper fix is to add the inspecting proxy's CA certificate to your trusted roots. If your IT department distributes one, use it; if not, you can extract it yourself.

# (1) Extract the certificate chain the proxy is injecting
mkdir -p ~/certs
openssl s_client -connect generativelanguage.googleapis.com:443 \
  -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' > ~/certs/corp-proxy-chain.pem
 
# (2) Verify whose certificate this is — the issuer should show your corporate CA
openssl x509 -in ~/certs/corp-proxy-chain.pem -noout -subject -issuer
# Example output:
# subject= /O=ExampleCorp Security/CN=ExampleCorp TLS Inspection CA
# issuer=  /O=ExampleCorp Security/CN=ExampleCorp Root CA

Then distribute that trust to each layer.

# (3) Trust for Node-based runtimes (agent, extensions)
#     NODE_EXTRA_CA_CERTS *adds to* the default roots — it does not replace them
export NODE_EXTRA_CA_CERTS="$HOME/certs/corp-proxy-chain.pem"
 
# (4) Give the same trust to the tools the agent spawns
git config --global http.sslCAInfo "$HOME/certs/corp-proxy-chain.pem"
npm config set cafile "$HOME/certs/corp-proxy-chain.pem"
 
# (5) For the IDE itself (Chromium layer), go through the keychain — macOS
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain ~/certs/corp-proxy-chain.pem

I prefer NODE_EXTRA_CA_CERTS for two reasons. First, it adds rather than replaces, so trust in public CAs stays intact. Second, it is an environment variable, so removing it is a one-liner: leave the corporate network, unset it, and the trust in the inspection CA disappears with it. The trustRoot entry deserves the same discipline — delete it when the assignment or the trip ends, so no leftover trust quietly follows you home.

Authenticated Proxies — A Relay Setup That Keeps Credentials Out of Plaintext

When the corporate proxy requires user authentication, the first idea that comes to mind is embedding credentials in the URL.

# It works, but I do not recommend it
export HTTPS_PROXY="http://masaki:P@ssw0rd@proxy.example.com:8080"

The problem: your password now lives in plaintext in env output, shell history, the process list, and your dotfiles. I sync my configuration files through Git across two Macs, so adopting this style would put me one careless commit away from pushing credentials to a repository. Years of handling AdMob and payment keys for my app business taught me to reject any design that multiplies plaintext locations, before convenience gets a vote.

What I use instead is a local relay proxy, one hop in front.

• Antigravity → (no auth) → local relay at 127.0.0.1:3128 → (NTLM/Basic auth) → corporate proxy

A lightweight tool like px works well as the relay. Only the relay process knows the credentials; they vanish from Antigravity's configuration entirely.

// settings.json — the IDE holds no credentials at all
{
  "http.proxy": "http://127.0.0.1:3128",
  "http.proxySupport": "override"
}

# Point the environment at the relay too — the password is written nowhere
export HTTPS_PROXY="http://127.0.0.1:3128"
export HTTP_PROXY="$HTTPS_PROXY"

The payoff is that credentials live in exactly one place: the relay's configuration. When the password rotates, there is one thing to change, and Antigravity, git, and npm are untouched. "One secret, many references" — the same principle I follow for API key management in my apps.

Designing NO_PROXY — Keeping Ollama and LM Studio Off the Proxy, Reliably

The most common piece of collateral damage right after configuring a proxy: "the local LLM that worked yesterday has disappeared." Once HTTPS_PROXY is defined, even traffic to 127.0.0.1 gets forwarded to the proxy unless you explicitly exclude it. To the corporate proxy, localhost means itself — so your requests will never reach the Ollama instance running on your own Mac.

NO_PROXY syntax carries an implementation-difference trap.

• Some tools do not interpret CIDR notation (192.168.0.0/16)
• Some implementations ignore port-qualified entries (127.0.0.1:11434)
• Wildcard handling (*.local) differs from tool to tool

So I lean on explicit enumeration of hosts and IPs, and avoid clever syntax altogether.

# Exclude local inference from the proxy — enumerate explicitly, skip clever syntax
export NO_PROXY="localhost,127.0.0.1,::1,192.168.11.20,mac-studio.example-tail.ts.net"
export no_proxy="$NO_PROXY"
 
# Verify: can you still reach Ollama directly with proxy variables set?
curl -s --max-time 3 http://127.0.0.1:11434/api/tags | python3 -m json.tool | head -6
# Expected output (a model list means NO_PROXY is working):
# {
#     "models": [
#         {
#             "name": "gemma4:27b",
# ...

The 192.168.11.20 and ts.net entries are from my own setup — a Mac Studio at home serving as an inference machine, reached from outside via Tailscale. If you keep an inference box on your LAN or VPN, remember to enumerate it as well. For LM Studio-specific symptoms, the isolation steps in LM Studio Models Not Visible or Disconnecting in Antigravity — Ports, CORS, and Model Visibility should help.

You may be tempted by NO_PROXY=* — exclude everything. On a proxy-mandatory network, that kills every external API at once. Express your actual intent in the NO_PROXY list — local goes direct, external goes through the proxy — and the configuration keeps meaning the same thing no matter which network you carry it to.

The Reality of Networks on the Road — Captive Portals, Tethering, and Profile Switching

Now for the part about working from hotels and venues. I have run my app business as an indie developer for over a decade, and these past few years the exhibitions have kept me moving abroad for weeks at a time. The user reviews and crash reports behind 50 million cumulative downloads do not pause while I travel, so Antigravity inevitably gets opened on a lot of hotel connections.

What that experience has taught me: networks on the road behave worse than corporate proxies.

• While a captive portal is unauthenticated, all HTTPS gets hijacked toward the consent page and turns into certificate errors. Nothing is broken — you just have not seen the consent screen yet
• Transparent proxies in budget hotels and venues sometimes buffer streaming responses. If chat answers arrive as one big lump after a long silence, that is it — no client setting fixes it, and switching lines is the correct move
• Downloading models over metered tethering is an accident waiting to happen. I once pulled Gemma 4's 27B over metered tethering between exhibition-setup sessions and burned several days' worth of data in a single evening. The lesson, learned that night: run ollama pull while you still have a fixed line This life eventually produced a small set of shell functions for switching and checking network state in one command.

# ~/.zshrc — connection profile switching and a quick locator
proxy_on() {   # entering a corporate/venue proxy network
  export HTTPS_PROXY="http://proxy.example.com:8080"
  export HTTP_PROXY="$HTTPS_PROXY" https_proxy="$HTTPS_PROXY" http_proxy="$HTTPS_PROXY"
  export NO_PROXY="localhost,127.0.0.1,::1" no_proxy="localhost,127.0.0.1,::1"
  echo "proxy ON: $HTTPS_PROXY"
}
 
proxy_off() {  # back to direct connection or tethering
  unset HTTPS_PROXY HTTP_PROXY https_proxy http_proxy NO_PROXY no_proxy
  launchctl unsetenv HTTPS_PROXY 2>/dev/null
  launchctl unsetenv HTTP_PROXY 2>/dev/null
  echo "proxy OFF"
}
 
net_check() {  # where am I right now, in three lines
  echo "captive: $(curl -s -o /dev/null -w '%{http_code}' --max-time 5 http://captive.apple.com/hotspot-detect.html)"
  echo "proxy:   ${HTTPS_PROXY:-none}"
  echo "ollama:  $(curl -s --max-time 2 http://127.0.0.1:11434/api/tags >/dev/null 2>&1 && echo OK || echo NG)"
}

Even on a travel day when the network is completely dead, local Gemma 4 keeps completion and refactoring conversations alive. For the offline-first setup, see Integrating Gemma 4 Local Models into Antigravity — AI Development in Offline and Air-Gapped Environments; for automatic switching between cloud and local, see Antigravity × Multi-Provider LLM Failover — A Production Setup That Keeps Gemini, Claude, and Local Gemma Running. Once I started treating proxy design and the local fallback as one package, development on the move became noticeably more stable.

Common Mistakes and Pitfalls

From my own failures and from readers' questions, in descending order of how often they recur.

• proxyStrictSSL: false survives for a year: the classic pattern — a business-trip band-aid becomes permanent configuration. Using it as a band-aid is fine; just pair it with an undo step. I put "restore strictSSL" on the calendar the same day I change it
• Variables written only in .zshrc never reach GUI launches: Dock-launched apps do not read shell rc files. Either pair them with launchctl setenv, or commit to always launching from a terminal — pick one and stop wavering
• Cramming CIDR, ports, and wildcards into NO_PROXY: produces the worst possible middle state, where the list works for some tools and silently fails for others. Explicit enumeration is boring and correct
• Hardcoding user:pass@ in settings.json and letting Settings Sync pick it up: your credentials get replicated to every synced machine and the sync service itself. Either exclude proxy settings from sync, or move to the relay setup so there is nothing secret in the settings at all
• Misdiagnosing an unauthenticated captive portal as a certificate problem: start fiddling with NODE_EXTRA_CA_CERTS over a hotel error page, and things will still be broken when you get home. Fix the diagnostic order — captive → proxy → issuer — and this misdiagnosis becomes structurally impossible
• Works at the office, fails at home: usually a leftover launchctl setenv proxy still pointing at an unreachable host. This is exactly why proxy_off includes launchctl unsetenv

Closing — Connections Are Something You Design, Not Something That Breaks

Proxy handling tends to become reactive — something you investigate only when things stop working. But for a way of working that assumes movement and changing environments, treating the connection layer itself as a design target turned out to be far less effort in total. Reverse-map symptoms to layers, decide where each layer's configuration lives — settings.json, environment variables, certificates, NO_PROXY — and any unfamiliar network tells you where you stand within ten minutes.

The next time you change networks, run the three lines of net_check before touching a single setting. Once knowing where you are becomes a habit, the proxy stops being an opponent and becomes just another precondition. If you also build and ship things from wherever life takes you, I hope this note saves you an evening or two.