Gemini CLI → Antigravity CLI: The 30-Day Migration Guide (2026)

TL;DR + the 30-day clock

The shortest version of this blog, for people who just want to know what to do:

• Deadline: June 18, 2026. After that, Gemini CLI stops authenticating personal-tier accounts.
• Who has to migrate: Google AI Pro, AI Ultra, free Gemini Code Assist for individuals, and Gemini Code Assist for GitHub users.
• Who doesn’t: Gemini Code Assist Standard / Enterprise license-holders, plus anyone on a paid Gemini API key or the Gemini Enterprise Agent Platform.
• Install Antigravity CLI: one curl command on macOS/Linux, one PowerShell one-liner on Windows (snippets below).
• What carries: Agent Skills, Hooks, Subagents migrate one-for-one; Extensions are renamed to Antigravity plugins.
• What’s new: Go rewrite, native multi-agent orchestration, asynchronous workflows, bidirectional settings sync with Antigravity 2.0.

What’s happening

On May 19, 2026 — the same day Google held its I/O keynote and announced Antigravity 2.0, Gemini 3.5 Flash, the Antigravity SDK, and a series of related launches — the Gemini CLI team posted a transition notice through developers.googleblog.com. Gemini CLI, the project will be retired for personal users. The replacement, Antigravity CLI, becomes Google’s single supported terminal entrypoint to its agent stack for consumers.

Some scale for what’s being retired. The migration post itself describes Gemini CLI at sunset as having “millions of users, with over 100,000 GitHub stars, 6,000 merged pull requests, and hundreds of contributors”. That puts it in the company of the largest open terminal-AI projects in the ecosystem. The decision to consolidate it into Antigravity CLI is not the kind a major vendor makes lightly, and the 30-day window reflects that — it’s tight, but it’s accompanied by an active migration doc, an Enterprise carve-out, and an explicit promise that API-key access keeps working.

The headline change isn’t a rename. It’s a rewrite. Gemini CLI was a Node/TypeScript codebase with weekly releases. Antigravity CLI is a Go binary that ships pre-compiled and shares its agent harness with the new desktop application announced the same day. The migration post’s own framing of why — quoted verbatim — captures the tension that motivated it: “you love a good terminal UI, you appreciate that we ship weekly releases, and your workflows have simply outgrown those early days of 2025… You now require multiple agents communicating with each other to split up the work and solve complex problems.”

Translation: the old single-agent Node design is being left behind because Google’s bigger bet — multi- agent orchestration with shared state across CLI and desktop — doesn’t fit cleanly on top of it. So they rebuilt it underneath you.

Who has to migrate (and who doesn’t)

The migration post is unusually direct about who’s in and who’s out. The clarity matters because the answer is different for individual developers, GitHub integration users, and enterprise teams. Here’s the breakdown straight from Google’s announcement.

Affected (must migrate to Antigravity CLI)

• Google AI Pro subscribers using Gemini CLI via their Google account.
• Google AI Ultra subscribers (both the new $100 tier and the existing $200 tier).
• Free Gemini Code Assist for individuals users — anyone using Code Assist on a personal Google account without an enterprise license.
• Gemini Code Assist for GitHub users — the GitHub integration that pulled in Code Assist functionality on PRs and issues.

Not affected (Gemini CLI keeps working)

• Gemini Code Assist Standard license-holders — the paid tier that sits between free individual use and full enterprise.
• Gemini Code Assist Enterprise license-holders — the top business tier.
• Paid Gemini API key users — anyone hitting the Gemini API directly with a billing-linked key keeps working unchanged.
• Gemini Enterprise Agent Platform users — the platform play for businesses building agents on Google Cloud.

The migration post puts it in a single sentence that’s worth quoting in full because it’s the cleanest line Google has drawn: “If your organization uses Gemini CLI or our IDE extensions via a Gemini Code Assist Standard or Enterprise license… your access remains unchanged. We’ll continue to support Gemini CLI… Gemini CLI will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys.”

If you’re not sure which tier you’re on, the simplest check: open Gemini CLI today and look at the account indicator. If it says anything other than Standard, Enterprise, or shows an API key as the auth method, you’re in the 30-day migration cohort.

Why a rebuild, not a rebrand

The dominant question on Hacker News and Reddit threads about this move is the same: if Gemini CLI was working, why retire it? Google’s stated rationale has three pieces.

Performance. The migration post is explicit: “Built in Go, Antigravity CLI is snappier and more responsive.” Anyone who’s spent time with Node CLIs knows the cold-start overhead — a few hundred milliseconds per invocation before the agent loop even starts. That adds up when the CLI is the thing you reach for a hundred times a day. Compiled Go binaries don’t pay that tax. They also ship as a single static file with no Node runtime dependency, which simplifies distribution and removes a class of “works on my machine” issues.

