Repository navigation
[Bug]: Misleading "Broken IPv6" network timeout error shown when Antigravity runtime hangs at startup #29039
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- On an Intel Mac or an environment where agy_acp_server.par fails or hangs during startup (e.g. [Bug]: Antigravity won't install on Intel Macs — the runtime hangs at startup #16714).
- Go to Settings -> Providers -> Antigravity.
- Click "Sign in" (OAuth personal).
- Wait 30 seconds.
Expected behavior
If the Antigravity child process has not emitted any stdout/JSON-RPC response or has hung during initialization, the UI should indicate that the provider process is unresponsive / timed out starting up, rather than diagnosing a network issue.
Actual behavior
T3 Code displays:
"Antigravity has not reached Google after 30 seconds. Check this machine's network connection. Broken IPv6 is a common cause."
This diagnostic is misleading when the issue has nothing to do with networking or IPv6, but rather that the local agy_acp_server.par subprocess hung before it could even begin the OAuth flow or emit a sign-in URL.
Impact
Blocks work completely
Version or commit
No response
Environment
macOS 15 (darwin-x86_64), T3 Code (Beta)
Logs or stack traces
Antigravity sign-in timed out waiting for authorization URL after 30000msScreenshots, recordings, or supporting files
No response
Workaround
Diagnosing the hang required manual process stack sampling (sample ) to find that the runtime was stuck in libffi before any network connection attempt was made.
Activity
hdkiller commentedon Nov 8, 2026
Can confirm this behavior on an Intel Mac mini (
darwin-x86_64).Investigation details
Looking at
apps/server/src/provider/AntigravityAuth.ts:runSignIninitializes the runtime and concurrently forks a 30s timer (NO_RESPONSE_HINT_MS = 30_000):AUTH_TIMEOUT_MS(5 minutes) expires, it fails withUNREACHABLE_MESSAGE:Both messages attribute the failure to networking/IPv6 reaching Google. However, in our trace logs on
darwin-x86_64,yield* runtime.initialize()hung indefinitely because the spawnedagy_acp_server.parsubprocess was stuck in an infinite loop insidelibffi(dlmmap_locked), as reported in #16714 (Google ships the binary with Hardened Runtime enabled but lackingcom.apple.security.cs.allow-unsigned-executable-memory). No network packets were ever sent.Proposed Improvement
Separate child process health from network readiness:
runtime.initialize()(the local JSON-RPC handshake with the child process) does not complete within a short startup window, report that the local provider runtime subprocess is unresponsive or hung.