Post

Antigravity CLI Migration: A Production-Minded agy Checklist After Gemini CLI

Posted
Antigravity CLI guide cover image from Goddaehee's Tistory post
Antigravity CLI guide cover image from Goddaehee's Tistory post
By Fodev JEO 8 min read

🤔 Curiosity: What happens when a daily AI CLI changes underneath us?

The uncomfortable part of AI tooling is not learning a new command. It is discovering that a tool has become part of your daily engineering muscle memory, and then watching the runtime contract change.

That is why I wanted to unpack Goddaehee’s Antigravity CLI guide. The original Korean post is practical: it starts from the Gemini CLI transition notice, then walks through agy basics, permission flags, aliases, and migration steps. My lens is slightly different. I care about what this means for teams that actually ship: game tooling, build automation, content pipelines, research prototypes, and agent-assisted refactors.

The production question is:

Can we move from Gemini CLI habits to Antigravity CLI without losing safety, reproducibility, or local workflow speed?

Antigravity CLI guide cover

đź“š Retrieve: What the source page establishes

The source page is a hands-on guide to Antigravity CLI, whose terminal command is agy, not antigravity. It frames the transition around Google’s announcement that affected Gemini CLI and Gemini Code Assist IDE extension request serving stops on June 18, 2026. The linked Google Developers announcement describes Antigravity CLI as the successor path for a more agent-first CLI platform.

The page’s practical structure is useful:

TopicSource-page takeawayProduction interpretation
NamingRun agy, not antigravityThe first failure mode is simply invoking the wrong binary
Interactive workagy starts a continuing conversationGood for exploration and project orientation
One-shot workagy -p / print-style execution returns one resultUseful for scripts, CI helpers, and quick repo questions
Conversation resumeagy -c or agy --conversation <ID> resumes workUseful only if the prior context is still safe and relevant
Permissions--dangerously-skip-permissions auto-approves tool actionsTreat this as a high-risk mode, not a speed feature
Safer testing--sandbox gives a middle pathBetter default for experiments on unfamiliar repos
MigrationBack up ~/.gemini, import Gemini plugin state, and check MCP config keysMigration should be testable and reversible

The linked sources from the page are:

What I downloaded from the source page

I saved the article media and code locally so this post does not depend on hotlinked Tistory assets.

Representative images:

Antigravity CLI background and migration context

Antigravity CLI command examples

Antigravity CLI permission warning

Antigravity CLI alias setup

All downloaded image assets:

  • /assets/img/posts/2026-05-18-antigravity-cli/antigravity-cli-01.png through /assets/img/posts/2026-05-18-antigravity-cli/antigravity-cli-20.png

Extracted sample-code files:

The workflow model: explore, act, resume, migrate

For a production engineer, I would not treat agy as “just another chat CLI.” I would treat it as a local agent runner with four modes of use:

flowchart LR
    A[Install and verify agy] --> B[Explore interactively]
    B --> C[Run one-shot checks]
    C --> D[Resume known-safe context]
    D --> E[Migrate Gemini-era config]
    E --> F[Validate on a disposable repo]

1. Start with boring verification

The first test should not be clever. It should prove the binary exists and the shell can run it.

1
2

agy --version
agy

If this fails, do not debug agent behavior yet. Debug PATH, shell initialization, and installation first.

2. Separate interactive work from one-shot work

Interactive mode is good when I want the agent to learn the project shape:

1
2

agy
agy -i "Explain this project structure before making changes."

One-shot mode is better when I want a bounded answer:

1

agy -p "List the three largest files in this directory and explain why they matter."

That distinction matters in production. Exploration benefits from context accumulation. Automation benefits from bounded outputs and predictable failure modes.

3. Resume only when the old context is still valid

The source page highlights recent-conversation resume and ID-based conversation resume:

1
2

agy -c
agy --conversation <conversation-id>

I would use this only after checking whether the repo state has changed. In a game build pipeline or large codebase, stale agent context can be more dangerous than no context.

4. Treat permission bypass as a risk boundary

The biggest practical warning in the source page is --dangerously-skip-permissions. The name is accurate. This mode removes the normal human approval step for tool actions.

For real projects, my default rule would be:

