Claude Operator: Prompt to Autonomy · 20 min · 150 XP

How a permission decision is actually made

Deny, then ask, then allow — and specificity does not break the tie.

This is the lesson where a wrong assumption costs the most, because a permission rule that doesn't do what you think is worse than no rule: you've stopped watching.

Rules are evaluated in order: deny, then ask, then allow. The first match in that order decides, and rule specificity doesn't change the order.

That last clause is the one that catches people, because almost every other system you know works the other way. CSS, routing tables, .gitignore — the more specific rule usually wins. Here it does not. A broad Bash(aws *) deny blocks aws s3 ls even when you've explicitly allowed Bash(aws s3 ls). An allow rule cannot carve an exception out of a deny rule. The same holds between ask and allow: a matching ask rule prompts even when a more specific allow rule also matches.

Both rules present, one outcome

deny:  Bash(aws *)
allow: Bash(aws s3 ls)

$ aws s3 ls    ──▶ DENIED

Deny is checked first and matches. The narrower allow
rule is never reached.

Settings come from several files, highest precedence first: managed settings, then the command line, then project-local (.claude/settings.local.json), then shared project (.claude/settings.json), then user (~/.claude/settings.json). Two consequences worth holding on to. Managed settings outrank the command line — an organisation policy is not something a flag can argue with. And deny rules are evaluated before allow rules across scopes too, so a user-level deny blocks a project-level allow, and vice versa.

Which makes reading a permission prompt a real skill rather than a formality. The prompt names the tool, the exact arguments and the target. Read the arguments — that's where the difference between the command you expected and a similar one lives. "Allow once" for the specific thing in front of you is almost always the right answer over a blanket allow you'll forget you granted.

Practice. Draw the deny/ask/allow order and check it against the official documentation. Build a table of the settings scopes that apply to you, naming who controls each and who inherits it. Then take a real permission prompt and write your decision based on the actual tool, arguments and target rather than the general shape of the request.

Loading your workspace…