How to prevent Google Antigravity from accessing .env

Google Antigravity is an agent-first IDE. You hand it a project, and it reads files, runs terminal commands and drives a browser on its own until the task is done.

That autonomy is the whole point of the tool. It's also why your .env needs a rule of its own, because API keys, database passwords and OAuth secrets are sitting in a plain text file inside the folder you just handed over.

In this article, we'll look at how to deny the agent access to .env in both the IDE and the CLI, how to verify it actually worked, and which of the surrounding settings matter.

How Antigravity decides what it can touch

Antigravity runs every sensitive action through one permission engine. Each action is written as action(target):

read_file(.env)
write_file(src/config.ts)
command(npm test)
read_url(google.com)

The actions you'll run into are read_file, write_file, command, read_url, execute_url and mcp. Each one lands in one of three lists: allow, ask or deny. When rules conflict, they're evaluated in a fixed order: Deny > Ask > Allow. A deny rule wins no matter what else grants access.

Two defaults are worth knowing before you change anything:

• Reading and writing files inside your active project folder is allowed automatically. You don't get prompted for it.
• Every other action you haven't configured defaults to Ask.

That first bullet is the problem in one line. Your .env lives inside the project folder, so it falls under the automatic allow.

The setting that already helps

There's one guardrail you get for free: Agent Gitignore Access, which is off by default. With it off, the agent's file tools skip anything your .gitignore lists, and .env is gitignored in most projects.

So on a fresh install you're already partly covered. Two things to check before you rely on it:

• It only helps if .env is actually in your .gitignore. Open the file and confirm, including the variants like .env.local.
• Off is the default, not a lock. Confirm the toggle is still off, and leave it off unless you have a real reason to flip it.

Worth noting that .gitignore is a tidiness list, not a security list. Your build output and your production credentials sit in it side by side, treated the same way. If you want "never this file," say it explicitly.

Deny it explicitly

In the IDE, open Settings (Cmd+, / Ctrl+,) and go to Global Permissions, which are the default tool boundaries applied to every conversation. Add your env files to the Deny list:

read_file(.env)
read_file(.env.local)
read_file(.env.production)

Breaking that down: read_file(...) is the action, and the target is a path. You only need to deny read_file, because write_file implies read, so denying the read on a path blocks writing to it as well. Targets match absolute paths or paths relative to your workspace root, and pointing at a folder covers everything inside it recursively. So if your project keeps credentials in a directory:

read_file(secrets)

denies the whole thing in one line.

You may be wondering why the list spells out each env file instead of one wildcard. Targets are matched as paths, and what the docs promise is recursive matching on directories, not shell-style globbing on filenames. Listing the files you actually have is more boring and less clever, and it's the version you can verify in thirty seconds.

Note: a deny on read_file stops the agent's file tools. It does not stop the shell. An agent that can run terminal commands can still cat .env, and that's not hypothetical, it's how researchers pulled secrets out of Antigravity shortly after launch. The terminal settings further down are part of the fix, not an optional extra.

Project permissions drift

Next to Global Permissions there are Project Permissions, scoped to one project. These are useful, but keep an eye on them: as you approve requests during a session, those approvals get written into the project's permission list. A few weeks of clicking "allow" and the project is more open than you remember. Open the list now and then and delete what you don't recognise.

The CLI

The Antigravity CLI has the same permission model, in ~/.gemini/antigravity-cli/settings.json:

{
  "permissions": {
    "deny": [
      "read_file(.env)",
      "read_file(.env.local)",
      "read_file(.env.production)",
      "read_file(~/.ssh)",
      "command(printenv)",
      "command(cat .env)"
    ]
  }
}

The first four entries are the same idea as in the IDE, with ~/.ssh thrown in because the CLI is easy to run from a directory you didn't think about. The last two are command targets, which match either a command prefix or an anchored regular expression.

Be honest with yourself about what those last two buy you. command(cat .env) blocks that exact spelling of the command. It doesn't block less .env, cat ./.env, or a script that reads the file and prints it. Command denies are worth having as a speed bump, but the real control over the terminal is the execution policy below.

Verify it works

Testing this on your real project defeats the purpose. Do it in a throwaway one:

1. Create a brand new empty folder, away from your real code.
2. Add a .env file with fake, dummy values:

API_KEY=dummy-value
DATABASE_URL=postgres://not-real

3. Open Antigravity in that folder and ask the agent to read the .env file. It should refuse.
4. Now ask it to run cat .env in the terminal. This is the test that matters, because it's the path around the file tools. You should get a review prompt instead of the file's contents.

Never run this test in your real project with real credentials. Prove the rules work in a throwaway folder, then trust them.

Harden the settings around it

Blocking the file is one rule. These are the settings that decide how much damage a bad instruction can do once it's inside your project, and they're all in Settings:

• Terminal Execution Policy → Request Review. The agent asks before running commands, except the ones on your allow list. The alternative, Always Proceed, runs everything that isn't explicitly denied, which is exactly the mode in which cat .env slips past you.
• Outside of Folder File Access Policy → Always Deny (or Always Ask). By default the agent is limited to your project folders and its own app data directory in ~/.gemini/antigravity/. Keep it that way, so ~/.aws/credentials and ~/.ssh stay out of reach even when the agent goes looking.
• Sandbox Mode → on, with Sandbox Allow Network off. Sandboxing gives terminal commands kernel-level isolation, using Seatbelt on macOS and nsjail on Linux, and limits writes to your workspace and a few essential system paths.
• Browser URL allowlist and denylist. This is the other half of a leak: reading a secret is harmless until something can send it somewhere. The browser lists govern which sites the agent can visit and which external images get rendered, and the shipped defaults have included request-logging services that are perfect exfiltration targets. Open the allowlist and prune it.

There's also Strict Mode, which is the single toggle version of most of the above. It forces .gitignore to be respected, isolates the agent to the workspace, sets terminal execution, browser JavaScript and artifact review to Request Review, and turns on sandboxing with network access denied. It also ignores your terminal allow list, which is the point: your convenience shortcuts stop applying. Turn it on whenever you open a repository you didn't write.

If Antigravity already read your .env

Treat every value in that file as compromised, and don't spend time working out whether it was harmless:

• Rotate every secret that was in the file: API keys, database passwords, OAuth tokens, all of them.
• Revoke the old keys in the respective dashboards (AWS IAM, Stripe, GitHub, and so on).
• Check access logs where you have them, and look for calls you can't account for.
• Update your .env with the new values once you've rotated.

Rotation is cheap. A breach is not.

Make it a habit

Set the deny rules in Global Permissions once, keep Terminal Execution Policy on Request Review, and every project you open on that machine starts from a sane place. It's the same instinct as .gitignore: you wouldn't commit .env to a public repo, so don't leave it readable by an agent that can also open a browser.

Each AI coding tool needs its own version of this. I've written the equivalent for Claude Code and for GitHub Copilot.