Skip to main content
Home/Blog/Antigravity CLI: Install, First Run, and Migrating Your Gemini CLI Config
Developer Tools

Antigravity CLI: Install, First Run, and Migrating Your Gemini CLI Config

A hands-on walkthrough for installing Google's new Go-based Antigravity CLI (agy), signing in, and migrating your GEMINI.md, MCP servers, skills, hooks, and extensions before Gemini CLI stops serving on June 18, 2026.

By Sean

If you've been running Gemini CLI as part of your daily loop, the clock is now a real constraint. On June 18, 2026, Gemini CLI and the Gemini Code Assist IDE extensions stop serving requests for Google AI Pro, Ultra, and free-tier users. That's the official hard cutover. Google is replacing Gemini CLI with the new Antigravity CLI, part of the broader Google Antigravity agent-first development platform, and the replacement is not a drop-in rename — it's a different binary, a different language under the hood, and a config layout that shifts in ways that will silently break things if you're not paying attention.

This is the hands-on companion to the deprecation announcement: how to install the new CLI, sign in, and move your existing config across without losing your skills, hooks, MCP servers, or context files. Where the research is solid I'll say so plainly; where sources conflict or rely on a single guide, I'll flag it. These tools are moving fast, so treat anything hedged here as "verify against official docs before you depend on it."

What actually changed

Antigravity CLI is built in Go, not the Python/TypeScript codebase Gemini CLI used. It shares the same agent harness as the Antigravity 2.0 desktop app, which is why the two can collide on a shared machine (more on that below). It's also reported to be closed-source, with no open-source release planned — a real departure from Gemini CLI.

The good news is feature continuity. Google states the most critical Gemini CLI capabilities carry over:

  • Agent Skills — carry over (folder locations shift)
  • Hooks — same JSON format and lifecycle
  • Subagents — carry over, but now run asynchronously in the background
  • Extensions — carry over, now renamed plugins

The single most important thing to internalize: the binary is agy, not antigravity. This trips up nearly everyone — "agy not found" is a documented first-run issue with its own GitHub bug report.

Installing the CLI

The commonly reported install path for macOS and Linux:

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

That installs the binary to ~/.local/bin/agy. On Windows, PowerShell:

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

The Windows binary lands under %LOCALAPPDATA%\Antigravity\. A Homebrew cask (brew install --cask antigravity-cli) has been mentioned by one source, but it's low-confidence — don't assume it exists until you've confirmed it. The canonical download page is antigravity.google/download.

Fixing "agy not found"

If agy isn't found after install, it's almost always one of two things:

# 1. ~/.local/bin isn't on your PATH — add it
export PATH="$HOME/.local/bin:$PATH"   # then add this line to ~/.zshrc or ~/.bashrc
# 2. (Linux) the desktop app's /usr/bin/antigravity collides with the CLI's expected `agy`
sudo ln -s /usr/bin/antigravity /usr/local/bin/agy   # or set a shell alias

Verify the install:

agy --version

One install guide reports version 1.0.1 — treat that as point-in-time, not a number to pin against.

First run and sign-in

Just run the binary:

agy

That starts the interactive session and triggers Google Sign-In OAuth. On a desktop, it auto-opens your browser. On a remote or SSH box with no browser, it instead prints an authorization URL — open that on your local machine, finish the OAuth flow, and you're authenticated. There's no headless-only flag you need to dig for; the CLI handles the fallback for you.

For non-interactive or automation contexts, API-key auth is reportedly supported via an ANTIGRAVITY_API_KEY environment variable, with the key coming from Google AI Studio. That variable name comes from a single source, so confirm it before wiring it into CI.

Migrating your Gemini CLI config

Here's where you need to slow down, because the headline command is genuinely unsettled.

Most community guides — and the agy binary naming itself — point to a non-destructive import:

agy plugin import gemini

This preserves your existing ~/.gemini/ directory rather than rewriting it in place. A minority source claims the command is antigravity migrate --from-gemini-cli instead. The two conflict, and I can't resolve it from secondary sources — the official docs at antigravity.google/docs/gcli-migration are the authority. Read those before you run anything.

Independent of the exact command, first launch is reported to be helpful here: if ~/.gemini/ exists, agy auto-detects the legacy config, prompts you to select which assets to import, and migrates active session tokens into the OS-native keyring. So in practice you may not need to type a migration command at all — the prompt may do it.

Where files end up

Reported config layout after migration (medium-to-low confidence — verify):

AssetOld location (Gemini CLI)New location (Antigravity CLI)
Global config~/.gemini/settings.json~/.gemini/antigravity-cli/settings.json
MCP config (global)inside settings.json~/.gemini/antigravity-cli/mcp_config.json
MCP config (workspace)inside settings.json.agents/mcp_config.json
Skills (global)~/.gemini/skills/~/.gemini/antigravity-cli/skills/
Skills (workspace).gemini/skills/.agents/skills/
Context fileGEMINI.mdGEMINI.md (still works; AGENTS.md also supported)

The key point: your old ~/.gemini/ directory is preserved, so the migration is reversible by design. Some of the folder moves (e.g. workspace skills) may be manual — something like git mv .gemini/skills .agents/skills.

The MCP silent-failure trap

This is the one that will eat an afternoon if you don't know about it. Remote MCP servers now require the field to be named serverUrl, not url. If you leave it as url:

// BROKEN — agy does not error at startup
{ "myserver": { "url": "https://mcp.example.com" } }

// CORRECT
{ "myserver": { "serverUrl": "https://mcp.example.com" } }

