Splitting AI Context Across Multiple Repos with Antigravity Multi-root Workspaces

I maintain four AI-focused tech blogs under Dolice Labs — Claude Lab, Gemini Lab, Antigravity Lab, and Rork Lab. They all share roughly the same Next.js 16 + Cloudflare Workers stack, but each repo has its own tsconfig.json aliases, its own Stripe Price IDs in pricing.ts, and slightly different generate-content.mjs behavior.

I started by keeping four separate windows open, one per site. The pain point was that I often wanted to ask the Manager Surface things like "take the article generation task from Claude Lab and port it to Gemini Lab." Crossing window boundaries makes the AI lose context fast — every cross-window question essentially became a fresh conversation, with the receiving window having no memory of the donor's code.

So I consolidated everything into a single Multi-root Workspace, and immediately walked into a different trap. The AI started pulling pricing.ts from a sibling repo and pasting Gemini Lab Price IDs into Claude Lab. Refactor suggestions for one site started referencing utilities that only existed in a sibling. This article walks through the concrete failures I saw and how splitting .antigravity/rules per folder fixed them.

Multi-root Workspace is "a set of folders," not "one project"

Multi-root Workspace inherits from VS Code: you write a .antigravity-workspace file (the equivalent of .code-workspace) listing several folder paths.

// dolice-labs.antigravity-workspace
{
  "folders": [
    { "path": "claudelab.net", "name": "Claude Lab" },
    { "path": "gemilab.net", "name": "Gemini Lab" },
    { "path": "antigravitylab.net", "name": "Antigravity Lab" },
    { "path": "rorklab.net", "name": "Rork Lab" }
  ],
  "settings": {
    "files.exclude": {
      "**/.next": true,
      "**/node_modules": true
    }
  }
}

The important detail to internalize is that Antigravity treats the entire workspace as a single context for AI features. The moment you press Cmd+I in the Editor View, the model has all four repos as candidate context, not just the file you're looking at. The Manager Surface's directory tree dump in its system prompt covers the union of every folder you've added.

If you don't take any precautions, you will get bleed-through. That was my first stumble — and I suspect anyone who works on multiple similar codebases will hit it eventually, regardless of which AI editor they use. VS Code with GitHub Copilot has milder versions of the same issue.

A concrete case where AI context bled across repos

Here's a real example. I was editing src/config/pricing.ts in Claude Lab and pressed Cmd+K with the prompt "Replace the Premium plan Price ID with the new value from the Stripe dashboard." The model proposed price_1QabcXY..., which was actually the Gemini Lab ID — not Claude Lab's at all.

The Manager Surface's reasoning trace made the cause clear after I dug into it:

• Right before that, I had a Gemini Lab pricing.ts open in another tab while comparing structures
• All four pricing.ts files have identical filenames and similar type definitions
• The model preferred "the most recently inspected pricing.ts shape"
• Because the file path differed only in the top-level folder name, similarity ranking made all four candidates near-equivalent

When filenames match exactly across folders, the model doesn't strongly distinguish "which repo." The directory tree visible in the Manager's system prompt contains the entire workspace, so the four pricing.ts candidates score nearly the same on retrieval. The disambiguator becomes "which one was touched most recently," which is exactly the wrong heuristic when you're switching between sites every few minutes.

This isn't documented in the official Antigravity material I've read, but if you open multiple similarly-shaped repos in a single Multi-root window, you should expect this kind of bleed-through. The same pattern shows up with tsconfig.json, next.config.ts, and any utility files that share names across your repos.

Fix 1: Place .antigravity/rules at each folder root

The simplest, highest-leverage fix was putting a .antigravity/rules.md at the root of every folder.

<!-- claudelab.net/.antigravity/rules.md -->
# Claude Lab specific context
 
This folder is the claudelab.net repository.
 
- Stripe Price IDs live in `src/config/pricing.ts`
- Never bring in Price IDs from sibling sites (gemilab, antigravitylab, rorklab)
- Article categories are limited to: claude-ai, claude-code, cowork, api-sdk
- The frontmatter `category` field must be one of those four values only
- The site name displayed in OG tags is "Claude Lab" — not "Gemini Lab" or "Antigravity Lab"

Antigravity automatically appends the .antigravity/rules.md of the folder containing the currently active file to the AI's system prompt. You don't need to attach it manually with @-references — just having the file open is enough for it to pick up the right rules.

