[Bug]: Antigravity Google sign-in stalls on Linux when IPv6 OAuth connections are unreachable #16781

Before submitting

• I searched existing issues and did not find a duplicate with this Linux OAuth/IPv6 connection failure; related reports are distinguished below.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server — Antigravity provider authentication, observed through apps/desktop.

Steps to reproduce

Network precondition: IPv6 sockets are supported and Google hostnames resolve to IPv6 addresses, but outbound IPv6 HTTPS connections to Google's OAuth endpoint stall. IPv4 HTTPS to the same endpoint works. This is not an environment with IPv6 disabled in the kernel.

1. Run the Linux x86_64 T3 desktop app with its local bundled server.
2. Enable Antigravity in Settings > Providers and install the managed ACP runtime. Leave Binary path empty initially; select personal Google account authentication (oauth-personal).
3. Have an existing saved Google login in the instance's private profile that requires a token refresh. This was the initial state on this machine.
4. Click Sign in. The UI stays at “Starting sign-in…” and does not expose a usable Google sign-in link.
5. Cancel, fully quit/reopen T3, retry, update T3, and reinstall Antigravity. These steps did not resolve the failure here.
6. To distinguish Google OAuth/network behavior from the desktop browser handoff, initialize and authenticate the installed official ACP runtime directly using a fresh temporary profile. It produces a Google authorization link. Complete OAuth in a local browser: the callback page reports success, but final token exchange can still stall on IPv6.

This is a reproduction on the affected real network, not a synthetic packet-drop test. A deterministic failure-injection harness and reproduction on other machines have not been completed.

Expected behavior

Google account sign-in and credential refresh should complete using a working connection. When the runtime cannot reach Google's OAuth service, setup should report a useful network failure rather than remain at the initial sign-in message and suggest another reinstall. A working IPv4 route should not be masked by a stalled IPv6 connection.

The OAuth callback page should not be mistaken for completion: final credentials must be saved and account/model access verified.

Actual behavior

The installed runtime stays alive, but the desktop provider remains stuck during sign-in. The initial provider card showed “Needs attention” and “Antigravity is installed. Google account access is not checked yet.” Reinstallation and application restarts did not help.

With direct terminal OAuth, the browser showed “Authentication successful” while the runtime was still waiting and the credential file had not yet been saved at the first checks. A runtime socket was observed in SYN-SENT to a Google IPv6 address on port 443. Credentials were eventually saved later; authentication was only considered successful after the ACP response and saved credentials were verified. This is a prolonged stall, not proof that the exchange can never finish.

Impact

Major degradation or frequent failure — prevented using this Antigravity provider through normal setup until a local workaround was applied; other providers were not the subject of this report.

Version or commit

Installed version verified during investigation after the update attempt: T3 Code 0.0.46-nightly.20261007.2761.

Official Google managed Antigravity ACP runtime: antigravity-acp 1.3.0, Linux x64, consisting of agy_acp_server.par and matching localharness_external.

Managed active.json release ID:

9fb60956af0a9d76220a4db91ca9ac88e2a2372ad68f985ab5fceace6b825b96

No regression boundary was established. The main-branch source links below are investigation references at cd41c4ada0c70cc2eec95ecd7266f3dab010c58c, not a claim that this is the installed nightly's build commit.

Environment

• Ubuntu 26.04 LTS, x86_64, kernel 7.0.0-28-generic.
• T3 desktop Linux AppImage with local bundled server; not WSL and not a remote OAuth callback flow.
• Bundled Node 24.21.0, Electron 44.4.2.
• Personal Google account authentication (oauth-personal), not Gemini API-key authentication or imported Antigravity IDE/CLI credentials.
• Browser brand/version was not recorded. The local browser did complete OAuth and deliver the callback.
• No proxy environment variables were present in the diagnostic shell; no packet capture or router-level investigation was performed.

Logs or stack traces

Network comparison, repeated after diagnosis:

curl -4 -s -o /dev/null -w 'IPv4 HTTP %{http_code}; connect=%{time_connect}s; total=%{time_total}s\n' --connect-timeout 3 --max-time 4 https://oauth2.googleapis.com/token
# IPv4 HTTP 404; connect=0.094498s; total=0.279831s

curl -6 -s -o /dev/null -w 'IPv6 HTTP %{http_code}; connect=%{time_connect}s; total=%{time_total}s\n' --connect-timeout 3 --max-time 4 https://oauth2.googleapis.com/token
# IPv6 HTTP 000; connect=0.000000s; total=3.002670s
# curl exit status: 28

The unauthenticated GET returning 404 is evidence of successful DNS/TCP/TLS/HTTP reachability over IPv4, not a successful token exchange. These commands do not send credentials.

Live official ACP process socket during the stalled terminal OAuth flow (ss -tpn; local IPv6 address, PID, and local port redacted):

SYN-SENT 0 1 [<local IPv6>]:<local port> [2a00:1450:400c:c00::5f]:443 users:(("agy_acp_server.",pid=<pid>,fd=36))

Other diagnostic results:

Fresh temporary profile: official runtime generated the Google login link.
T3 browser-helper preflight: exit 0; expected __T3_ANTIGRAVITY_AUTH_URL__ marker emitted.
Saved credentials before callback exchange completed: absent at the first checks.

