A gate that opens 93% of the time
Anthropic published the number, in its own engineering writeup on auto mode
(anthropic.com/engineering/claude-code-auto-mode, re-check date in the rot register below):
users approve about 93% of permission prompts.
Sit with that. The permission prompt is the control most people believe is protecting them, and in practice it is a dialog that gets dismissed nineteen times out of twenty. That is not a gate. It is a doorbell.
This is not a criticism of anyone's discipline. It is what happens to any control that depends on sustained attention across hundreds of interruptions. The useful response is not to try harder — it is to move enforcement to a layer that does not get tired.
Everything technical below was verified against Anthropic's documentation on 2026-08-05, with a rot register at the foot of this page listing every claim likely to be stale within ninety days and where to re-check it. This product changes at the patch level. A page about it that is not dated is lying to you by omission.
The frame that makes this tractable
Your permission configuration is your org chart, in executable form.
In a firm with employees, who may do this without asking is a governance document: signing authority, deploy rights, spending limits. Nobody thinks of that as friction. It is the thing that lets a business operate without the owner in every room.
The same object exists in your harness, and most operators have never read theirs:
| Permission construct | What it is in a firm |
|---|---|
permissions.allow | a job description |
ask rules | the co-signature list |
deny rules | what nobody does, including you on a tired Friday |
| managed settings | the board resolution no manager can waive |
| protected paths | the rule that nobody edits the org chart unilaterally |
The tutorial discourse frames permissions as UX friction. The correct frame is delegation of judgement — and every "Yes, don't ask again" is a standing delegation, written silently to a settings file, that survives the session and the mood that granted it.
Run /permissions. It prints your effective policy and the source file of every rule. If you
cannot produce and defend that output, you do not know your own org chart.
What the rules actually enforce
Here is the sentence from the documentation that most changes how you should work:
Permission rules are enforced by Claude Code, not by the model.
Your CLAUDE.md, your prompts, your careful instructions — those shape what the agent tries.
Only rules, modes, hooks and the sandbox change what is allowed. The distinction is the whole
ballgame, and conflating them is the most common serious mistake operators make.
And the rules are string patterns over a shell, not semantics. The docs say so; the tutorials never mention it.
Bash(curl http://github.com/ *) looks tight. It is defeated by:
- putting a flag first —
curl -X GET http://github.com/… - using https instead of http
- a redirect to somewhere else entirely
URL=$SOMETHING && curl $URL
And Bash(npx *) or Bash(devbox run *) allow arbitrary code, because environment runners are
not stripped the way a timeout prefix is.
Think like the matcher. Not what did I intend to authorise but what string patterns did I actually authorise, and what can be smuggled through them. Where the honest answer is "too much," the fix is one level down (the sandbox) or one level up (domain rules, hooks) — not a cleverer pattern.
Compound commands are split on &&, ; and | and matched independently, which is the right
behaviour — but it means approving one compound command can quietly write up to five separate rules
you did not intend.
The non-delegables
A short list any operator can adopt as-is. These are the things that stay behind an ask or a
deny, permanently, regardless of how confident you get.
Recursive deletes outside the workspace. git push --force. Rewriting history the session did not
create. terraform destroy and its equivalents. Production migrations. The common property is
that being wrong costs more than the task saved.
Reading credential stores beyond what the task's own API genuinely needs. Printing live tokens into
a transcript. Committing or publishing anything sourced from ~/.ssh, cloud credential files, or
session transcripts.
Deploys. DNS and TLS changes. IAM grants. Feature-flag ramps. Anything that writes to a secret manager or creates recurring cost. A one-line change that bills monthly is not a small change.
It is telling that Anthropic's own auto-mode classifier blocks essentially this exact list by default. If you are running without auto mode, you have to reconstruct it yourself as explicit rules — because in default mode these operations are only protected if you actually read the prompt, and see the 93% figure above for how that goes.
Reads are not harmless
The permission table says read-only operations need no approval, and that trains people to think reads are free. They are not.
Exfiltration is a read plus a network write. CVE-2025-55284, a published vendor advisory, needed nothing but reads and allowlisted commands that generate DNS lookups.
And the sandbox — the thing people install because they want containment — reads the whole disk
by default, including ~/.aws/credentials. That is documented, not a bug. "Sandboxed" does not
mean "cannot see your secrets" until you configure the credential deny rules that say so.
The read side of the boundary is configured separately from the write side, and by default it is open.
The boundary has to protect itself
The most under-taught mechanism in the product: protected paths.
The harness will not auto-approve writes to .claude/, .git, .mcp.json, shell rc files or hook
configs. The reason is exact: an agent that can edit its own settings file can grant itself
tomorrow the permission it lacks today.
That is the executable version of a real governance rule — nobody amends the org chart unilaterally — and the harness enforces it mechanically, right up until you bypass it.
--dangerously-skip-permissions inside a container is fine for your host. It is not
containment. Anthropic's own devcontainer documentation warns that a malicious project can still
exfiltrate anything inside the container — including the Claude Code credentials in ~/.claude,
if you mounted your real one in.
Isolation bounds the blast radius. It does not remove the risk if the container holds your tokens and has internet access.
The per-session audit worth thirty seconds
Simon Willison's lethal trifecta: access to untrusted content, access to private data, and the ability to communicate externally. Any two are manageable. All three is the shape that gets people hurt.
The operator move is to ask it per session, not once at setup:
A session reading a cloned open-source repo with gh authenticated has all three. The same
session inside the sandbox, with credential reads denied and a domain allowlist, has mechanically
shortened two of them.
Tutorials teach tools additively — connect everything. Operators learn subtractively. Every added tool and every added directory is a leg-lengthening event, and the boundary has to be re-derived when the toolset changes.
What smart people wrongly believe
What to do this week
Run /permissions and read the output. Every rule, and which file it came from. Most people
find at least one standing delegation they do not remember granting.
Write the non-delegables in as deny rules. Ten minutes, and it is the only part of this that
protects you on a bad day.
Pick one session and do the trifecta audit. Name the three legs out loud. If you have all three, shorten one before you continue.
Then diff your settings file like code, on a schedule. It is your org chart. You would notice if someone quietly amended your signing authority; notice this too.
Rot register
Verified 2026-08-05. Permission modes, flags and sandbox mechanics are the fastest-moving surfaces in this product — the docs annotate behaviour changes at the patch level. If you are reading this more than a quarter after that date, re-check these before relying on them:
| Claim | Re-check at |
|---|---|
| Permission mode names and cycle order | code.claude.com/docs/en/permission-modes |
| Auto mode availability, model floor, denial thresholds | code.claude.com/docs/en/permission-modes |
Auto mode default block list (claude auto-mode defaults prints current) | code.claude.com/docs/en/permission-modes |
| Built-in read-only Bash command set | code.claude.com/docs/en/permissions |
| Protected paths list | code.claude.com/docs/en/permission-modes |
| Sandbox platform support and settings keys | code.claude.com/docs/en/sandboxing |
| Where "don't ask again" persists | code.claude.com/docs/en/permissions |
| The 93% approval and 17% false-negative figures | anthropic.com/engineering/claude-code-auto-mode |
No page about a product that ships weekly should pretend to be timeless. This one tells you where it will rot first.
The argument underneath: generation got cheap, checking did not, and what one person can run is now set by what they can verify.
