If you have used Antigravity for more than a few days, you have probably been hammered by the same prompt: "Allow this command?" — for npm install, git status, or another routine command you ran ten times yesterday. You click "Always Allow", and the next morning the dialog is back from scratch.
The first week I switched over, this approval loop completely broke my flow. Once I dug into the actual storage layout, the cause turned out to be a combination of three things — none of them obvious from the UI. This guide walks through each one with the configuration that finally made the prompts stop.
Why the dialog keeps coming back
Antigravity's permission system is separate from VS Code's Workspace Trust. Whenever the agent calls the run_terminal_command tool, Antigravity checks the command against an allow-list and shows the dialog when nothing matches.
That allow-list lives in three different places:
- User settings:
~/Library/Application Support/Antigravity/User/settings.jsonon macOS - Workspace settings:
.antigravity/settings.jsonat your project root - Session memory: temporary entries that disappear when you close the window
Where "Always Allow" actually writes depends on the workspace's trust state at the moment you click the button. That single detail is the source of most of the frustration.
Cause 1: Your workspace is in Restricted Mode
This is the most common one. Look at the bottom-right of the Antigravity window when you open the project. Do you see a small banner that says "This workspace is in Restricted Mode"? If yes, every "Always Allow" you click is being saved only to session memory, not to disk. The next time you reopen the project, the list is empty again.
To check, open the command palette (Cmd+Shift+P on macOS or Ctrl+Shift+P on Windows/Linux) and run Workspaces: Manage Workspace Trust. If the trust toggle is off, that is your direct cause.
How to fix it
- Run
Workspaces: Manage Workspace Trustfrom the command palette - Click "Trust" so the folder shows as Trusted
- Clear any existing approval entries you do not need
- Run the same command and click "Always Allow" again
The entry now lands in .antigravity/settings.json inside the project, and it survives restarts.
Cause 2: Your patterns do not match the actual commands
The second trap is subtle. Antigravity's matcher uses exact match by default, not prefix match. So once you allow npm install, the very next call — npm install --save-dev typescript — is treated as a new command and prompts again. Since agents tend to vary arguments constantly, exact-match entries lose their grip almost immediately.
Use glob and regex in settings.json
Open your user settings (~/Library/Application Support/Antigravity/User/settings.json) and edit antigravity.commands.alwaysAllow:
{
"antigravity.commands.alwaysAllow": [
{
"pattern": "npm install*",
"match": "glob"
},
{
"pattern": "npm run *",
"match": "glob"
},
{
"pattern": "git (status|log|diff|branch).*",
"match": "regex"
},
{
"pattern": "ls *",
"match": "glob"
},
{
"pattern": "cat *",
"match": "glob"
}
]
}pattern is the string Antigravity matches against. match is the matching strategy: exact, glob, or regex. Glob is the shell-style wildcard you already know — * covers any characters. Regex lets you collapse a family of commands into one entry, which I find the most expressive option for read-only operations.
A practical convention: keep read-only commands (ls, cat, git status) on broad globs and keep destructive ones (rm, git push, npm publish) on exact matches. The few extra clicks for destructive commands are worth the safety margin.
Reload without restarting
Once you save the file, you do not need to restart Antigravity. Run Antigravity: Reload Permission Settings from the command palette and the new patterns kick in immediately. Try npm install --save-dev typescript and the dialog will not appear.
Cause 3: Settings Sync is overwriting the list
This one took me embarrassingly long to figure out. If you have Settings Sync enabled across machines, an Antigravity window on a second machine with an empty allow-list can silently push that empty list back to your main machine. In my case, my laptop had no patterns set, so my desktop's carefully curated list was getting wiped every few days.
Stop syncing the allow-list
Add this to your settings to keep the allow-list local to each machine:
{
"settingsSync.ignoredSettings": [
"antigravity.commands.alwaysAllow",
"antigravity.commands.alwaysDeny"
]
}If you use Antigravity on more than one machine, I would treat this as a default. Permission lists rarely make sense to sync — your laptop and desktop usually have different security postures anyway.
Auto-deny dangerous commands
Once your allow-list gets generous, the trade-off is that the agent might run something you didn't intend. The defensive pairing is alwaysDeny, which always wins over alwaysAllow:
{
"antigravity.commands.alwaysDeny": [
{
"pattern": "rm -rf /*",
"match": "glob"
},
{
"pattern": "sudo *",
"match": "glob"
},
{
"pattern": "git push --force*",
"match": "glob"
},
{
"pattern": ":(){ :|:& };:",
"match": "exact"
}
]
}Even if your allow-list says git * is fine, git push --force is still blocked because deny rules take precedence. I keep this exact block as a four-line template in every project I work on.
Debugging when the dialog still appears
If you have applied the steps above and the dialog is still showing, walk through this checklist in order:
- Run
Antigravity: Show Permission Resolver Logsfrom the command palette and watch which pattern Antigravity is evaluating - If the log says "No matching pattern", your glob or regex is not catching the actual command — copy the command text verbatim and adjust
- If the log says "Workspace not trusted", you are back at Cause 1
- If the log itself does not appear, your settings file probably has a JSON syntax error preventing the entire file from loading — run
jq . settings.jsonto validate it
I cannot count how many times a stray comma or smart-quote has silently broken my settings file. JSON validation is the boring but reliable last step.
A reference table for the patterns I actually use
After a few months of iteration, this is the allow-list I copy into every new project. The patterns are intentionally narrow on the destructive side and broad on the read-only side:
{
"antigravity.commands.alwaysAllow": [
{ "pattern": "ls *", "match": "glob" },
{ "pattern": "cat *", "match": "glob" },
{ "pattern": "head *", "match": "glob" },
{ "pattern": "tail *", "match": "glob" },
{ "pattern": "find . *", "match": "glob" },
{ "pattern": "grep *", "match": "glob" },
{ "pattern": "rg *", "match": "glob" },
{ "pattern": "git (status|log|diff|branch|show|fetch).*", "match": "regex" },
{ "pattern": "git checkout -b *", "match": "glob" },
{ "pattern": "git add *", "match": "glob" },
{ "pattern": "git commit -m *", "match": "glob" },
{ "pattern": "npm install*", "match": "glob" },
{ "pattern": "npm run *", "match": "glob" },
{ "pattern": "npx *", "match": "glob" },
{ "pattern": "pnpm *", "match": "glob" },
{ "pattern": "node *", "match": "glob" },
{ "pattern": "python *", "match": "glob" },
{ "pattern": "pytest *", "match": "glob" },
{ "pattern": "tsc --noEmit*", "match": "glob" }
]
}A few notes on the reasoning behind specific choices. git add * is on the allow-list because reverting an over-eager git add is just git restore --staged. By contrast, git push is intentionally absent — pushing to a remote is the kind of action where an extra confirmation pays for itself. tsc --noEmit* is on the list because type-check loops are a constant during refactoring and approving each one would be unbearable.
Where to keep this configuration
There is a workflow question worth deciding once: do you keep the allow-list in user settings or workspace settings? My rule of thumb:
- User settings (
~/Library/Application Support/Antigravity/User/settings.json): keep generic, language-agnostic patterns here.ls,cat,git status, etc. - Workspace settings (
.antigravity/settings.json): keep project-specific patterns here. The build command, the test runner, deployment scripts.
Workspace settings can be checked into git so your collaborators inherit the same approvals. That is genuinely useful on a small team — a new contributor opens the repo and the right commands are pre-approved without any setup.
If you commit .antigravity/settings.json, double-check that no secrets are inside. The file should only contain command patterns and similar configuration; it has no business storing API keys.
Two settings worth checking on your build
Two related options have appeared in recent Antigravity releases that fine-tune this behaviour. They are off the beaten path in the settings UI but searchable by name in the JSON editor:
antigravity.commands.approvalScope— typically accepts"session","workspace", or"user". This determines the default destination when you click "Always Allow". Setting it explicitly to"workspace"removes the ambiguity that fuels Cause 1 above.antigravity.commands.maxAllowEntries— caps how many entries the allow-list can hold. I have only seen this become an issue in monorepos with dozens of sub-projects.
If these settings are missing in your install, your build is older than the release that introduced them — updating Antigravity from the help menu will surface them.
Related tuning
Once approvals stop being a problem, the next concern usually flips: the agent now runs commands too freely. Two related guides help close that loop. The complete guide to .antigravityignore shows how to constrain which files the agent is allowed to touch, and How to fix Antigravity Settings Sync conflicts goes deeper on the third cause covered above.
Where to start
The minimum useful action right now: open your project, switch it to "Trusted" through the command palette, and add three to five glob patterns to antigravity.commands.alwaysAllow for the commands you run most. That alone takes the daily friction down by half. Once the configuration is in place, the time you used to spend dismissing dialogs simply turns back into coding time.