Crucially, agy does not complain at startup. The failure only surfaces the moment a tool from that server is invoked, which makes it look like a runtime bug rather than a config typo. Rename the field proactively during migration.

Context files

GEMINI.md continues to work, and AGENTS.md is supported too. One source claims a new .antigravity.md takes precedence over GEMINI.md, but that precedence detail is single-sourced — leave your GEMINI.md in place and confirm the agent is reading it before you restructure anything.

Quota, plugins, and other gotchas

A few things that aren't strictly install/migration but will bite you right after:

  • Quota model changed. Gemini CLI's roughly 1,000 requests/day gives way to a weekly compute-based cap. Heavy users report exhausting it quickly, with multi-day cooldowns, and parallel subagents each consume independent token budget. If you lean on async subagents, budget accordingly.
  • Extensions → plugins. Most carry over, but some third-party extensions that relied on internal Node.js APIs won't work in agy and need a Go rewrite or the official MCP bridge.
  • CI/cron is on you. Pipelines calling gemini are not auto-migrated — update them to agy by hand. And ACP stdio mode (gemini --acp) is reportedly absent at launch, tracked in a GitHub issue.
  • Model IDs may have changed. One source notes preview suffixes were dropped and models are referenced like gemini-3.1-pro and claude-opus-4-6. Exact IDs are unconfirmed — check before hardcoding them.

Bottom line

If you're on a consumer tier (Pro, Ultra, or free), June 18, 2026 is a real deadline — migrate before it, not on it. The install is a one-liner, but the binary is agy, not antigravity, and PATH plus the desktop-app collision are the two reasons it "won't run." First launch auto-detects ~/.gemini/, prompts you through importing assets, and the import is non-destructive, so the worst case is recoverable. Budget your real attention for the MCP urlserverUrl rename (silent failure) and for manually fixing any CI that calls gemini. And because the headline migration command and several config-path details still conflict across sources, do your final reconciliation against the official docs at antigravity.google/docs/gcli-migration rather than any single guide — this one included.

If your migration is hitting SSL or proxy errors on a corporate network, that's a separate problem worth handling on its own; see the related corporate-network guide below.

Frequently Asked Questions

Find answers to common questions

Sources conflict. The majority of community guides, along with the agy binary naming, point to agy plugin import gemini as a non-destructive import that leaves your existing ~/.gemini/ directory intact. A minority report antigravity migrate --from-gemini-cli. Treat the exact command as unconfirmed and check the official docs at antigravity.google/docs/gcli-migration before running anything.

The commonly reported install is curl -fsSL https://antigravity.google/cli/install.sh | bash on macOS/Linux, which drops the binary at ~/.local/bin/agy. Windows uses irm https://antigravity.google/cli/install.ps1 | iex. A Homebrew cask (brew install --cask antigravity-cli) has been mentioned by one low-confidence source — verify it exists before relying on it. The canonical download lives at antigravity.google/download.

Two common causes. First, ~/.local/bin may not be on your PATH — add export PATH="$HOME/.local/bin:$PATH" to your ~/.zshrc or ~/.bashrc. Second, on Linux the Antigravity desktop app installs /usr/bin/antigravity, which can collide with the expected agy command. A symlink (sudo ln -s /usr/bin/antigravity /usr/local/bin/agy) or a shell alias resolves it.

Running agy triggers Google Sign-In OAuth. On a desktop it auto-opens your browser; over SSH it prints an authorization URL instead. Copy that URL to a browser on your local machine, complete the flow, and the session is established. API-key auth is also reportedly supported via an ANTIGRAVITY_API_KEY environment variable (key from Google AI Studio), though that variable name is single-sourced.

GEMINI.md context files continue to work, and AGENTS.md is also supported. One source claims a new .antigravity.md takes precedence over GEMINI.md, but that precedence detail is single-sourced and unconfirmed. For now, leave GEMINI.md in place and test that the agent picks it up.

The most reported trap is the MCP config field rename: remote MCP servers now require serverUrl instead of url. If you leave it as url, agy does NOT error at startup — the failure only surfaces when a tool from that server is actually invoked. MCP config also reportedly moves into a separate mcp_config.json (global at ~/.gemini/antigravity-cli/mcp_config.json, workspace at .agents/mcp_config.json).

Google states the most critical Gemini CLI features carry over: Agent Skills, Hooks, Subagents, and Extensions (now called plugins). Hooks reportedly keep the same JSON format and lifecycle. Subagents carry over but now run asynchronously in the background. Folder locations may shift — workspace skills to .agents/skills/, global skills to ~/.gemini/antigravity-cli/skills/ — and some moves may be manual.

Partially. On June 18, 2026, Gemini CLI and the Gemini Code Assist IDE extensions stop serving requests for Google AI Pro, Ultra, and free-tier users. Enterprise/standard license users and those authenticating with paid Gemini API keys (Gemini Enterprise Agent Platform) retain access past that date. So a paid API key buys you time, but consumer-tier users need to migrate.

Likely yes, and the migrator does NOT fix them. Pipelines that invoke gemini are not auto-migrated and must be manually updated to agy. Separately, ACP stdio mode (gemini --acp) is reportedly absent at launch and tracked in a GitHub issue — if your automation depends on it, confirm support before cutting over.

No. Antigravity CLI is reported to be closed-source with no open-source release planned, a notable contrast with Gemini CLI, which was open source. This detail is medium-confidence; if open-source licensing matters to your team's tooling decisions, confirm it directly.

Building Something Great?

Our development team builds secure, scalable applications. From APIs to full platforms, we turn your ideas into production-ready software.