Migrate Gemini CLI to Antigravity: configs, skills and MCP

To migrate Gemini CLI to Antigravity CLI with a personal Google account, install Antigravity CLI, launch agy once so it can detect the legacy Gemini profile, then verify plugins, project instructions, skills and MCP servers one by one. Keep the old files until the new CLI has read a real workspace successfully.

Applies to: Antigravity CLI v1.2 or later; Google’s migration, setup and consumer deprecation documentation. Last checked: October 22, 2026.

On this page

First, check whether the migration applies

Google says consumer access to Gemini CLI and the Gemini Code Assist IDE extensions through Login with Google stopped serving individual users, including Google AI Pro and Ultra subscribers, on June 18, 2026 (Google deprecation notice). Google directs those users to Antigravity.

That deadline does not describe every Gemini CLI setup. The same deprecation page says Gemini Code Assist Standard and Enterprise subscriptions are subject to a separate deprecation schedule. Google’s announcement also says Gemini CLI remains accessible with paid Gemini and Gemini Enterprise Agent Platform API keys.

Use this decision rule:

• Personal Google login: plan the move to Antigravity CLI.
• Gemini Code Assist Standard or Enterprise: follow the separate deprecation schedule and your organisation’s documentation.
• API key: the existing Gemini CLI path may remain available, but confirm the current product documentation before changing team workflows.

Google’s announcement says there won’t be 1:1 feature parity at first. Treat this as a configuration conversion followed by verification, not as a binary rename.

1. Install Antigravity CLI

Google’s get started guide lists these installation commands.

macOS or Linux:

curl -fsSL https://antigravity.google/cli/install.sh | bash

Windows PowerShell:

irm https://antigravity.google/cli/install.ps1 | iex

Windows Command Prompt:

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

Confirm the installed version:

agy --version

The quickstart specifies Antigravity CLI v1.2 or later. On first launch, agy asks about colour scheme, rendering mode and workspace trust. Its authentication table lists personal Google OAuth for individual Free, Pro and Ultra plans, alongside business and enterprise options.

If you are moving from a consumer Gemini CLI login, choose the personal Google OAuth path presented by Antigravity. Do not paste tokens into project files.

2. Let the first-run flow detect the old profile

Launch the CLI:

agy

According to Google’s migration guide, Antigravity detects legacy Gemini CLI configuration during the first launch and shows an interactive checklist of assets to convert. Review the proposed imports instead of accepting them blindly.

The same page says the CLI moves active session tokens into the operating system’s native keyring. That is preferable to copying secrets into a repository. After conversion, open a non-sensitive test workspace and confirm authentication before importing the rest of the tooling.

A sensible order is:

1. Authenticate.
2. Open one trusted workspace.
3. Confirm project instructions are recognised.
4. Import extensions as plugins.
5. Verify skills.
6. Convert MCP server definitions.
7. Run a harmless read-only prompt.

This sequence keeps failures attributable. If everything moves at once, an authentication problem can look like a broken plugin or MCP server.

3. Import Gemini extensions as Antigravity plugins

Antigravity represents migrated Gemini CLI extensions as plugins. Google’s migration guide provides a direct import command:

agy plugin import gemini

Run it after the base CLI launches successfully. The documented output reports, per extension, which skills, agents, legacy commands and MCP server definitions were converted; legacy commands become skills. Then inspect the resulting plugin list and test each plugin’s commands separately.

Google’s product announcement says Antigravity CLI keeps Agent Skills, Hooks, Subagents and Extensions, with extensions now as Antigravity plugins. It does not promise identical behaviour for every extension. An import still needs functional verification, especially if the extension depended on experimental Gemini settings or a specific authentication flow.

Before migration, note each extension’s source, commands, required environment variables and workspace settings. That inventory becomes the acceptance test and makes it easier to remove unused integrations instead of carrying them forward.

4. Keep project instructions in place

Google’s migration guide says Antigravity CLI continues to read both GEMINI.md and AGENTS.md in the workspace, and the global file at ~/.gemini/GEMINI.md. You do not need to rename a working GEMINI.md just to start the migration.

For mixed-tool repositories, AGENTS.md can hold the shared baseline while tool-specific details remain in their native files. If you change the instruction layout, make that a separate reviewed change.

After opening the workspace in agy, ask a read-only question whose answer depends on a distinctive repository rule. For example, ask which test command the instructions require. If the answer ignores the rule, check file location and workspace trust before rewriting the content.

For a broader comparison of repository instruction files, see CLAUDE.md vs AGENTS.md.

5. Move skills to the documented paths

Google’s migration guide documents these skill locations:

Do not assume a skill is active because its files exist. Open its instruction file, check any relative paths, and run the smallest non-destructive task that proves the skill loaded.

Workspace skills belong in the repository only when the team intends to version them. Personal helpers and machine-specific paths should stay in the global directory.

6. Convert MCP paths and field names

MCP migration is the part most likely to need a manual edit. Google’s migration guide documents these destinations:

The remote-server schema also changes. In Antigravity CLI, use serverUrl rather than the legacy url or httpUrl field.

A minimal remote-server shape looks like this:

{
  "mcpServers": {
    "example": {
      "serverUrl": "https://mcp.example.com",
      "headers": {
        "Authorization": "Bearer ${MCP_EXAMPLE_TOKEN}"
      }
    }
  }
}

The token is a placeholder. Keep real credentials in the approved secret store or environment mechanism for your system, never in committed JSON.

For every server, verify that the file uses the correct global or workspace path, remote endpoints use serverUrl, environment variables exist outside the repository, and a read-only tool call succeeds. Leave write-capable tools disabled until you intentionally test them.

If you are still deciding which servers belong in a coding workspace, use the MCP server directory for discovery, then return to each server’s official documentation for setup.

7. Verify one representative workspace

Use one repository, not the entire project estate, for the first acceptance pass.

Configuration checklist

• agy --version reports v1.2 or later.
• Authentication completes with the intended account type.
• The workspace is explicitly trusted.
• GEMINI.md or AGENTS.md rules are recognised.
• Required Gemini extensions appear as Antigravity plugins.
• Global and workspace skills load from the documented paths.
• MCP servers use the Antigravity files and schema.
• No credentials were copied into tracked files.

Behaviour checklist

• A repository question returns the expected instruction-driven answer.
• A plugin command starts without a missing-package error.
• A skill performs one bounded, reversible task.
• An MCP server completes one read-only call.
• Version control shows only the files you intended to migrate.

If a check fails, fix that layer before moving to the next repository. Avoid deleting the legacy Gemini configuration until the Antigravity workflow has passed the checklist.

8. Expect partial, not identical, parity

Google’s announcement says Antigravity CLI will not have 1:1 feature parity with Gemini CLI right away, while keeping skills, hooks, subagents and extensions.

Record each difference as a named gap: the missing feature, available alternative, temporary Gemini CLI dependency, owner and review date. That is more useful than a generic “migration complete” checkbox, and it lets API-key or enterprise users keep a narrow Gemini CLI dependency without blocking the rest of the move.

For maintenance of a remaining Gemini CLI installation, see How to update Gemini CLI. If your work stays inside an editor, Gemini CLI in VS Code covers that integration separately.