Agent Permissions in Antigravity

Antigravity (AGY) has an extensive permission system that defines how the agent should behave and what it has access to. However, these permissions are scattered across different settings and saved in various files that might make reasoning them difficult.

In this post, I’ll deep dive into these permission settings and share my learnings.

Permission Hierarchy

Before looking at the permission settings in detail, it’s important to note that the permissions in AGY are organized in a hierarchy:

1. Global (user) permissions.
2. Project (workspace) permissions.
3. Conversation (sesssion) permissions.

Each level inherits the permissions of the level above it but can override them. A project inherits global permissions but it can override them and a conversation can override both project and global permissions.

Global permissions

Global permissions apply to all projects and conversations of the user. They can be access via Settings -> General and are scattered across Agent Settings, Agent Behavior, Network Permissions, Terminal & Tooling Permissions and Browser sections:

These permissions are persisted in ~/.gemini/config/config.json file.

Project permissions

Project permissions inherit global permissions and can override them at the project level. These settings can be accessed via Project Settings and scattered across Agent Settings, Agent Behavior, and Local Permissions sections:

They’re very similar to global settings but arranged slightly differently in the UI and persisted in ~/.gemini/config/projects/<project_id>.json where <project_id> is the UUID of the project.

Conversation permissions

Conversation permissions are specific to a single conversation and they are triggered when an agent needs to perform an action that is not allowed by default:

You can allow the action once or only in the current conversation. You also have the option to always allow it at the project level or globally. In both cases, the relevant configuration files are updated.

Permissions

Now, let’s look into different permissions in detail. They’re presented slightly differently depending on whether you’re looking at global or project level settings.

Security preset

Security Preset dropdown is shown under Agent Settings both in global and project level settings. It is not a permission per say but rather it’s a pre-set of 3 permissions: Outside of folders file access policy, Terminal Command Auto Execution and Enable Sandbox Mode with the following pre-set configurations:

• Default - manual review of terminal commands and files outside project folders.
• Full Machine - manual review of terminal commands and ability to read/write to any file.
• Turbo Mode - no review of terminal commands and ability to read/write to any file.
• Custom - custom settings.

💡 Tip

Always choose Custom in order to see and control the actual 3 underlying permissions.

Let’s break down the individual permissions in more detail.

Outside of folders file access policy

Configures how the agent tries to access files outside of its working folders:

• Always Ask (Default)
• Allow
• Deny

Terminal command auto execution

Controls whether terminal commands require your approval before running:

• Require Review (Default)
• Proceed in Sandbox
• Always Proceed

Enable sandbox mode

Restricts agent tools to a secure, isolated local sandbox:

• False (Default)
• True

Artifact review policy

Under Agent Behavior, there’s Artifact Review Policy that determines whether the agent asks your review of artifacts (e.g. implementation plan) before proceeding:

• Always Ask (Default)
• Always Proceed

Browser Javascript execution policy

Only in global settings, under Browser, you’ll find Browser Javascript Execution Policy that controls whether the agent can run custom JavaScript to automate complex browser actions:

• Disable (Default)
• Request Review
• Always Proceed

Agent Permissions

In addition to the settings above, there’s a number of fine-grained Agent Permissions on various actions such as file or network access, MCP tools, terminal commands, etc. with Deny, Ask, Allow options and a flexible pattern to specify what’s allowed (e.g. read_file(/path) or read_file(dir), or read_file(*)).

These permissions show up in slightly different places in global and project settings but they’re for the following:

• File Access Rules: Allowed/denied file paths for read_file and write_file actions.
• Network Access Rules: Allowed/denied URLs for read_url action.
• Browser Actuation Rules: Allowed/denied URLs for execute_url action.
• Terminal Commands: Allowed/denied terminal commands for command action.
• Commands Outside Sandbox: Allowed/denied commands for unsandboxed action.
• MCP Tools: Allowed/denied MCP tools for mcp action.

Configuration files

It’s useful to know where these settings are persisted, in order to back them up or just see what’s being used without having to rely on the UI.

If you set these permissions globally, they end up in ~/.gemini/config/config.json under userSettings as follows:

{
  ...
  "userSettings": {
    "artifactReviewMode": "ARTIFACT_REVIEW_MODE_ALWAYS",
    "autoExecutionPolicy": "CASCADE_COMMANDS_AUTO_EXECUTION_OFF",
    "browserJsExecutionPolicy": "BROWSER_JS_EXECUTION_POLICY_DISABLED",
    "enableTerminalSandbox": false,
    "nonWorkspaceFileAccessPolicy": "AGENT_SETTING_POLICY_ASK",
    "globalPermissionGrants": {
      "allow": [
        "read_file(/Users/atamel/dev/local/testing)",
        "read_url(https://www.bbc.co.uk/)",
        "command(ls)",
        "unsandboxed(ls)",
        "mcp(cloudrun)"
      ],
      "ask": [
        "execute_url(https://www.bbc.co.uk/)",
        "command(ps)"
      ],
      "deny": [
        "write_file(/Users/atamel)",
        "command(rm)"
      ]
    }
  }
}

If you set them per project, they end up in ~/.gemini/config/projects/<project_id>.json under settings as:

{
  ...
  "permissionGrants": {
    "permissionGrants": {
      "allow": [
        "read_file(/Users/atamel/dev/local/testing)",
        "read_url(https://www.bbc.co.uk/)",
        "command(rm)",
        "unsandboxed(ls)",
        "mcp(cloudrun)"
      ],
      "deny": [
        "write_file(/Users/atamel)",
        "command(ls)"
      ],
      "ask": [
        "command(ps)"
      ]
    }
  },
  "settings": {
    "artifactReviewMode": "ARTIFACT_REVIEW_MODE_ALWAYS",
    "autoExecutionPolicy": "CASCADE_COMMANDS_AUTO_EXECUTION_OFF",
    "fileAccessPolicy": "AGENT_SETTING_POLICY_ASK",
    "sandboxMode": false
  }
}

ℹ️ Note

Global and project level settings have slightly different configuration names and organization, as you can see from the json snippets above.

What about AGY CLI and AGY IDE?

Everything I talked about above applies to AGY but you might be wondering: What about AGY CLI and AGY IDE and IDE extensions?

In AGY CLI, there’s a /permissions command that allows you to set some permissions and some of them end up in ~/.gemini/antigravity-cli/settings.json and some end up in the global ~/.gemini/config/config.json file. However, it’s not quite intuitive and I couldn’t figure out exactly which permissions ends up where and why.

In AGY IDE standalone, it seems like some of the permissions are saved in totally different place ~/Library/Application Support/Antigravity IDE/User/globalStorage/state.vscdb but I didn’t dig into it further.

In a future post, I might try to explore permissions in AGY CLI and IDE in more detail.

Summary

This is a lot of information but hopefully the following table can be a good reference for all the permissions you can set in AGY:

See also

• Summary : Where does Antigravity look for configurations?
• Where does Antigravity look for Agents?
• Where does Antigravity look for Plugins?
• Where does Antigravity look for Sidecars?
• Where does Antigravity look for Hooks?