The evening I unboxed a new Mac, I signed in to Antigravity and watched Settings Sync do its thing. Theme, keybindings, extensions — everything visual was back within minutes. So far, almost suspiciously smooth.
Then the first agent run asked me to authenticate. Workspace search came back empty. Not a single local LLM model was anywhere to be found. The settings screens looked exactly like they had the day before, but the tool behaved like a stranger. That gap — looking restored while not actually being restored — was the most disorienting part of the whole migration.
Looking back, my mistake was trusting sync to cover more than it does. An Antigravity environment is not one thing; it is three layers with very different properties. As an indie developer keeping several apps and the Dolice sites running on my own, I cannot afford to sink a full day into a machine swap. If I had drawn this three-layer distinction before opening the box, most of the rework would never have happened. Here is the breakdown, along with the order of operations that ended up working.
Your Environment Is Three Layers, Not One
Before planning anything, sort your current environment by a single criterion: where is this state actually stored?
| Layer | Typical contents | How to treat it during migration |
|---|---|---|
| The synced layer | Settings, keybindings, extensions, themes | Settings Sync carries it. A pre-flight check is all you need |
| The machine-bound layer | Auth tokens in the OS keyring, workspace indexes, local LLM models | Do not copy. Rebuild fresh on the new machine |
| The repo-bound layer | AGENTS.md, project-specific skills and task definitions | Comes back with git clone. Migration never touches it |
The key move in this model is refusing to carry the middle layer. If you try to move it by copying files, authentication breaks silently and indexes arrive in a half-consistent state. Deciding upfront that rebuilt things get rebuilt is, counterintuitively, the faster path.
The Synced Layer: Verify the Last Sync Before You Power Down
On the new machine, the synced layer needs nothing from you. The care goes into the old machine. Before you box it up, confirm that your most recent changes actually made it to the cloud.
Open the command palette, run Settings Sync: Show Sync Activity, and check that Last Synced is newer than your last working session. It takes thirty seconds. I skipped it, and the keybindings I had tuned the week before stayed behind on the old laptop. If sync is not behaving at all, the layered diagnosis in Antigravity Settings Sync Not Working Across Devices: A Layered Troubleshooting Guide walks through the failure modes.
Extensions are part of the synced layer too, but anything with native dependencies may rebuild itself on first launch. Once the list reappears, resist the urge to trust it wholesale — exercise your daily drivers one by one before relying on them.
The Machine-Bound Layer: Rebuild, Do Not Copy
This layer caused all of my confusion, so let me take it piece by piece.
Auth tokens. Since v2.2.1, refreshed OAuth tokens are stored in the OS keyring — the Keychain on macOS. A keyring is a machine-local vault, so no amount of careful config copying will bring your authentication with you. The right move is boring: sign in again on the new machine and let it mint fresh tokens into its own keyring. Hunting down token-like files on the old machine and moving them over is a habit worth not forming, for security reasons as much as operational ones.
Workspace indexes. The first time you open a repository, index construction runs in the background, and on a large repo it takes a while. On migration day I opened my biggest workspace first and simply left it alone while I did everything else. If an index seems to run forever, the diagnostic steps in When Antigravity's Workspace Indexing Won't Finish: A Field Guide to Fixing Stalled Indexes apply to fresh machines just as well.
Local LLM models. Models served through Ollama and similar tools are multi-gigabyte artifacts. If your bandwidth allows, pulling them again is the reliable route; copying the models folder directly can leave version metadata subtly out of step, which surfaces later as hard-to-trace flakiness. In the end I re-pulled only the two models I use daily and deferred the rest until I actually needed them. Not trying to restore everything on day one is itself a migration technique.
The Repo-Bound Layer: The More You Push Here, the Lighter the Next Move
The third layer is where I felt the payoff. Because AGENTS.md and my project-specific skills and task definitions lived in the repositories, the agent's behavior snapped back to normal the moment each clone finished — before I had fixed anything else.
The flip side: prompt fragments squirreled away in local editor settings, or notes sitting in the home directory, all stayed behind. A migration is a good forcing function for asking, of each piece of state, whether it belongs to the machine or to the project — and moving the project's belongings into the repo. This connects directly to the maintenance loop I described in Iterating on AGENTS.md with a Weekly Failure Review — A Loop That Makes Antigravity Smarter. The less state you keep bound to the editor, the closer a machine swap gets to just sign in and clone.
The Order That Worked, and the One Thing That Still Caught Me
Here is the sequence I would repeat next time:
- On the old machine, confirm Last Synced in Settings Sync, then power down
- Sign in to Antigravity on the new machine, letting it rebuild credentials in the keyring
- Clone the main repositories and open the largest workspace first, leaving the index to build
- Meanwhile, verify your core extensions and re-pull the local LLM models you actually use
- Finish by handing the agent one small task, confirming that auth, search, and models are all alive
The one thing I had not anticipated: even with Antigravity itself signed in, git commit signing keys and the gh CLI's authentication are entirely separate concerns. The first agent task that included a push stalled at the signature step. It is easy to assume that agent-driven operations are covered by Antigravity's own auth, but the toolchain underneath needs each of its credentials restored individually. Add a line for git config and gh auth to your checklist.
The next time a machine swap is on your horizon, start with a blank page and the three layers — write down where every piece of your environment actually lives. That inventory may turn out to be more valuable than the migration itself. I hope this serves as a usable first draft of yours.