Antigravity CLI: Google's Terminal Agent, and What Its README Leaves Out

What Antigravity CLI is for, and who it is not for

Antigravity CLI is a terminal user interface for the Antigravity agent. The README describes it as bringing multi-step reasoning, multi-file editing, tool calling and persistent history to the terminal, and it frames the target user narrowly: people who work over SSH or remote sessions and prefer the keyboard. The comparison table in the README draws the line against Antigravity 2.0, the GUI application, which it describes as aimed at comprehensiveness, visual orchestration and project management.

That split matters. If your work involves reviewing diffs in a visual editor, managing several projects at once, or orchestrating agents across a workspace, the README positions the GUI as the intended surface, not the CLI. The CLI is for the case where a full GUI is impractical, such as a remote shell with limited bandwidth. The README also notes the CLI is optimized for low resource overhead, which is the same argument.

What the README does not say is who should not use it. There is no stated minimum terminal, no list of unsupported shells, and no statement about whether the agent works without network access. Those gaps are worth noting before you commit a workflow to it.

The shared agent engine and how sessions move between CLI and GUI

The integration section is the most concrete part of the README. Both interfaces run on the same core agent engine, so the README states that improvements apply to both. Settings and permissions sync bidirectionally, meaning a permission you grant in the terminal should appear in the GUI as well. Session export goes one way: terminal sessions can be exported to Antigravity 2.0 to continue working there.

The README does not describe the reverse path. There is no statement about importing a GUI session into the terminal, and no detail on what an exported session contains, whether it includes full history or only a summary, or where the export is stored. If your workflow depends on moving a long-running task from the GUI back to SSH, the README is silent on whether that is supported.

The shared engine also means you cannot isolate the two surfaces. A change in engine behaviour, or a change to how permissions are evaluated, applies to both. That is convenient for consistency and inconvenient if you wanted the CLI to remain on a known older behaviour while the GUI moved ahead. Nothing in the README suggests a version pin between the two.

Installing Antigravity CLI on macOS, Linux and Windows

The README gives three install paths. On macOS and Linux, a shell script is piped into bash. On Windows, there is a PowerShell one-liner and a CMD variant that downloads a script, runs it, and deletes it. All three fetch from antigravity.google, so the install depends on that host being reachable.

For macOS and Linux, the README gives this command:

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

Piping a remote script into bash means you are trusting whatever the server returns at that moment. The README does not publish a checksum, a signature, or a versioned installer URL, so there is no documented way to install a specific release such as 1.2.5 rather than whatever is current. If your environment requires pinned artifacts, this install method does not satisfy it.

On Windows, the README shows two options. The PowerShell path is:

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

The CMD path downloads to a local file, executes it, and removes it:

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

After installation, the README says to start the tool by running `agy`. That is the only command name the README documents for launching it. There is no documented `--version` flag, no `agy --help` example, and no statement about where the binary is placed. If you need to verify the installed version matches a release listed in CHANGELOG.md, the README does not tell you how.

Authentication on local machines and over SSH

Authentication is described in more detail than most other parts of the README. The CLI authenticates through the system keyring, and falls back to Google Sign-In when no active session exists. On a local machine it opens the default browser automatically. In a remote or SSH session, it detects the SSH context and prints an authorization URL instead, so you complete the login on a local browser and the remote session picks up the result.

That SSH detection is the feature most likely to matter for the stated target user, and it is the one place where the README anticipates a real constraint. The sign-out path is `/logout`, a slash command rather than a shell command, which tells you the interface is a TUI with its own command grammar. The README does not list the other slash commands, so `/logout` may be the only one you can rely on without opening the tool and looking.

For enterprise access, the README says to connect your GCP project during onboarding and points to an Enterprise page for details. It does not explain what connecting a GCP project changes about data handling, billing, or which models are available. If you are evaluating this for a company, that is the first thing to clarify outside the README.

Data collection, opt-out and the security warning

The README carries a warning that AI coding agents have known security risks, naming autonomous code execution, data exfiltration, prompt injection and supply chain risks, and telling users to monitor and verify all actions the agent takes. This is honest but generic; it does not describe how Antigravity CLI specifically mitigates any of these. The README does say the agent makes edits with your permission, which implies a confirmation step, but the permission model itself is not documented here.