ModeWhere I would use itWhere I would avoid it
agyNormal repo exploration and assisted editsNone; this is the baseline
agy --sandboxExperiments, new tools, unknown reposTasks that need full host access
agy --dangerously-skip-permissionsDisposable directories onlyProduction repos, secrets, shared worktrees

That is not conservatism for its own sake. Agentic tools can edit files, run commands, and call other tools. Removing prompts means your repo hygiene, sandboxing, backups, and git checkpoints must carry more of the safety burden.

Alias design: fast should still communicate risk

The source page proposes three aliases:

1
2
3

alias ag='agy'
alias agd='agy --dangerously-skip-permissions'
alias agr='agy --continue --dangerously-skip-permissions'

I like the convenience, but I would add one team convention: dangerous aliases should look dangerous in docs and onboarding. A short name like agd is efficient, but it hides risk after the first week.

For my own team workflow, I would document aliases like this:

AliasExpands toTeam rule
agagyNormal daily entry point
agsagy --sandboxDefault for unfamiliar projects
agdagy --dangerously-skip-permissionsDisposable directories only
agragy --continue --dangerously-skip-permissionsResume only inside a disposable worktree

The source page’s shell setup block is attached as a local sample-code file. I would adapt it rather than paste it blindly, especially on shared machines.

Migration checklist from Gemini CLI

The migration part of the original guide has a good shape: inspect, back up, import, then fix config differences.

My production version would look like this:

  1. Inventory old state: check ~/.gemini/, project-local .gemini/, and any MCP config files.
  2. Back up before moving anything.
  3. Run the Gemini import path only after agy --version works.
  4. Move skills deliberately, not with a blind global copy.
  5. Review MCP config keys, especially url versus serverUrl.
  6. Validate on a throwaway repo before touching a real product repository.

The MCP key difference is small but operationally important:

1
2
3
4
5

// Gemini-style remote MCP server shape
"mcpServers": { "my-server": { "url": "http://localhost:3000" } }

// Antigravity-style remote MCP server shape
"mcpServers": { "my-server": { "serverUrl": "http://localhost:3000" } }

This is the kind of detail that breaks an agent workflow silently: the CLI starts, but the tool it needs is no longer reachable.

đź’ˇ Innovation: How I would ship this into a real workflow

If I were introducing Antigravity CLI to an AI/game engineering team, I would not start by telling everyone to replace their daily command overnight.

I would stage it like a runtime migration:

StageGoalExit criteria
LabConfirm install, auth, and basic command behavioragy --version, agy, and agy -p work on a scratch folder
Tooling repoTest one-shot analysis and safe sandbox flowsNo unexpected file edits; command outputs are reproducible
Migration dry runBack up Gemini config and test import behaviorSkills/MCP servers are visible and documented
Production pilotUse agy on a bounded non-critical taskGit diff is reviewable and validation commands pass
Team adoptionDocument aliases and safety rulesEveryone knows when not to use dangerous mode

For game production, this maps cleanly to real work:

  • Use agy -p for quick asset-pipeline diagnostics.
  • Use interactive agy to understand unfamiliar build scripts.
  • Use sandbox mode when testing new automation around Unity, Unreal, or Python tools.
  • Avoid permission bypass in repositories with credentials, generated asset caches, or platform signing material.

The insight is not “Antigravity CLI is better because it is new.” The insight is that CLI agents are becoming infrastructure. Infrastructure needs migration plans, safety boundaries, and rollback paths.

Key takeaways

InsightImplicationNext step
agy is the daily command surfaceMigration starts with shell and PATH reliabilityVerify install before moving workflows
Gemini CLI transition has a hard date for affected usersWaiting until the last week creates avoidable riskBack up config and test import early
Permission bypass changes the trust modelSpeed moves risk from prompts into environment designUse disposable directories or sandboxing
MCP config drift is easy to missTool integrations may fail even when the CLI worksAudit config keys and server reachability
Aliases shape behaviorShort commands can normalize risky modesMake dangerous aliases explicit in team docs

The new question this raises for me is broader than Antigravity CLI:

As AI CLIs become agent runtimes, should every team maintain an “agent migration checklist” the same way we maintain database and build-system migration checklists?

I think the answer is yes.

References

AI, Developer-Tools, Workflow
antigravity-cli gemini-cli agy cli-workflow ai-agents migration
This post is licensed under CC BY 4.0 by the author.