Antigravity sign-in: Manage AIs starts a second login, CLI login outlives sign-in, dead hub goes unnoticed (arav, mirrored WSL)

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity

Open bug report

John Lauer · 2d ago

Seen on arav-rog (Windows 11, WSL2 networkingMode=mirrored), Hydrogen 1.0.659, Antigravity extension 1.5.0, agy CLI 1.4.3, 2026-10-20. Antigravity's own panel sign-in (Continue with Google, the browser redirect to localhost:/auth/callback) works: I completed it twice. Four things around it are worth fixing or knowing:

Manage AIs "Sign in" for Antigravity starts a second sign-in. Clicking it opens the panel's Welcome screen (whose Continue with Google is the extension's flow) and also starts a CLI login (script ... agy, ADOM_LOGIN_URL_FILE=~/.adom/agent-login-antigravity.url). Two OAuth flows run at once with different PKCE state. Whichever URL the user (or an AI) completes, the other keeps waiting. Suggest: one flow per click, either open the panel or run the CLI login, and say which.
A CLI login can outlive the sign-in. A login started with POST /agents/login and completed with POST /agents/login-input (the code-paste path) left its script ... agy process running for about 25 minutes, login-url still reporting needs_input: true until POST /agents/login-stop. It held ~/.adom/agent-login-antigravity.url (stale URL) the whole time. Suggest: end the login process as soon as the catalog oracle reports authed: true, whichever side signed in.
The panel hub can die after printing the auth URL, and nothing restarts it. Twice the extension log showed ANTIGRAVITY_OPEN_URL ..., [LAUNCH] Intercepted auth URL ..., then [LAUNCH ERROR] Server process exited unexpectedly with code 0. With the hub gone the callback port is closed, Google's redirect lands nowhere, and the panel sits on "Welcome to Antigravity" with no error. Both times came right after an external pkill -x agy plus a VS Code reload (a film script's reset), so the trigger may be that race; I could not reproduce it otherwise. Suggest: Hydrogen (or the sign-in dialog) should notice the hub is gone and say so, or restart it.
Mirrored networking: localhost from Windows hangs on IPv6. A server bound inside the container on 127.0.0.1 or 0.0.0.0 answers at http://127.0.0.1:<port> from Windows but http://localhost:<port> and http://[::1]:<port> time out (no refusal), because localhost resolves to ::1 first and IPv6 loopback is not mirrored. Browsers recover by falling back to IPv4, so the OAuth redirect still works, but non-browser clients (PowerShell Invoke-WebRequest, anything without happy-eyeballs) stall for their full timeout. Worth a note in the networking skill, or binding ::1 too where Hydrogen owns the listener.

(Separately, a stale-URL bug in my own film helper caused an "invalid state parameter" failure; that one was mine, not Hydrogen's.)

1 Reply

John Lauer · 2d ago

Thanks, point by point (fixes in a1b17831, next build after 1.0.659):

1. One click, two sign-ins. In 1.0.659's code, Manage AIs' Sign in for Antigravity opens the VS Code panel and nothing else (POST /agents/open-panel, which asks adom-vscode for the side bar). A CLI login (script ... agy with ADOM_LOGIN_URL_FILE) starts only from POST /agents/login: the "sign in the CLI (terminal) instead" link under the row, or a direct API call. I could not find a path where one click does both. If you can say what was clicked (or whether a script or AI also called /agents/login), I'll chase it. Point 2's fix also makes a leftover CLI login harmless: it now ends as soon as either side signs in.

2. A CLI login outlives the sign-in. Fixed. The watcher that already notices the sign-in landing (it brings Hydrogen to the front) now also ends the login process (login_stop) the moment the account reports authed, whichever side signed in. agy stays running after it signs in, which is why it sat there for 25 minutes with a stale URL file.

3. The panel's hub dies after printing the auth URL. Not fixed yet. Hydrogen does not watch the Antigravity extension's own server process today, and both times followed an external pkill -x agy plus a reload, so a reset race is the likely trigger. The cheap, honest version: while a panel sign-in is pending, Hydrogen checks that the callback port answers, and if it stops, says "Antigravity's sign-in server stopped; reload the panel" instead of leaving Welcome on screen. I'll do that once there is a repro outside the film reset.

4. localhost from Windows hangs on IPv6 under mirrored networking. Added to the hydrogen-ports skill under Common bugs: only IPv4 loopback is mirrored, so Windows clients without IPv4 fallback (Invoke-WebRequest, many CLIs) stall on localhost. Use http://127.0.0.1:N, or have a server you own listen on :: as well.