antigravity-agents

Antigravity CLI Sub-Agents

Google Antigravity CLI (agy) is an autonomous terminal coding agent (Gemini and other models) that can read a repo, edit files, and run commands. This skill uses its non-interactive print mode to run delegated jobs: you write a self-contained task prompt, launch agy -p in the background, keep doing your own work, then collect and verify the result.

Treat an agy job like a contractor you briefed over email: it only knows what's in the prompt and the directory you point it at, and its work is unverified until you check it.

Resolving the binary

After install, agy is normally on your PATH. If a tool-spawned shell can't find it (some shells don't inherit a freshly updated PATH), fall back to the full path:

• Windows: %LOCALAPPDATA%\agy\bin\agy.exe (in Bash-style shells: "$LOCALAPPDATA/agy/bin/agy.exe")
• macOS / Linux: check which agy

Critical: always close stdin. agy blocks forever (0% CPU, no output, even in print mode) when stdin is an open pipe, which is exactly what non-interactive tool shells give it. Launch jobs with </dev/null appended (POSIX shells), or from PowerShell via cmd /c '... < NUL'. A "stalled" job with an empty log almost always means stdin was left open — kill it and relaunch with stdin closed.

Preflight (once per session)

Before the first job of a session, verify auth with a cheap probe:

agy -p "Reply with exactly: OK" --print-timeout 60s </dev/null

• Replies OK → authenticated, proceed.
• Prints a sign-in URL or errors about credentials → stop and tell the user to run agy once in their own terminal to complete the Google sign-in (it's a browser OAuth flow you cannot do for them). Don't retry until they confirm.
• Hangs with no output → you forgot </dev/null.

Conflict rule — the one thing that must not go wrong

An agy job and your own edits must never touch the same working tree at the same time. Decide the isolation level before launching: