Gemini CLI’s Antigravity Migration Is Really an Auth Migration
The Gemini CLI to Antigravity CLI migration was never going to fail because developers could not find the new command. It was going to fail because the old tool had quietly accumulated state: OAuth clients, Workspace scopes, local token files, Cloud project IDs, MCP servers, environment variables, and just enough undocumented muscle memory to make a clean migration feel like an exorcism.
That is why a new Google Cloud Community migration guide is more useful than the usual “here is the successor product” post. The deadline is the forcing function: Gemini CLI is preparing to give way to Antigravity CLI on June 18, 2026 for unpaid tier and Google One users. But the real story is the Google Workspace extension, because moving an agent that can touch Gmail, Drive, Calendar, Sheets, Docs, Slides, and Chat is not a rename. It is an identity and permissions migration wearing a developer-tool hoodie.
The guide says Antigravity CLI should prompt users on first launch to migrate Gemini CLI extensions into the new Antigravity Plugin ecosystem. The manual path is also simple enough: agy plugin import gemini google-workspace. For the Workspace extension, that import processes six skills, converts four commands into skills, and processes one MCP server. The author tested against gemini-cli-extensions/workspace v0.0.8, released May 4, 2026.
The import command is the easy part
The useful part of the guide is not the import command. It is the failure map. The author recommends starting with a clean Antigravity auth slate: log out with /logout, sign in again with /auth, use a Google Cloud project rather than generic Google OAuth, complete the browser OAuth flow with the intended end-user account, enter the Cloud project ID, and choose global as the default Cloud location.
That sounds fussy until you remember what is happening underneath. Workspace APIs are Google Cloud APIs: gmail.googleapis.com, drive.googleapis.com, calendar-json.googleapis.com, and the rest. If Antigravity thinks it is using one Cloud project, gcloud is configured for another, and stale Gemini CLI OAuth files are still sitting under ~/.gemini, the resulting failure will not look like “identity layer mismatch.” It will look like an agent randomly failing to call tools.
That is the most annoying class of AI tooling bug: the model gets blamed for infrastructure drift. A developer asks the agent to create a Calendar event or inspect a Drive folder; the agent produces a plausible explanation; the real issue is an API not enabled, a token cached for the wrong account, or an environment variable pointing at yesterday’s project. The fix is not a better prompt. The fix is boring operational hygiene.
The guide calls out the Workspace APIs that need to be enabled in the selected Cloud project: Calendar, Sheets, Docs, Slides, Gmail, Drive, and Chat. It also lists stale Gemini-era files that can cause confusion: ~/.gemini/oauth_creds.json, ~/.gemini/google-accounts.json, ~/.gemini/mcp-oauth-tokens.json, and ~/.gemini/mcp-oauth-tokens-v2.json. Engineers should not blindly delete credentials on a shared machine, but the principle is right: know which tool owns which token, and do not let two CLIs compete for authority over the same local identity store.
Workspace plugins are not harmless once they can write
The OAuth scope list is the part teams should read slowly. The Workspace plugin can request access to Drive, Gmail modify, Calendar, Chat spaces/messages/memberships, Docs, Directory readonly, user profile information, and read-only Sheets. That is a broad surface area. The source even appears to contain a typo — presentations.readyonly where presentations.readonly is presumably intended — which is exactly the kind of small detail that deserves verification before an internal migration guide gets copied around a company.
This is where the Antigravity migration stops being a developer convenience story and becomes an enterprise controls story. A coding agent that edits a local repo is one risk profile. A coding agent that can modify Gmail, write Docs, create Calendar events, read Drive, and post into Chat is a different animal. If your team is moving from Gemini CLI to Antigravity CLI, the right checklist is not “did the import finish?” It is: which Workspace APIs are required, which scopes are actually necessary, who approved those scopes, how are tokens stored, and what audit trail exists when the agent acts on behalf of a human?
The guide’s Calendar bug makes the same point from the MCP side. According to the author, all Workspace requests succeeded except Calendar. The failure came from parameter flattening: the standard client-side call_mcp_tool handler can strip or flatten nested schemas, while calendar.createEvent and calendar.updateEvent expect nested start and end objects containing dateTime. Flatten that structure and the MCP server receives undefined fields where objects should be.
That is not a glamorous bug, but it is a good preview of where agent tooling breaks in production. Tool schemas look deterministic until a shim mutates JSON between model intent and server validation. Then the agent recovers by writing a scratch script to call the MCP server directly with unflattened JSON. Clever locally. Terrifying as a general operating model.
The enterprise version of this problem is already visible in Google Cloud’s Agent Gateway docs: agent identity, authorization, MCP policy, observability, and read/write restrictions by tool. The Antigravity migration guide is the personal-machine version of the same architecture pressure. Once agents call tools, the hard problem becomes preserving identity, structure, permissions, and auditability across every layer between the prompt and the API.
So the practical migration plan is straightforward. Test before June 18 on a non-critical machine. Import the Workspace plugin. Re-authenticate Antigravity CLI with the intended Cloud project. Check gcloud config configurations list for account and project drift. Enable only the Workspace APIs you need. Archive stale Gemini credential files rather than letting old state silently participate. Exercise each migrated skill with harmless read and write operations. For Calendar, test event creation and updates involving nested start/end objects before relying on the agent in a real workflow.
The bigger take: Antigravity CLI is not merely a replacement binary. It is becoming a plugin runtime over Google Cloud identity, Workspace APIs, and MCP-shaped tools. That is powerful, but it means the migration deserves the treatment normally reserved for internal platform changes: staged rollout, least privilege, smoke tests, rollback notes, and a runbook. If that sounds heavy for a CLI, that is the point. The moment your AI assistant can touch business data, it stops being “just a CLI.”
Sources: Google Cloud Community, Antigravity migration docs, gemini-cli-extensions/workspace v0.0.8, Google Workspace API docs, Google Cloud Agent Gateway docs