Antigravity Settings Sync Not Working Across Devices: A Layered Troubleshooting Guide

You set up Antigravity on your main desktop, enabled Settings Sync, then opened your laptop expecting the same theme, the same keybindings, the same extensions — and instead you got something that felt like a fresh install. If you have spent any time bouncing between two machines, you have probably hit this. The symptom is rarely "sync is slow"; it is almost always one of four distinct layers quietly failing in the background.

I once spent half an hour the morning before a flight trying to figure out why my "comment line" shortcut would not work on my laptop, and ended up walking through every layer below before I realized my OAuth token had silently expired. So instead of the usual "sign out, sign in" advice, this guide walks through how I actually diagnose the problem now — top-down, with one extra layer at each step that catches the cases the previous one misses.

Step 1: Check what Antigravity Itself Thinks Is Synced

Before doing anything destructive, see what state Antigravity reports. Open the command palette and run these in order:

1. Cmd/Ctrl + Shift + P → Settings Sync: Show Sync Activity
2. In that view, note three values: Last Synced, Account, and Status
3. Then run Settings Sync: Show Synced Data to see what is actually living in the cloud

The two values that matter most are when sync stopped and what scope is included. If Last Synced was three days ago, your auth or network broke three days ago — that is your starting point. If Status reads Turned on but settings.json is missing from Show Synced Data, your settings were never in scope to begin with, and no amount of resigning will help.

A common false alarm here: keybindings appear to sync, but a single keybinding seems to be missing. That is rarely a sync failure — it is usually a workspace-vs-user scoping issue, which we will cover at the end.

A useful diagnostic shortcut: if Last Synced updates correctly but the change you made on Machine A is not landing on Machine B, the problem is on Machine B's end (its sync is fine; the data is just not being pulled or applied). If Last Synced is frozen on Machine A, the upload itself is failing — that is the layer to investigate first. Knowing which side is broken saves you from running the entire flow on the wrong machine.

Step 2: Recover from an Expired OAuth Session

The single most common cause is an expired Google or GitHub OAuth refresh token. Antigravity uses short-lived tokens internally, and a laptop that sat offline for a while will quietly drop into a logged-out state without surfacing it to you.

The fix is simple, but the order matters — get it wrong and you can overwrite your local settings with a stale cloud copy.

1. Back up your local settings first. Run Preferences: Open User Settings (JSON) and save the entire file somewhere outside the Antigravity directory.
2. Run Settings Sync: Sign Out. This stops sync but does not delete your local settings.
3. Restart Antigravity.
4. Run Settings Sync: Sign In. When asked, choose Merge rather than Replace Local. Replace Local will overwrite your machine with whatever was last successfully pushed — which, if your sync has been broken for days, may be much older than what you have locally.

If you accidentally pick Replace Local, the backup from step 1 is your recovery path: paste it back into settings.json and you are home. Getting into the habit of backing up before any sync operation has saved me more than once.

Step 3: Reset a Corrupted Local Sync Cache

If signing back in does not fix it, the problem is on your machine, not in the cloud. Antigravity keeps a local SQLite-backed cache for sync, and rare crashes or full disks can leave it in an inconsistent state where the editor thinks it is in sync but is not actually pushing changes.

The reset sequence:

# 1. Fully quit Antigravity (force-quit is fine if it hangs)
# macOS: confirm no antigravity process remains in Activity Monitor
 
# 2. Back up the user data directory before touching anything
cp -R ~/Library/Application\ Support/Antigravity ~/antigravity-backup-$(date +%Y%m%d)
 
# 3. Remove only the sync subdirectory — your settings stay put
rm -rf ~/Library/Application\ Support/Antigravity/User/sync
rm -f ~/Library/Application\ Support/Antigravity/User/syncedKeybindings.json.lock
 
# 4. Relaunch Antigravity, then run "Settings Sync: Reset Local"
# Expected output in the toast: "Local sync data has been reset. Please sign in again."

