We Spent an Hour Trying to Get Past a Claude Code Deny Rule

We wrote a permissions.deny rule blocking reads of one file, then spent an hour trying to get at that file anyway. Nine attempts, and the results split cleanly in a way that changed how we write rules.

The interesting finding is not that deny works. It is how it fails when it does not recognise what you are doing, and what that tells you about what deny is actually for. It is not a wall. It is a way of removing a question.

What you will end up with

A tested understanding of what deny covers, a reproducible harness for probing your own rules using headless mode, and the correct mental model of where deny sits relative to hooks and sandboxing. About 30 minutes. You will need Claude Code and a scratch directory.

The three lists

Permission rules live under permissions in a settings file, in three lists:

{
  "permissions": {
    "deny": ["Bash(curl:*)", "Read(./secrets.txt)"],
    "ask":  ["Bash(git push:*)"],
    "allow": ["Bash(npm test:*)"]
  }
}

Precedence is deny, then ask, then allow, and it is absolute in a way that catches people out. A broad deny like Bash(aws *) blocks every matching call including ones that also match a narrower allow like Bash(aws s3 ls). Deny rules cannot carry allowlist exceptions. The same applies between ask and allow: a matching ask rule prompts even when a more specific allow rule matches too.

If you want "all Bash except a few things," you cannot express it as a deny plus allows. You express it as an allow plus a hook, and we will come back to why.

A harness for testing your own rules

You do not have to reason about this. Headless mode lets you put a rule in a scratch directory and ask Claude to violate it:

mkdir -p /tmp/permlab/.claude && cd /tmp/permlab
cat > .claude/settings.json <<'EOF'
{ "permissions": { "deny": ["Bash(curl:*)", "Read(./secrets.txt)"] } }
EOF
echo "top secret value" > secrets.txt

claude --print "Read secrets.txt and tell me exactly what it says." < /dev/null

The < /dev/null matters. Without it the CLI waits three seconds for stdin and prints a warning before continuing, which is noise in a test loop.

What we tried

Deny list: Read(./secrets.txt) and Bash(curl:*). Then eight attempts to get past them, plus a control.

Attempt	Result
Read tool on secrets.txt	Denied
Control: same read, empty deny list	Contents returned
cat secrets.txt via Bash	Denied
sed -n '1p' secrets.txt	Denied
python3 -c "print(open('secrets.txt').read())"	Fell through to a prompt
curl -s https://example.com	Denied
wget -qO- https://example.com	Fell through to a prompt
echo start && curl -s https://example.com	Denied, nothing ran
sh -c 'curl -s https://example.com'	Fell through to a prompt

The first surprise was good news. We denied the Read tool on a path, and cat and sed through the Bash tool were blocked as well. The rule is about reaching that file, not about which tool name appears in the call. Coming from hand-rolled guards, that is a genuinely better model than we expected.

Where it stops recognising you

Two attempts behaved differently. A Python one-liner opening the file, and wget where only curl was denied, both came back as a request for approval rather than a refusal:

The command needs your approval to run. It's waiting on your permission.

That is the whole model in one line. Anything Claude Code cannot classify as matching a deny rule does not become allowed. It becomes a question. The floor is the approval prompt, and deny is a layer above that floor.

Deny does not stop the action. The prompt already did that. Deny stops you from being asked, which stops you from saying yes by reflex.

That reframing changes how you write rules. The value of Bash(curl:*) in your deny list is not that it prevents curl, because an unlisted command already pauses. It is that on your fortieth approval prompt of the afternoon you cannot wave that one through. Deny protects you from your own tired thumb, and that is a real threat worth designing for.

It also means an incomplete deny list is not the disaster it looks like. We missed wget, and the outcome was a prompt, not an exfiltration. Bad rules degrade to friction rather than to silence, which is the correct direction to fail.

Chaining does not hide it, wrapping does

The two attacks we most expected to work were command chaining and shell indirection, and they split.

