Gemini CLI personal access ends June 18 as Google moves users to Antigravity

AI 요약

• What happened: A Google Gemini CLI announcement says personal-user access will move to Antigravity CLI on June 18, 2026.
  • Google AI Pro, Google AI Ultra, and free personal users will no longer send requests through Gemini CLI, Gemini Code Assist IDE extensions, or Gemini Code Assist on GitHub through the old path.
• What remains: Gemini Code Assist Standard and Enterprise, Google Cloud, paid Gemini, and API-key based organizational access continue to support Gemini CLI.
• Developer impact: Teams using CLI wrappers, IDE extensions, GitHub apps, or OAuth-based scripts should test authentication, permissions, logs, and automation before moving to agy.
  • The Gemini CLI repository remains Apache 2.0, but the operational boundary between open-source code and personal-user request routing is changing.

Google posted Discussion #27274 in the Gemini CLI repository on May 19, 2026. The announcement is a migration notice for the terminal AI agent experience. Starting June 18, 2026, Google AI Pro, Google AI Ultra, and free personal users will no longer be able to send requests through Gemini CLI. The same change applies to Gemini Code Assist IDE extensions and Gemini Code Assist on GitHub when they rely on Gemini CLI.

This is not a simple notice that Gemini CLI is being deleted. Google wrote that organizations using Gemini Code Assist Standard or Enterprise, Google Cloud, paid Gemini, and Gemini Enterprise Agent Platform API keys will keep Gemini CLI access. The repository also remains available under Apache 2.0, with Google promising model releases, bug fixes, and security fixes for enterprise customers. The changing part is the request path used by personal, free, Pro, and Ultra accounts.

For developers, the product name is less important than the dependency graph. A person who runs Gemini CLI directly may only need to install Antigravity CLI and adjust muscle memory. A team that wrapped the gemini command in internal scripts, reused the same authentication inside IDE extensions, or connected GitHub app workflows for pull-request and issue work has a different risk profile. After June 18, failures may not look like a model deprecation warning. Some requests will stop because the access channel has moved.

Google's explanation points to a product architecture problem: multi-agent work has grown beyond a standalone command-line interface. The announcement says Antigravity CLI is written in Go, has faster responsiveness, supports asynchronous background workflows, and shares architecture with the Antigravity 2.0 desktop app. Google also says core Gemini CLI capabilities such as Agent Skills, Hooks, Subagents, and Extensions are carried forward, with Extensions moving into Antigravity plugins.

The Antigravity CLI product page describes the tool as a terminal-first surface for invoking, supervising, and interacting with agents inside the command-line workflow. Its feature cards list natural-language tasks, parallel subagents, an /agents panel, ctrl+k tool approval, /config, /keybindings, slash commands, MCP, skills, hooks, and plugins. Google is not presenting the CLI as an isolated utility. It is making the terminal part of a broader Antigravity agent platform.

That makes this migration different from the recent Antigravity 2.0 subagent demos. A demo that mentions 93 subagents or billions of tokens is about scale and capability. This announcement changes account eligibility and product routing. For an individual developer, the immediate risk is not whether the model became smarter. The risk is whether authentication, account type, IDE extension routing, and GitHub integration still point to a working channel after June 18.

Community reaction focused on that boundary. In the GitHub discussion, users quickly asked whether Antigravity CLI would be open source like Gemini CLI. Others said early Antigravity CLI usage felt weaker than Gemini CLI in areas such as diff review or remembering documentation-project context. One contributor who said they had merged a 27-commit pull request into Gemini CLI raised a sharper concern: whether community-built code now primarily remains as an enterprise-maintained codebase while personal access moves elsewhere.

Google did not say it is closing the repository. The official wording says the opposite. Gemini CLI remains public under Apache 2.0, and Google says it will continue model releases, bug fixes, and security fixes. For personal users, however, source availability and request availability are separate questions. A developer may still install the code, but if backend authentication and quota routing change, the working routine can break.

That separation exposes how AI coding tools behave more like SaaS systems than traditional command-line utilities. A conventional CLI can often keep running as long as the binary, local configuration, and dependencies remain available. An AI agent CLI depends on the model service, authentication, rate limits, account policy, and remote backend. The Gemini CLI repository can remain open, while the gemini command used by a personal account stops reaching the previous request path.

