Fixing Antigravity Google Sign-in That Won't Return From the Browser

On a fresh machine or right after switching Google accounts, Antigravity sometimes refuses to finish signing in. You press "Sign in with Google," the browser opens, you choose an account, you press the consent button — and from that moment nothing changes. The browser tab sits on a "loading" indicator and the editor's status bar quietly spins on "Waiting for sign-in..." forever. As an indie developer who has shipped Dolice-branded wallpaper and relaxation apps since 2014 (the AdMob revenue side of that business forces me to juggle several Google accounts), I have walked into this sign-in dead end on every new laptop I set up.

The frustrating part is the silence. There is no error toast, no log line that screams at you. The cause is almost never one thing — it is usually a combination of a busy loopback port, a browser privacy setting, a stale session profile, and a quiet VPN route. The good news is that once you split the flow into a few discrete stages, you can almost always rescue it within a few minutes.

Locate Where the Flow Actually Stalls

Treat the sign-in as three stages. (A) Antigravity opens your browser and Google's account picker appears. (B) After consent, the browser is redirected to a local loopback URL such as http://127.0.0.1:54321/callback. (C) Antigravity reads the callback and flips itself to "Signed in." Almost every reported failure happens in (B) or (C). A stall in (A) is normally a DNS or proxy problem and gets handled differently.

To find which stage is broken, start the editor and run one short check from a terminal. On macOS or Linux:

lsof -nP -iTCP -sTCP:LISTEN | grep -i antigravity

On Windows PowerShell:

Get-NetTCPConnection -State Listen |
  Where-Object OwningProcess -in (Get-Process antigravity).Id

If a port around 127.0.0.1:54321 is in the listening state, the editor is genuinely waiting for the callback — the work then moves to stages (B) and (C). If nothing is listening, the sign-in module inside Antigravity itself is the suspect, and reinstalling or clearing the session profile becomes the priority.

The Loopback Port Is Already Taken

Antigravity opens a loopback port for the OAuth callback. In my experience the editor walks through 54321, 54322, 54323, and so on until it finds a free one. The trouble starts when something else has already grabbed the range: Docker Desktop, a forgotten next dev from last night, or a second Electron app that exposes a local API.

A quick scan tells you everything:

# macOS / Linux
for port in 54321 54322 54323 54324 54325; do
  lsof -nP -iTCP:${port} -sTCP:LISTEN 2>/dev/null \
    | awk 'NR>1 {print $1, $2, $9}'
done

If a process other than Antigravity shows up, you found the conflict. Kill it with kill -9 <PID>, fully quit Antigravity, then re-launch and re-trigger the sign-in. On a corporate laptop the same symptom can come from an EDR agent that quietly terminates "unauthorized listeners" — in that case the right fix is to ask IT to allowlist that local port range rather than to fight the agent.

Third-Party Cookies and Browser Extensions Step On the Redirect

The next layer is the browser. Safari's "Prevent cross-site tracking," Brave Shields, and Firefox's strict tracking protection all block the cookie that ties accounts.google.com to the loopback redirect. The browser returns to 127.0.0.1, but with no session — and Antigravity dutifully treats the empty callback as a failed login.

The fastest sanity check is to repeat the sign-in inside a private or incognito window. Extensions are disabled by default there, so a single try rules out 1Password, Bitwarden, uBlock, and any cookie auto-clean extension at once. You only need the private window for that single sign-in; afterwards you can return to your normal profile.

If a private window also stalls, add an explicit cookie exception for both accounts.google.com and 127.0.0.1 to your browser. In Chrome the relevant page is chrome://settings/cookies. Trying to keep third-party cookies blocked globally while still completing OAuth no longer works in 2026 — I gave up on that fight a long time ago.

A Stale Local Session Profile Is Refusing to Refresh

Once you have signed in successfully and then later try to re-authenticate (after switching accounts, after a token rotation, or after a force-quit), Antigravity sometimes locks itself out because its embedded Chromium session profile is corrupted. The cookies, local storage, and IndexedDB are all involved, and any one of them being broken will freeze the flow.

The session profile lives here on each OS:

macOS:   ~/Library/Application Support/Antigravity/
Windows: %APPDATA%\Antigravity\
Linux:   ~/.config/Antigravity/

Before you touch any of it, fully quit Antigravity — on macOS killall Antigravity is worth running even if the dock shows nothing. Deleting files while the app is still alive tends to recreate them in a slightly different broken state.

What I land on as a low-risk reset is to rename only the Network/ subfolder rather than nuke the whole profile, so settings and extension caches survive:

APP_SUPPORT="$HOME/Library/Application Support/Antigravity"
mv "$APP_SUPPORT/Network" "$APP_SUPPORT/Network.bak.$(date +%Y%m%d%H%M)"

That brings the cookie and IndexedDB pieces back to a first-run state while keeping the rest of your editor identity intact. The first launch after this will look like a fresh install for sign-in, but everything else behaves as usual.

The VPN, Proxy, or Firewall Quietly Drops the Token Exchange

On corporate laptops and always-on VPNs, the OCSP check against accounts.google.com or the token endpoint at oauth2.googleapis.com can be delayed or filtered. Because nothing fails outright — packets just take twelve seconds to come back — you usually misdiagnose this as the editor being slow.

The fastest split test is to turn the VPN off briefly, or tether through a phone, and try again. If sign-in completes that way, the problem is path-related; if it still stalls, you are back on the local side. For environments where the VPN cannot be disabled, ask IT to split-tunnel *.google.com, *.googleapis.com, and 127.0.0.1 so they bypass the corporate gateway.

There is one more macOS-specific pitfall. The Application Firewall in System Settings, when combined with "stealth mode," can silently swallow loopback callbacks to 127.0.0.1. Turning stealth mode off temporarily restores the sign-in. It took me half a day to track that one down, so on managed Macs I always look there.

A Checklist That Keeps Future Machines Out of This Hole

After enough rounds of this troubleshooting, I now run through a short checklist on every new machine before I even open Antigravity:

• Stop Docker Desktop and any background next dev before launching the editor.
• Add a cookie exception for accounts.google.com to my default browser.
• Switch 1Password / Bitwarden autofill to "manual trigger" rather than auto-detect on the sign-in page.
• On corporate hardware, ask IT to split-tunnel 127.0.0.1, *.google.com, and *.googleapis.com.
• On macOS, explicitly allow outbound traffic for Antigravity in the Application Firewall.

Walking that list cuts sign-in recovery time to around ninety seconds in my experience. Antigravity itself has gotten much more stable, so what stays unpredictable is the environment around it — browsers, VPNs, and firewalls. Setting them up once, carefully, makes everything that follows much smoother.

If you have been stuck on the same spinner, I hope one of the four layers above turns out to be the culprit. Thank you for reading.