If you’ve been using AI coding agents seriously in 2026, you’ve probably reached the moment where the agent is good enough to do real work, but every five minutes it interrupts you with a permission prompt. It’s annoying. The temptation is to flip the switch labelled “trust me, run anything” and get back to your day.
Don’t.
Or rather: understand exactly what that switch means before you flip it. Because what looks like a productivity setting is, in security terms, the same as handing your shell over to a process that doesn’t share your priors about what shouldn’t be touched.
What “auto-approve everything” actually means
When you tell Claude Code, Codex, Gemini, or Copilot CLI to skip permission prompts, you’re saying: any command this LLM can compose is allowed to execute on this machine. Including commands the LLM was never explicitly asked to compose. The model doesn’t separate “commands the user wanted” from “commands that seemed like a reasonable next step given the context window.”
A few concrete failure modes people have actually hit:
- Surprise
git push. You ask the agent to clean up a feature branch. It interprets “clean up” as “rebase, force-push.” Your collaborator’s commits, gone. - Wrong directory
rm -rf. The agent gets confused about cwd, deletes a build directory in the parent project, and the parent project is your dotfiles repo. - Dependency replacement. The agent reads a stack trace, decides the fix is to
pip installa similarly-named package. The similarly-named package is not the one you wanted. - Secret exfiltration. The agent debugs an HTTP issue by piping the request body (which contains a JWT) to a remote pastebin to “share for analysis.”
- Leaked credentials in commits. The agent writes a quick test script with a hardcoded API key, commits, pushes. The repo is public.
None of these require malice. None require the model to be “jailbroken.” They’re what happens when a probabilistic system has unconstrained side-effect access to your filesystem, your shell, and your network.
The risk isn’t a malicious AI. It’s a confident AI doing the wrong correct-looking thing fast.
Why “manual approval in the terminal” is also wrong
The other extreme — approving every single command at your keyboard — has its own failure mode: it’s the path of least resistance to not using AI agents at all. Every ls, every grep, every cat package.json becomes a friction point. After ten of those you start mashing y on autopilot, which collapses back to auto-approve with extra steps.
The real cost of constant terminal prompts is that they make you a bad reviewer. You don’t actually read the command before approving — you just want the agent to keep going.
What a sane permission model looks like
The principle worth borrowing from operating-system security is least privilege, with structured exceptions. Not “allow nothing,” not “allow everything,” but: allow obvious-safe stuff silently, intercept anything that touches state, and require a deliberate human signal for the latter.
Concretely, a good permission layer for AI coding agents has four properties:
1. Read-only is free. Listing files, reading files, grepping, running tests — these don’t change the world. They shouldn’t prompt. If they do, you’re training yourself to ignore prompts.
2. Anything that mutates state asks once. File writes, shell commands that aren’t pure-read, network calls, package installs, git operations that touch refs — these get intercepted. The interception should show you the exact command and let you approve, deny, or edit it.
3. Patterns can be promoted. When you’ve approved npm test a hundred times, you should be able to promote it to a standing rule without that rule being “allow all npm.” Granular pattern matching — exact, prefix, glob, regex — matters.
4. The interruption shouldn’t require attention. If you have to look at the terminal to approve, you stop reading. If the prompt comes to a separate device with biometric auth, you have a few seconds to actually evaluate the command, and the act of approving requires a tiny but real cognitive effort. That’s the right friction.
Where this leaves you
You don’t need a complicated security policy. You need three things you can probably set up in under an hour:
- Make sure the read-only commands your agent runs constantly aren’t prompting. Most agents have a way to pre-allow these — use it.
- Make sure the dangerous commands route somewhere you can actually evaluate them. The terminal-prompt-while-coding pattern is broken; phone-with-biometric is a much cleaner separation of concerns.
- Keep an audit log of what your agents have actually run. Most of the time you don’t need it. The one time you do, you really need it.
That’s the model. The implementation is a one-time setup — everything after that is the agent quietly doing its job until something genuinely needs your attention.