Chat history and Knowledge should be scoped to workspace, not shared globally

I ran into something annoying today. I have multiple workspaces set up for different projects. Asked the agent to check where we left off and give me the next step. It came back with a roadmap that mixed in features from a completely different project. Took me a minute to realize it was pulling context from another workspace’s conversations and knowledge items.

Did some digging. Turns out everything under ~/.gemini/antigravity/ is stored in one flat pool. Conversations, Knowledge Items, annotations, implicit context, even the MCP config. None of it is partitioned by workspace. The only thing that IS workspace-scoped is .agents/memory/ inside the project directory, which I set up myself.

I get why global rules and global skills are shared across workspaces. That makes sense. Those are universal. But chat history and Knowledge Items are project-specific by nature. If I’m working in Project A, I don’t want the agent pulling in Knowledge Items it built from Project B sessions. That’s how you get cross-contamination, which is exactly what happened to me.

What I’d expect:

  • Knowledge Items tagged with the workspace they came from, filtered to the active workspace
  • Conversation summaries scoped (or at least tagged) by workspace when fed to the agent
  • MCP config supporting per-workspace overrides instead of one global file

Right now my workaround is a BOOT.md file in each project that explicitly says “this is Project A, do NOT reference Project B.” It works but it’s duct tape. The platform should handle this natively.

Anyone else running into this with multiple workspaces?

2 Likes

Another one: model selection is global too. If I switch to Model A in one editor window, every other open editor switches to it as well. I work on different projects with different models for good reasons. More than once I’ve started prompting in a workspace thinking I was on Model B, only to realize it silently switched to Model A because I changed it in another editor tab five minutes ago. This kind of silent sync on a destructive setting is a real problem. Wrong model on the wrong codebase can produce completely wrong patterns, wrong framework assumptions, wrong everything. One accidental prompt with the wrong model and you’re rolling back commits.

2 Likes