Repository navigation
[Bug]: Antigravity ACP callback listener refuses WSL loopback connections #10907
Description
Activity
Triage
Confirmed as a distinct bug from #9624 / PR #10704. #10704 is still open and does not close this.
What this report is
T3 Code 0.0.40 on a Windows host with a WSL backend starts the managed Linux ACP runtime (
agy_acp_server.par). That process advertises a Google OAuth callback on127.0.0.1:<ephemeral>.ssshows the listen, but a same-distro connect (/dev/tcp/127.0.0.1/<port>) isConnection refused(reproduced on 45295, 45803, 53907). Pasting the Google redirect URL into T3 then fails with:Could not deliver the sign-in response. Start sign-in again.
That string is T3’s paste-back delivery error, not URL validation. Validation already accepted the URL as the current flow’s
http://127.0.0.1:<port>/callback.Standalone
agyworking in WSL is useful contrast only. T3 does not launchagy; it launchesagy_acp_server.par+localharness_externalwith a privateGEMINI_HOMEand Linux registry args.What the code is doing
T3 does not allocate or bind the OAuth callback port. The ACP process does. T3 parses
redirect_urifrom the Google URL and later forwards the pasted redirect with a one-shotGET:apps/server/src/provider/antigravityCallback.ts—forwardAntigravityCallback(node:httpto127.0.0.1, no proxy, no readiness probe). Connect/RST/non-2xx → the exact error above.apps/server/src/provider/AntigravityAuth.ts—complete()validates the owned callback, then forwards. A successful HTTP status is not treated as a finished Google login; the ACP process still has to exchange the code.apps/server/src/provider/antigravityAuthSupport.ts— Linux spawn always adds--uid=(ACP registry launch args). A WSL backend is Linux, so this applies.
T3 already documents WSL localhost as unreliable for its own server (
DesktopBackendConfiguration: bind0.0.0.0, prefer the distro eth0 IP because wslhost127.0.0.1forwarding is flaky). That workaround cannot be used here: Google’s redirect and T3’s validator both require127.0.0.1. This report is also stronger than wslhost flakiness — the refuse happens inside WSL, so paste-back from the WSL T3 server fails the same way.Likely next place to look:
--uid=/.parisolation (private loopback or netns). That pattern matches “ss -pshows LISTEN, default-netns connect is refused.” Still possible: WSL mirrored-networking / localhost-relay ghost sockets, or a runtime bug inagy_acp_server_1.1.1on WSL. The listen socket is Google’s binary, so this is partly upstream; T3 may still need a WSL spawn workaround.Not a duplicate of #9624 / #10704
#9624 + #10704 This issue Broken step Delivering the Google sign-in URL to the T3 UI Delivering the OAuth callback to ACP Listener Proposed T3-owned tokenized sink (unmerged) ACP-owned 127.0.0.1callbackTypical host Native Windows, stderr / webbrowserWSL backend, listen-but-refused Status #9624 open; #10704 open, not merged Separate, no merged fix Even if #10704 landed, the user could open Google, finish auth, paste the redirect, and still hit this error.
Severity
Google-account Antigravity setup is blocked on WSL. Gemini API key / Agent Platform methods that skip the browser callback are unaffected. A native Windows backend is the practical workaround today.
Suggested follow-up (optional)
If you can capture these during a failed attempt, it will distinguish netns isolation from a WSL relay ghost:
readlink /proc/<agy_pid>/ns/netvsreadlink /proc/self/ns/net- full
ss -ltnpeline for that port (inode, users, netid) - WSL
networkingMode(mirroredvs NAT) from.wslconfig - whether a custom
agy_acp_server.parlaunched without--uid=accepts127.0.0.1
No credentials or full OAuth URLs, please.
Next step
Keep open. Do not close via #10704. Investigate WSL spawn (
--uid=) and ACP loopback accept; community PR is the realistic path.I plan to investigate this and prepare a PR. I will start by reproducing the ACP listener behavior under the WSL backend and checking whether
--uid=or runtime isolation causesssto showLISTENwhile same-distro TCP connections are refused. I will report findings here and link a PR if I can produce a tested fix.Confirmed resolved upstream.
I upgraded WSL from 2.7.12.0 to 2.9.11.0 while keeping Cisco VPN connected and networking mode set to Consomme.
Before the upgrade, we reproduced the failure with worker-thread listeners that bind port 0: the socket appeared in
ss, but loopback connections returnedECONNREFUSED. Main-thread listeners and explicitly assigned ports worked. This matches microsoft/WSL#41051, which fixes port-0 tracking for threaded binds.After upgrading, the same worker-thread test passed. The original, unmodified T3 callback transport then delivered the native Antigravity OAuth callback successfully (HTTP 200), and Google sign-in completed successfully. No T3 code change is required.
Reopened per triage guidance.
I closed this after confirming that the failure no longer reproduced, but that was premature. After upgrading WSL from 2.7.12.0 to 2.9.11.0 with Cisco VPN connected and Consomme networking, the worker-thread port-0 reproduction disappeared and the original, unmodified T3 callback transport completed Antigravity Google sign-in successfully.
No T3 code change was made, so I’m leaving this open for maintainer disposition. The original failure was observed on the older WSL version and may be resolved by the upstream WSL update.
Closing as not planned (upstream).
Reporter confirmed the listen-but-refuse loopback failure was a WSL port-0 / worker-thread tracking bug fixed in WSL 2.9.11.0 (microsoft/WSL#41051). After upgrading, unmodified T3 delivered the Antigravity OAuth callback successfully — no T3 code change required.
Workaround for anyone still on older WSL: upgrade WSL (or use a native Windows backend). Reopen if this reproduces on a current WSL build without needing an upgrade.
Description
Antigravity sign-in fails when T3 Code uses a WSL backend. T3 launches its managed Antigravity ACP runtime and allocates a callback port, but the listener refuses local WSL TCP connections before the Google sign-in link is opened.
Environment
agy_acp_server.paragyCLI works in WSLSteps to reproduce
Open Settings > Providers > Antigravity.
Install Antigravity from T3 settings.
Click Sign in with Google.
Before opening the link, inspect the listener in WSL:
Test the ACP callback port shown by
ss:Restart T3 and repeat the sign-in flow.
Expected behavior
The ACP callback listener accepts a local WSL connection and the Google sign-in completes.
Actual behavior
ssreportsagy_acp_server.parlistening on127.0.0.1:<port>, but connecting to that same port returnsConnection refused. This reproduced after restart with ports45295,45803, and53907. When the callback URL is pasted into T3 after completing Google authentication, T3 shows:No OAuth URLs or credentials are included here.
Related: #9624, #10704