Articles/Antigravity Basics

◉ Antigravity Basics/2026-06-12Intermediate

Six Days Until Gemini CLI Shuts Down — Auditing Automation Dependencies and Migrating to Antigravity CLI

With Gemini CLI ending on June 18, here is a practical walkthrough for finding gemini command dependencies hiding in cron, CI, and shell scripts, then migrating and verifying them on Antigravity CLI.

Antigravity CLI² Gemini CLI⁸ Migration² Automation⁵ CI/CD¹³ Operations⁶

✦ Premium Article

I looked at the calendar and sat up a little straighter. On June 18, 2026, Gemini CLI and the Gemini Code Assist IDE extensions stop processing requests for AI Pro, Ultra, and free individual tiers. That leaves six days.

If you only use the CLI interactively, switching to Antigravity CLI on the day itself would be mildly annoying at worst. What worries me is everything humans are not watching: the cron job that fires at 3 a.m., the CI step buried in a workflow file, the lone gemini -p line deep inside a shell script. On the morning of June 18, those will stop quietly, leaving nothing behind but an error log.

I had wired Gemini CLI into the update pipelines for several sites I run as an indie developer, and my migration began with an uncomfortable admission: I did not know exactly where all the dependencies were. What follows is the order I worked in — inventory, migration, verification — and what I actually found.

What Stops on June 18, and What Doesn't

It pays to define the blast radius precisely first. Get the scope wrong and the whole audit loses accuracy.

Two things stop:

Gemini CLI (the gemini command in your terminal) — request processing ends for AI Pro, Ultra, and free individual use
Gemini Code Assist IDE extensions — discontinued on the same date

Equally important is what keeps running:

The Gemini API itself — application code calling the API directly with an API key is unaffected
Antigravity IDE and the desktop app — these are the successors, not casualties
Antigravity CLI — the new Go-based CLI, which carries over Agent Skills, Hooks, Subagents, and Extensions

The critical distinction is between "code that uses the Gemini API" and "scripts that invoke the Gemini CLI." Anything going through an SDK is out of scope; anything launching the gemini command from a shell is in scope. The official background is in the Gemini CLI to Antigravity CLI transition announcement.

Surface Every Dependency Mechanically — Don't Trust Memory

I gave up on finding dependencies from memory. Only the me of six months ago knows what the me of six months ago put in those scripts.

Here is the three-stage inventory I actually ran:

# 1. Search projects and config directories for gemini command invocations
grep -rn --include="*.sh" --include="*.yml" --include="*.yaml" --include="*.mjs" \
  -E '(^|[^a-zA-Z_-])gemini( |$|[^a-zA-Z_-])' \
  ~/projects ~/.config 2>/dev/null | grep -v node_modules
 
# 2. Check jobs registered in cron
crontab -l 2>/dev/null | grep -n 'gemini'
 
# 3. Mine shell history for usage patterns that have become muscle memory
history | grep 'gemini -p' | tail -20

Stages 1 and 2 find the places where breakage causes real damage; stage 3 finds the places where your own hands will fumble after the switch. The search pattern is deliberately strict so that package names like gemini-api-client or compound words like antigravity-gemini don't produce false positives.

As you triage the results, sort them into two buckets: "used interactively by a human" and "invoked unattended by a script." Unattended wins priority every time — there is no human nearby to notice the failure.

In my environment, grep returned eleven hits, three of them unattended. Not a dramatic number, but one of those three sat inside a daily morning job and would have failed on June 18 without question had I missed it.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A working inventory script that mechanically surfaces gemini command dependencies across cron, CI, and shell scripts

✦The three compatibility gaps that actually stopped me mid-migration — auth, config files, and output format — with fixes for each

✦A smoke-test design and decision framework for a migration that has no rollback path

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The Three Compatibility Gaps That Actually Stopped Me

Antigravity CLI is the spiritual successor to Gemini CLI, but the implementation is a separate Go binary. If your plan is "replace the command name and done," you will likely trip exactly where I did. In order:

Gap 1: Config files do not carry over automatically

The old Gemini CLI's ~/.gemini/settings.json is not read by Antigravity CLI. The new configuration lives at ~/.gemini/antigravity-cli/settings.json, and the schema has changed too.

Before touching anything, stash the old configuration:

# Back up old settings and custom definitions wholesale
mkdir -p ~/cli-migration-backup
cp -r ~/.gemini ~/cli-migration-backup/gemini-$(date +%Y%m%d)

