Repository navigation
[Bug]: Antigravity sign-in still does not open browser after #9425 #9624
Description
Activity
Im having the same issue on windows, the sign in just does not work.
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.
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.
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
webbrowserit returns success without the stderr marker reaching T3. A sign-in-only preload plus tokenized127.0.0.1sink 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.same issue
Im having the same issue on windows, the sign in just does not work.
same issueWe can't replicate this and we also don't really care about antigravity.
We're happy to consider a fix if one of you guys opens a PR (but I will be ignoring it if it was opened using a Gemini model)
Reacted by Arnab Mondal, Barnabé Jouanard and Sunjay KumarAfter install the runtime its dosnt find the instaltion. I`ll do have the same issue
Faced the exact same issue as @braminsign on Windows today. Here is what is happening under the hood and how to unblock it:
Root Cause
When T3 Code shows:
"Antigravity is not installed. Install it in this environment or set a custom executable path."
Most users assume it is looking for the Antigravity CLI (
agy.exe) or IDE executable. However, T3 Code strictly requires Google's headless Agent Client Protocol (ACP) adapter runtime:- Windows:
agy_acp_server.exe+ its siblinglocalharness_external.exe - Linux:
agy_acp_server.par+ its siblinglocalharness_external
If you point the "Custom Executable Path" to
agy.exe, T3 Code rejects it becauselocalharness_externalis missing:"The custom Antigravity executable or its localharness_external sibling is missing or not executable."
Furthermore, if the in-app download gets interrupted or fails to write
.install-complete.json/active.jsoninside~/.t3/tools/antigravity-acp/<platform>/, T3 Code silently reports Antigravity as not installed.Workaround to unblock immediately:
- Download the official ACP bundle directly from Google's CDN:
- Windows:
https://dl.google.com/agy-extensions/releases/windows/agy-acp-server-agy_acp_server_1.1.1-windows-x86_64.zip - Linux:
https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-agy_acp_server_1.1.1-linux-x86_64.zip
- Windows:
- Extract both files (
agy_acp_serverandlocalharness_external) into a local directory (e.g.%LOCALAPPDATA%\agy\acp\on Windows or~/.t3/tools/antigravity-acp/linux-x64/on Linux). - Open Settings → Providers → Antigravity and set Binary path to the extracted
agy_acp_server.exe(or.par).
- Windows:
Root cause found (Windows): it's MAX_PATH, not auth.
T3 launches the Antigravity ACP server with
TEMP/TMPpointed at a deeply nested profile directory (antigravityAuthSupport.ts→antigravityEnvironment()):C:\Users\<you>\.t3\userdata\providers\antigravity\<64-char sha256>\antigravity-acp\tmp\run-XXXXXXThe server is a PyInstaller one-file bundle that extracts ~1GB into
%TEMP%\_MEIxxxxxon every launch. The deepest file lands at 276 characters, 16 over Windows' 260-charMAX_PATH:...\tmp\run-XXXXXX\_MEIxxxxx\google3\cloud\developer_experience\antigravity_extensions\acp_server\_private__agy_acp_server_bin.lazy_imports_info.jsonThe bootloader dies in ~250ms with:
[PYI-xxxxx:ERROR] Failed to extract ... lazy_imports_info.json: failed to open target file! fopen: No such file or directoryI reproduced this exactly by running
agy_acp_server.exewithTEMPset to the deep path, and confirmed the fix by flipping it back. This is why the provider is stuck on "Google account access is not checked yet" with empty models:refreshModelscan never spawn the server. It also explains why it works on macOS/Linux and when the binary is run manually (short temp path).Workaround: enable Windows long paths, since the binary's manifest already declares
longPathAware:reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
Then restart T3. Verified the server extracts and runs cleanly under the deep temp path with this set.
Suggested fix:
resolveAntigravityRuntimeTempDirectory()nests too deep on Windows. The temp dir could live somewhere short like%LOCALAPPDATA%\Temp\t3-antigravity\<short-id>instead of under the 114-char profile directory.
Before submitting
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
Steps to reproduce
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:
Despite those events:
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?