Multi-agent as a first-class primitive. The pull-quote from the migration post is the clearest signal of where Google sees workflows heading: “You now require multiple agents communicating with each other to split up the work and solve complex problems.” Gemini CLI was built around a single agent loop. Antigravity CLI inherits the dynamic-subagents model from Antigravity 2.0 — a main agent that can spawn and orchestrate subagents on the fly, each with its own isolated context window. That’s not a feature you bolt onto an existing single-agent runtime; it’s a different architecture.

Shared harness with Antigravity 2.0. This is the one that’s barely mentioned in the migration post itself but is visible in the way the CLI and the desktop app are being launched together. They share the same agent harness, the same conversation format, and bidirectional settings sync. Settings you change in the CLI propagate to the desktop app; permissions you grant in the desktop app are honored in the CLI. That kind of sync only works if the two surfaces run on the same core. The rebuild was the price of admission to that integration.

Worth saying out loud: a Node-to-Go rewrite for a project with 100,000 stars and 6,000 merged PRs is not a casual decision. The community contributions live in the old repo — Google’s challenge over the next few months will be re-attracting the contributor base to the new Go codebase. The Antigravity CLI repo at github.com/google-antigravity/antigravity-cli was created on May 13, 2026 and has a modest star count at launch. The interesting metric to watch is whether the open-source contributor cohort follows across the rewrite.

What carries over: Skills, Hooks, Subagents, Plugins

The good news for migrators: the constructs you already use are preserved by name. The migration post calls out four explicitly:

• Agent Skills. Migrate one-for-one. The Skills you’ve authored or installed in Gemini CLI work in Antigravity CLI with no schema changes.
• Hooks. Migrate one-for-one. Antigravity CLI inherits the same JSON-defined hook system the desktop app uses — global and workspace-scoped, with workspace taking precedence.
• Subagents. Migrate one-for-one. The runtime gets richer (dynamic spawning, parallel execution, isolated context windows) but existing subagent definitions don’t need to change.
• Extensions → Plugins. The one rename. Gemini CLI’s extensionsbecome Antigravity CLI’s plugins. Functionally identical, but the CLI command tree uses the new noun.

The Extensions-to-Plugins rename is the only place a working Gemini CLI user has to retrain muscle memory. If you’ve memorized gemini extension install or similar, you’ll re-learn the equivalent under the new plugin namespace. The data model itself doesn’t change — a plugin still ships the same kinds of tools and the same authoring shape.

Beyond those four, settings and conversation history transfer through the shared harness with Antigravity 2.0. If you install the desktop app first and then the CLI (or vice versa), your settings sync once you sign in.

What’s new in Antigravity CLI

The carry-over list is reassuring; the new-capabilities list is where the rebuild earns its keep.

• Go runtime. Single static binary, faster cold start, no Node dependency.
• Multi-agent orchestration. Dynamic subagents that can be spawned and orchestrated from inside a CLI session, each with its own isolated context window. Parallel execution; main agent collects results.
• Asynchronous workflows. Long-running operations move to background processes that don’t block the main agent. The practical version of this: kick off a build, keep talking to the agent, get notified when the build completes.
• Shared agent harness with Antigravity 2.0. Same runtime that powers the desktop app’s agents. Conversations are exportable between the two via the @conversation dropdown.
• Bidirectional settings and permissions sync. Permission grants and configuration choices flow both ways between CLI and 2.0.

None of these are revolutionary in 2026 — multi-agent and async workflows are table stakes in the category by now — but having them in a terminal UI that shares state with a desktop app is the integration story Google is selling. For users whose workflow already straddles a terminal and an IDE-or-desktop tool, the sync is the most practically valuable bit of the rebuild.

If you want a deeper map of how the desktop-side Antigravity flows are organized, the skill card above unpacks the agent-manager architecture that informed the CLI’s harness design too — useful context for understanding why settings sync works the way it does.

Install Antigravity CLI on macOS, Linux, Windows

The install is a single command. Pick the line for your platform.

macOS and Linux

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

The installer fetches the platform-appropriate binary, drops it on your PATH, and prints a completion message. First run will trigger the auth flow (covered in the next section).

Windows (PowerShell)

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

Same idea, PowerShell-native syntax. irm is Invoke-RestMethod and iex is Invoke-Expression — the script downloads and runs the Windows installer.

Repository

The source is at github.com/google-antigravity/antigravity-cli. The repo was created on May 13, 2026 — about a week before the public launch — and ships pre-compiled binary artifacts rather than buildable source at the time of writing. There is no LICENSE file in the repo at capture, which is worth noting if you need license clarity (see the unclear-things section below).

Auth: keyring + SSH-aware sign-in

The first time you run Antigravity CLI it walks through authentication. The flow is more thoughtful than the Gemini CLI predecessor in a few specific ways:

