One evening I watched the same git status trigger "Run command?" five times in a row. It was already on my allow list, and restarting changed nothing. Each prompt broke my concentration, and by the end I had clicked "approve" more often than I had written actual code.
What I want to say up front is that this symptom mixes two different things: settings that are easy to misread, and bugs on the product side. I assumed everything was my own mistake and spent hours going back and forth in the settings screen. It did not go well. These days I keep what the docs actually say separate from what people on the forum have merely reported.
What the official docs say
I reread the official agent settings page and found that the way it is organized has changed. Which options you see now depends on your account.
On the desktop app (v2.23.0 and later) you choose a permission preset, under Settings > General > Global Permissions, per project, or from the picker in the message box:
- Request Review: every command needs approval, and the sandbox is off.
- Default: commands run without prompting inside the terminal sandbox, and anything outside it needs approval.
- Auto (Preview): commands that must leave the sandbox are evaluated automatically. Safe, reversible ones proceed, and risky or irreversible ones wait for you. It is not available to business or enterprise accounts.
- Turbo: no prompts and no isolation, so all commands run.
Your own allow, deny and ask rules sit on top of the preset and always win, according to the docs. So "Always Proceed but it still asks" turns, on the current desktop app, into the question of which rule matched on top of a preset other than Turbo.
Business and enterprise accounts use the earlier three settings instead of presets, which the page lists under "Previous permission settings":
- Require Review: the agent asks every time, except for commands on your Allow list.
- Proceed in Sandbox: commands run without prompting inside the terminal sandbox, and anything outside it still needs review.
- Always Proceed: the agent runs commands without asking, except for commands on your Deny list.
In these earlier settings, the Allow list is the exception to Require Review, and the Deny list is the exception to Always Proceed. If you keep growing an Allow list while the policy is Always Proceed, the list does nothing. And if you write a Deny list while on Require Review, you are prompted every time anyway.
If you use the CLI, the same axis is toolPermission in /config or settings.json: request-review (the default), proceed-in-sandbox, strict and always-proceed. The docs say strict and always-proceed override auto mode. The sandbox is off by default and turns on automatically in auto mode.
The page does not describe the entry format or matching rules for the lists, or whether a command that hits the Deny list is blocked outright or simply prompts. I would rather not guess, so from here on I separate what I could confirm from what has only been reported. An earlier version of this article said the rule layering applied only on macOS and Linux. I could not find that distinction on the current page, so I removed the sentence.
A narrowing-down order
Checking in this order was faster than poking at settings at random:
- Check which preset (or policy) is currently selected in the settings screen
- If it is Request Review or Require Review, check whether the stalled command is really on the Allow list
- If it is listed but still stalls, check whether the arguments or chaining differ from what you allowed
- If it still stalls, suspect a known bug
Does the policy match what you want?
If you want fewer prompts overall, Always Proceed plus a Deny list fits. If you want only specific commands to pass, Request Review plus an Allow list fits. Allow what should pass, deny what must stop. Deciding that first removes most of the confusion.
Is the command shaped differently?
Agents vary arguments and flags constantly. You allow npm install, and npm install --save-dev typescript still stops. Compound commands joined with && or ; can also be judged piece by piece, with the right-hand side evaluated separately. I wrote about that in who actually approved the right side of &&.
Known bugs reported on the forum
A thread on the Google AI Developers Forum has multiple reports of "Run command?" appearing even with Always Proceed and wildcard entries on the allowed list. Most of the reports come from Windows. A separate thread about Always Proceed having no effect describes the same kind of problem.
As for causes, what I found were guesses from other users rather than a confirmed answer from Google. The workarounds people tried were:
- Setting the HOME environment variable: on Windows, one user set the user-level HOME variable to the USERPROFILE path, restarted Antigravity, and the prompts stopped.
- Prefixing commands with
cmd /c: some said it helped a lot, others said it did nothing. - An unofficial patch script: one user reported it worked, but it is third-party code, and I would not run it without reading it first.
None of these is guaranteed to work in every environment. I work on a Mac, so I could not reproduce the Windows-specific behavior myself, and I am only relaying reports here.
Copy the stalled command exactly
The most useful step turned out to be a humble one: copy the command shown in the dialog, verbatim, into a note.
At first I summarized it in my head as "stuck on npm install again." When I finally lined the entries up, the argument order and trailing options differed a little each time. Put the string on your Allow list next to the string that actually stalled, and the mismatch is usually visible by eye. If it is not, that is the point where I start suspecting a known bug.
Three things are enough to record:
- The full command: pasted as displayed, not paraphrased
- The policy at that moment: Request Review or Always Proceed
- The matching Allow or Deny line: confirm the entry you think you saved is really there
With those three, anyone reading your forum post can reproduce the situation. Record it verbatim. It is a small rule I still keep whenever I am debugging settings.
Keeping the allow list from growing too wide
When approvals get tiring, it is tempting to allow everything. But every entry you widen also widens what the agent can run unexpectedly. Where I have landed is this: read-only commands (ls, cat, git status) can be broad, while destructive ones (rm, git push --force, npm publish) stay on individual review.
For designing fewer approvals in the first place, I wrote up consolidating permissions around approval fatigue. If you use more than one machine, also check that settings are not being overwritten, using the Settings Sync article.
A quick triage table
This is the note I keep pinned next to my editor:
| Symptom | Suspect first |
|---|---|
| Listed on the Allow list but still prompts | Is the policy Request Review? Do arguments or chaining differ? |
| Prompts even on Always Proceed | Is it on the Deny list? Possibly a known bug |
| Resets after restart | Where settings are stored, and sync across machines |
| Only on one OS | Forum reports (HOME variable, cmd /c) |
As a first step, open the settings screen, confirm which policy is selected, and write down the most recent command that stalled. That alone usually points to the cause. I try to follow this order especially when I am impatient, because that is when I skip it.
FAQ
I set Always Proceed but still see "Run command?". Is my config broken?
Not necessarily. Commands that match your Deny list are still reviewed under Always Proceed. If the command does not match and it still stalls, it may be one of the bugs reported on the forum.
How wide should I make the Allow list?
I keep read-mostly commands broad and review deletions or publishing commands one by one. Every entry you add also widens what the agent can run unexpectedly.