I dropped one of these into all four sites, each describing what is "absolutely off-limits to mix in." Cmd+K accuracy improved by a noticeable margin — I'd estimate 30–40% in everyday feel — and I have not seen a single Price ID mix-up since. The rules file works whether the active editor is a .ts, .mdx, or .json file, which means the same guardrail covers code edits and content authoring with one declaration.

A small detail worth knowing: keep these files short. Five to ten lines per folder is enough. Long rules dilute the signal and start to compete with one another in the system prompt.

Fix 2: Lead Manager prompts with @folder references

When I hand a longer task to the Manager, I now always start with an explicit @folder: reference.

@folder:claudelab.net
 
In claudelab.net, take _skills/claudelab/SKILL.md Step 7 and diff it
against the same file in gemilab.net. Bring claudelab to parity.
Do not edit anything outside this folder.

When @folder: appears first, the Manager always begins its first action inside that folder. I arrived at this through trial and error: without it, the Manager often starts by searching across the entire workspace, and that initial broad search raises the chance of unrelated edits sneaking into the plan.

A side benefit is that Manager action logs become easier to audit. When I review what the Manager did over a 30-minute run, I can see at a glance which folder each action "lived in." The more cross-folder tasks become routine, the more this opening declaration pays off — even when the body of the prompt naturally constrains the work, the explicit anchor seems to reduce drift in long sessions.

Fix 3: Tighten files.watcherExclude at the workspace level

This isn't strictly an AI-context issue, but it mattered just as much for daily comfort once I unified everything.

// dolice-labs.antigravity-workspace
{
  "settings": {
    "files.watcherExclude": {
      "**/.next/**": true,
      "**/node_modules/**": true,
      "**/.wrangler/**": true,
      "**/_cache/**": true,
      "**/_backup/**": true
    },
    "search.exclude": {
      "**/_cache": true,
      "**/_backup": true,
      "**/public/content": true
    }
  }
}

Antigravity's semantic code search indexes the whole workspace. With four node_modules directories and four .next build outputs included, my initial scan was reading nearly 30 GB on disk. After tightening search.exclude, the first-time index dropped from 5–8 minutes to about 40 seconds. files.watcherExclude directly affects sustained CPU usage when files change in the background.

The trap to know: these settings have to live in the .antigravity-workspace file's settings block, not in per-folder .vscode/settings.json. Per-folder settings don't reach the AI's semantic search index. I lost about an afternoon to this before I noticed the workspace-level settings were being ignored simply because I'd put them in the wrong place.

Operating rules I converged on

After about three months of Multi-root use, two rules have stuck.

First, keep filenames consistent across folders, but enforce separation through .antigravity/rules.md. The instinct, after the bleed-through incidents, is to rename pricing.ts to pricing-claude.ts, pricing-gemini.ts, and so on. Doing that drives up the cost of propagating shared improvements: when you fix a bug in one site's pricing logic, you now have to remember four different filenames to mirror it. Keeping names aligned and teaching the AI what not to mix has been less painful long-term, even if it required more upfront discipline.

Second, for cross-site work, put a .antigravity/rules-global.md at the workspace root. Things like "if you change pricing.ts, sync the change to all four sites" go there. Antigravity also reads .antigravity directly under the workspace root, not just under each folder. The global file is where I encode the few rules that apply everywhere — like "this is a content-driven blog network and Stripe Price IDs always differ between sites."

There is a third rule I keep going back and forth on: whether to pin the Multi-root window to a fixed set of folders or to dynamically add and remove sites depending on the day. So far, leaving all four pinned has been the cleaner workflow — context switches between sites are cheaper than tearing down and rebuilding the workspace, even when I am only actively working on one site for a week. The semantic search index stays warm, and the .antigravity/rules.md files keep the AI focused regardless of how many folders are open.

If you pair this with my notes on Antigravity Custom Rules and project config and @-references for context precision, the combined effect is much stronger than any one piece alone.

What to do next

If you already use Multi-root Workspace, write a five-line .antigravity/rules.md in each folder root today. Just describe "what this folder is, and what must never be mixed in from neighbors." Cmd+K and Manager accuracy will visibly shift, usually within the same afternoon.

I'm still refining how I use Multi-root myself, especially the boundary between folder-level rules and the global rules file. If you're juggling multiple similar repos the same way, I hope these notes save you a few hours of debugging mysterious cross-repo suggestions.