After applying the IPv4 wrapper:
Google sign-in completed. In T3, choose Refresh provider status.
Saved login verified.
Antigravity session and localharness started successfully.
Available model entries: 11

T3 live provider catalog after refresh:
providerInstanceId=antigravity; modelCount=11; constraints=[]

Relevant server trace spans during the failed setup included successful installation resolution, profile preparation, and runtime construction (AntigravityInstallation.resolve, prepareAntigravityProfile, makeAntigravityAcpRuntime, AntigravityDriver.makeDisposableRuntime), followed by stdout handling and cancellation. A successful construction span alone does not prove authentication completed.

Diagnosis and limitations

The observed connection state, repeated IPv4/IPv6 reachability comparison, and successful authentication/session/model discovery when limiting the runtime's unspecified hostname lookups to IPv4 point to broken outbound IPv6 routing as the immediate blocker.

Inspection of the installed Google 1.3.0 bundle found:

• oauth/credential_manager.py calls flow.fetch_token(authorization_response=...) after receiving the loopback callback (line 372 in the installed bundle).
• Saved credentials are refreshed using self._creds.refresh(self._request_class()) (lines 509/531).
• The 300-second loopback listener timeout is separate from those network operations; the shown calls do not explicitly pass a request timeout.

Relevant T3 references:

• AntigravityAuth.ts: setup state and overall AUTH_TIMEOUT_MS = 300_000.
• antigravityAuthSupport.ts: private profiles, GEMINI_HOME, file-backed credential storage, browser helper, and native stderr authorization-URL handling.
• AntigravityInstallation.ts: custom executable validation also requires its sibling localharness_external.
• User guide: this ACP account is separate from IDE/CLI sign-in; callback success alone does not confirm account access.

An early hypothesis that the saved login itself was bad was revised: backing up that token allowed a fresh browser flow, but the post-callback exchange still hit the same IPv6 stall. A fresh profile's ability to generate a link also does not prove the desktop handoff is fault-free in every configuration. No claim is made that T3 itself caused the routing failure, or that every report of “Starting sign-in…” has this cause. The Google runtime owns these network requests; T3's actionable error reporting and integration behavior are the relevant surfaces for triage.

Screenshots, recordings, or supporting files

The supplied screenshots' relevant UI text is transcribed above and below. Raw images and trace dumps are omitted because they include personal machine identifiers or unrelated activity. No account tokens, OAuth authorization URLs/state, callback codes, private profile hashes, or personal home directory paths are included.

Source-only workaround and optional terminal sign-in driver: https://gist.github.com/WISSAM492/4ca69575b3a83156df2662be85434b40

Workaround

Applied a per-runtime Linux IPv4 workaround, without disabling IPv6 system-wide or altering Google's downloaded executables:

1. Compile a small LD_PRELOAD shared library that wraps getaddrinfo: hostname queries with AF_UNSPEC use AF_INET; explicit address-family requests and IPv6 literals are left alone.
2. A Python launcher reads the current managed release from ~/.t3/tools/antigravity-acp/linux-x64/active.json, prepends that library to LD_PRELOAD, and execs the official ACP binary with its original arguments.
3. Set the provider's Binary path to the absolute path of ~/.t3/tools/antigravity-ipv4/antigravity-acp.
4. Put executable localharness_external beside that wrapper. A sibling symlink to the dispatcher launches the matching managed helper with the same IPv4 environment. Both Google executables remain at the same active managed release.
5. Complete or reuse Google OAuth in the existing T3 private profile, then refresh provider status.

The first version of this local wrapper omitted the sibling helper. T3 correctly rejected it with:

Not found
The custom Antigravity executable or its localharness_external sibling is missing or not executable.

That intermediate error was introduced by the workaround and fixed by adding the helper; it is not a second T3 bug. Reinstalling does not clear a custom Binary path, so reinstall alone could not fix that intermediate state.

Final verification used the official ACP initialize, authenticate, and session/new requests; no model prompt was sent. The helper started, 11 model entries were returned, T3's live catalog subsequently exposed those 11 models with no constraints, and the user confirmed it worked in the app.

The source bundle includes the library, dispatcher, build/layout instructions, rollback, and optional terminal OAuth driver. This workaround has only been checked on the Linux/glibc environment above; it is diagnostic evidence, not an upstream patch proposal. Clearing Binary path returns to the managed launch and preserves the saved Google login, but can reintroduce the network stall on this network.

Related issues

• [Bug]: Antigravity installation hides IPv6-related startup failure on WSL2 #9800: IPv6-related startup failure on WSL2 with ipv6.disable=1, resulting in SIGABRT/EAFNOSUPPORT. Here IPv6 sockets work and the runtime initializes; outbound IPv6 OAuth HTTPS remains in SYN-SENT. Different failure stage and workaround.
• [Bug]: Antigravity sign-in still does not open browser after #9425 #9624: similar missing-link sign-in symptom on Windows, with browser handoff and Windows extraction-path investigations. This report supplies Linux IPv6 socket evidence and a verified per-runtime workaround; it does not assert the same root cause.

Investigation attribution

Filed on the user's behalf after local investigation using Codex (gpt-6.1-sol, medium reasoning effort) in T3 Code. Used the bug-report template; this was not a t3 triage invocation. No upstream code changes or pull request are included.