# How to give Antigravity (agy) full permission, safely

agy --dangerously-skip-permissions for one run, toolPermission always-proceed to persist, Turbo in the app. What each skips, and what still blocks.

To give Antigravity full permission in the `agy` CLI, run `agy --dangerously-skip-permissions` for one session, or set `"toolPermission": "always-proceed"` in `~/.gemini/antigravity-cli/settings.json` to make it the default. In the Antigravity app, the same thing is the **Turbo** preset. Deny rules still apply in every mode, which is what makes the safe version below possible.



This comes from Google's [CLI reference](https://antigravity.google/docs/cli/reference/), [agent settings](https://antigravity.google/docs/agent-settings/) and [permissions](https://antigravity.google/docs/permissions/) pages, plus the live checks on [our Antigravity control-model page](/controls/antigravity). Checked against `agy` 1.1.21; newer versions may differ. The rule language has its own page: [Antigravity permissions reference](/blog/antigravity-permissions-reference).

## The three ways to allow everything

| Where | What you set | Scope |
|---|---|---|
| `agy` CLI, one run | `--dangerously-skip-permissions` | That invocation only |
| `agy` CLI, persistent | `"toolPermission": "always-proceed"` in `settings.json`, or Tool Permission in `/config` | Every session for that user |
| Antigravity app | Turbo preset | Global, or one project |

### One run: the flag

```sh
agy --dangerously-skip-permissions
agy -p "fix the failing tests" --dangerously-skip-permissions
```

