At some point an owner asks the developer building their automation a simple question: "Does this thing ask before it does something?" Increasingly the honest answer is "no." Coding agents like Claude Code can be started with a flag called --dangerously-skip-permissions, and the name is not marketing. This post explains what that flag removes, what the vendor has measured about the alternative, and the specific gates we put around any automation that touches a client's live systems.
You do not need to read code to follow this. You need to know which questions to ask, and what a good answer sounds like.
What the flag removes, in plain terms
According to the Claude Code documentation, the tool normally stops and asks before it edits files, runs commands, or reaches the network (Claude Code, 2026). --dangerously-skip-permissions starts it in a mode the documentation calls bypassPermissions, which "disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths" (Anthropic, 2026). Protected paths are things like the .git folder that holds a project's history and the agent's own configuration folder.
According to Anthropic's documentation, the mode is meant for one situation: "Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system" (Anthropic, 2026). Two guardrails survive even there. The mode refuses to run with administrator (root) privileges, and the first time a person turns it on, Claude Code shows a dialog asking them to accept responsibility for actions taken without checks.
Translate that for your business. If your developer runs the flag on a laptop that also holds your CRM export, your accounting login and a Slack token, the agent can use all three the moment it decides to, and nothing in the tool will pause to ask. That is the whole risk, and it is a location question as much as a software question.
The alternative the vendor built, with its numbers
Anthropic did not leave "prompts or nothing" as the only choice. Auto mode replaces the prompts with a second model, a classifier, that reviews each action before it runs and blocks "anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content" (Anthropic, 2026). If the classifier blocks an action 3 times in a row or 20 times in a session, the tool falls back to asking a human.
The numbers behind it are public. Per Anthropic's engineering write-up, users approve 93% of permission prompts, which is why the prompts had become a reflex rather than a review (Anthropic, March 25, 2026). On 10,000 real tool calls the classifier wrongly blocked 0.4% of benign actions. On 1,000 synthetic attempts to leak data it missed 5.7%. On 52 real "overeager" actions, where the agent did more than it was asked, it missed 17% (Anthropic, March 25, 2026).
Read that last figure as an owner: roughly 1 in 6 cases of an agent overstepping got through. The classifier also sees only the user's messages and the commands the agent tries to run. It does not see the agent's reasoning or the content of the web pages and documents the agent reads (Anthropic, March 25, 2026). Anthropic's product post states the position directly: "Auto mode reduces risk compared to --dangerously-skip-permissions but doesn't eliminate it entirely, and we continue to recommend using it in isolated environments" (Anthropic, updated July 10, 2026).
Per reports from Help Net Security, auto mode became the default starting mode for Pro, Max and Team plans on August 14, 2026, and Anthropic cited teams on auto mode shipping about 25% more pull requests (Help Net Security, August 10, 2026). Reports from The Register put the same shift in plainer terms, calling it auto mode taking "the driver's seat" (The Register, August 10, 2026), and according to 9to5Mac the default flipped for existing users the week of August 14 (9to5Mac, August 14, 2026). So the odds are that your developer is already running some form of automatic approval. The question is what sits behind it.
The three-legged risk every automation project carries
Per Simon Willison, the dangerous combination is the "lethal trifecta": an agent that can read private data, is exposed to content it did not write, and can send information out (Simon Willison, June 16, 2025). Most useful business automation has all three legs. An intake agent reads your inbox (private data), processes whatever a stranger emailed (untrusted content), and replies or updates a system (external communication).
According to OWASP, this attack class is called prompt injection and sits at number one on its Top 10 for LLM Applications, with a direct form, where a user's own message changes the agent's behavior, and an indirect form, where a web page or a file does (OWASP, 2025). A permission prompt would not have stopped an injected instruction that looks like ordinary work, because the developer would have approved it 93% of the time anyway.
This is why we do not treat "does it ask" as the safety question. The safety question is: which actions can this agent take that we cannot reverse, and what stands between the agent and those actions besides its own judgment?
The four gates we scope into every engagement
Our engagements start with a free 30-minute operations audit that maps the repetitive work, and the scoping that follows always answers the same four questions. We covered the broader method in our AI operations automation guide; this section is the safety-specific part.
1. Which actions are irreversible, and who approves them. We list every action the automation can take and sort it into two piles: reversible (draft an email, create a task, update a field we log) and irreversible (send, pay, delete, publish, change a permission). Irreversible actions go behind an explicit approval step or a hard rule, written into the scope before any code exists. An approval for one action never carries over to the next one.
2. Where the agent runs, and what it can reach from there. An agent that only needs to read a spreadsheet and write to a task board should not run on a machine that also holds your bank login. Isolation is the control the vendor itself recommends, and it costs little: a separate account, a container, or a scoped API key that can do exactly one job.
3. What proves the work happened. We call these receipts. A receipt is an independent check that does not rely on the agent describing its own work: fetch the record after the write and compare, count the rows before and after, confirm the email landed in the sent folder. If the agent claims it booked 12 appointments and the calendar shows 12 new events, that is a receipt. If the agent claims it and nothing checks, that is a story.
4. How we roll back. Every automation that writes to a system of record ships with a documented way to undo a bad run: a backup taken before the batch, a log of every record touched, and a tested restore. We rehearse the rollback once before go-live, on real data, with the client watching.
What this looks like in a real week
Here is the shape of a common engagement, a property-management client with an intake mailbox, a maintenance system and a bookkeeping tool, with the gates applied. The hours are the kind of range we scope against and measure after delivery, not a promise.
| Automation step | Reversible? | Gate applied | Receipt | Typical manual time replaced per week |
|---|---|---|---|---|
| Read new tenant emails, classify, draft a reply | Yes (draft only) | Runs unattended in an isolated mailbox account | Draft appears in a review folder with the source email ID | 3 to 5 hours |
| Create a maintenance ticket from the email | Yes (ticket can be closed) | Field-level rules: no priority above "normal" without a human | Ticket ID written back to the email thread | 2 to 3 hours |
| Send the reply to the tenant | No | Human clicks send, or a rule allows only templated replies | Message found in the sent folder | 1 to 2 hours |
| Post the vendor invoice to bookkeeping | No | Amount and vendor must match an approved list; anything else stops | Invoice number matched in the ledger export | 2 to 4 hours |
| Weekly summary to the owner | Yes | None needed | Summary contains the ticket and invoice counts from the receipts | 1 hour |
Notice where the human sits. Not on every action, which is the 93%-approval trap Anthropic measured (Anthropic, March 25, 2026), but on the two rows that cannot be undone. The agent runs the rest without asking, and we know it ran because the receipts say so. That is how the client gets the 9 to 15 hours a week back without handing the agent the keys to the whole building.
Questions to ask your developer, with good answers
| Ask this | A good answer sounds like | A bad answer sounds like |
|---|---|---|
"Does the agent run with --dangerously-skip-permissions?" |
"Only inside a throwaway container with no network. On anything connected, it runs in auto mode or behind our own tool gates." | "Yes, it's fine, it's just a dev thing." |
| "Which actions can it take that we can't undo?" | A written list, with an approval step next to each one. | "It's smart, it won't do anything dumb." |
| "How do we know it did what it says?" | "Every run writes a receipt we check independently." | "You can read the logs." |
| "What happens if it reads a malicious email?" | "It can only draft; sending and paying are behind rules it can't change." | "The model is trained to ignore that." |
| "How do we roll back a bad run?" | "Backup before every batch, touched-record log, restore tested on day one." | "We'd fix it by hand." |
If you are still choosing who to work with, our guide to how to choose a software development partner covers the rest of the diligence. The safety answers above are the ones that separate a partner who has run automation in production from one who has run it on a laptop.
When skipping permissions is the right call
The flag exists for a reason and we use it in the right place. Batch jobs that regenerate 300 reports or re-process a year of records would otherwise produce 300 identical prompts, and a prompt nobody reads is worse than no prompt. The documentation's own example is exactly this: "Run fully unattended inside a container" with claude -p "<prompt>" --dangerously-skip-permissions (Anthropic, 2026). The dev container configuration Anthropic publishes runs the agent as a non-root user for this purpose (Anthropic, 2026).
The rule we apply is simple. The flag is acceptable when the machine holds nothing you cannot regenerate and can reach nothing you would miss. The moment either condition fails, it is the wrong tool, and the developer should be able to say which of the other modes they use instead and why.
What it costs to do this properly
The gates above add real hours to a scope, and it is fair to ask what they are worth. In our experience, on a typical intake-and-bookkeeping automation, the safety work is roughly 15% to 25% of the build: the action inventory, the isolation setup, the receipt scripts and one rollback rehearsal. That is a hypothetical range from our own scoping, not a survey, and your numbers depend on how many systems the agent touches.
Against that, weigh a single bad run: an agent that pays 40 vendor invoices twice, or emails 200 tenants a draft. The rollback plan turns that from a week of cleanup into an afternoon, and the receipts mean you find out the same day, not at month end. Our integration ROI guide shows how to put those numbers side by side for your own operation.
Frequently asked questions
Is --dangerously-skip-permissions illegal or against the vendor's terms?
No. It is a documented, supported option with a documented use case: isolated environments where the agent cannot damage the host system (Anthropic, 2026). The risk is misuse on a connected machine, not the flag itself.
If auto mode is the default now, are we already protected?
Partly. Auto mode's classifier blocks a defined set of destructive and out-of-bounds actions, but Anthropic's own evaluation reports a 17% miss rate on real overeager actions and states that the mode does not replace isolated environments (Anthropic, March 25, 2026). Treat it as one layer, and put the irreversible actions behind your own.
Can we make the flag impossible for our developers to use?
Yes. Setting permissions.disableBypassPermissionsMode to "disable" in a managed settings file removes bypass mode, and disableAutoMode does the same for auto mode (Anthropic, 2026). Whether you should depends on whether your team also runs isolated batch jobs that legitimately need it.
What is the first thing to fix if our automation has none of these gates?
Receipts. Before adding approvals or moving anything into a container, write one independent check for the action you rely on most. It is the cheapest gate, and it tells you within a day whether the other three are urgent.
Book a free 30-minute operations audit — identify the repetitive work, then scope an ongoing automation engagement; measure actual hours saved after delivery.