When can a coding agent stop asking permission?

I've worked in sandboxes for ages without approving each command an agent runs. Babysitting an agent one click at a time doesn't make much sense to me. Containment over endless yes clicks feels right.

That raises a narrower question. When is it reasonable to let a coding agent run commands without approving each one?

My answer is to start with a boundary you have actually checked, covering the filesystem, the network, and credentials. Inside that boundary, let the agent work. Actions with consequences outside it still need a human decision.

Why approving every command is a weak control

Approving everything looks like the careful option. I suspect it often isn't.

An agent working through a codebase lists directories, reads files, runs tests, searches for symbols, and tries small edits. Most of this is low-risk. My concern is that a reviewer facing a long run of such prompts may stop reading closely. If that happens, the one command that matters gets the same reflexive yes as the rest. This is a plausible failure mode, not something I've measured.

Per-command prompts also focus on the wrong thing. The real question is what the process can reach, not whether ls is safe. Code an agent writes can use whatever files, credentials, and network access its environment provides. If the environment exposes too much, approving commands one at a time is a thin defense. If it exposes very little, many of those approvals protect almost nothing.

I think of control as having two layers:

• The environment sets what is possible through isolation, restricted network access, and keeping credentials out.
• Human review covers the smaller set of actions that remain consequential even inside that environment, such as ambiguous requests or side effects that reach other systems.

The two layers should be independent. Review shouldn't be the only thing keeping a secret from leaving the machine. The environment shouldn't be trusted to decide whether a change is fit for a shared branch.

A hypothetical task inside a sound boundary

The following example is invented. It illustrates the argument and doesn't describe my own setup.

Suppose an agent is asked to fix a failing unit test in a local repository. The cause looks like an off-by-one error in a date-parsing helper. The environment is set up like this:

• Filesystem: the agent can read and write in a copy of the repository. It can't see the rest of the home directory, shell history, SSH keys, or other projects.
• Network: outbound access is off by default. Dependencies are installed in advance, or through a narrow allowance someone added on purpose.
• Credentials: no production tokens, cloud keys, or personal access tokens are present. A secret that isn't in the environment can't leak from it.

Within that space, it would be reasonable to let the agent do the following without asking:

• read any file in the repository
• run the test suite as often as it likes
• add print statements and scratch scripts, then remove them
• edit the helper and its tests
• create a local branch and commit to it

If the boundary holds, the likely worst case is a broken working copy that you discard and recreate.

The following actions cross the boundary or deserve a deliberate look:

• pushing to a shared remote
• opening a pull request or commenting under someone's name
• changing CI configuration, deploy scripts, or anything that runs with elevated privileges elsewhere
• requesting network access that wasn't granted at the start
• touching files outside the working copy

Each of these reaches other people or other systems. Careful review of a few such actions is likely a better use of attention than skimming dozens of routine ones.

This setup has a cost. With the network closed, a missing dependency stops the task until someone decides whether to allow it. Preparing a clean copy with no stray secrets takes more effort than pointing the agent at an existing directory. That friction is the price of making the boundary real.

The same task with one detail wrong

Now change one assumption. Instead of a copy, the real project directory is mounted. It contains an old .env file with a live API key. The network was left open because that made package installs easier.

While debugging, the agent writes a script that loads configuration to reproduce the bug. The script reads .env, initializes an API client with the key, and sends a test request to a service that was never approved for this task. Each step could look routine on its own. A reviewer approving them one at a time might not see the combined effect.

In this scenario, the test request sends a live credential to an outside system. The boundary existed on paper but failed in practice: a secret was inside the sandbox, and the open network gave it a way out. Isolation, network restriction, and credential separation are meant to reinforce each other. Weakening one reduces what the others can protect.

For this reason, I don't treat a sandbox as a guarantee. It is a set of claims about what the agent can reach, and those claims can be wrong. A careless mount, an inherited environment variable, or a temporary exception nobody removed can each break them.

Trusting the environment instead of the agent

Letting an agent run unattended isn't really trust in the agent. It's trust that the environment keeps mistakes contained and cheap to undo.

That kind of trust can be checked. You can inspect what is mounted, which network destinations are allowed, and which secrets are present. Approving a single command gives you no comparable view of the environment.

So spend attention on the boundary and on the few actions that cross it. Inside, let the agent explore. At the edge, slow down and read what it is about to do.