• System keyring first. The CLI checks your platform’s credential store (Keychain on macOS, Secret Service on Linux, Credential Manager on Windows) for an existing Antigravity token. If found, it uses it and skips the browser flow.
• Google Sign-In fallback. If no cached credential is found, the CLI opens a browser tab for OAuth-style sign-in with your Google account.
• SSH detection. If the CLI detects it’s running inside an SSH session — i.e. there’s no graphical session to open a browser in — it prints an auth URL to the terminal that you can complete on a different machine. The completed sign-in pushes the credential back to the remote machine’s keyring.
• /logout to clear. The CLI exposes a /logout slash-command that clears stored credentials from the keyring. Use this if you switch Google accounts, or before handing the machine to someone else.

The SSH-aware detection is the bit that matters most for ops workflows. Gemini CLI’s default browser-redirect flow caused friction for users running the CLI on a headless server over SSH. Antigravity CLI handles that path natively without requiring a manual --no-browser flag.

Migration cheat-sheet

What you do differently on day one of Antigravity CLI versus the Gemini CLI you’ve been living in.

Commands that map 1:1

• Chat with the agent. Same conversational loop; Skills, Hooks, and Subagents you have defined carry over unchanged.
• Hook definitions. Same JSON shape, same lifecycle hook points. You may need to copy the file from the Gemini CLI config dir to the Antigravity CLI config dir on first launch — the migration doc has the exact paths.
• Subagent specs. Same authoring format. They run in the new dynamic-subagents harness but the spec doesn’t change.
• Skill installations. Skills you have installed in Gemini CLI work in Antigravity CLI by re-pointing at the new skills directory.

What needs reconfiguration

• Extensions → plugins. Re-install any extensions you depend on through the plugin command surface. The CLI’s command tree uses plugin as the noun.
• Auth. First run triggers a fresh sign-in. Old Gemini CLI tokens are not transferred — they live in a different credential store entry.
• Settings file path. Antigravity CLI stores settings under its own config directory rather than the Gemini CLI one. If you have hand-edited config, copy the relevant bits across; the migration doc enumerates the per-platform paths.
• Repo-local configs. If you shipped a .gemini-cli/ directory in any repos for project-specific settings, you’ll want a parallel Antigravity CLI configuration in those repos too. The two can co-exist during the transition.

The terminology shift

The one rename that bites is extensions → plugins. Everywhere a Gemini CLI doc says “install an extension,” Antigravity CLI says “install a plugin.” The concept is the same; the noun changed. If you maintain internal documentation for your team’s Gemini CLI usage, this is the one find-and-replace you’ll want to run.

The Enterprise carve-out: why it exists

Google’s decision to leave Enterprise customers on Gemini CLI — even as they retire the consumer paths — is one of the more interesting signals in the migration post. The reasons aren’t stated explicitly, but four are plausible.

Stability for production deployments. Enterprise customers integrate the CLI into CI pipelines, internal developer platforms, and audit workflows that depend on stable, well-known behavior. A 30-day window to swap out a CLI binary in those environments is a non-starter. By keeping Gemini CLI alive on Enterprise tiers, Google avoids forcing a re-validation of every downstream pipeline in a month.

Compliance and audit posture. Enterprise contracts often specify exact versions or include a change-management process for tooling. Pushing a rewritten binary at those customers without notice would trigger contract reviews and security re-evaluations. Holding the old CLI steady gives those customers time to schedule the transition on their own timeline.

Cost predictability. Gemini Code Assist Standard and Enterprise are priced contracts with terms tied to existing CLI behavior. Switching CLIs mid-contract creates pricing ambiguity that’s easier to avoid by simply supporting both binaries for now.

The 100,000-star contributor base. Many of those contributors are inside enterprises. Leaving the old CLI supported there gives the community somewhere to land while the new Go codebase matures and absorbs the contributor attention.

What this means in practice: if you’re at a company with a paid Gemini Code Assist seat, you’re under no migration pressure. Your IT or platform team will choose when (or whether) to migrate. If you’re using Gemini CLI on a personal Google account at a company that doesn’t yet pay for Code Assist seats, that’s the gap the 30-day window applies to — and it might be worth a conversation with your IT team about whether to pick up an Enterprise seat as part of the transition.

If you don’t migrate: what breaks on June 19

For personal-tier users who skip the 30-day window, here’s what actually changes when the deadline passes.

