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, notantigravity. 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):
| Asset | Old 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 file | GEMINI.md | GEMINI.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
geminiare not auto-migrated — update them toagyby 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
previewsuffixes were dropped and models are referenced likegemini-3.1-proandclaude-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 url → serverUrl 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.