Why Antigravity's Agent Keeps Referencing the Previous Repo After You Switch Projects — Diagnosis and Fix

One morning I was iterating on a wallpaper iOS project in Antigravity. By afternoon I had switched to the Dolice Labs Next.js repo, asked the agent to refactor a route handler — and watched it open a Swift file from the previous project and try to "fix" it. As an indie developer who has been juggling AdMob-monetized iOS apps since 2014 alongside several web properties, that's not a minor annoyance: a misrouted edit can leak API keys or end up in the wrong commit.

The phenomenon is what I call context bleed: the agent's understanding of "what project we're in" lags behind the editor's. It usually comes from three overlapping sources — workspace roots, agent memory, and the file/index cache. Below is the diagnostic flow I now use whenever it happens, and the routine I've adopted to stop it from happening at all.

Three flavors of context bleed — split them before you fix them

The first mistake most people make is restarting Antigravity immediately. Restart is the right answer for only one of the three patterns; for the others, it wastes 30 seconds and changes nothing.

• (A) Recent Files lingering: The agent's @ reference autocomplete still surfaces files from the previous repo. @Open Editors shows tabs you did not reopen yourself.
• (B) Memory carry-over: A fresh chat, yet the agent says things like "as we discussed about your AppDelegate." This means an entry from the previous project escaped into your global agent memory.
• (C) Multi-root workspace leak: The window looks like one project, but the workspace actually has multiple root folders attached. The indexer is silently keeping both alive.

The fastest disambiguation is the Command Palette command Antigravity: Show Active Workspace Roots. If the output lists a path you didn't expect, you are in case (C). If only the right root is listed, the cause is either (A) or (B).

Cause 1: Stale folders in a multi-root workspace

Antigravity, like its VS Code-family relatives, lets a single window host multiple root folders. The trap is File → Add Folder to Workspace..., which is one menu item away from Open Folder.... Opening a saved .code-workspace or .antigravity-workspace file produces the same outcome.

Steps

1. Run Antigravity: Show Active Workspace Roots from the Command Palette
2. Confirm every listed path is intentional
3. In the Explorer sidebar, right-click any unwanted root → Remove Folder from Workspace

Prevention

Treat project switching as a hard policy: always go through Open Folder (or a launcher script). Reserve Add Folder to Workspace for the rare cases you actually want a multi-root view. I keep separate launcher entries for my wallpaper apps and for the lab websites so the wrong menu item is physically harder to hit.

Cause 2: Entries that escaped into global agent memory

Antigravity's agent has a long-term memory that survives sessions. Some of it lives in AGENTS.md at the repo root, but there's also a global tier that stores facts the agent considers broadly useful. When a project-specific fact ("this repo uses SwiftUI") gets promoted to the global tier, the agent will quietly carry it into a totally unrelated project.

Inspect what's actually stored

# macOS
ls -la ~/Library/Application\ Support/Antigravity/User/globalStorage/
tail -20 ~/Library/Application\ Support/Antigravity/agent-memory/global.jsonl 2>/dev/null
 
# Linux
ls -la ~/.config/Antigravity/User/globalStorage/
tail -20 ~/.config/Antigravity/agent-memory/global.jsonl 2>/dev/null

Look for entries that name a specific repo, file path, or function. Anything that specific has no business in global memory.

Fix

1. Quit Antigravity completely, back the file up, and delete the offending lines manually if you're comfortable with that
2. Or use Settings → Agent → Memory → Manage Global Memory to remove individual entries from inside the app
3. Add a Scope: project-only directive at the top of each repo's AGENTS.md to discourage future promotions

In practice I write completely separate AGENTS.md headers for my wallpaper-app repos and my Dolice Labs sites, so the operational know-how from the app business (which has crossed 50 million cumulative downloads) never accidentally leaks into a public blog repo.

Cause 3: Recent Files and tab restoration carrying over

Antigravity restores your previous window state on launch by default. After switching folders, the previously open tabs are still hanging around, and the agent's @ autocomplete happily indexes them.

Open Settings.json and consider these keys:

{
  "window.restoreWindows": "none",
  "workbench.editor.restoreViewState": false,
  "antigravity.agent.includeRecentFilesInContext": false
}

If "none" is too aggressive (you lose your tabs every time), "folders" is the middle ground: tabs are restored per folder, so switching to a different project gives you a clean slate.

Cause 4: Indexer lag when switching folders in the same window

File → Open Recent is convenient, but the Antigravity indexer disposes of the old project's index asynchronously. Talk to the agent before that disposal finishes and it will reach into the previous repo's index.

The safer pattern

For every project switch, open a new window (Cmd+Shift+N / Ctrl+Shift+N) and close the old one only after ending the agent session. This single habit cut context bleed in my own workflow by roughly 90%.

If you must reuse the same window, run Antigravity: Reload Workspace Index from the Command Palette after switching and wait until the status bar's "Indexing..." message disappears before invoking the agent.

A short checklist so it doesn't happen again

• [ ] Run Antigravity: Show Active Workspace Roots at the start of each session
• [ ] Put a project scope line at the top of every AGENTS.md
• [ ] Skim global memory weekly with tail -50
• [ ] Prefer New Window over Open Recent for project switches
• [ ] Use restoreWindows: "folders" so old tabs don't follow you across projects

When you're running several monetized apps and a handful of websites side by side, context bleed isn't just an inconvenience — it's a path to committing the wrong credentials into the wrong repo. If you keep a similar parallel workflow, I hope this saves you the same afternoon I lost.