On Linux the path is ~/.config/Antigravity/User/sync; on Windows it is %APPDATA%\Antigravity\User\sync. The important detail is that we are deleting the sync state, not the settings themselves. After Reset Local, signing in pulls the cloud copy fresh and rebuilds the local state from scratch.

If you want a clue that this layer is the culprit before doing the reset, look for .lock files left behind in the sync directory or for an unusually large sync.db file (anything above ~50 MB is suspicious for sync metadata). I have seen the cache balloon when an extension repeatedly writes large state objects into the synced settings; resetting clears it and the editor rebuilds a healthy copy.

This step alone resolves most cases that survive Step 2. If it still does not work, it is almost always a network problem.

Step 4: Sync Failures Behind Corporate Proxies and TLS Inspection

If you are on a corporate network or behind a VPN that does TLS interception, Settings Sync will silently fail because the self-signed root CA used by the inspecting proxy is not trusted by Antigravity. The signature here is very specific: Sign In succeeds, the editor looks healthy, but Last Synced never updates.

The two places to check are argv.json and your shell environment.

// ~/.antigravity/argv.json — example for a corporate proxy
{
  // Route Antigravity through the corporate proxy
  "proxy-server": "http://proxy.corp.example:8080",
  "proxy-bypass-list": "<local>;*.corp.example",
 
  // ⚠ Never set this to true on a personal machine — it disables
  //   certificate validation entirely and exposes you to MITM.
  "ignore-certificate-errors": false
}

argv.json is read only at launch, so you must restart Antigravity after editing it. The expected result is that Settings Sync: Show Sync Activity updates Last Synced to the current time within a few seconds.

The right way to handle a corporate root CA is to install it into the OS certificate store rather than disabling validation in argv.json. If your symptoms match more broadly — connection timeouts, generic TLS errors, plugins failing to install — the deeper proxy guide at Antigravity Corporate Proxy and Firewall Connection Fixes is the better starting point.

Step 5: Things That Will Never Sync, By Design

The last cause is the one that traps newcomers most: not everything is in scope for Settings Sync. The following live entirely on your local machine and will never appear on another device, no matter how many times you sign in:

• Workspace settings (.vscode/settings.json or .antigravity/settings.json)
• Extension authentication (GitHub PATs, API keys, sign-in sessions)
• Credentials stored in your Git credential helper
• argv.json itself (including the proxy settings above)
• Machine-specific absolute paths (custom font paths, local interpreter locations)

If your symptom is "my keybindings sync but my OpenAI API key does not," that is working as designed. Run Settings Sync: Configure... to inspect the scope, and re-read what is and is not included before assuming sync is broken.

For the items that genuinely need to follow you between machines (API keys, tokens, machine-specific paths), I keep them in a separate, encrypted secrets manager — 1Password and pass are both good options — and reference them via environment variables in my shell profile. That way the editor never tries to sync them, and a leaked sync history can never expose them. The exact tool matters less than separating the two concerns.

What to Do Next

Walk down these layers in order until Last Synced moves forward, and you are done. The one habit I would suggest adopting today is committing your settings.json to a personal dotfiles repository on GitHub — even a private one is fine. The next time Settings Sync breaks, instead of working through this entire flow again, you can git pull and be back in 30 seconds.

If you maintain dotfiles already, consider adding a tiny shell alias such as alias agdiff='diff <(curl -s https://raw.githubusercontent.com/you/dotfiles/main/antigravity/settings.json) ~/.../User/settings.json' so that you can spot at a glance whether the local copy has drifted from the version you trust. It takes ten seconds to set up and removes the guesswork the next time something feels off.

Cloud sync is a convenience layer, not the source of truth for your editor configuration. Once that mental model clicks, working across multiple machines becomes a lot calmer — and the time you spend troubleshooting drops sharply, because you always have a known-good baseline to fall back on.