[Bug]: Antigravity sign-in still does not open browser after #9425

[PabloValencia14]

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 / Antigravity provider authentication

Regression after #9425

The original Antigravity sign-in issue (#9405) was fixed by #9425. I installed a new Nightly containing that fix, but Google sign-in still does not open a browser or expose the sign-in link.

Environment

• OS: Windows 11 25H2
• T3 Code: 0.0.39-nightly.20260904.1276
• Installed managed runtime: agy_acp_server_20260818_01_RC01
• Browser: Vivaldi, registered as the default HTTP/HTTPS browser
• T3 server: local Windows environment

Steps to reproduce

1. Enable Antigravity in Settings > Providers.
2. Install the managed Antigravity runtime.
3. Click Sign in with Google.
4. Wait for the authentication flow.

Expected behavior

T3 opens the Google sign-in page, or displays Open sign-in page / Copy sign-in link so the URL can be opened manually.

Actual behavior

No browser opens and no sign-in link is shown. The provider remains stuck in sign-in progress and eventually returns to an unauthenticated/error state.

Diagnostics

The installed build contains the #9425 stderr-handling changes. During the latest attempt, the server trace recorded:

• ProviderAuthService.start: Success
• ws.rpc.provider.auth.start: Success
• antigravityAuthSupport.handleStderr: Success
• antigravityAuthSupport.handleStdoutLine: Success
• offerOutgoing: Success

Despite those events:

• No external browser launch is recorded in the desktop trace.
• No complete authentication URL is exposed in the server or desktop logs.
• RpcClient.authenticate ended as Interrupted after approximately 283 seconds.
• removeAntigravitySessionFiles then completed successfully.
• The provider cache reports status error, auth unauthenticated, and message: Antigravity sign-in or sign-out is in progress. Try again after it finishes.

The managed ACP process is present and the runtime installation itself succeeds. The failure appears to remain in the handoff from the Antigravity auth URL handler/outgoing event to the desktop provider UI and browser-opening/copy-link fallback.

Could this be investigated as a follow-up to #9405/#9425, particularly the desktop/client handling of the URL after it is forwarded from ACP stderr?

[gegamoteam]

Im having the same issue on windows, the sign in just does not work.

[PabloValencia14]

I traced this to the auth-state subscription: the server retained the waiting URL, but a subscription mounted/reconnected afterward only received future changes. I opened PR #9643, which replays the current ownership-filtered snapshot and adds regression coverage. It preserves the existing privacy rules for other clients.

[PabloValencia14]

Correction: after review of the proposed fix, I withdrew PR #9643. The existing SubscriptionRef.changes already replays the current auth snapshot atomically; my added Stream.concat would have introduced a race. No unvalidated code change is being requested from maintainers. The original symptom remains open for a separate, reproducible fix.

[PabloValencia14]

Follow-up with a validated transport-level reproduction and a process-compliant proposal: #9690

The current helper works when invoked directly, and Python preserves its parsed arguments, but through Python webbrowser it returns success without the stderr marker reaching T3. A sign-in-only preload plus tokenized 127.0.0.1 sink delivered the URL through that same launch path. This rules out the late-subscriber theory and the default browser as the primary failure.

A current-main implementation, preserving the original #9550 authorship and correcting its explanation, is staged here for maintainer review: PabloValencia14@ec33a5d

I am waiting for maintainer direction in the discussion before opening another non-trivial PR, per CONTRIBUTING.md.

[y-ziane]

same issue

Im having the same issue on windows, the sign in just does not work.
same issue