antigravity-rescue · git:20260713.797aca7 · 2026-07-13 · sha256 cea3dec21d6a7462
antigravity-rescue git:20260713.797aca7A
Immutable. This exact content is served forever at /api/v1/blob/cea3dec21d6a7462.
--- name: antigravity-rescue description: > Use when stuck, wanting a second implementation or diagnosis pass, or handing a substantial task to Google's Antigravity CLI (agy) through a real subprocess -- a genuinely different agent harness, not just another model. Not relevant when already running under Antigravity CLI itself. --- # Antigravity Rescue A thin forwarding wrapper around Google's Antigravity CLI (`agy`). Your only job is to forward the task and return its output. Do not inspect the repo, read files, draft your own solution, or do any independent analysis — that defeats the purpose of getting a second, independent opinion. ## Security: `agy -p` has no enforced sandboxing Verified live (three separate tests, all on `agy` 1.0.6): in headless print mode, `agy` executed a shell command, deleted a file inside the declared `--add-dir` workspace, and deleted a file **outside** it — all instantly, with zero confirmation, whether or not `--dangerously-skip-permissions` was set. That flag appears to only affect the interactive TUI's confirmation dialogs; headless mode has no technical permission boundary at all. `--add-dir` is a workspace *hint* (it decides where ambiguous file operations default to when unspecified) — it is **not** an access restriction, and does not confine `agy` to that directory. Practical consequence: `--read-only` below is **prompt-compliance only** — the model choosing to honor an instruction, not anything CLI-enforced. There is no equivalent of Claude Code's `--permission-mode plan` here. Forward a task expecting the same trust you'd extend to giving `agy` unrestricted filesystem access under your own user account, regardless of which flag you pass — because that's what you're actually doing. ## When to use - Proactively, when stuck: a recurring error, an approach that isn't converging, or a task that would benefit from a different agent harness's take. `agy` is a multi-vendor router (`agy models` lists Gemini, Claude, and GPT-OSS variants) — the value isn't necessarily a different underlying model, it's Google's own agent orchestration and tool-execution layer. - Don't grab a task you can finish quickly yourself — this is a rescue mechanism, not a first resort. ## How to forward ```bash scripts/antigravity-companion.sh task "<the task, verbatim>" [--model <name>] [--resume|--fresh] [--write|--read-only] [--timeout <duration>] ``` - Preserve the task text as-is; strip only the routing flags below before forwarding. - **`--model`**: leave unset by default (agy picks its own default). Only pass a value on explicit request — check `agy models` for the current list; names span multiple vendors, not just Gemini. - **`--write` / `--read-only`**: `--write` (default) runs with `--dangerously-skip-permissions`. `--read-only` prepends an explicit "diagnosis only, do not modify files" instruction to the task text — see the Security section above: this is the *only* protection either mode has, CLI-enforced or not. Prefer `--read-only` whenever the ask doesn't clearly need `agy` to make changes. - **`--resume` / `--fresh`**: `--fresh` (default) starts a new Antigravity conversation. Use `--resume` (`agy -c`) only when continuing a prior rescue in the same repo. - **`--timeout`**: defaults to `10m` (agy's own default is `5m`, tight for a substantial rescue task). Raise it further for a large ask. - Return the script's output exactly as printed. No added commentary before or after it. If the call fails, surface the raw failure — don't paper over it or retry silently. ## Why `--add-dir` is still non-negotiable The companion script always passes `--add-dir "$(pwd)"`. Without it, `agy` silently operates in its own internal scratch sandbox (`~/.gemini/antigravity-cli/scratch`) instead of the real project — confirmed live, not a hypothetical edge case. This makes ambiguous file operations land in the right place; it does **not** restrict `agy` to that directory (see Security above) — never invoke `agy -p` directly without it regardless.