[Bug] Antigravity live discovery is blocked under TUN Fake-IP because its canonical URL is not registered #4261

Client or integration

Other — OpenCodex dashboard and ocx CLI in Docker behind a Clash/Mihomo-style TUN.

Provider or upstream service

google-antigravity / Google Cloud Code Assist (Gemini)

OpenCodex version

2.50.0 (2d4d7a22381a2e497c2442902104619e25f937c7)

Endpoint or capability

Live model discovery and provider connection test:

POST https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels

Current behaviour

With TUN-only Fake-IP DNS and no HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY in the Docker container, daily-cloudcode-pa.googleapis.com resolves to 198.18.7.201. OpenCodex builds the correct POST RPC, but isRegistryModelDiscoveryUrl() returns false because the google-antigravity registry entry has no modelDiscovery declaration. Destination policy blocks the request before HTTP and the dashboard falls back to configured models with “Discovery failed”.

Excluding only this hostname from Fake-IP makes the same account and configuration immediately discover 7 models. This rules out OAuth, account location, and the upstream response as the cause of this reproduction. This is not #723: no GET /models request or HTTP 404 occurs.

Expected behaviour

The exact built-in Antigravity discovery RPC should use the existing canonical TUN/Fake-IP exception. Custom hosts, modified paths or queries, literal benchmark-IP URLs, and unsafe DNS companions must remain blocked.

Minimal redacted request or reproduction

# Docker uses host/TUN DNS; no HTTP_PROXY/HTTPS_PROXY/ALL_PROXY is set.
getent ahostsv4 daily-cloudcode-pa.googleapis.com
# 198.18.7.201 ...

ocx provider test google-antigravity --json

# Runtime construction (redacted):
# method=POST
# url=https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
# canonicalDiscoveryProof=false

Actual response or error

Provider model discovery for "google-antigravity" was blocked by destination policy: provider URL hostname daily-cloudcode-pa.googleapis.com resolves to benchmark address (198.18.7.201) [urlClass=provider-models, fallback=configured].

No upstream HTTP status exists because the request is blocked before transmission.

Upstream documentation

No public specification was found for the private Cloud Code Assist discovery RPC. OpenCodex already implements and tests this authenticated POST contract in buildModelsRequest() and parseAntigravityAvailableModels(); #1897 established the live endpoint.

Suggested mapping or implementation notes

A minimal isolated experiment added the following declaration to the canonical google-antigravity registry entry:

modelDiscovery: { path: "./v1internal:fetchAvailableModels" }

The relative form preserves custom base URLs and path prefixes. In an isolated patched container forced to resolve the official host to 198.18.7.201, canonical proof became true, ocx provider test returned 7 models, and a Gemini 3.8 Flash request completed with HTTP 200.

A new regression test was red on the unmodified v2.50.0 image (39 pass / 1 fail) and green after the change. Four focused suites passed 87/87, along with TypeScript typecheck, Docker compatibility-manifest validation, Docker runtime build, GUI production build, and git diff --check.

The exact canonical URL was admitted. A custom https://custom.example/proxy destination retained its URL and canonicalDiscoveryProof=false; foreign-host and query-modified URLs also remained false. An absolute modelDiscovery.url experiment was rejected because it retargeted same-named custom-base-URL providers to the Google host.

Additional context and attachments

Related: #3781 (Antigravity quota-side canonical Fake-IP handling), #3618 (canonical TUN discovery infrastructure), #723 (historical GET /models bug; different endpoint and error), and #1897 (current Antigravity POST discovery RPC).

The same HTTP-preflight pattern may also affect the Grok and Claude discovery endpoints when they resolve into 198.18.0.0/15, but those providers were not authenticated or verified end to end here. They are mentioned only as possible follow-up scope for maintainers to assess, not as confirmed regressions and not as part of the requested fix.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on the existing canonical TUN/Fake-IP contract and the concrete built-in Antigravity discovery endpoint.