# What is approval fatigue in coding agents?

Approval fatigue is the habit of approving an agent's permission prompts unread, because so many appear that the prompts stop protecting anything.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define approval fatigue
-   Explain why frequent prompts weaken safety
-   Identify safer alternatives to approving every action

## Related content

-   [What is a sandbox for AI agents?](https://specstory.com/learning/environments/ai-sandbox)
-   [What is least privilege for AI agents?](https://specstory.com/learning/environments/least-privilege-for-ai-agents)
-   [What is the difference between Docker, dev containers, and VMs?](https://specstory.com/learning/environments/docker-vs-devcontainer-vs-vm)
-   [What is prompt injection in coding agents?](https://specstory.com/learning/environments/prompt-injection-in-coding-agents)

## What is approval fatigue in coding agents?

Approval fatigue is a failure in which people approve the permission prompts of a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) out of habit, without reading what each one allows. It builds when the agent asks for approval so often that answering "yes" becomes routine. The prompts keep appearing, but they no longer stop a harmful action.

A permission prompt pauses the agent before an action that could cause harm, e.g. a shell command, until a person approves or denies it. Under approval fatigue, the prompt still appears on screen, so the setup looks safer than it is.

A [sandbox](https://specstory.com/learning/environments/ai-sandbox) reduces the number of prompts by limiting which files each command can change and which hosts it can reach. [Anthropic's engineering post](https://www.anthropic.com/engineering/claude-code-sandboxing) on sandboxing warns that clicking "approve" constantly can lead to approval fatigue, "where users might not pay close attention to what they're approving."

## How does approval fatigue happen?

Approval fatigue builds over one session in five steps:

1.  The agent stops before an action that needs approval and shows the command in a prompt.
2.  A person reads the command and approves it, and the agent continues.
3.  The agent requests many similar actions, e.g. running the tests after each edit, and nearly all of them are harmless.
4.  The person starts approving at a glance, often while doing other work, without reading the command.
5.  A risky action arrives in the same format and gets the same answer.

Diagram: How a risky prompt gets the routine answer

The person reads only the first prompt. The risky prompt has the same format as the routine ones and gets the same quick approval.

A prompt shows the command, not what the command will do. Approving `npm test` approves whatever the project's test script runs, and the agent can edit that script. A long command joined with `&&` can hide one risky step among routine ones. A risky command can also come from [prompt injection](https://specstory.com/learning/environments/prompt-injection-in-coding-agents), where text in a file or web page steers the agent's next action.

A coding agent saves time because it works while the person does something else. Each prompt pulls the person back, and answering "yes" ends the interruption fastest. The habit that removes the protection is also the one that keeps work moving.

## What is an example of approval fatigue?

Here is an illustrative example. A developer at Acme Co. asks a coding agent to "Let customers edit their delivery address during checkout." The agent runs on the developer's laptop and asks before each shell command it runs:

1.  The agent edits the checkout code and asks to run `npm test`. The developer reads the command and approves it.
2.  Over the next 25 minutes, the agent asks 39 more times, mostly to rerun the tests or run `npm run lint`. The developer approves each prompt in about a second.
3.  One test fails on an old test cart. The agent asks to run `npm run db:reset` to clear the test data.
4.  The developer approves it the same way. The project's `.env` file points `DATABASE_URL` at the team's shared staging database.
5.  The reset deletes and recreates the staging tables, and other developers lose their test orders.
6.  The developer adds allow rules for `npm test` and `npm run lint`, an ask rule for the database scripts, and a local database for the agent.
7.  In the next session, a similar task brings 3 prompts instead of 41, and the developer reads each one.

The reset prompt looked the same as the 40 before it. This example is simplified. A real project would also keep staging and production credentials out of the agent's environment.

## What is YOLO mode?

YOLO mode is the informal name for running a coding agent with its approval prompts turned off, so it runs actions without asking. The name comes from "you only live once." People also call it skip permissions mode, after a Claude Code flag. Developers often turn it on to escape approval fatigue, and it removes whatever protection the prompts still gave.

Coding agents give the flag different names:

| Agent | Flag | What it turns off |
| --- | --- | --- |
| Claude Code | `--dangerously-skip-permissions` | Most permission prompts, though deny rules still block and ask rules still prompt |
| Codex | `--yolo` | Approval prompts and the built-in sandbox |
| Gemini CLI | `--approval-mode=yolo` | Approval prompts for each tool call |

Outside a sandbox, the agent's commands then run with the developer's own access, and no person checks a harmful one before it runs. Claude Code's [permissions documentation](https://code.claude.com/docs/en/permissions) says to use its bypass mode only "in isolated environments like containers or VMs where Claude Code can't cause damage." A [dev container](https://specstory.com/learning/environments/docker-vs-devcontainer-vs-vm) or a virtual machine with no real credentials gives the agent that kind of boundary.

## What are safer alternatives to approving every step?

The aim is fewer prompts, each one read, and limits that hold while nobody watches. A team can combine these six changes:

-   **Allow routine commands and ask for risky ones.** An allowlist lets the agent run named commands, e.g. `npm test`, without a prompt. Ask rules keep a prompt for named risky commands, and the agent still asks before other commands. In Claude Code, deny rules win over ask rules, and ask rules win over allow rules.
-   **Run the agent in a sandbox.** Commands inside a sandbox can run without prompts, because its boundary, not a person, limits which files they can change and which outside hosts they can reach. Claude Code, with its sandbox turned on, runs sandboxed shell commands without a prompt by default. Its default settings still let commands read most files on the host, including credential files, so pair it with [least privilege](https://specstory.com/learning/environments/least-privilege-for-ai-agents).
-   **Limit what the agent can reach.** Under least privilege, the agent gets test credentials and no production keys. [Egress control](https://specstory.com/learning/glossary#egress-control) limits which outside hosts its commands can reach.
-   **Keep prompts for actions that leave the sandbox.** A person approves the few actions whose effects reach past the boundary, e.g. a deploy. A [human-in-the-loop](https://specstory.com/learning/ai-coding/human-in-the-loop) check at that point can stop harm that a sandbox cannot contain.
-   **Treat an auto mode as one layer.** In some auto modes, e.g. Claude Code's, a second model called a classifier approves or blocks actions in place of a person, which removes most routine prompts. [A security researcher](https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/) showed a prompt injection chain that worked in 3 or 4 of 5 attempts against one such mode. That mode had scored 0% attack success on a fixed benchmark that its vendor commissioned, and a benchmark covers only the attacks it contains. Use an auto mode inside a sandbox, not in place of one.
-   **Check the result instead of each step.** An [agent hook](https://specstory.com/learning/ci-cd/agent-hooks) can run the tests each time the agent tries to end its turn, so a failing check reaches the agent while nobody watches. A person then reviews the diff and the test output once, at the end. Reading the changes and running checks, rather than accepting the code unread, is what separates [agentic coding](https://specstory.com/learning/ai-coding/agentic-coding-vs-vibe-coding) from vibe coding.

## How is approval fatigue different from alert fatigue?

Alert fatigue is the loss of attention that follows when a monitoring system sends so many alerts, many of them false alarms, that people start to ignore them. Both failures come from volume, and both improve when there are fewer interruptions, each worth reading. The habit differs. An ignored alert leaves a real problem unhandled, while a prompt approved unread lets a harmful action run.

[Rubber-stamp review](https://specstory.com/learning/glossary#rubber-stamp-review) is the same pattern in the review of a finished change. The [review bottleneck](https://specstory.com/learning/code-review/review-bottleneck) is the queue that often causes it.

## FAQs

### What is an allowlist for agent commands?

An allowlist for agent commands is a set of rules that lets a coding agent run named commands, e.g. the project's test command, without asking first. Commands outside the list still prompt a person. A narrow allowlist removes routine prompts, so the prompts that remain are more likely to be read.

### What can go wrong when permissions are skipped?

When permissions are skipped, the agent runs the actions it requests without a person checking them first, including a command planted by prompt injection. Outside a sandbox, that command runs with the developer's own access, so it can change real files and reach real credentials.

### Can a sandbox replace approval prompts?

A sandbox can replace approval prompts for commands that stay inside it, because its boundary, not a person, limits the files they can change and the hosts they can reach. Actions whose effects reach past the sandbox, e.g. a deploy, still need a person to approve them.

### Does auto mode remove approval fatigue?

Auto mode removes most of the routine prompts that cause approval fatigue, because a classifier model approves or blocks actions in place of a person. The classifier can still approve a harmful action, as a security researcher's prompt injection test showed. Auto mode works as one layer inside a sandbox, not as a replacement for one.

---

Source: [Approval fatigue | AI agent permission prompts | SpecStory](https://specstory.com/learning/environments/approval-fatigue)