'Approve All' is the Dangerous Default for Coding Agents

The Illusion of Control: Constant Prompts

You've handed your coding agent a shell. Now you're trapped in a digital purgatory, oscillating between two equally undesirable outcomes. The first scenario is the one where every potentially risky command is presented for your explicit approval. Imagine this: your agent wants to push code to a remote repository, delete a file, or download a script from an untrusted source. Each time, a prompt appears: 'Can I run git push?' 'Can I delete this file?' 'Can I curl this URL?'

Initially, this feels like robust security. You're in control. But the reality of a productive workflow is that these prompts become a relentless barrage. You approve, approve, approve—a cascade of reflexive 'yes' responses driven by the sheer volume of mundane tasks. Somewhere in this deluge, the one command that truly mattered, the one that carried genuine risk or consequence, gets lost. It slides through not because you consciously approved it, but because your brain has been trained to dismiss the prompts as background noise. This is the 'Approve All' problem manifesting itself through sheer user fatigue.

This constant interruption erodes the agent's utility. It transforms a tool meant to accelerate development into a cumbersome gatekeeper. Developers are left with a choice: either endure this friction, slowing down their work to a crawl, or seek a way to bypass it. The desire for efficiency is powerful, and when faced with endless, often redundant, approval requests, the temptation to streamline becomes overwhelming.

The fundamental issue isn't the existence of permission prompts, but their implementation and frequency in a typical developer workflow. A system designed for safety can become a bottleneck if it doesn't intelligently distinguish between low-risk, routine operations and high-impact, potentially destructive actions. The human brain is not wired to maintain peak vigilance through hundreds of identical micro-decisions. When the signal-to-noise ratio of these prompts drops to zero, so does their effectiveness.

The 'Dangerously Skip Permissions' Trap

The second house you can live in is the one where you've had enough. You’ve encountered the approval fatigue and sought a solution. You find the command-line flag, the configuration setting, the 'expert mode' that promises to end the interruptions. You run your agent with something like --dangerously-skip-permissions. Now, it never asks.

This is the other extreme, and it’s arguably worse. The agent proceeds with its tasks unchecked. The safeguards that were in place, however imperfectly implemented, are now entirely bypassed. The rm -rf command, which in the first scenario would have at least prompted an approval, now executes without a second thought. It might be in the wrong directory, targeting critical system files, or wiping out hours of unsaved work. The agent, stripped of its need for explicit consent, becomes a blunt instrument, capable of inflicting significant damage with unsettling ease.

This 'skip permissions' approach is a capitulation to the problem of prompt fatigue, but it replaces the annoyance of constant questions with the terror of unchecked execution. It’s like removing all the locks from your house because you’re tired of using your keys, only to find yourself vulnerable to anyone walking in. The agent, no longer constrained by user oversight, operates with a dangerous autonomy. It doesn't distinguish between a safe, automated build script and a malicious command injected through a compromised dependency. The consequences can range from minor data loss to complete system compromise.

This dichotomy highlights a critical gap in how we approach AI agent security in development environments. The current models often present a false choice: either constant, productivity-killing interruptions or complete, unchecked execution. Neither is a sustainable or safe path forward. The problem isn't just about asking for permission; it's about asking for the *right* permission, at the *right* time, with the *right* context.

The Underlying Problem: Context and Trust

The core issue lies in the agent's lack of nuanced understanding and the user's erosion of trust. When an agent proposes an action, it needs to provide not just the command, but also the context: Why is this command necessary? What is its potential impact? What is the source of this instruction? Without this information, the user is forced to operate on incomplete data, leading to either over-approving or over-skipping.

Consider the difference between an agent suggesting git commit -m "fix typo" and one suggesting rm -rf / --no-preserve-root. Both are shell commands, but their implications are vastly different. A system that treats them identically, either by demanding approval for both or skipping both, is fundamentally flawed. The agent needs to be able to assess the risk profile of its own proposed actions. This requires a deeper integration with the development environment, understanding project structures, dependencies, and even the overall state of the code.

Furthermore, the trust model is broken. If a user repeatedly approves low-risk commands and then misses a high-risk one, the system has failed. Conversely, if a user has to disable all checks to get work done, the system has also failed. We need mechanisms that allow for progressive delegation of trust. Perhaps the agent can earn trust for certain types of operations within specific project contexts over time, or perhaps there are tiered permission levels that can be granted. The current binary choice—approve everything or trust nothing—is unsustainable for complex, fast-paced development workflows.

The tools that aim to provide these agents, like agentproto, are grappling with this. While the primitives might be checkable and the commands real, the user experience often defaults to these two dangerous extremes. The challenge for the industry is to build agents that are not only capable of executing tasks but also capable of operating safely and transparently, fostering a partnership rather than a constant battle for control.

What nobody has addressed yet is what happens to the thousands of developers who have already adopted these agents and, out of necessity, have likely fallen into the "approve all" or "skip all" trap. Re-educating them or providing a safer default will be a significant hurdle.