The [CLI reference](https://antigravity.google/docs/cli/reference/) describes it as "Auto-approve all tool permission requests without prompting." The [agent settings page](https://antigravity.google/docs/agent-settings/) says the flag activates the `always-proceed` tool permission mode and that it overrides `auto` mode.

### Persistent: `toolPermission`

```json
{
  "toolPermission": "always-proceed"
}
```

That goes in `~/.gemini/antigravity-cli/settings.json`. You can also set it from inside a session with `/config`. The four values, in Google's words:

| `toolPermission` | Behaviour |
|---|---|
| `request-review` (default) | Prompts for write, bash, web and MCP tools unless an allow rule covers them |
| `proceed-in-sandbox` | Runs terminal commands without prompting when the sandbox is on and the command runs inside it |
| `always-proceed` | Runs commands, web requests and MCP tools without prompting unless an ask or deny rule matches |
| `strict` | Prompts before every tool action, including file reads, even if an allow rule matches |

File edits are a separate switch. `agentMode` decides whether edits need a diff review:

```json
{
  "agentMode": "accept-edits",
  "toolPermission": "always-proceed",
  "artifactReviewPolicy": "always-proceed"
}
```

`accept-edits` auto-approves workspace file edits and creations and keeps following `toolPermission` for commands. `artifactReviewPolicy: "always-proceed"` stops the agent waiting for your review of plans and other artifacts; Google notes it does not affect file edits. Leave it out if you want to read plans before work starts.

The CLI reference lists no `--yolo` or `--approval-mode` flag. Those belong to Gemini CLI, which `agy` replaced.

### The app: Turbo

Google's [agent settings page](https://antigravity.google/docs/agent-settings/) lists four presets. Turbo is the full-access one: "All commands run without prompting with no isolation or restrictions", with full read and write access to the filesystem. MCP and web are allowed.

| Preset | Sandbox | Commands | Files | MCP and web |
|---|---|---|---|---|
| Request Review | Off | Always ask | Workspace only | Ask |
| Default | On | Allowed in sandbox, ask outside | Workspace and temp dirs | Ask |
| Auto | On | Allowed in sandbox, checked automatically outside | Not stated | Not stated |
| Turbo | Off | Allowed, unrestricted | Full filesystem | Allowed |

Auto is not offered on business or enterprise accounts. Those accounts use the previous settings, where **Always Proceed** under terminal command auto execution is the equivalent: commands run without prompting except those on your Deny list.

## Per-project vs global

**In the app** this is built in. Set the global preset under **Settings > General > Global Permissions > Permission Preset**. Override it for one project under **Settings > Projects**. Projects start on **Inherit Global**; choose **Use Global Settings** to drop an override. So the common setup is a strict global preset and Turbo only on a throwaway repo.

**In the CLI** Google documents one settings file, `~/.gemini/antigravity-cli/settings.json`. There is no documented per-project settings file. The per-project equivalent is per-invocation: keep the global file strict, and pass `--dangerously-skip-permissions` or `--mode=accept-edits` only when you launch `agy` in the project you want opened up. A shell alias scoped to a directory does the same job.

Hooks are the exception: a workspace can register its own in `.agents/hooks.json`, which loads behind folder trust. See the [hooks reference](/blog/antigravity-hooks-reference).

## What still blocks in full-permission mode

**Deny rules.** The CLI reference is explicit: "Deny rules apply in every mode." The app says the same thing for presets: your allow, deny and ask rules are layered on top of the preset and always take precedence. Precedence is strict, Deny > Ask > Allow.

**Ask rules.** `always-proceed` runs without prompting *unless an ask or deny rule matches*. If you once added `command(*)` to `ask`, every command will still prompt under `always-proceed`. That is the usual answer to "agy full permission still asks me."

**Headless asks become denies.** In print mode (`agy -p`) nobody can answer a prompt. Antigravity soft-denies it: the run continues, exits 0, and stderr names the tool and the allow rule you would have needed. Any matching ask rule therefore turns into a block in CI. See the [control-model page](/controls/antigravity#headless-the-empty-chair-answered-correctly).

**`strict` wins.** Google documents that `strict` and `always-proceed` both take precedence over `auto` mode, and `strict` prompts even when an allow rule matches.

**The sandbox, if you turn it on.** `enableTerminalSandbox` is `false` by default outside `auto` mode. With it on, `proceed-in-sandbox` lets sandboxed commands run freely and prompts for anything that needs to leave it.

**Workspace boundary.** `allowNonWorkspaceAccess` defaults to `false` in the CLI. Turbo in the app grants the full filesystem; the CLI setting is separate.

## What the flag skips that the setting might not

The flag does more than approve prompts. On `agy` 1.1.21 we ran an A/B pair of identical headless turns: without the flag a registered `PreToolUse` hook fired before the permission layer; with the flag the hook was **not invoked at all**. No decision, no record. Details on the [control-model page](/controls/antigravity#the-escape-hatch).

So `--dangerously-skip-permissions` removes the one layer that can see a call's actual arguments. That includes ACP's hook: with the flag on, ACP checks nothing and records nothing for that run. We have verified this only for the flag. If you rely on a hook, use `toolPermission` in `settings.json` instead, and confirm the hook still fires with `/hooks` and a test call before you trust it.

## The safe version: allow all, deny the destructive

Allow everything, then keep a short deny list for what you never want run without you. This is the shape Google's rule language supports; the syntax is documented on the [permissions reference](/blog/antigravity-permissions-reference).

```json
{
  "agentMode": "accept-edits",
  "toolPermission": "always-proceed",
  "permissions": {
    "allow": [],
    "ask": ["command(git push)", "mcp(sql/execute_mutation)"],
    "deny": [
      "command(rm -rf)",
      "command(sudo)",
      "command(regex:curl .*)",
      "write_file(.git/)",
      "write_file(/home/you/.ssh)"
    ]
  }
}
```

What this does:

- Commands, web and MCP run without prompting.
- `git push` and the named MCP mutation still ask. In headless runs they are soft-denied.
- Recursive deletes, `sudo`, `curl` and writes into `.git/` or your `.ssh` directory are blocked in every mode.

Two caveats from Google's matching rules. `command()` is a token-prefix match, so `command(rm -rf)` does not catch `rm -r -f` or `rm -fr`. And commands containing substitution, brace expansion or similar lose prefix matching entirely; they then need an exact match or fall back to Ask. A deny list is a floor, not a full filter.

For anything a prefix can't express, add a `PreToolUse` hook. It runs before the permission layer, receives the full command in `toolCall.args.CommandLine`, and can answer `deny` or `force_ask`. `force_ask` prompts every time, even when the user clicked Always Allow earlier. Registration goes in `~/.gemini/config/hooks.json`:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "run_command",
        "hooks": [
          { "type": "command", "command": "node ~/hooks/check-shell.mjs", "timeout": 30 }
        ]
      }
    ]
  }
}
```

The hook must always exit 0 and answer in JSON. In our live test on agy 1.1.21 the hook core failed closed: a crash, timeout or non-zero exit blocked the call ([integration notes](/blog/antigravity-acp-integration)). Google's [hooks page](https://antigravity.google/docs/hooks/) documents only the 30-second default timeout, not the failure posture, so treat fail-closed as observed rather than specified and test it on your version. The full contract is in the [hooks reference](/blog/antigravity-hooks-reference).

A gentler middle ground, if your account has it: `agentMode: "auto"` (or `--mode=auto`). It auto-approves workspace edits, runs commands in the terminal sandbox, and lets safe, reversible commands outside it run while irreversible ones pause. It needs the terminal sandbox and `agy` v1.3.5+ on macOS and Linux or v1.4.4+ on Windows, and is not available on business or enterprise accounts.

## What this does not cover

- **Prefix deny lists leak.** Spelling variants and wrapped commands can slip past a `command()` rule. A hook sees the real string; a rule does not.
- **The flag removes hooks, ACP's included.** Verified on 1.1.21. If a hook is your safety net, do not launch with `--dangerously-skip-permissions`.
- **No CLI per-project settings file is documented.** Per-project in the CLI means per-launch flags.
- **No decision record.** Transcripts show what happened, not which rule allowed or blocked it.
- **Turbo has no isolation.** Google's own description is "no isolation or restrictions". Use it in a container or a disposable checkout.

If you want one allow-most-but-hold-the-destructive policy across the harnesses you run, ACP installs a hook for Antigravity with one command ([install guide](/integrations/antigravity)). It sits on the same `PreToolUse` hook described above, so it is also gone when you launch with `--dangerously-skip-permissions`. Without the flag, a held call is blocked in the agent. You approve it on the console or from the email, then ask the agent to retry. The [coverage table](/coverage) lists how other harnesses differ.

## Frequently asked questions



## Where to read more

- [Antigravity CLI reference](https://antigravity.google/docs/cli/reference/): flags and every `settings.json` key
- [Antigravity agent settings](https://antigravity.google/docs/agent-settings/): tool permission modes, agent modes, presets, per-project overrides
- [Antigravity permissions](https://antigravity.google/docs/permissions/): the `action(target)` rule language and precedence
- [Antigravity permissions reference](/blog/antigravity-permissions-reference): every action, matching rule and two worked rule sets
- [Antigravity hooks reference](/blog/antigravity-hooks-reference): events, payloads and the decision contract
- [Antigravity control model](/controls/antigravity): sandbox, headless soft-deny and the escape hatch, verified live