Your Claude Code Read Deny Rule Is a Screen Door — I Built a Tool That Proves It

A recent post by @rulestack stopped me cold: they ran 20 real claude -p sessions against a Read(./.env) deny rule and found 4 of 11 exfiltration routes sailed straight through. I read it, nodded along, and then did the thing I always do — I automated the paranoia.

Meet deny-probe: a stdlib-only Python CLI that penetration-tests your Claude Code permissions.deny rules. Point it at your settings.json, and it predicts — for 12 built-in bypass routes — which ones your rules actually stop and which ones walk right in. Then it tells you exactly which rules to add.

pip install deny-probe
deny-probe audit --settings ~/.claude/settings.json

The core insight: deny rules are enforced per tool

This is the whole ballgame. When you write Read(./.env), Claude Code blocks the Read tool for that path. It says nothing about:

• the Grep tool — search for . and the whole file comes back as "matches"
• Bash — cat, grep -r, sed, awk, head, or the classic python3 -c "print(open('.env').read())"
• CLAUDE.md @import chains — if your CLAUDE.md contains @./.env, then Read(./CLAUDE.md) pulls the denied file into context through a document your rule doesn't cover
• nested CLAUDE.md files, which Claude Code auto-loads

deny-probe's route library encodes 12 of these, each as a concrete (tool, argument) pair. The static analyzer then asks one question per route: is there a deny rule naming this tool whose pattern matches this argument? If yes: HOLD. If no: LEAK.

What a typical audit looks

Here's the output for the config most of us are running — a single Read(./.env) rule:

Target: ./.env
Deny rules (1):
  Read(./.env)

ROUTE             TOOL    VERDICT  BLOCKED BY
----------------------------------------------------------------------
read-direct       Read    HOLD     Read(./.env)
grep-tool         Grep    LEAK     -
glob-tool         Glob    META     -
bash-cat          Bash    LEAK     -
bash-grep         Bash    LEAK     -
bash-sed          Bash    LEAK     -
bash-awk          Bash    LEAK     -
bash-head         Bash    LEAK     -
bash-python       Bash    LEAK     -
bash-perl         Bash    LEAK     -
claude-md-import  Read    LEAK     -
claude-md-nested  Read    LEAK     -

Summary for ./.env: 10/12 routes leak content, 1 hold, 1 metadata-only.

Hardening suggestions:
  [grep-tool] Grep tool search
    + Grep(./.env)
  [bash-python] Bash: python one-liner
    + Bash(python *)
    + Bash(python3 *)
  [claude-md-import] CLAUDE.md @import chain
    + Read(./CLAUDE.md)
    ...

Ten out of twelve. The read-direct row holding feels less like a victory and more like a participation trophy once you see the rest of the table.

The sneaky ones deserve a closer look

Grep tool. This is the one people miss most. Grep(path="./.env", pattern=".") returns every line as a search result. Nothing about it touches the Read tool, so your Read(...) rule never fires. Fix: Grep(./.env).

Python one-liner. You blocked cat, grep, sed? Congratulations, you played whack-a-mole with binaries while the interpreter walked past. python3 -c "print(open('./.env').read())" needs no reader binary at all. Fix: Bash(python *) and Bash(python3 *) — and then think about perl, ruby, node, php…

CLAUDE.md @import. Claude Code expands @-imports when it reads CLAUDE.md. So @./.env sitting in your CLAUDE.md means the deny rule covers the file but not the importing document. The exfiltration route is Read(./CLAUDE.md) — a perfectly innocent-looking call. Fix: Read(./CLAUDE.md), or better, stop importing secrets into your agent context in the first place.

Live mode: trust, but verify with a canary

Static predictions are a model, and models are wrong sometimes. So deny-probe ships a --live mode: it writes a canary marker into a temp file, runs real claude -p sessions asking for the file through one route's method, and checks whether the canary appears in the answer (plus an optional transcript scan — the dual check):

deny-probe live --target ./.env --route bash-cat --runs 3
deny-probe live --target ./.env --all --runs 5 --format json

Live mode is deliberately not part of CI — it's nondeterministic (the model may refuse, paraphrase, or take a different path than prompted) and it shells out to your claude CLI. The test suite (55 tests) covers only the static predictions via fixture assertions. That's the honest split: deterministic claims get automated tests; nondeterministic ones get a manual harness and a warning label.

CI gating

The static audit exits 1 when any route leaks content, 0 otherwise, so it drops straight into a workflow:

- run: deny-probe audit --settings .claude/settings.json --target ./.env

Now a PR that adds a secret file without covering its routes fails loudly instead of silently.

How the matcher works (and where it can be wrong)

Deny rules are Tool(pattern) with glob-ish patterns: * stays within a path segment for file tools, ** crosses segments, ? matches one character. Bash patterns match against the full command line. It's ~60 lines of regex translation — deliberately simple so you can audit the auditor.

But let me be straight about the limits, because a security tool that oversells is worse than no tool:

1. The route library is "known techniques", not "all techniques." New Claude Code versions can add tools, flags, or auto-loading behaviors that open routes I haven't encoded. A clean report means "no known bypass", not "provably safe". Re-run after upgrades.
2. The pattern matching is an approximation of Claude Code's undocumented edge cases (absolute paths, symlinks, ~). A predicted HOLD is only as good as that model.
3. Command-prefix blocklists are fragile by nature. Bash(python *) blocks the prefix; renamed binaries and new interpreters appear constantly. For real secrets, the fix isn't a longer deny list — it's keeping secrets out of the agent's working directory entirely (secret stores, ask-gated hooks).
4. The CLAUDE.md routes have preconditions — they assume the @import or nested file actually exists. deny-probe tells you what would happen given your rules.

Try it

pip install deny-probe
deny-probe audit --settings ~/.claude/settings.json

Repo: https://github.com/hahahahahahahahah6/deny-probe — MIT, stdlib-only, PRs welcome, especially new bypass routes. If you've found a route the library doesn't know about, that's the most valuable contribution you can make: every new route makes everyone's audit stronger.

Go check your Read(./.env) rule. I'll wait. 🙂