Before Gemini CLI Shuts Down (June 18): Audit Every Hidden Dependency Before Moving to Antigravity CLI

Confirm command mapping, and sequence the dry run

Once the inventory is done, confirm the behavioral diff in one place before replacing anything. The binary name changes from gemini to antigravity, but what actually bites you in a migration isn't the name—it's everything around it. At a minimum, verify these four against the real new CLI before any bulk replace:

• The launch command name (gemini → antigravity) and whether non-interactive subcommands/flags are spelled the same as before
• The config search path (does the new CLI read the old CLI's home-directory config, or look somewhere else?)
• Where credentials come from (did env var names or the auth flow change?)
• The meaning of exit codes (does success = 0 / failure = non-zero still match? Your CI pass/fail logic depends on this)

The rule is to verify in a throwaway directory, starting with read-only, low-impact operations. Running a production script first makes it hard to isolate the cause when it fails with side effects mixed in.

# Minimal checks in an isolated dry-run directory
TMP="$(mktemp -d)"; cd "$TMP"
echo "console.log('hello')" > sample.js
 
# Is the new CLI on PATH, can we read a version? (start with zero-side-effect checks)
antigravity --version || { echo "❌ antigravity not found. Install it first"; exit 1; }
 
# Read help to confirm the real subcommand/flag surface
# NOTE: always confirm exact subcommand names against the official migration notes
antigravity --help | head -40
 
echo "Once verified, proceed to replacing the production scripts"; cd - >/dev/null

Reading the --help output plainly is the shortcut here. I once assumed "the flags must be the same as the old CLI," ran a bulk sed, and a one-character difference in a non-interactive flag turned CI red. Don't guess spellings—look at the real surface before any mechanical replace.

Rewrite CI workflows while making failures visible

Calls inside CI are a chance to make failures visible at the same time you replace them. The number-one reason last-minute automation dies quietly is swallowed errors.

# Before (one GitHub Actions example) — failure is swallowed
- name: Generate code summary
  run: gemini summarize ./src > summary.txt || true

# After — replace the command and surface failure as a job failure
- name: Generate code summary
  run: |
    set -euo pipefail
    antigravity summarize ./src > summary.txt
  # For the first few days only, continue-on-error gives you a "fail but don't block" observation window
  continue-on-error: true

Two points. One: drop || true and add set -euo pipefail so you can judge whether it's actually working from the exit code. Two: for just the first few days after migrating, add continue-on-error: true to create an observation mode—"don't halt the pipeline on failure, but leave it in the logs and status." That way a missed replacement or auth drift shows up on your dashboard before it takes production down with it. Once the window passes, remove continue-on-error and return it to a required step.

If you want to rethink how you call agents from CI at all, pairing this with how to choose between the Antigravity CLI and the editor lets you tidy up the division of labor while you're in there.

Design the rollback before you cut over

The worst thing you can do in a migration is "swap everything to the new CLI and pray." To keep production automation running, prepare the way back before you move forward.

What works in practice is consolidating calls behind one thin wrapper. Instead of each script invoking antigravity directly, route them through an intermediary like ai-cli and switch the real implementation inside the wrapper.

#!/usr/bin/env bash
# ai-cli — a thin wrapper for the migration window; switch the impl with one env var
set -euo pipefail
 
# AI_CLI_IMPL=antigravity (default) / gemini (for emergency rollback)
IMPL="${AI_CLI_IMPL:-antigravity}"
 
if ! command -v "$IMPL" >/dev/null 2>&1; then
  echo "❌ '$IMPL' not found (check AI_CLI_IMPL)" >&2
  exit 127
fi
 
exec "$IMPL" "$@"

Replace each call site with ai-cli ... and, if antigravity does something unexpected, you can revert instantly just by setting AI_CLI_IMPL=gemini (until June 18, or for as long as the old binary remains locally). Because the switch point is consolidated in one place, you don't have to re-sed every script.

Of course, after June 18 the gemini side stops accepting requests, so this is insurance for "if the new CLI breaks on migration day, keep the old behavior alive just long enough to isolate the cause." The permanent fix is closing out every missed replacement and auth drift during the observation window. Keep the wrapper around and the same defense works the next time a CLI changes.

Don't make post-migration verification a manual checklist

If you finish the cutover on "probably fine" and the next thing to run is a midnight cron job, you won't learn about the failure until morning. Mechanize the verification too.

#!/usr/bin/env bash
# verify-migration.sh — machine-judge whether the migration is complete
set -uo pipefail
FAIL=0
 
echo "== 1. Remaining references to the old binary =="
if grep -rInE '\bgemini\b' . \
     --include='*.sh' --include='*.yml' --include='*.yaml' \
     --include='*.json' --include='Makefile' 2>/dev/null \
   | grep -v '/node_modules/' | grep -v 'ai-cli' | grep -q .; then
  echo "⚠️ gemini references still remain (see above)"; FAIL=1
else
  echo "✅ no direct references"
fi
 
echo "== 2. Does the new CLI respond? =="
if antigravity --version >/dev/null 2>&1; then echo "✅ antigravity responds"; else echo "❌ antigravity does not respond"; FAIL=1; fi
 
echo "== 3. Can we run through the wrapper? =="
if AI_CLI_IMPL=antigravity ./ai-cli --version >/dev/null 2>&1; then echo "✅ via ai-cli OK"; else echo "❌ wrapper failed"; FAIL=1; fi
 
[ "$FAIL" -eq 0 ] && echo "🎉 migration verification PASS" || { echo "🛑 there are incomplete items"; exit 1; }

Wire this verification into your migration branch's CI as one step and block the merge on exit 1, and you erase the human error of "forgetting to verify" entirely. The same hazard—a broken result getting frozen at the edge—shows up in web delivery too; the idea is shared with designing so a broken result never gets cached. Make failure observable, prevent it from being frozen, and keep a way back. Push hard enough and CLI migration and cache design arrive at the same principle.

The order that worked for me as a solo developer

The order that actually went smoothly for me was five steps: (1) surface all references with the audit script, (2) dry-run in an isolated directory to confirm the old/new diff, (3) consolidate calls behind the wrapper, (4) replace inside CI in observation mode, (5) wire the verification script into CI. It took about half a day, but only a tenth of that was the actual replacing—the rest was time spent making "where is it being called" visible. Put the other way: once the visibility is done, the migration stops being scary.

With days left on the clock, there's exactly one concrete step to take now. Run the audit-gemini.sh above against every repository you touch and your current user's crontab, and get the list of where gemini is buried out in front of you. Replacement can come after. As long as you can see it, June 18 passes by quietly.

If the migration is also a prompt to redesign how your agents run on a schedule, notes on implementing scheduled background agents make a solid foundation. Thanks for reading—I hope it helps anyone juggling several automations the way I am.