TL;DR
agy --yolo is not a flag. The CLI's YOLO is agy --dangerously-skip-permissions, or "toolPermission": "always-proceed" in ~/.gemini/antigravity-cli/settings.json. proceed-in-sandbox in the CLI with the sandbox actually enabled.
Checked against Google's Antigravity docs (antigravity.google/docs) on October 7, 2026. Antigravity is closed source and Google doesn't publish the CLI's full flag list, so everything here comes from the documentation, not the code.
Migration muscle memory. On June 18, 2026, Google moved free, Google AI Pro and Ultra users from Gemini CLI to the Antigravity CLI. Gemini CLI had --yolo (now deprecated in favour of --approval-mode=yolo). agy didn't carry it over. Instead, it borrowed Claude Code's spelling:
agy --dangerously-skip-permissions
The naming is a design statement in itself. "yolo" sounds like a fun mode. "dangerously skip permissions" says what you're giving up. Google's CLI guide lists it with --sandbox as launch flags that override your saved settings for that one session, and the settings panel shows when a value came from a flag rather than the file.
Like most serious agents, Antigravity separates two questions:
Where the IDE and CLI differ is in how their "YOLO" maps onto those layers:
| Approvals | Terminal sandbox | Filesystem | MCP / web tools | |
|---|---|---|---|---|
| IDE Turbo | Off | Off | Whole filesystem | Allowed |
CLI --dangerously-skip-permissions |
Off | Unchanged ( --sandbox /enableTerminalSandbox , default off) |
Unchanged | Allowed (no prompts) |
So "YOLO in the CLI" leaves you exactly as sandboxed as you were before. On a stock install, that's not at all. Turbo is the more honest of the two: it's labelled as the everything-off preset.
The CLI keeps settings in ~/.gemini/antigravity-cli/settings.json, and it only writes the keys you change. The one that matters is toolPermission, which takes four values. Ordered from most to least paranoid:
| Value | Behaviour |
|---|---|
strict |
Asks before every tool that isn't a read |
request-review (default) |
Asks before writes, shell commands and web tools |
proceed-in-sandbox |
Runs terminal commands without asking as long as they stay in the sandbox , asks otherwise |
always-proceed |
Never asks. This is YOLO |
proceed-in-sandbox is the interesting design. Approval depends on containment, so the prompt only appears when the command wants out. The catch is that it's only meaningful if the sandbox is on:
{
"toolPermission": "proceed-in-sandbox",
"enableTerminalSandbox": true
}
In-session, /permissions opens the permissions manager (mode and rules for the running session), and /config or /settings opens the full editor. When a subagent is waiting on an action, Ctrl+K approves just that one action.
Yes, with rules. A permissions block takes allow, ask and deny lists:
{
"permissions": {
"allow": ["command(git)", "command(npm test)", "write_file(src/)"],
"deny": ["command(rm)"]
}
}
Matchers cover commands (including command(regex:...)), file writes, URLs and MCP tools ( mcp(server/tool)). Precedence is the conservative one: deny beats ask, ask beats allow. So a broad allow can never swallow a specific deny, and that's what lets you safely allow command(git) while still denying something narrower.
On macOS and Linux: Settings → General → Permission Settings. A project can override the preset or choose Inherit General.
| Preset | Sandbox | Terminal commands | Files | MCP and web |
|---|---|---|---|---|
| Default | On | Free inside the sandbox, ask outside | Workspace + temp | Ask |
| Request Review | Off | Always ask | Workspace only | Ask |
| Turbo | Off | Run without asking | Whole filesystem | Allowed |
Look at the shape of Default. It isn't "ask about everything". It's the IDE version of proceed-in-sandbox: the agent runs freely while it's contained, and stops when it wants to leave. For most work that's the better trade than Turbo. You keep the speed, and the blast radius stays at "workspace + temp".
Request Review is the odd one out. It turns the sandbox off, but makes up for it by asking about every command and limiting files to the workspace. That's human review instead of OS containment.
Two more IDE knobs:
asks-for-review, agent-decides, always-proceed) decides whether the agent waits for you to review its plans and other artifacts. It's YOLO for planning, separate from YOLO for tools.
Windows still uses the older model. Set Terminal Command Auto Execution to Always Proceed (it still respects your deny list) and the outside-of-folder file access policy to Always Allow. Sandbox mode is a separate toggle there.
Forum posts mention "Antigravity 2.0", but we found no official 2.0 page that changes the permission model. Today's documented options are Turbo in the IDE and --dangerously-skip-permissions / always-proceed in agy. If that changes, the doc pages above are where it'll show up first.
Both native switches cover a whole session (or a whole IDE preset). AgentRQ moves the decision to the task, and lets you answer prompts away from the terminal.
1. Connect Antigravity through the ACP Gateway (Antigravity setup guide). Its registry build publishes no checksum, so the first run needs --allow-unverified-agent:
npx @agentrq/acp-gateway@latest --agent antigravity-acp --allow-unverified-agent
Start it without --dangerously-skip-permissions or always-proceed. The gateway also moves each new session out of any self-approving mode and into one where the agent asks a person.
2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, your phone or Slack, with the command or edit it wants to run. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes the limit.
3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every request in that task is auto-approved, and every other task still asks. The flag lives on the task, so it survives agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.
3b. YOLO for the whole workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.
Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.
The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.
The trade-off. Per-task YOLO is scoped trust: it ends with the job you vetted, so a nightly scheduled run can be YOLO while your interactive tasks stay supervised. Workspace-wide YOLO is less friction, but every future task inherits it. With Antigravity in particular, remember the layering above. AgentRQ's YOLO only answers the approval question, so set "enableTerminalSandbox": true and auto-approved commands still run inside the sandbox. Add a clean git tree before each YOLO task and a look at the tool call history afterwards. More: AgentRQ YOLO mode.
Does agy --yolo exist? No. Use agy --dangerously-skip-permissions, or "toolPermission": "always-proceed".
What's the difference between Turbo and the agy flag? Turbo also turns off the sandbox and opens the whole filesystem. The CLI flag only skips approvals.
Is the agy terminal sandbox on by default? No. Enable it with --sandbox or "enableTerminalSandbox": true.
What's the safest "fast" setting? The IDE's Default preset, or proceed-in-sandbox with the sandbox on in the CLI: no prompts while contained, a prompt when the agent wants out.
Do deny rules still work with always-proceed? The docs say Windows' Always Proceed respects the deny list. For rules in general, deny beats ask beats allow.
How do I approve Antigravity commands from my phone? Connect it to AgentRQ through the ACP Gateway. Permission requests show up in the task.
For every other agent, see what YOLO mode is and how to turn it on in every coding agent.
Question for the comments: is "approve automatically only while sandboxed" (Default / proceed-in-sandbox) the pattern every agent should copy, or does it just move the trust problem into the sandbox config? 👇
Originally published on AgentRQ.