Teams should audit four surfaces before the migration date. First, find local scripts and CI jobs that call gemini directly. Second, separate IDE extensions and GitHub apps that authenticate through personal accounts from those governed by an organization license. Third, check whether hooks and skills will move cleanly into Antigravity plugins or a new skills location without changing file paths and permission assumptions. Fourth, decide where existing logs and audit records will live if Antigravity 2.0 artifacts or agent-management views replace the old workflow.

Hooks deserve security review before simple installation work begins. The Antigravity hooks documentation describes configurations that run scripts or shell commands at specific execution events. That is familiar to teams that attached custom workflows to Gemini CLI, but it is also the point where a local command can run inside an agent loop. Migration should therefore include a fresh approval pass for which event triggers which command, not just a package swap.

Plugins matter for the same reason. The Antigravity CLI plugins documentation describes bundles that can include skills, background subagents, linting rules, MCP definitions, and event hooks. Teams that previously managed .gemini settings, MCP servers, internal prompt packs, and shell hooks separately may be able to package them together in Antigravity. That can simplify distribution, but it also makes permission review more important because one bundle can introduce multiple execution surfaces.

Individual developers have a smaller but still concrete checklist. Google's announcement says Antigravity CLI can already be used with Google Cloud projects. Anyone who treated the old Gemini CLI as a local open-source tool should test Antigravity CLI before June 18 in a real repository. Installation, login, quota display, file-edit approval, diff review, task cancellation, and log storage should all be checked against an actual coding task. For coding agents, first-run success is less important than how the product behaves after a failed command or partial edit.

Enterprise users should not read the notice as permission to ignore the migration. Google says existing Gemini CLI access remains for supported organizational channels, but the split between personal and enterprise paths can reveal shadow usage. An official company IDE extension may continue to work, while a developer's local script that authenticates through a personal Google AI Pro account suddenly needs Antigravity. Security teams should search for personal-account automation instead of stopping at the sentence that says organization access continues.

The competitive pattern is visible across the coding-agent market. Claude Code emphasizes long-running workflows and subagent operation. OpenAI Codex connects desktop, mobile, and remote execution surfaces. GitHub Copilot ties IDE, CLI, cloud agent, and mobile workflows to model selection and billing. Google is making the same structural move: Gemini CLI is being aligned with Antigravity 2.0, Antigravity CLI, and Antigravity SDK as one agent platform rather than a standalone open-source terminal tool.

That alignment has a trust cost. Repository stars and contributor counts do not fully cushion a product-channel migration. Users contributed to open-source code while also depending on Google accounts and backend quota. Google now says the repository remains, while personal access through the old route ends. There is no technical contradiction in those statements, but many developers experience value through continuity of use rather than source visibility alone.

For Korean development teams watching this news, the practical issue is not a benchmark comparison. June 18 should be treated as a dependency deadline. Shell aliases, VS Code settings, JetBrains settings, GitHub app permissions, MCP server configuration, internal prompt packs, hook scripts, and cost-tracking dashboards all need one pass. Teams should decide whether personal-account agent workflows move into organization licenses, migrate to Antigravity CLI, or get replaced by another CLI.

Based on the confirmed facts, Gemini CLI is not disappearing. The old personal-user request path ends on June 18, 2026. Antigravity CLI is the new terminal surface Google wants those users to adopt, and Google is tying the change to multi-agent execution and shared desktop architecture. The part that is easy to miss is that an AI coding agent's dependency chain is not just the binary name. It includes account policy, backend availability, permission design, logs, and automation paths.

The minimum migration test is straightforward. Before June 18, install Antigravity CLI in one real repository and reproduce one workflow that previously used Gemini CLI. Check diff review, tool approval, hook execution, MCP connectivity, failure logs, and quota or cost visibility. To see whether automation will break, create failure cases rather than only happy paths: a command without permission, a failing test, a file-edit conflict, and a long-running task that must be canceled. Those cases will show whether the new CLI fits the team's operational bar before the deadline arrives.