# There is no agy --yolo. How YOLO mode actually works in Antigravity (IDE and CLI)

> Source: <https://dev.to/agentrq/there-is-no-agy-yolo-how-yolo-mode-actually-works-in-antigravity-ide-and-cli-456l>
> Published: 2026-10-08 15:37:53+00:00

**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](https://agentrq.com) moves the decision to the task, and lets you answer prompts away from the terminal.

**1. Connect Antigravity** through the [ACP Gateway](https://agentrq.com/docs/connect-acp-agent) ([Antigravity setup guide](https://agentrq.com/docs/agents/antigravity)). 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](https://agentrq.com/features/task-scheduling), [event triggers](https://agentrq.com/features/events) and [workflow](https://agentrq.com/features/workflows) 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](https://github.com/agentrq/agentrq/blob/main/docs/EXTENSIONS.md) 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](https://agentrq.com/blog/jev-system-one-models), 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](https://agentrq.com/features/tool-call-history) afterwards. More: [AgentRQ YOLO mode](https://agentrq.com/features/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](https://agentrq.com) 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](https://agentrq.com/blog/what-is-yolo-mode-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](https://agentrq.com/guidelines/yolo-mode/antigravity).