Safeguard
Developer Tools•

Claude Code permission rules: deny, ask, allow and which wins

Claude Code checks deny first, then ask, then allow, and the first match wins. Why a narrow allow cannot carve out a broad deny, and where rules fall short.

Safeguard Security Team
3 min read

Claude Code evaluates permission rules in a fixed order: deny, then ask, then allow. The first match decides the outcome, and specificity does not change that order. So a broad deny rule beats a narrower allow rule, and a matching ask rule still prompts even when a more specific allow exists.

The order in practice

Anthropic's permissions documentation gives a direct example. A deny rule such as Bash(aws *) blocks every matching call, including calls that also match a narrower allow rule like Bash(aws s3 ls). An allow rule cannot carve an exception out of a deny rule.

That surprises people who expect "most specific rule wins" as in many firewalls. If you want to allow one command and block the rest of a family, write the allow list for the commands you want and do not add a broad deny.

Naming a tool versus scoping a pattern

A bare tool name in a deny rule, such as Bash, removes the tool from Claude's context entirely, so Claude never sees it. A scoped rule, such as one for a command prefix, leaves the tool available and blocks only matching calls. Deny and ask rules also accept glob patterns in the tool name position, and a pattern for all MCP tools can switch off that whole class.

Compound commands

Rules are applied per subcommand. The docs say deny and ask rules apply when any subcommand matches, including one nested in a subshell, a command substitution or a loop body. An ask rule for git clean still prompts for cd /tmp && git clean -f. A deny rule also matches past a leading environment variable assignment, so a deny on rm still catches an assignment followed by rm.

The honest limit of Bash rules

The documentation is clear that a Bash rule matches the command text Claude writes. It does not match the same program invoked in a different form, so a deny or ask rule is not a security boundary around the program. For network restrictions that must hold, the docs recommend pairing deny rules with the sandbox network allowlist.

Two other points from the page:

  • The allow side is the risky one. Use narrow prefixes and keep the space before the wildcard, since a pattern without the space also matches longer command names.
  • Share approved rules through version control, and review changes to .claude/settings.json like code.

A starter set

A reasonable team baseline is read-only commands allowed, destructive and network commands asked or denied, and sensitive files denied for reads. The next post in this series covers blocking reads of secret files.

Checking what is in force

Run /permissions to audit the rules in your session. Anthropic's security page also recommends doing this regularly for sensitive repositories.

Quick check

If I deny Bash(aws *) and allow Bash(aws s3 ls), what happens to aws s3 ls?

It is denied. Deny is evaluated first and the first match decides.

Is a deny rule enough to stop a program from running?

Not on its own. It matches the command as written. Use the sandbox for enforcement that does not depend on command text.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.