[Bug]: Antigravity ACP callback listener refuses WSL loopback connections

[satyalyadav]

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

• T3 Code 0.0.40
• Windows host with WSL backend
• Managed runtime: agy_acp_server.par
• The regular agy CLI works in WSL

Steps to reproduce

1. Open Settings > Providers > Antigravity.

2. Install Antigravity from T3 settings.

3. Click Sign in with Google.

4. Before opening the link, inspect the listener in WSL:

   ss -ltnp | rg 'agy_acp_server|127\.0\.0\.1'
   

5. Test the ACP callback port shown by ss:

   timeout 2 bash -c '</dev/tcp/127.0.0.1/<port>' && echo reachable || echo unreachable

6. 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

ss reports agy_acp_server.par listening on 127.0.0.1:<port>, but connecting to that same port returns Connection refused. This reproduced after restart with ports 45295, 45803, and 53907. When the callback URL is pasted into T3 after completing Google authentication, T3 shows:

Could not deliver the sign-in response. Start sign-in again.

No OAuth URLs or credentials are included here.

Related: #9624, #10704

[juliusmarminge]

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 on 127.0.0.1:<ephemeral>. ss shows the listen, but a same-distro connect (/dev/tcp/127.0.0.1/<port>) is Connection 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 agy working in WSL is useful contrast only. T3 does not launch agy; it launches agy_acp_server.par + localharness_external with a private GEMINI_HOME and 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_uri from the Google URL and later forwards the pasted redirect with a one-shot GET:

• apps/server/src/provider/antigravityCallback.ts — forwardAntigravityCallback (node:http to 127.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: bind 0.0.0.0, prefer the distro eth0 IP because wslhost 127.0.0.1 forwarding is flaky). That workaround cannot be used here: Google’s redirect and T3’s validator both require 127.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= / .par isolation (private loopback or netns). That pattern matches “ss -p shows LISTEN, default-netns connect is refused.” Still possible: WSL mirrored-networking / localhost-relay ghost sockets, or a runtime bug in agy_acp_server_1.1.1 on 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.1 callback
Typical host	Native Windows, stderr / webbrowser	WSL 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/net vs readlink /proc/self/ns/net
• full ss -ltnpe line for that port (inode, users, netid)
• WSL networkingMode (mirrored vs NAT) from .wslconfig
• whether a custom agy_acp_server.par launched without --uid= accepts 127.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.

[satyalyadav]

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 causes ss to show LISTEN while same-distro TCP connections are refused. I will report findings here and link a PR if I can produce a tested fix.