For the new config, I recommend rewriting only what you need rather than porting the old file wholesale. Going through my old settings.json line by line, I realized more than half were settings I no longer used. A migration is also an opportunity to declutter.

Gap 2: Authentication shifts from API keys to OAuth

With Gemini CLI, running off an API key in .env was common practice. Antigravity CLI's first-run setup is built around OAuth instead. On a local terminal this is painless — follow the authorization link in your browser and you are done.

The problem is CI and headless servers, where no browser can complete an OAuth flow. Here is how I split the decision:

Cron jobs on my own Mac — authenticate via OAuth once and let the CLI hold the token (renewal is automatic afterward)
Jobs running in CI — stop going through the CLI entirely and rewrite them as direct Gemini API calls. The API is not being discontinued, so peeling unattended workloads away from the CLI is the more stable position long-term

Rather than "move everything to the new CLI," the call that paid off most was "push unattended environments toward direct API calls." A CLI is fundamentally a human's workbench; as a component in an unattended pipeline, its auth and update mechanics make it one notch more fragile than the API. Once I accepted that framing, the architecture settled into place.

Gap 3: Output format and exit code differences break pipes silently

This one took the longest to discover. Anywhere I piped the old CLI's output straight into jq or grep, the new CLI's progress indicators and formatting quietly skewed the parsing. Nothing errored — empty results just flowed downstream. That silence is what makes it nasty.

The fix is simple: always state the output format explicitly when calling from a script.

# Explicitly request plain, undecorated text
antigravity -p "Draft release notes in three lines" --output-format text 2>/dev/null

And add a one-line guard before handing the result downstream, so a future format change fails loudly instead of silently:

RESULT=$(antigravity -p "$PROMPT" --output-format text 2>/dev/null)
[ -n "$RESULT" ] || { echo "[NG] CLI output was empty" >&2; exit 1; }

Keep the Post-Migration Verification as a Smoke Test

This part matters more to me than the migration itself. "It worked on migration day" and "it is still working next week" are different claims.

I wrote a small smoke test and placed it at the head of my daily scheduled run:

#!/usr/bin/env bash
# antigravity-smoke.sh — liveness check for non-interactive CLI execution
set -euo pipefail
 
VERSION=$(antigravity --version 2>/dev/null) || {
  echo "[NG] antigravity command not found" >&2; exit 1; }
 
OUT=$(antigravity -p "Reply with just: ok" --output-format text 2>/dev/null) || {
  echo "[NG] non-interactive run failed (possible expired auth)" >&2; exit 1; }
 
[ -n "$OUT" ] || { echo "[NG] response was empty (suspect output format change)" >&2; exit 1; }
 
echo "[OK] ${VERSION} responding"

It checks exactly three things: the command exists, authentication is alive, and output is non-empty. A dozen lines, but they catch the two failure modes most likely to appear after a migration — token expiry and output format drift from an update — first thing in the morning.

If this test halts before the pipeline body runs, broken output never reaches downstream steps. Without it, discovery waits until a human notices that an expected artifact never appeared, which in my experience can take days.

A Migration With No Rollback Path Rewards Moving Early

In a normal tool migration, "roll back to the old version if something breaks" is your insurance. That policy is void here. After June 18, the old Gemini CLI will not process requests — there is nothing to roll back to.

When rollback is off the table, the only insurance left is time. Concretely, I suggest this sequence:

Today — run stage 1 of the inventory script and build the dependency list (it takes thirty minutes)
By tomorrow — assign each unattended dependency to one of three fates: migrate to the new CLI, rewrite against the API, or retire
By June 15 — finish the migration; zero remaining calls to the old CLI
June 16–17 — run the new setup in parallel with normal operations for two days and watch it
June 18 — make deadline day a day where you do nothing

Step 4 is the one that matters. For the first day or two after migrating, check both the smoke test and the actual artifacts deliberately. Migrate at the last minute and you lose this parallel-run window — any problem then gets debugged after the deadline, in a world where going back is no longer possible.

Finish deadline-driven migrations three days before the deadline. Beyond this particular case, I find that margin matters most for indie developers like me, where one person watches everything.

Your Next Step

Run just stage 1 of the inventory script today. If it returns zero hits, you can meet June 18 with an easy mind. If it returns even one, this weekend is the right moment to migrate.

If you are facing the same deadline, I hope this record saves you a stumble or two.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.