Approval prompts stop working before you notice

The first permission prompt of the day gets read. So does the second. Somewhere around the fortieth, you are pressing yes with one hand while thinking about the thing you were doing before the agent interrupted you. Anthropic measured this on its own product and published the number: Claude Code users approve 93% of permission prompts [2]. Its engineering write-up names the mechanism without softening it, describing approval fatigue as the point where “people stop paying close attention to what they’re approving” [2].

That number is the whole problem with treating approval as oversight. A control you exercise 93% in one direction is not filtering anything; it is adding latency to work you were going to allow anyway. This guide is for solo operators and small teams running agents that can reach real things, meaning your repository, your cloud account, your customers’ data, your money. It is not a compliance guide. If you deploy a system that falls under the EU AI Act’s high-risk rules, your human-oversight obligations are set out in Article 14 and a permission setting does not discharge them [5]. And if you already run everything inside a throwaway container that holds nothing you would miss, most of what follows is optional for you, which is a legitimate position rather than a lazy one.

The approval step degrades exactly where the risk concentrates

Prompt volume scales with what an agent can do. Your attention does not. The fiftieth approval request of an afternoon arrives at a worse moment than the first, gets less thought, and sits inside a longer task where you have less memory of what you originally asked for. Risk does not fall off on the same curve, so the prompts most likely to matter arrive when you are least equipped to judge them.

This is not a new observation, and it is old enough to be written into law. The EU AI Act requires that people assigned to oversee a high-risk system be enabled to remain aware of the tendency to automatically rely or over-rely on the output of an AI system, which the text names as automation bias, and to be able to disregard, override or reverse an output, and to interrupt the system with a stop button or a similar procedure [5]. The regulation applies to a narrow set of systems. The human factor it describes applies to you at your desk on a Tuesday.

The practical consequence is that your oversight budget is fixed and small. Spend it on the handful of actions where a wrong call is expensive and hard to undo, and stop spending it on file edits inside a directory you can restore from git.

A permission prompt asks about one command, not about the plan

The prompt shows you a command string and asks for a decision. It does not show you the eight calls that follow it, or the tool output that convinced the agent this call was a good idea. Claude Code attaches natural-language descriptions to complex bash commands specifically so you can understand them [6], which is a quiet admission that reading shell one-liners at speed is a task people are bad at.

The design of the automated alternative makes the point sharper. Anthropic’s auto-mode classifier is deliberately reasoning-blind: it sees your messages and the agent’s tool calls, while Claude’s own messages and the tool outputs are stripped out [2]. It reads your CLAUDE.md content too, but it never sees the agent’s explanation of itself [1][2]. At a permission prompt you get the opposite deal. You see the persuasive part, the agent’s account of why this is fine, and you rarely go back to check the file or the web page that shaped it. If that page contained hostile instructions, the explanation you are reading is downstream of them.

Command text also hides things. In Claude Code, rule matching strips a fixed set of wrappers, so a rule like Bash(npm test *) also matches timeout 30 npm test, while exec wrappers such as watch, setsid, ionice and flock cannot be approved by a prefix rule at all and always prompt in Manual mode [7]. Those are the tool’s own hedges against text that looks like one thing and does another. You are performing the same parsing job, faster, on less coffee.

Rules you write once outlive the attention you do not have

The alternative to deciding case by case is deciding once, in a file. Claude Code evaluates rules in a fixed order, deny then ask then allow, with the first match winning and rule specificity not changing the order [7]. A deny rule blocks an action before the classifier is even consulted, and neither the classifier nor your stated intent can override it [3]. An ask rule forces a permission prompt even when the session is in auto mode, because an explicit ask rule counts as your stated intent to be asked [3].

That last one is the mechanism most people miss. You do not have to choose between reviewing everything and reviewing nothing. Anthropic’s own recommended recipe is two lines in a settings file, putting Bash(git push *) and Bash(gh pr create *) into permissions.ask so those two actions still stop for you while everything else runs [3]. Pick your equivalent of those two. For most small operations the honest list is short: anything that sends email, anything that moves money, anything that touches production, anything that rewrites history someone else depends on.

Every serious agent tool now ships the same shape of control. OpenAI’s Codex has approval policies named untrusted, on-request and never, and separate sandbox modes read-only, workspace-write and danger-full-access. On launch it checks whether the folder is version-controlled and recommends workspace-write with on-request approvals when it is; the combination of no sandbox and no approvals is the one its own table marks not recommended [4]. The vocabulary differs. The decision is identical: pre-declare the boundary, or answer the same question fifty times and get it wrong once.

One trap to avoid on the way. Buying quiet with a blanket allow rule does not work in Claude Code, and it should not work anywhere. On entering auto mode, broad allow rules that grant arbitrary code execution are dropped, including Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands and Agent rules, while narrow rules such as Bash(npm test) stay in effect [1].

A boundary you state in chat lasts as long as the transcript

Telling the agent a rule feels like setting one. In Claude Code it partly is: the classifier treats boundaries you state in conversation as a block signal, so telling Claude not to push until you have reviewed will block matching actions even when the default rules would allow them, and Claude’s own judgment that the condition has been met does not lift it [1].

