Approval dialogs keep appearing, but reviews get shorter
When Claude Code asks for approval every time it runs a shell command, you read the details carefully at first. But as testing and file exploration continue, approval dialogs start to feel less like a safeguard and more like interruptions. Eventually, you may want to create broad allow rules or skip permission checks altogether.
In real usage data, 97% of permission requests were approved. Still, that number alone does not prove that every user clicked reflexively without reading the details. The observation period and total number of prompts were not disclosed, and most may have been routine, harmless commands. The careful interpretation is simply that there is reason to revisit whether repeated approvals are a mechanism that effectively identifies risk.
To address this issue, Anthropic made Auto Mode the built-in starting mode for new sessions on Pro, Max, and Team plans starting August 14, 2026. Users and organizations that had already selected another default mode retain their existing settings.
For the same risky commands, people stopped 143 while Auto Mode stopped 937
In a controlled experiment, Auto Mode blocked far more risky commands than repeated manual approvals. Anthropic replaced one permission request with an obviously risky command in a coding research environment involving 1,053 paid expert testers. The commands were never actually run, and the study compared how people and Auto Mode handled the same 1,053 commands.
| Decision maker | Risky commands blocked | Block rate |
|---|---|---|
| Users approving manually | 143 / 1,053 | 13.6% |
| Auto Mode | 937 / 1,053 | 89% |
The human block rate fell from about 17% at the beginning of a session to about 5% after more than 50 prior permission requests, while Auto Mode’s block rate did not vary with session length. This suggests that, in environments where approval requests accumulate, automated classification may provide a more consistent default control.
Do not generalize 89% into the safety of all development work. Participants worked in a test environment rather than a real repository, and they knew they were being evaluated. Sample sizes by segment, confidence intervals, and the list of risky commands were not disclosed. This is not evidence that Auto Mode is always superior to an expert who carefully reviews infrastructure changes.
Auto Mode does not ask AI about every command
Auto Mode first lets clearly safe tasks through, then sends only potentially risky tasks to a two-stage classifier. Read-only tools, edits to files inside the project, and narrowly scoped user allow rules are handled at the first stage. The classifier’s first stage sensitively flags suspicious actions, while the second reasons over flagged actions again to reduce unnecessary blocks.
The classifier focuses on the user message and the actual tool input, rather than explanations or execution rationales written by Claude. This separation is designed to keep a plausible explanation generated by the agent from swaying the safety decision.
Tasks that send sensitive data externally, production deployments and migrations, shared infrastructure changes, force pushes, and irreversible destruction of existing files are included in the default blocking categories. However, you should not interpret roughly 20 rules as absolute prohibitions that can never be lifted in any situation. Users can leave Auto Mode, and organizations need to add separate deny and ask policies.
Existing allow rules also need their scope checked. Narrow rules such as Bash(npm test) remain, but rules such as Bash(*) or rules that grant broad code-execution permission to interpreters or package managers may be excluded when entering Auto Mode. The excluded rules are restored when you leave the mode.
The classifier misses cases too: 17% of 52 real overreach incidents
Auto Mode’s advantage is not eliminating risk, but making selections more consistently than repeated approvals. The deployed two-stage classifier allowed 17% of 52 real overreach samples collected from Anthropic employee sessions. It missed 5.7% of 1,000 synthetic data-exfiltration attempts and incorrectly blocked 0.4% of 10,000 normal internal traffic samples.
Here, 17% is not a failure rate for all real-world commands. It comes from a small, biased sample of only 52 cases that were already rejected or later flagged as problematic. Conversely, the 89% block rate does not represent every real production environment. Together, the two figures show both that Auto Mode is useful and that it cannot replace human review for high-risk work.
Choose permission modes based on how reversible the work is. For tasks such as local code edits and tests that can be inspected in a diff and reverted, you can start with Auto Mode. For production deployments, shared infrastructure changes, sensitive-data transfers, and bulk data changes, it is safer to retain separate human approvals and organizational policies.
Start your first check in a test repository
First see how Auto Mode works in your environment in a version-controlled repository where no commit, push, or deployment is needed. The selected account, organization, and model must support Auto Mode, and permissions.disableAutoMode must not be set to "disable" in any settings file. On Team and Enterprise, an administrator may have deployed this value through organization settings.
Before practicing, install the project dependencies and prepare a repository with one failing test that can be reproduced repeatedly using the existing test command. If there is no failing test, do not intentionally break code; instead, use a test repository that your team has already designated for fixes.
- Prepare Claude Code and a test repository.
If you have not installed it yet, choose an installation method for your operating system in the official Quickstart. After installation, verify it withclaude --version, then runclaudefrom the prepared project directory and sign in. - Reproduce the failure yourself first.
Run the test command defined in the repository and confirm that the same test fails repeatedly. Record the command you ran and the name of the failed test. If the issue is not something a code change can solve, such as missing dependencies or an external-service outage, choose another test. - Select Auto in a new session.
In the CLI, cycle through permission modes withShift+Taband confirm thatauto mode onappears in the status bar. In Desktop and VS Code, choose Auto from the mode selector near the input field. - Assign only one reproduced failure.
Enter: “Analyze the cause of one test that failed in the test command I just ran, fix it with the smallest possible code change, and then run the same command again. Do not commit, push, deploy, or send anything to an external service.” - Review both success and block records.
Confirm that the same test command succeeds and thatgit diffcontains only the changes needed to fix that failure. If the task was blocked, find the blocked item under Recently denied in/permissions; rather than bypassing it immediately, narrow the request scope and trust boundary further before trying again.
If Auto Mode is blocked three times in a row or 20 times cumulatively in the same session, it pauses and returns to manual approval prompts. Auto Mode resumes when the user approves the task. In non-interactive runs, it does not switch to an approval dialog; it skips that task and continues with other work.
If you want to dig deeper
Auto mode is now the default in Claude Code for Pro, Max, and Team plans explains the 97% approval rate, the design of the controlled experiment with 1,053 participants, and the reasoning behind the default-mode change. claude.com
How we built Claude Code auto mode: a safer way to skip permissions is the original engineering article covering the two-stage classifier, default blocking categories, and real and synthetic evaluation results. anthropic.com
Choose a permission mode is the current product documentation for switching modes, excluded allow rules, block thresholds, and administrative settings. code.claude.com
