Just want the answer? Antigravity permissions are three lists — allow, ask, deny — of action(target) rules. Deny beats ask beats allow. Files in the workspace are allowed by default; commands outside the sandbox, MCP tools, and URLs ask. A working permissions block, in the shape Google's own examples use:
{
"permissions": {
"allow": ["command(git)", "command(regex:npm run (build|lint|test))", "write_file(src/)", "read_url(google.com)", "mcp(linter/*)"],
"ask": ["command(*)", "execute_url(aws.amazon.com)", "mcp(sql/execute_mutation)"],
"deny": ["command(rm -rf)", "command(sudo)", "write_file(.git/)"]
}
}
Antigravity's full control model → · The hooks reference → · Put policy on the hook in one command →
*Read from [Google's Antigravity permissions documentation](https://antigravity.google/docs/permissions/) on September 16, 2026. Where this page says "verified live," the check was done against the shipped `agy` 1.1.21 binary and is written up on [the control-model page](/controls/antigravity). Anything Google's docs don't state and we haven't verified is left out.*
Antigravity — Google's agent-first IDE, the `agy` CLI, and the editor extensions — puts one permission engine under every surface. It's a good one: a single `action(target)` syntax that covers files, shell commands, URLs, browser actuation, and MCP tools, with strict precedence and defaults that mostly do the right thing. It also has real edges, and the edges are where agents get away with things. This is the reference for the rule language, the presets, the matching rules that decide whether `command(git)` covers `git log $(whoami)` (it doesn't), and the two things a rule can't do that a hook can.
## Where the rules live
Two ways in, one engine:
| Surface | Where |
|---|---|
| IDE | **Settings → General → Permission Settings** sets the preset; **Settings → Projects** overrides it per project. New projects start on **Inherit General**. Permission requests approved during a session can be added to the project's rules from the same place. |
| `agy` CLI | The CLI's settings file, `~/.gemini/antigravity-cli/settings.json`, under a `permissions` object with `allow`, `ask`, and `deny` arrays. |
One platform note before anything else, because it changes which of the sections below apply to you: **the engine described here runs on macOS and Linux.** Google's documentation says Windows still uses the prior permission system, to be updated in a future release. The Windows-specific differences are called out where they exist.
## The rule shape: `action(target)`
Every sensitive operation the agent performs is a *permission resource* written as `action(target)`. Seven actions cover the surface:
| Action | Syntax | What it matches |
|---|---|---|
| `read_file` | `read_file(/abs/path)`, `read_file(relative/dir)`, `read_file(*)` | Absolute or workspace-relative paths; a directory covers everything under it |
| `write_file` | `write_file(/abs/path)`, `write_file(src/)`, `write_file(*)` | Same matching as `read_file`; an allow here also grants read on the same path |
| `read_url` | `read_url(domain)`, `read_url(*)` | Hostnames plus subdomains — `google.com` covers `mail.google.com`; path segments are ignored |
| `execute_url` | `execute_url(domain)`, `execute_url(*)` | Browser actuation — clicking, typing, interactive workflows in a page |
| `command` | `command(prefix)`, `command(regex:pattern)`, `command(*)` | Terminal commands, inside and outside the sandbox — see matching below |
| `mcp` | `mcp(server/tool)`, `mcp(server/*)`, `mcp(*)` | One tool, every tool on a server, or every MCP tool, local and remote alike |
| `unsandboxed` | `unsandboxed(prefix)`, `unsandboxed(regex:pattern)`, `unsandboxed(*)` | **Windows only** on the current engine — runs a matching command outside container isolation while sandboxing is on |
`*` as the target matches every target in that action's namespace, uniformly: `read_file(*)`, `command(*)`, `mcp(*)`.
Rules are portable across operating systems. On Windows, Antigravity strips drive letters (`C:`) and converts backslashes to forward slashes before evaluating a path rule, so `write_file(src/)` means the same thing everywhere.
## How `command()` matching actually works
This is the section to read twice. Most permission surprises on Antigravity come from here.
**Default: exact token prefix.** `command(git)` matches any command whose leading tokens are `git` — `git status`, `git log --oneline`. `command(npm run build)` matches `npm run build --watch` and not `npm run test`.
**`regex:` switches to regular expressions.** `command(regex:npm run (build|lint|test))` — and note how the anchoring works: **each whitespace-separated token is anchored as `^(?:pattern)$`**, so the pattern is matched token by token, not against the whole line as one string.
**Prefix matching survives ordinary composition.** Pipelines, `&&`, `||`, `;` chains, quoted literals, plain `$VAR` arguments, simple redirects, and wrappers like `timeout`, `nohup`, `nice`, and `env` all still prefix-match, with the wrapped inner command evaluated on its own. With `command(git)` allowed, `git status && git log` runs without a prompt.
**Prefix matching is disabled entirely when the command carries anything that could change what runs.** Google's list: command substitution (`$(...)`, backticks, `<(...)`), arithmetic `$((...))`, brace expansion, non-literal command names, network or file-descriptor redirections, and flags that spawn subcommands — `git -c core.pager=