Antigravity 2.8.1 (macOS): sign-in never starts — language server never generates an OAuth URL, no browser is ever opened
Summary
On Antigravity 2.8.1 (macOS, Apple Silicon), clicking Continue with Google (or Use business account) on the onboarding screen never opens a browser. The UI stays on “Awaiting Authentication…” indefinitely and eventually shows “There was an unexpected issue setting up your account. Failed to fetch”.
I instrumented the running app via its Chrome DevTools Protocol endpoint and traced the flow end to end. The result narrows the failure down precisely:
- The renderer does issue the local
LanguageServerService/LoginRPC. - The bundled
language_serverdoes start its local OAuth callback server. - Electron can open an external browser (verified independently).
- The
language_servernever produces a Google authorization URL, so nothing is ever handed to the browser.
This is not a client-side environment problem — see “Ruled out” below.
Environment
| Antigravity | 2.8.1 (com.google.antigravity, notarized, Team EQHXZ*****) |
| Installed from | https://storage.googleapis.com/antigravity-public/antigravity-hub/2.8.1-…/darwin-arm/Antigravity.dmg |
| macOS | 15.2 (build 24C101) |
| Hardware | Apple M2 Max (arm64) |
| Default browser | Google Chrome 151.0.7922.138 |
| Account type | Google Workspace |
| Prior state | Antigravity worked on this machine before; the account was signed out and could not sign back in |
Steps to reproduce
- Launch Antigravity 2.8.1 while signed out.
- On the onboarding screen, click Continue with Google.
- Observe: no browser window or tab opens. The button changes to “Awaiting Authentication…” and stays there.
- After some time the screen changes to “There was an unexpected issue setting up your account. / Failed to fetch”.
Expected: a browser tab opens at accounts.google.com for the OAuth consent flow.
Actual: no browser is opened; the app waits forever.
Same result with Use business account.
Evidence
1. The renderer issues the Login RPC
Captured over CDP against the onboarding page (https://127.0.0.1``:<port>/onboarding?login=true):
POST https://127.0.0.1:<port>/exa.language_server_pb.LanguageServerService/GetUserStatus → 200
POST https://127.0.0.1:<port>/exa.language_server_pb.LanguageServerService/Login → stream opened, never completes
POST https://127.0.0.1:<port>/exa.language_server_pb.LanguageServerService/HasAuthToken → {} (no token)
Renderer console error, present continuously:
Failed to fetch NUX configs: ConnectError: [unknown] error getting token source:
You are not logged into Antigravity. (error ID: e7e06cb47ce747ac99611e15f8bfcc7c)
2. The OAuth callback server does start
Diffing the language server’s listening sockets before/after the click shows a new port appearing on every login attempt. That port is live and is the OAuth callback endpoint:
$ curl -i http://127.0.0.1:<callback-port>/auth/callback
HTTP/1.1 400 Bad Request
Invalid state parameter
So the server-side half of the flow is initialized correctly and is waiting for a redirect that never arrives — because the user is never sent anywhere.
3. Opening an external browser works
To rule out shell.openExternal / LaunchServices, I triggered a window open from the app’s own renderer:
window.open('https://example.com/antigravity-openexternal-test', '_blank')
Chrome opened the URL in a new tab (tab count 133 → 134, URL confirmed present). The app’s browser-opening path is intact.
Conclusion: the missing piece is the authorization URL itself. The language server starts the callback listener but never emits a URL to open.
4. The backend endpoint is hardcoded to an internal “daily” host
Contents/Resources/app.asar contains, as a literal argument array:
'--cloud_code_endpoint',
'https://daily-cloudcode-pa.googleapis.com',
This is the only *cloudcode-pa.googleapis.com string in the bundle — there is no production endpoint string present, and no environment variable, setting, or CLI flag to override it (language_server --help exposes -override_oauth_client_id / -override_business_oauth_client_id, -use_test_gaia, -use_stubby_auth, but nothing for the Cloud Code endpoint).
Full argv of the language server as spawned by the app:
/Applications/Antigravity.app/Contents/Resources/bin/language_server \
--standalone --override_ide_name antigravity --subclient_type hub \
--override_ide_version 2.8.1 --override_user_agent_name antigravity \
--https_server_port 0 --csrf_token <redacted> --app_data_dir antigravity \
--api_server_url https://generativelanguage.googleapis.com \
--cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com \
--enable_sidecars
Historical language-server logs from this installation show every backend call going to that host, plus:
Clearcut responded with HTTP code 401
I cannot verify from outside whether daily-cloudcode-pa is the intended production backend. If it is not, that would explain why account provisioning fails for an external account. Please confirm which endpoint 2.8.1 is supposed to ship with.
Ruled out
All checked on the affected machine:
- DNS / connectivity —
accounts.google.com,oauth2.googleapis.com,cloudcode-pa.googleapis.comanddaily-cloudcode-pa.googleapis.comall resolve and respond.POST …/v1internal:loadCodeAssistreturns401on both the daily and the production host (i.e. both reachable, auth required). - Proxy / VPN — no proxy configured (
scutil --proxy), no proxy environment variables, no VPN interface active. - Default browser — Chrome is the registered
http/httpshandler;open <url>from the shell works;window.openfrom inside the app works. - URL scheme handler —
antigravity:had stale duplicate registrations from a still-mounted installer DMG. I ejected it and re-registered/Applications/Antigravity.appas the sole handler. No change in behaviour. - App integrity —
spctlreportsaccepted / Notarized Developer ID / Google LLC (EQHXZ8M8AV). Unmodified official build. - Cache / state resets — cleared
~/Library/Application Support/Antigravity/{Session Storage,Local Storage}, revoked and re-granted access atmyaccount.google.com/connections, switched default browsers, tried with VPN off. No change.
Side note on troubleshooting guidance
Community guides (and several forum threads) tell macOS users to clear ~/Library/Application Support/Antigravity/. That directory only holds the Electron/Chromium cache. The actual Antigravity state lives in ~/.gemini/antigravity/ (antigravity_state.pbtxt, daemon/, conversations/, …). This likely explains why the widely circulated reset instructions have no effect for many reporters.
Impact
The application is completely unusable — it cannot be signed into at all, and there is no manual or device-code fallback exposed in the UI. The language_server binary contains a device-code endpoint string (https://oauth2.googleapis.com/device/code), but I found no way to reach that flow from the app.
Suggested fixes
- Confirm/correct the
--cloud_code_endpointvalue shipped in 2.8.1. - Surface an error in the UI when the authorization URL cannot be obtained, instead of spinning on “Awaiting Authentication…” indefinitely.
- Expose a manual fallback: print the authorization URL (or offer the device-code flow) so users can complete sign-in when the automatic browser handoff is unavailable.
