Hello community,
with Antigravity 2.0, the Agent Manager was separated from the IDE as a standalone application. Since then I have been kind of confused as to: why? I think or can imagine some of the reasoning — isolate sidecar crashes, keep processes contained or something? Or just different target and peer groups between collaboration and fully automated vibe coding?
But I’ll have you know, even as a non-dev you can find much use in being able to check out the actual files created and pick files for reference by dragging and dropping them to the chat. Which is way more limited with the part of AG2.0 formerly known as the Agent Manager.
In my new every day practice, the split creates more friction than it solves when resources are still shared:
- MCP servers are configured globally but initialized independently by both instances on startup → duplicate OAuth flows, race conditions on
RefreshMcpServers - Brain/Conversations are strictly siloed → no knowledge transfer between a running sidecar session and a parallel IDE session
- Daemon directories exist three times (
antigravity/,antigravity-ide/,antigravity-backup/) with identical filenames and different timestamps — which one is authoritative?
We’ve already built a workaround using a custom /handoff workflow to manually bridge context between instances — saving session artifacts as files so they can be @-referenced across the split. It works, but it’s duct tape. The root problem remains: as long as MCP servers, OAuth tokens, and similar shared resources are invoked by both instances independently, we keep running into collisions — duplicate auth flows, stale states, and initialization races that have nothing to do with our actual work.
What I used to love about Antigravity was precisely this seamless duality: a lean, automated surface for background sidecar work — and with one click, the same intelligence, the same resources, the same context loaded into the full IDE for deep co-working. That felt coherent. To me it felt like the actual game changer for so many workflows.
Now Antigravity feels like two separate products that happen to read the same config file and stand in each other’s way.
Question for the team: Is the current split a deliberate, permanent design decision — or a transitional state while the architecture is still being consolidated? And is there a recommended way to handle shared MCP resources cleanly across both instances in the meantime?