Then comes the part worth internalising. Those boundaries are not stored as rules. The classifier re-reads them from the transcript on every check, so a boundary can be lost when context compaction removes the message that stated it, and the documentation says plainly that a hard guarantee requires a deny rule instead [1][3]. A control that lives in a conversation has the lifetime of a conversation, and long agent sessions are exactly the ones that get compacted.

The same logic explains why a line in a project file beats a sentence in chat. The classifier reads the same CLAUDE.md content Claude itself loads, so a project convention written there steers both at once [3]. Chat for this task, file for every task.

Cap what an action can reach instead of counting how many you approve

The stronger lever is not who approves an action but how much an action can touch. Anthropic’s security guidance for working with untrusted content is a short list: review suggested commands before approval, avoid piping untrusted content directly to Claude, verify proposed changes to critical files, and use virtual machines to run scripts and make tool calls, especially when interacting with external web services [6]. It also points at dev containers for isolation on sensitive work [6]. Codex takes the same route by defaulting to read-only in folders that are not under version control, and by leaving network access off by default in workspace-write [4].

Tool designers apply this to themselves in ways worth copying. Claude Code never lets an allow rule or a hook approve an rm or rmdir aimed at a critical path such as rm -rf / or rm -rf ~, in any mode [1]. It maintains a protected-path list that no settings-file allow rule can pre-approve, covering directories like .git and .claude and files like .bashrc, .zshrc, .npmrc and .mcp.json [1]. That list is a usable definition of irreversible: the things whose corruption you would not notice until much later.

Two defaults are worth knowing before you decide your own boundary, because both are reasonable and both surprise people. In auto mode, reading .env and sending those credentials to their matching API is allowed by default, and so is pushing to any branch of the repository you are working in, including the default branch [1]. Neither is a bug. If neither is what you want, that is precisely the job an ask rule does.

The test to apply to any pending action is not how confident you feel. It is what the worst case costs to undo. If the answer is a git reset, approve it fast or let the classifier handle it. If the answer is an email that has been read, a payment that has cleared, or a colleague’s afternoon of work overwritten by a force push, it belongs in a rule, whatever your confidence today.

Automated review is a second gate, and its numbers are small

Anthropic published the evaluation behind auto mode, which is more than most vendors do, and the numbers deserve reading rather than quoting. The full classifier pipeline showed a 0.4% false-positive rate against 10,000 real internal tool calls, a 17% false-negative rate against a set of 52 real overeager actions, and a 5.7% false-negative rate against 1,000 synthetic data-exfiltration attempts [2].

Read that honestly and it says two things at once. A gate that fires on 0.4% of routine traffic is quiet enough to live with. A gate that misses 17% of a 52-item dangerous set is a real filter with a real hole, measured by the vendor that sells it, on a sample small enough that the figure should be treated as an internal claim rather than a settled fact. Anthropic’s own documentation carries the warning in plain terms: auto mode reduces permission prompts but does not guarantee safety, and should be used for tasks where you trust the general direction, not as a replacement for review on sensitive operations [1].

The fallback behaviour is the part most worth copying into your own thinking. If the classifier blocks an action 3 times in a row, or 20 times in total, auto mode pauses and Claude Code resumes prompting you, and those thresholds are not configurable [1]. The system assumes that heavy blocking means it has lost the plot, and hands control back. Your own process should have the same reflex: repeated refusals are a signal to stop and look, not a queue to clear.

Two operational details close the loop. The classifier runs on Claude Sonnet 5 by default rather than your selected model, and on Enterprise plans and accounts using the Claude API, Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry, those classifier calls count toward your token usage [1]. And which mode you start in is not uniform: auto mode became generally available in Claude Code for all users on 10 July 2026 [8], Pro, Max and Team sessions in a terminal or VS Code now start in auto, while Enterprise plans, Console API keys, claude -p runs and Agent SDK sessions start in Manual [1]. Check what your sessions actually do rather than what you assume, with claude --permission-mode default or a defaultMode value in ~/.claude/settings.json if you want the old behaviour back [1].

What still goes wrong

Prompt injection survives all of this. Anthropic’s security page lists several defences and then says that while these protections significantly reduce risk, no system is completely immune to all attacks [6]. OpenAI says the same about Codex, warning that enabling network access or web search can cause the agent to fetch and follow untrusted instructions [4]. An agent that reads a poisoned issue comment, dependency README or web page can be steered, and the action it then proposes will look reasonable, because looking reasonable is the attack. Isolation limits the damage. Nothing removes the class.

Rules also rot. You write an ask rule for the deploy command, then the deploy command changes name, and the rule matches nothing while you carry on feeling protected. Rules built around wildcards are worse, because the gap is invisible until something slips through. Set a recurring reminder to re-read your own permission rules the way you would re-read a backup policy, and open one full transcript occasionally to see what actually ran, not what you remember approving.

And the responsibility does not move. Claude Code’s documentation states it directly: the tool only has the permissions you grant it, and you are responsible for reviewing proposed code and commands for safety before approval [6]. Handing per-action review to a classifier changes where your judgment goes, not whether it is required. If your work falls under the EU AI Act’s high-risk rules, that judgment has a legal shape as well, including the ability to override or reverse an output and to interrupt the system [5]. Turning off the prompts is a decision about where to spend attention. It is not a decision to stop paying any.