Approval fatigue

What is approval fatigue?

Approval fatigue is what happens when a system asks a person to approve something so often that the approving stops being a decision. The prompt appears, the person clicks yes, the record says a human approved it, and nobody read anything. The control exists on paper and has stopped existing in practice.

It is not the same thing as trusting the machine too much. Automation bias is about the credence you give to what a system produces. Approval fatigue is about volume: you can be entirely sceptical about the agent and still click through prompt thirty-one of the morning without your eyes stopping on the text. You can see it in a log. A gate that fires forty times a day and is approved every single time, a second after it appeared, is not a control. It is a keystroke the process document happens to call an approval.

Why agent tools generate so many approvals

Older software asked for a decision at the end of something. You filled in a purchase request, you sent it, one person approved it. One prompt, and what you approved was a whole request that meant something on its own.

An agent takes a task apart into small steps and runs them one at a time, and every step can be gated: read this file, run this command, write this file, call this API, reach this domain. Adding a VAT number to a customer form and to the nightly export becomes thirty or forty tool calls once you count the exploring, the test runs and the fixes. The tools sit on that grain by design. Claude Code asks before shell commands apart from a built-in read-only set, Codex splits it into an approval policy and a sandbox mode you set separately, and VS Code asks before file changes, terminal commands and external URLs. All three assume the person on the other side reads each prompt. At three prompts per task that holds. At forty it does not.

What the research on repeated warnings shows, and what it does not

Habituation to a repeated warning is measurable and it sets in fast. A team at Brigham Young University put people in an fMRI scanner and showed them security warnings. Their 2015 write-up reports a sharp drop in the visual processing centres of the brain after only the second exposure, and the change that slowed it down was making the warning look different each time. Brian Stanton and Mary Theofanos, at the US standards body NIST, interviewed computer users and named what they found security fatigue: weariness at dealing with security, showing up as avoiding decisions and taking the easiest option available. Their first recommendation was to limit the number of security decisions people have to make.

Hospital software has the longest experience of it. A 2006 review in the Journal of the American Medical Informatics Association gathered seventeen studies of drug safety alerts in prescribing systems and found clinicians overrode them in 49 to 96 percent of cases. Those rates are not proof that doctors were clicking blind. The review's own authors say overriding is often justified, because many alerts fire on combinations that are fine for the patient in front of you. A high override rate tells you the alerts are aimed badly, not that the person stopped reading.

What nobody has is a number for agent prompts. None of this research was done on them, so anyone who quotes you a threshold for when a developer stops reading is making it up.

Turning the prompts off, and what the vendors say about that

The escape valve is always there and people reach for it within about a week. Every one of these tools has a setting that stops asking altogether. The community name is YOLO mode, and it stuck well enough that VS Code ships a /yolo slash command that switches global auto-approval on.

The wording the vendors attach to that setting is unusually blunt. Microsoft writes that global auto-approval removes critical security protections and makes it easier for an attacker to compromise the machine, and points to agent sandboxing or a dev container instead. Anthropic's line for the bypass-permissions mode in Claude Code is one sentence: only use this mode in isolated environments like containers or VMs where Claude Code cannot cause damage. OpenAI marks the flag that drops both the sandbox and the approvals as not recommended. None of them says never turn the prompts off. They say the prompts are one of two boundaries, and that dropping this one means you need the other, which is isolation. The position nobody writes documentation for is the middle: prompts on, clicked without reading, no sandbox anywhere. That gives you a security model with nothing behind it and an audit trail claiming otherwise.

Thirty-eight prompts for one task, and the two that mattered

A developer at a thirty-person company asks a coding agent to add a VAT number to the customer form, store it, and include it in the nightly export. In a manual permission mode the run goes: run the tests, edit the entity, edit the form type, generate a migration, run it against the local database, edit the template, edit the export service, edit the test, clear the cache, test again, repair three files that broke, test once more, stage, commit. Thirty-eight prompts, most of them an edit or a command already approved four times that morning. Two of them could cost real money: the migration, because it alters a database, and the commit with the push, because that is when the work leaves the machine.

The redesign is four settings and ten minutes. Allow-list the repetitive safe commands, because the test runner, the linter, the cache clear, git status and git diff ran eleven times between them and the answer was always yes. Stop gating individual file edits inside the working directory, because eighteen edits approved one at a time are eighteen chances to stop reading rather than eighteen reviews. Put an explicit ask rule on the migration and on the push. Then point the whole run at a local copy of the database, so a wrong migration is a wasted afternoon instead of an incident.

Two prompts remain and both get read, because they are the only two that day and because they say what will change. Not that the agent wants to run doctrine:migrations:migrate, but that this applies three migrations to your local database and adds one column. Outside a terminal it is the same. If your bookkeeping agent wants a signature on each of the nine steps in posting one purchase invoice, the fix is one approval on the finished posting.

Design changes that cut the number of prompts

The measures that work change what gets asked, or how often. None of them ask the person to concentrate harder.

• Raise the granularity. One approval on a unit of work a person can describe in a sentence: this invoice posted, this pull request, this batch of price changes.

• Allow-list the safe and repetitive actions. What you have approved five times running without changing your answer should stop asking. Leave the interruptions to the actions that have earned one.

• Say what will change, not which function will run. This deletes 340 rows from orders, or this mails 62 customers, is something a reader can judge in the two seconds they will spend. A tool name with its arguments is not.

• Batch the review into one diff. Let the work finish, then show the whole change on one screen the person reads once. Developers already hold each other to that standard for code.

• Make the dangerous actions impossible rather than discouraged. A prompt in front of a destructive command asks the person to be careful. A sandbox with no production credentials in it is a wall, and behind a wall you do not need to interrupt anyone.

Many small approvals versus one approval on a unit of work

The two differ on the dimension that decides everything else: whether the person actually reads what they are approving. Each small prompt is one call with its arguments and takes a second to scan, and that second is real the first three times. By the twentieth the prompt is the shape you press through to get back to work, and the step being approved says nothing about the outcome anyway. Approving an edit to a form class tells you nothing about whether the feature is right.

A diff across eleven files takes two minutes, and people spend them, because it happens once and because they are looking at the outcome. The trap on that side is going too far. A four hundred file diff at the end of a week is as unread as the thirty-eight prompts were, and worse, because it looks thorough. The right unit is the largest one a person can still hold in their head, which is about what fits on two screens.

What an unread approval means for your oversight

Article 14 of the EU AI Act requires that a high-risk system be designed so people can effectively oversee it, and Article 26 puts the doing of it on the deployer, which is what a company that buys such a system is. The human oversight entry works through both. Neither says how many prompts is too many. Both make clear the oversight has to be effective, and an approval nobody reads is not that. This is where the audit trail turns around on you: a log full of approvals timestamped a second after the prompt appeared is not evidence of a control that was exercised, it is a dated record of the opposite, produced by your own system.

You do not need a regulator to make this worth measuring. Watch one person work for an hour and count the prompts a normal task produces. A handful means the design is fine. Thirty means the design is wrong and the person clicking through them is behaving the way anyone would. Two more numbers finish the picture: how often anyone answers no, and how long they take to answer. A rejection rate near zero and an answer time under two seconds are the same finding written twice.