• Personal-tier authentication stops. Google AI Pro, AI Ultra, free Code Assist for individuals, and Code Assist for GitHub no longer authenticate against the old Gemini CLI binary. Run it and you’ll get a sign-in error.
• The binary on disk doesn’t get force-removed. Your installed Gemini CLI keeps existing as a file. It just can’t talk to the consumer backend anymore.
• Paid Gemini API keys keep working. This is the escape hatch Google explicitly preserves: if you generate a paid API key and point your Gemini CLI installation at it, you’re back online. The migration post calls this out: “Gemini CLI will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys.” That’s a meaningful workaround for users who want to stay on the Node CLI for other reasons.
• Skills, Hooks, Subagents you have authored don’t go anywhere — they’re files on your disk. They migrate cleanly into Antigravity CLI when you’re ready.
• No data loss in the typical case. Conversation history is local. You won’t lose anything by waiting; you just lose access to the consumer authentication path.

The honest answer to “what’s my forcing function” is: the consumer auth path going dark. If you can’t pay for API key credits and you’re not on a Code Assist Standard/Enterprise seat, June 18 is a hard day to be ready for.

Relationship to Antigravity 2.0 desktop

Antigravity CLI is not a standalone product. It was launched the same day as the new Antigravity 2.0 desktop app and explicitly shares its agent harness, settings, and permission model with it. Worth understanding the shape of that relationship because it changes how the CLI fits into a workflow.

The CLI and the 2.0 desktop are two surfaces on the same runtime. A conversation you start in the CLI can be exported via the @conversation dropdown into the desktop and continued there. Permissions you grant in either surface honor the other. Settings synchronization is bidirectional — grant a tool in the CLI and the desktop app inherits the grant; toggle a setting in the desktop and the CLI picks it up.

The original Antigravity IDE — launched in November 2025 — still exists but is being de-emphasized; its agent-manager piece is being merged into Antigravity 2.0 in a later release. For migration purposes the takeaway is: if you use both a terminal and a desktop AI workflow today, the new CLI + 2.0 pairing is the supported path. You don’t have to install both, but they’re designed to be used together.

Quota usage in the unified setup is also worth tracking — the desktop app and CLI draw from the same account-level quota, so heavy use in one affects what’s available in the other. The skill card above is the practical helper for keeping tabs on quota state.

What’s still unclear (as of May 20, 2026)

Honest section. Several things in this migration aren’t pinned down yet. Treat these as open questions, not load-bearing facts.

• License of the CLI itself. The repo at github.com/google-antigravity/antigravity-cli does not include a LICENSE file at capture. Under default copyright law that means “all rights reserved” even though the repo is public. The companion Python SDK at github.com/google-antigravity/antigravity-sdk-python is explicitly Apache 2.0. We’d avoid calling the CLI “open source” in any rigorous sense until that file lands.
• On-prem story for Enterprise. Google left Enterprise on the old CLI, but hasn’t said whether or when Enterprise gets a migration path to the new harness with its data-residency and self-hosted requirements intact. Watch for a follow-up post.
• Contributor migration from Gemini CLI. 100,000+ stars and 6,000+ merged PRs is a substantial community footprint. Google hasn’t detailed how (or whether) that contributor base is being invited to the new Go codebase. The Antigravity CLI repo had a modest star count at launch — still early days. The community-momentum question is real.
• Behavioral parity between old and new. Google says Skills/Hooks/Subagents migrate one-for-one, but the edge cases — race conditions, error semantics, output formatting — will only surface as users port real workflows over the next few weeks. If you have a complex automation that depends on specific CLI behavior, allocate testing time.
• Per-token pricing for 3.5 Flash. Antigravity CLI uses Gemini 3.5 Flash as its default model. Google has described it as “less than half the cost of other frontier models” but has not published a per-token price card at launch. The only public anchor is the OS-demo math from their build-an-OS post.

None of these unknowns block the migration. They just shape how aggressively you’d commit to the new stack in the first 30 days. For most personal users the answer is: migrate this week, treat the first month as a soak period, give yourself room to find rough edges before the deadline.

FAQ

Sources

• Google migration announcement: developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli (May 19, 2026) — the canonical reference for affected tiers, sunset date, Enterprise carve-out, and the “snappier and more responsive” Go quote.
• Antigravity CLI launch blog: antigravity.google/blog/introducing-google-antigravity-cli
• Migration docs: antigravity.google/docs/gcli-migration
• Antigravity CLI repo: github.com/google-antigravity/antigravity-cli (created May 13, 2026; no LICENSE file at capture)
• Antigravity SDK (Python, Apache 2.0): github.com/google-antigravity/antigravity-sdk-python
• Antigravity 2.0 launch blog: antigravity.google/blog/introducing-google-antigravity-2-0 — background on the shared agent harness the CLI inherits.
• Gemini CLI catalog entry on mcp.directory: mcp.directory/servers/gemini-cli (third-party MCP wrapper)
• Logan Kilpatrick (Gemini team) on the unification: x.com/OfficialLoganK/status/2056803907154924031
• @geminicli migration announcement: x.com/geminicli/status/2056796084790304833