AI Coding Agent Keeps Asking for Permission? Fix It
The problem is not that your agent asks too much. It is that you now approve without reading, which means the permission prompt has stopped being a safety control.
AI Coding Agent Keeps Asking for Permission? Fix It
If your AI coding agent interrupts you every ninety seconds for approval, the problem is not that it asks too much. It is that you now approve without reading, which means the permission prompt has stopped being a safety control and become a keystroke. Fix it by cutting the volume of prompts until the ones that remain are ones you would genuinely consider declining.
The goal is not fewer interruptions for comfort. It is a prompt you actually read.
Measure your approve rate first
Before changing any setting, spend one working session counting. Two numbers:
How many approval prompts did you see?
How many did you decline?
If you approved 40 out of 40, your permission system is decorative. That is the finding, and it is extremely common. A control you always say yes to provides no protection and costs you a session's worth of attention.
If you declined 3 out of 40, you are at roughly 7%, which is low but real. The 37 you approved are the noise to eliminate, and the 3 are the signal to protect.
This matters because the usual advice, which is to loosen permissions until the prompting stops, quietly removes both. The better move is to remove the 37 and keep the 3.
Why the prompts pile up
Four causes, in rough order of how often they are the real one.
Read operations are gated. Reading a file, listing a directory, and running git status are not dangerous, and many setups prompt for them anyway. This is usually the bulk of the volume.
Every invocation is treated as new. The agent runs npm test, you approve. It runs npm test again four minutes later, you approve again. Without a way to say "this command, always", repetition dominates.
The scope is one command rather than a class. Approving git log --oneline -5 teaches the system nothing about git log --oneline -20. Rules written against exact strings will never keep up.
The agent is doing work it should not be doing. If you are constantly approving edits to files unrelated to the task, the prompt volume is a symptom. The fix is upstream, in the task definition, not in the permission config.
That last one is worth sitting with. A flood of prompts about unexpected files is the system working, telling you the agent has drifted.
Build a three-tier allowlist
Sort operations into three buckets and treat each differently.
Tier | What belongs here | Behaviour |
|---|---|---|
Always allow | Reads, status checks, tests, linters, type checks, formatters | No prompt |
Always ask | Writes outside the working directory, package installs, network calls, anything touching credentials, database commands, | Prompt every time |
Always deny | Production credentials, CI config, secrets files, | Blocked outright, no prompt |
The deny tier is the one people skip, and it is the one that does the most work. A prompt you can approve under time pressure is weaker than a rule that does not offer the option. Anything you are confident you would never approve belongs in deny, not in ask, precisely because you might approve it at 6pm on a Friday.
Start with the always-allow tier. It is where the volume is, it is the lowest-risk change, and the improvement is immediate. Getting it right usually cuts prompts by 60 to 80% on its own.
Write rules by class, not by string
The rule that matters is the shape of the operation, not its exact text. Prefer patterns:
allow: Read(**)
allow: Bash(npm test:*)
allow: Bash(git status:*)
allow: Bash(git diff:*)
ask: Bash(npm install:*)
ask: Edit(../**)
deny: Bash(git push --force:*)
deny: Read(./.env)
deny: Edit(./.github/workflows/**)Syntax varies by tool, but the principle does not: match the family, not the invocation. If you find yourself approving near-identical commands repeatedly, that is a rule waiting to be written.
Do not solve this by turning permissions off
Every agent has a mode that stops asking entirely. It is genuinely useful in one situation and dangerous everywhere else.
Use it when the blast radius is already bounded: a disposable container, a scratch branch, a repository with no credentials and nothing deployed from it. In that setting there is nothing to protect, so a prompt protects nothing.
Do not use it on a machine that holds production credentials, on a repository that deploys on merge, or in a working directory with anything you have not committed. The relevant question is not whether you trust the agent. It is what happens if it is wrong once, and whether you would notice.
If you want the speed without the exposure, the better trade is a tighter sandbox with looser permissions inside it. Sandboxing an agent and restricting file system access both buy you room to say yes more often, safely.
The prompts worth keeping
After the noise is gone, these should still stop you, and you should still read them:
Anything writing outside the project directory.
Anything installing a dependency. New packages are a supply chain decision, not an implementation detail.
Anything running against a database that is not local and disposable.
Anything touching auth, permissions, or payment code.
Anything with a network call to a host you do not recognise.
A useful test: if you cannot state in one sentence what would go wrong when you approve, do not approve yet. That question is cheap when you face it five times a day and impossible when you face it fifty.
For the team-level version of this, where the tiers become policy rather than personal preference, setting permissions for AI coding agents on a team covers the enforcement mechanisms. The deny tier in particular overlaps heavily with files an agent should never write.
When you want it to run unattended
The endpoint of good permission design is an agent you can leave alone for twenty minutes. That is achievable, and the route to it is not a looser config. It is a narrow enough task and a small enough blast radius that the remaining prompts are rare and real.
How long to let an agent run unattended is the companion question, and the honest answer depends almost entirely on what it can reach. Broader context in our overview of AI coding tools.
FAQ
Why does my AI coding agent ask permission for everything?
Usually because read operations are gated alongside write operations, and because rules are written against exact command strings rather than command families. Allowlisting reads, tests, and linters typically removes most of the volume.
Is it safe to turn off permission prompts?
Only when the blast radius is already bounded, such as a disposable container or a repository with no credentials and nothing deployed from it. On a machine with production access it is not.
What should always require approval?
Writes outside the working directory, dependency installs, non-local database commands, anything touching auth or payments, and network calls to unfamiliar hosts.
How do I stop approving the same command repeatedly?
Write the rule against the command family rather than the exact invocation. If npm test is safe, allow npm test with any arguments rather than approving each variation.
Does approving everything quickly actually cause problems?
The problem is that it makes the control useless. If you approve 40 of 40 prompts, the three that deserved scrutiny got none, and you spent a session's attention for nothing.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
