Running Antigravity CLI 1.1.13 on a Machine You Cannot Sign In From

I dropped agy onto a machine with no browser installed, and the very first screen asked me to sign in. Nothing surprising about that once you think it through, but the shape of it stuck with me: a terminal-first tool that needs a browser before it will say hello.

CLI 1.1.13, released on August 14, removes that wall. Put GEMINI_API_KEY in the environment and the CLI talks to the Gemini API directly, no sign-in step involved.

The setup itself takes about five minutes. What mattered more, at least for me, was knowing how to confirm the switch actually took, and deciding which key to hand over. Both of those are below.

Machines you cannot sign in from are more common than they sound

The change matters in situations like these:

• Small servers with no GUI and no browser. There is simply nothing there to open a callback URL with
• Shared machines, where leaving your Google account signed in and walking away is not something you want to do
• Unattended runners where credentials should not be tied to one person. A setup that needs re-authentication every time ownership changes will not survive
• Machines that do have a browser but never come back from the auth screen. Proxies and third-party cookie settings both cause this (I wrote up how to isolate that symptom in Fixing Antigravity Google Sign-in That Won't Return From the Browser)

Until now that fourth case left you two options: fight the callback until it worked, or give up and use Antigravity only on your own machine. From 1.1.13 there is a third — don't sign in at all.

Two places to configure, and that's it

You need a model provider in your settings file, and a key in your environment.

First, add this to settings.json:

{
  "modelProvider": "gemini"
}

Then pass the key through the environment:

# Trying it out in an interactive shell
export GEMINI_API_KEY="YOUR_API_KEY"
agy

If you plan to keep using it, this ends up in a shell profile. There is one rule I hold to here, though.

Do not put the key in settings.json.

Config files travel further than you expect them to. They get committed as dotfiles, synced to cloud storage, and screenshotted verbatim when you ask someone for help with a bug. Keeping the key in the environment removes at least one of those paths.

If you feed the value from a .env file instead, watch out for how it is written. Quoting and a leading export both trip things up — I covered those cases in Why Antigravity's AI Agent Misreads .env Values, and the "it isn't being read at all" version in Why Antigravity Agents Can't Read Your .env File — Three Propagation Paths to Check First.

The startup banner tells you whether the switch took

There is a built-in way to confirm you are actually running on key auth.

The startup banner and /help both list the credential in use, and it should read "Gemini API key". If you still see a signed-in account name there, either the settings file you edited isn't the one being read, or the environment variable never reached that process.

The behavior that caught me off guard was /logout.

Run it expecting a session to end, and instead you get an explanation: the credential is coming from the environment. My first reaction was that something was broken. It isn't — an environment-supplied credential is not the CLI's to revoke. When you want it gone, you remove it from your side.

unset GEMINI_API_KEY
agy   # back to the usual sign-in prompt

A command that explains itself and then does nothing looks unhelpful at first glance. I've come around to it. It tells you exactly which lever to pull, which beats the alternative — believing you logged out when the credential is still sitting right there.

Changing the endpoint with GOOGLE_GEMINI_BASE_URL

If you need to route through a gateway or pin a region, the destination is an environment variable too.

export GEMINI_API_KEY="YOUR_API_KEY"
export GOOGLE_GEMINI_BASE_URL="https://your-gateway.example.com"
agy

Resist the urge to change both at once. When an auth error comes back, you won't know whether the key or the gateway is at fault. Get the key working against the default endpoint first, then add GOOGLE_GEMINI_BASE_URL. Following that order cuts your suspect list in half.

Staying on the theme of locked-down machines, 1.1.13 carries one more relevant fix: /codesearch now falls back to a local search when the bundled ripgrep binary cannot be executed. On machines where endpoint protection blocks unsigned binaries, that used to take the entire search feature down with it. Worth knowing before you deploy onto a managed device.

Don't hand the CLI the key your app is already using

This is the part I most wanted to write down after actually running it.

I use the Gemini API for image classification in my wallpaper apps. The key already exists on my machine, so wiring it up is a single export. That is exactly what I started to do.

Three reasons I stopped:

As a solo developer, adding another key feels like pure overhead. But the overhead is a one-time cost at issue time, while the cost of mixing them recurs with every incident. Keeping one key per purpose turned out to be the easier path.

The rule I settled on: split them when the person inconvenienced by an outage is different. If the app pipeline stops, users notice. If the CLI stops, only I do. Two different blast radiuses do not belong on one credential.

For the deeper version — injecting secrets at the moment of execution and keeping them out of logs — see Passing API Keys to Agents Safely. Worth a look if you're planning unattended runs.

Sign-in or key: choosing a default

Now that both work, here is how I pick between them.

I've landed on sign-in for my Mac and keys everywhere else. There is no need to standardize on one.

Where to start

Issue one throwaway key, export it on any machine other than the one you normally sign in from, and start the CLI. The moment the banner reads "Gemini API key," the configuration in this article is done. Just keep the "don't reuse an existing key" rule from that very first one — it saves you the untangling later.