Before kicking off a nightly update run, I opened the chat-style agent app to fire off a quick check through an MCP server I use every day. The tool wasn't in the list. It had been working fine in the IDE, so for a second my hands froze — had the configuration disappeared?
Nothing had disappeared. When Antigravity 2.0 split the IDE and the chat-style agent into two separate apps, the place each one reads its settings from also split. That's the whole story. Since others may hit the same wall, I'll keep my notes in the order I actually worked through them.
The symptom — works in the IDE, missing in chat
Here's what I was seeing:
- The MCP server's tools call cleanly from the IDE
- The same server never appears in the chat app's tool list
- There is no error — it's simply treated as absent
- Adding the MCP in one app does nothing for the other
The absence of an error was the tricky part. A failed connection gives you a red badge to chase. A silent gap makes you doubt yourself and re-read the same settings screen over and over.
Why they split — the 2.0 modular layout
Antigravity 2.0 broke into two apps: a VS Code–based IDE, and a chat-style agent interface. The split supports a design where dynamic sub-agents run several tasks in parallel, with each app owning a role.
What's easy to miss is the obvious consequence: if the apps are separate, so are their settings. User-scoped settings — registered MCP servers, the default model, various flags — are read from a different directory per app. An MCP you registered in one app was never written to the other app's config file, so of course it doesn't show up there.
In other words, this isn't a bug. It's a scope issue. Miss that, and you'll reach for heavy fixes like reinstalling or signing in again — all of which miss the mark.
First, find out which scope holds it
The first thing to do is separate two possibilities: is the MCP registered at the user scope, or at the workspace scope?
Open the MCP list from each app's settings and check which scope each server belongs to. Usually, something you registered as a user-level setting in the IDE simply doesn't exist in the chat app's user-level settings.
You can confirm this from the command line, too. Line up the MCP definitions in each app's config directory and diff them, and you'll see at a glance what lives where.
# Locate each app's MCP config file (names vary by version, so check yours)
find "$HOME/Library/Application Support" -maxdepth 3 -iname 'mcp*.json' 2>/dev/null
# Compare the two definitions (swap in the real files found above)
diff <(jq -S '.mcpServers | keys' ide-app/mcp.json) \
<(jq -S '.mcpServers | keys' chat-app/mcp.json)Whatever shows up in the diff is the server that lives in only one place. In my case the IDE had three registrations and the chat side was empty. Just knowing the cause is "a sync gap" is enough to settle on a direction.
The fix — make one workspace-level source of truth
The quick move is to copy the missing definition from one side to the other. But that only treats the symptom. The next time you add a setting on either side, the same drift appears again.
I stopped keeping MCP definitions duplicated at the user scope and moved them into a workspace-level config file instead. The config lives inside the repository, and both apps read it. Now the source of truth is a single file in the repo, and the count stays stable no matter how many apps read it.
// <repo>/.antigravity/mcp.json (workspace-scoped, kept under version control)
{
"mcpServers": {
"my-content-tools": {
"command": "npx",
"args": ["-y", "@example/content-mcp"],
"env": { "API_KEY": "${env:CONTENT_MCP_KEY}" }
}
}
}The key is to never write secrets directly into this file. Reference an environment variable with ${env:...} and keep the real key in the app's environment or a secret manager. You want to commit and share the workspace config, so a leaked key here becomes an incident.
Once the config is consolidated, reload both apps and confirm the same server appears in each tool list. As an indie developer I run several sites (Dolice Labs) on my own, so giving each repository its own .antigravity/mcp.json means the tool lineup is identical whichever project I open, and there's a lot less to double-check.
Line the CLI up the same way
Antigravity also ships a CLI, which I use for nightly automation. The same trap is here. If the MCP config the CLI reads differs from the IDE and chat app's user settings, it surfaces as "works by hand, MCP missing on the scheduled run."
The fix is the same: point the CLI at the workspace-level definition. Launch the CLI from the project directory so it reads the repo's .antigravity/mcp.json, and all three paths — interactive, chat, and automation — share one layout. The more unattended the automation, the more these "missing yet quietly proceeding" gaps cost you later, so it's worth keeping a single source of truth across every path. I missed this drift at first myself: everything passed by hand, yet only the scheduled run kept going with the MCP silently absent. Nothing failed in the logs, so the only way I caught it was by comparing the results side by side.
A small check to prevent a relapse
Even after consolidating, if you later add an MCP from one app's UI on impulse, the user-scope drift creeps back. I've made a quick check a habit.
# List the server names carried in the workspace definition
jq -r '.mcpServers | keys[]' .antigravity/mcp.json
# Watch for user-scope registrations that duplicate the workspace ones
# (a duplicate makes precedence ambiguous — consolidate before that happens)What it does is simple. Treat the one workspace file as authoritative, and don't stack the same server again at the user scope. Holding to that single rule was enough that I never returned to the original "works in the IDE, missing in chat" symptom.
Next time you land in this situation, suspect "which scope is it written in?" before "it's broken." One diff of the settings directories usually sorts it out in about a minute. Thanks for reading.