The data-use section states that by using the CLI you agree to let Google collect and use your Interactions data under the Google Terms of Service and Privacy Policy, and that you can opt out at any time via your settings. Two things are left open. First, the README does not say what Interactions data includes, whether that is prompts, file contents, command output, or all of them. Second, it does not name the setting that controls the opt-out, so you will have to find it in the TUI or in synced settings rather than in this document.

The licence is not stated in the README at all. There is no licence identifier, no link to a LICENSE file, and the repository's top-level entries do not include one. Treat the terms of service as the governing document, and read them before deploying this anywhere that handles regulated data.

Where Antigravity CLI is the wrong tool

The clearest limitation is the install and upgrade story. Every documented install path pulls the current build from a live URL. There is no documented version pin, no checksum, and no package manager route. The README does not mention Homebrew, npm, apt or any other registry, so if your policy requires artifacts from a signed package repository, this project as documented does not meet it. The related search terms people use suggest demand for exactly those routes, which is a sign the README is not answering the question.

The second limitation is the absence of a rollback path. The README does not document how to downgrade from 1.2.5 to an earlier release, how to uninstall, or where configuration and credentials live on disk. The CHANGELOG.md exists in the repository, so release history is tracked, but the README does not connect that history to any install or revert command.

The third is the missing configuration surface. There is no documented config file, no environment variable list, and no explanation of how settings sync with the GUI is implemented. The repository has an examples directory with statusline and title examples, which suggests some configuration exists, but the README does not describe it. If you need to reproduce a setup across machines, you are working from the examples folder and the tool's own interface, not from documentation.

Finally, the README does not state whether the CLI can operate offline or against a self-hosted model. Given the authentication flow runs through Google Sign-In, the default assumption is that it cannot.

Antigravity CLI compared with Gemini CLI and Claude Code

People searching for this project often compare it with Gemini CLI and Claude Code, so it is worth being precise about what the README supports. It does not mention either tool. The comparison it makes is internal: Antigravity CLI against Antigravity 2.0, the GUI. That is the only alternative the project itself positions against.

The difference in approach is the shared engine. Antigravity CLI and Antigravity 2.0 are two interfaces over one agent core, with settings that sync both ways and one-way session export from terminal to GUI. A standalone terminal agent has no second surface to export into; the terminal is the product. Whether that matters depends on whether you want to hand a session off to a visual environment later. If you do, the shared engine is the reason to pick this over a tool that only exists in the shell.

If you do not, the shared engine is also the cost. You inherit the GUI's permission model and settings, and you cannot pin the CLI to a different engine version than the GUI. For a team that wants a terminal agent with its own release cadence, that coupling is a constraint, not a feature.

Release cadence, maintenance and upgrade cost

The repository is not archived, and the last push was on 2026-09-17, the same day as the 1.2.5 release. The two prior releases, 1.2.4 and 1.2.3, landed on 2026-09-16 and 2026-09-15. Three releases in three days is a fast cadence for a tool at 1.2.x.

Fast releases cut both ways. You get fixes quickly, and you also get churn. Because no install path is pinned, running the install script again is the only documented way to move forward, and there is no documented way to move back. If a release breaks your workflow, the README offers no recovery procedure. That is the upgrade cost: you are always on the current build, and the current build changes often.

The licence question is unresolved in what the README and the repository entries show. No licence identifier appears in the README or in the top-level repository entries, so any adoption decision should be based on the Terms of Service and Privacy Policy links the README provides, not on an open source licence. This is not legal advice; it is a statement that the licence is not documented where you would normally look for it.

Editorial conclusion

Adopt Antigravity CLI if you work over SSH or live in a terminal and want the same agent engine as Antigravity 2.0 without the GUI. Do not adopt it if you need a documented offline mode, a pinned package manager install, or a written rollback path; the README offers none of these. Before installing, read the Terms of Service and Privacy Policy links in the README, confirm whether your GCP project is required for enterprise access, and decide whether you will opt out of Interactions data collection in settings.

Frequently asked questions

Official sources

1. google-antigravity/antigravity-cli on GitHub
2. Issues
3. README
4. Releases