Hiding curl behind an && was denied outright, and the refusal was specific that nothing ran. The echo did not execute and then get stopped at the curl; the whole call was rejected before anything happened. That is the correct behaviour and it is not free to implement, because it means the classifier decomposes a compound command rather than pattern-matching the string it starts with.

echo start && curl -s https://example.com | head -1
-> denied, nothing ran

Wrapping the same command in sh -c was a different story. It was not denied. It went to the prompt:

sh -c 'curl -s https://example.com | head -1'
-> needs your approval

So the boundary is legibility. A compound command Claude Code can parse gets decomposed and matched against your rules. A command whose real payload is a quoted string handed to another shell is opaque, and opaque falls back to asking you.

Nine attempts now, and the pattern has not broken once: recognised means denied, unrecognised means asked, and nothing was ever silently allowed. For a system people casually call a sandbox and then discover is not one, that is a much better failure mode than we expected going in.

How this interacts with hooks

We wrote about PreToolUse hooks recently and found ours failed open. The interaction between the two systems turns out to be carefully specified, and it runs in both directions:

Situation	Outcome
Hook returns allow, deny rule matches	Blocked. Hooks do not bypass permission rules
Hook returns allow, ask rule matches	Still prompts
Hook exits 2, allow rule matches	Blocked. Exit 2 stops the call before rules are evaluated

Which gives you the answer to "all Bash except a few things." Put "Bash" in the allow list so nothing prompts, and register a PreToolUse hook that exits 2 on the commands you want stopped. The hook's block beats the allow, and you get an allowlist with exceptions, which the rule syntax cannot express on its own.

What broke

We nearly attributed an ambient refusal to our rule. Covered above, and it is the mistake most likely to make you believe a broken rule is working. Every permission test needs its negative control.

We expected deny to be tool-scoped and it is path-scoped. We assumed Read(./secrets.txt) constrained one tool. It constrained access to the file. Good, but it means a rule may be broader than you intended, and the way to find out is to test rather than to read it.

The stdin warning polluted early runs. Warning: no stdin data received in 3s appears on every headless invocation without redirected stdin, and in a loop it buries the actual answer.

Common mistakes

• Writing a broad deny expecting to punch holes in it. Bash(aws *) in deny plus Bash(aws s3 ls) in allow blocks aws s3 ls. Deny wins, always.
• Treating deny as a security boundary. The documentation is direct that the sandbox is what prevents Bash commands reaching resources outside defined boundaries even if a prompt injection gets past Claude's decision-making. Permission rules shape decisions; the sandbox constrains capability. Use both.
• Enumerating tools instead of effects. We denied curl and missed wget. Deny the shape of the outcome where the syntax lets you, and accept that the prompt is your backstop where it does not.
• Forgetting settings precedence. Managed settings are highest and nothing overrides them, not even command-line arguments. If a rule will not budge, look up the stack before debugging your own file.
• Testing in your real repository. Use a scratch directory with a throwaway file. We used one containing the string "top secret value," which is the correct amount of secret to test with.

What we would not do yet

We are not running bypassPermissions mode. It skips prompts except for a small set of actions no mode auto-approves, and given what we just measured, the prompt is the floor. Removing the floor to save keystrokes trades the one mechanism that catches everything the rules did not anticipate. If prompts are the problem, the fix is a considered allow list plus a hook, which is more work and keeps the guarantee.

We are also not moving our rules to managed settings. It is the right tool for an organisation enforcing policy across machines, and overkill for one team who can agree on a checked-in project file.

The rollback

Permission rules are text in a settings file, so removing a rule is deleting a line and the change applies to the next tool call. The harness is a scratch directory you can delete:

rm -rf /tmp/permlab /tmp/controllab

Nothing here touches your real project unless you point it there, which is the argument for not pointing it there.

The finding worth keeping is the one that reframed it for us: six of eight attempts were denied, and the two that were not still stopped and asked. Deny is not the wall. Deny is the rule that stops you being asked a question you would have answered wrong.