Antigravity “Failed to Fetch”: Safe Network Triage

Error: [unknown] Failed to fetch is a symptom, not a root cause. First determine whether Antigravity denied the request, the network failed before an HTTP response, or a server returned a status code. Do not clear caches, change DNS, or weaken TLS until the evidence points to that layer.

What “Failed to Fetch” Can and Cannot Tell You

The browser Fetch API documentation says a fetch promise rejects for network-level failures but normally resolves when the server returns an HTTP error such as 404 or 504. Antigravity may wrap errors from several internal surfaces, so the text alone cannot prove a firewall, Google outage, expired token, or quota problem. A visible HTTP status, destination host, and certificate error are much stronger evidence.

Avoid undocumented developer-menu commands, guessed cache paths, fixed wait times, and any assumption that a status code identifies one owner without the responding host and headers.

Capture One Small Reproduction

1. Choose the smallest action that reliably fails. Avoid a long agent task with many tools.
2. Record the exact local time and timezone, Antigravity surface/version, active project, and exact error text.
3. If the UI exposes request details, record the hostname and status. Otherwise ask IT to inspect proxy/firewall logs for that timestamp.
4. Note whether ordinary Antigravity conversation works and only a URL-reading or terminal action fails.
5. Sanitize tokens, cookies, query strings, prompt content, source code, and account identifiers before sharing evidence.

Decision Table: Route by Observable Evidence

Check Antigravity Policy Before the Perimeter

Antigravity's official permissions guide documents that read_url governs outbound URL access and can feed the terminal sandbox's domain allowlist. The IDE settings guide documents a separate sandbox network-access toggle. If chat works but a terminal or URL tool fails, inspect these controls before changing the corporate firewall.

Grant only the required hostname and repeat the same action. If the denial disappears, the root cause was product policy. If Antigravity still shows a DNS, connection, or certificate failure, restore any diagnostic permission you do not want to keep and continue to the network path.

Test the Observed Network Path

Use the hostname from the failed request or administrator logs—not a guessed list of Google services:

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

• DNS fails: verify the corporate resolver/VPN state with IT. Do not switch a managed device to public DNS unless policy explicitly permits it.
• Connection times out or resets: compare the timestamp with firewall/proxy logs. A terminal success does not guarantee every app process follows the same route.
• TLS fails: record the certificate issuer and error. If it is the approved inspection CA, use IT's managed trust procedure. Never disable certificate validation.
• An HTTP status appears: some HTTP responder was reached. Use the certificate and headers to distinguish a proxy or gateway from the origin before applying status-specific checks.

See the dedicated corporate proxy and firewall runbook for safe trust and allowlist guidance.

Interpret the HTTP Responder, Not Just the Number

The HTTP status code is useful only with the responding host and headers. The HTTP Semantics specification defines the status classes, but a proxy can generate a 5xx just as an origin service can.

• 401/403: if the responder is a confirmed Antigravity service, open Settings and confirm the expected account and project scope. The current settings docs place account sessions under Global Settings. If a proxy or other origin responded, follow that owner's authentication path. Do not delete credential stores.
• 407: IT must correct proxy authentication or policy. Do not put proxy passwords in repositories, shell history, or screenshots.
• 429: honor server-provided retry guidance and identify the responder. Use Antigravity's usage/quota UI only when the response belongs to the product service; a proxy or other API can enforce its own rate policy. A hard-coded “wait five minutes” rule is not reliable.
• 5xx: note whether the response came from a Google host or an intermediary, preserve a sanitized request ID, retry once after a short pause, then escalate if reproducible.

Verify the Fix and Keep the Test Reversible

1. Save the original setting before changing it.
2. Change one layer only: Antigravity permission, OS proxy/trust, account session, or administrator rule.
3. Restart only when that setting is loaded at process startup.
4. Repeat the same small action and record the new timestamp/result.
5. Test one unrelated workflow to catch collateral breakage.
6. If nothing changed, restore the previous value before trying the next hypothesis.

Escalate Without Leaking Secrets

Send Google or IT the product/version, OS, timestamp/timezone, failing action, hostname, status or network error, certificate issuer, request ID, and whether the issue reproduces on an authorized comparison network. Antigravity's official settings guide identifies Feedback as the in-product reporting route. The Google AI Developers Forum can reveal similar user reports, but forum diagnoses are community evidence rather than official product behavior.

Frequently Asked Questions

Does “Failed to fetch” mean Google is down?

No. Without a responding hostname, HTTP status, or service notice, the phrase does not identify who failed. Capture the network layer before assigning ownership.

Should I clear Antigravity's cache?

Not for an unclassified network error. Cache deletion cannot repair DNS, routing, proxy authentication, or certificate trust and may remove useful state.

Will changing to public DNS fix it?

Only a proven resolver failure makes DNS relevant. On managed devices, use the organization-approved resolver and involve IT rather than bypassing network policy.

Can I ignore certificate errors temporarily?

No. Record the issuer and error, then install only an administrator-approved CA through the supported trust mechanism.

All Sources and Links

Official Antigravity documentation

• Agent permissions and sandbox URL access
• IDE settings and sandbox network access
• Antigravity settings, account scope, and Feedback

Browser and protocol references

• MDN: Window.fetch()
• MDN: Response.status
• RFC 9110: HTTP status codes
• curl command reference

Community reports

• Google AI Developers Forum: Antigravity category (user reports; not normative documentation)