Antigravity Behind a Corporate Proxy or Firewall

If Antigravity works on an approved alternate network but fails on the corporate network, treat that as evidence of a network-policy difference—not proof of a specific proxy, certificate, or blocked Google hostname. Capture the failing host and error, check Antigravity's own permissions, then have IT configure the managed proxy and trust chain without disabling TLS verification.

The Practical Verdict

Google's public Antigravity documentation does not currently publish a complete consumer-product egress allowlist or an Antigravity-specific proxy-variable contract. Avoid copied “exact domain lists,” undocumented editor settings, assumed loopback behavior, and guesses about an embedded runtime. Observe the hostname that fails in your environment and change only the layer proven to be responsible.

Separate Antigravity Policy from the Corporate Network

A blocked agent request can come from Antigravity itself. The official permissions documentation says read_url controls outbound web access and, when terminal sandboxing is enabled, supplies the sandbox's allowed domains. The official IDE settings guide also documents a separate sandbox network-access toggle.

1. Reproduce one small failing action and note whether Antigravity shows a permission prompt or sandbox denial.
2. Open the relevant Global or Project settings and inspect URL permissions and sandbox network access.
3. Grant only the hostname required for the task. A broad read_url(*) rule is not needed for diagnosis.
4. If the same request still fails outside the sandbox, continue with the corporate-network checks below.

Capture the Failure Before Changing Configuration

Record the timestamp, Antigravity version, active account type, exact error text, and destination hostname. If the product does not expose the hostname, ask the network administrator to filter proxy or firewall logs for your device and the reproduction time. Never send access tokens, cookies, authorization headers, full signed URLs, or proprietary prompt bodies.

From a terminal governed by the same corporate policy, test the observed hostname:

nslookup actual-host.example
curl -Iv --connect-timeout 10 https://actual-host.example/

Replace actual-host.example with the host from your own trace. A DNS error, connection timeout, proxy 407, TLS certificate error, or HTTP response point to different layers. An HTTP status means some responder was reached, but it may be a forward proxy, gateway, WAF, or the origin. Use verbose output, certificate details, and response headers to identify it; the status alone does not prove the origin's DNS or TLS path completed. This command tests the terminal path, not necessarily every Antigravity process, so use it as comparison evidence rather than a product verdict.

Configure the Proxy Safely

Chromium's documented network design uses system network settings for proxy, TLS, and certificate stores. Start with the organization-managed OS proxy profile; do not invent an Antigravity settings.json key or argv.json flag. Google's current Antigravity docs do not document either as a supported proxy interface. See the Chromium network-settings design for the browser-runtime principle.

Child tools are separate. Git, npm, curl, MCP servers, and user-run Node programs may each have their own proxy configuration. Configure only the tool that fails, following that tool's documentation. Node's current documentation supports environment-proxy handling only in versions and modes that enable --use-env-proxy or NODE_USE_ENV_PROXY=1; that does not prove that Antigravity itself inherits or enables those options.

Trust the Corporate CA Without Weakening TLS

If the certificate issuer shown by the failing connection is your organization's approved TLS-inspection CA, ask IT for the official root/intermediate certificate and installation procedure. Install it through the managed OS trust mechanism, restart the affected application, and retest. If the issuer is unexpected, stop and escalate instead of trusting it.

For a Node program you own, Node documents NODE_EXTRA_CA_CERTS as a PEM bundle that extends trusted CAs and is read only when the Node process starts. Use it only for that verified Node tool and only with an IT-provided certificate. Do not present it as an Antigravity-wide fix.

Build an Evidence-Based, Non-Exhaustive Allowlist

There is no complete public Antigravity consumer egress list in the current docs. The official enterprise setup names aiplatform.googleapis.com for the Gemini Enterprise Agent Platform integration, but that is one documented enterprise dependency—not a universal Antigravity allowlist. Product surface, account type, selected features, region, and release can change the hosts used.

Verify the Smallest Change and Keep a Rollback

1. Save the original proxy, trust, and Antigravity permission values.
2. Apply one approved change.
3. Fully restart the affected process because trust and environment settings are commonly loaded at startup.
4. Repeat the same small Antigravity action and the same timestamped terminal comparison.
5. Confirm unrelated internal sites and development tools still work.
6. If the result does not change, restore the previous value before testing the next hypothesis.

Do not delete Antigravity caches or credential stores as a networking experiment. Cache deletion cannot repair a blocked TCP route or an untrusted certificate, and it can destroy useful state.

Escalate with Evidence IT and Google Can Use

• Exact local time and timezone of one reproduction
• Antigravity product surface and version
• Managed network/VPN state and whether an authorized comparison network differs
• Destination hostname, proxy status, and certificate issuer—sanitized
• Whether the denial came from Antigravity permissions, terminal sandboxing, OS proxy, or perimeter logs

Antigravity's official settings documentation identifies Feedback as the in-product reporting path. For generic network-message triage, continue with our Antigravity “Failed to fetch” guide. For MCP-only failures, use the MCP timeout guide.

Frequently Asked Questions

Which domains should my firewall allow?

Use the FQDNs observed in your own Antigravity and network logs. Google does not currently publish a complete universal Antigravity consumer allowlist; the enterprise API named in official docs is not an exhaustive list.

Should I disable certificate checks to confirm TLS inspection?

No. Inspect the returned certificate chain and have IT deploy the approved CA or policy exception. A TLS bypass both weakens security and makes the test less representative.

Do HTTPS_PROXY and NODE_EXTRA_CA_CERTS configure all of Antigravity?

No supported public Antigravity documentation establishes that contract. Those settings may apply to particular child tools; test and document them per tool instead of treating them as global product settings.

All Sources and Links

Official Antigravity documentation

• Agent permissions and sandbox domain controls
• IDE settings and sandbox network access
• Antigravity 2.0 settings and Feedback
• Antigravity enterprise setup

Primary runtime and network documentation

• Chromium network settings
• Chromium NetLog capture guidance
• Node.js environment-proxy option
• Node.js extra CA certificates
• curl command reference