My read-deny rules never reached inside the folder I had allowed

Counting the reach instead of eyeballing it

The problem with reading a config file is that it tells you nothing about how many files it currently covers. .env is listed, so .env is safe. But what about .env.production? What about apps/ios/config/AuthKey_ABC123.p8?

Recalling them one at a time was hopeless, so I wrote a small script that pulls the deny Read rules out of the settings file and applies them to the real tree.

#!/usr/bin/env python3
"""List which files in the working tree are actually reached by the
Read rules in permissions.deny, and report the secret-looking files
that no rule covers."""
import json, re, sys
from pathlib import Path
 
# What "looks like a secret" here. Extend this for your own stack.
SECRET_HINTS = [
    "**/.env*", "**/*.pem", "**/*.p8", "**/*.key", "**/*keystore*",
    "**/*credential*", "**/*token*", "**/*secret*", "**/.dev.vars",
    "**/google-services.json", "**/Keys.plist",
]
 
def read_deny_patterns(settings_path: Path):
    """Extract only the Read(...) rules from permissions.deny"""
    if not settings_path.exists():
        return []
    data = json.loads(settings_path.read_text())
    rules = data.get("permissions", {}).get("deny", [])
    out = []
    for r in rules:
        m = re.fullmatch(r"Read\((.+)\)", r.strip())
        if m:
            out.append(m.group(1).strip())
    return out
 
def expand(root: Path, pattern: str):
    """Drop a leading ./ and glob. If a pattern hits a directory,
    expand its contents recursively as well."""
    pat = pattern[2:] if pattern.startswith("./") else pattern
    hits = set()
    for p in root.glob(pat):
        if p.is_dir():
            hits.update(q for q in p.rglob("*") if q.is_file())
        elif p.is_file():
            hits.add(p)
    return hits
 
def main(root_str=".", settings_str=".claude/settings.json"):
    root = Path(root_str).resolve()
    patterns = read_deny_patterns(root / settings_str)
    if not patterns:
        print(f"No deny Read rules found in {settings_str}")
        return 1
 
    covered = set()
    print("== Files actually reached by deny rules ==")
    for pat in patterns:
        hits = expand(root, pat)
        covered |= hits
        print(f"  {pat}  -> {len(hits)} file(s)")
        for h in sorted(hits)[:3]:
            print(f"      {h.relative_to(root)}")
 
    suspects = set()
    for hint in SECRET_HINTS:
        suspects |= expand(root, hint)
    gap = sorted(suspects - covered)
 
    print("\n== Secret-looking files no deny rule covers ==")
    if not gap:
        print("  none")
    for g in gap:
        print(f"  !! {g.relative_to(root)}")
    # Non-zero exit when anything is uncovered, so CI and hooks can use it
    return 1 if gap else 0
 
if __name__ == "__main__":
    sys.exit(main(*sys.argv[1:]))

Three things matter here.

First, expand() recurses into directories with rglob. A rule like Read(./secrets/**) means both the directory and everything under it. Skip that expansion and your counts come out smaller than reality.

Second, SECRET_HINTS is maintained separately from the deny rules. If you only inspect the rules, all you learn is that the things you wrote down are covered. Defining what you want protected independently, then taking the set difference, is what makes the gap visible.

Third, it exits non-zero when anything is uncovered, so you can call it from a pre-commit hook or a scheduled job.

Two lines of config, eight files walking straight past

Running it against the starting configuration:

== Files actually reached by deny rules ==
  ./.env  -> 1 file(s)
      .env
  ./secrets/**  -> 1 file(s)
      secrets/deploy_token.txt

== Secret-looking files no deny rule covers ==
  !! .env.local
  !! .env.production
  !! apps/android/app/google-services.json
  !! apps/ios/config/AuthKey_ABC123.p8
  !! apps/ios/config/Keys.plist
  !! sites/labs/.dev.vars
  !! sites/labs/.github/tokens.md
  !! tools/backup/.env.bak

Two rules, two files covered. Ten files I wanted covered.

Written out like that it looks obvious, but while staring at the config file all I had was the feeling that .env was handled. The fact that .env.local is a different filename simply did not register. The further apart the day you wrote the rule and the day the file appeared, the wider that gap between feeling and reality gets.

One rename and the pattern stops matching

Before rewriting anything, I noticed something worse.

The pattern **/.env* catches names that begin with .env. It does not catch env.old, which was sitting in the same folder. Checked directly:

**/.env*   -> .env, .env.local, .env.production, tools/backup/.env.bak
**/env*    -> tools/backup/env.old
**/*env*   -> .env, .env.local, .env.production, tools/backup/.env.bak, env.old

Removing a single leading dot moves the file into a different pattern universe.

What made this genuinely uncomfortable is that it was not only a deny-rule problem. My own SECRET_HINTS list missed env.old too. So that "eight files" figure from the first scan may well have been nine. The detection side of the script deserved no more trust than the rules it was auditing, and it took my own tooling to teach me that.

Adding an extension, dropping the leading dot, appending a date — the things people do without thinking when taking a backup are exactly the things that fall outside pattern matching. The awkward part is that you are most likely to trip over this while doing something sensible: taking a copy before swapping configuration is supposed to be good practice.

That last row is the real point. Protecting things by name carries a built-in ceiling: it cannot protect what the name does not reveal.

The rewritten deny list

What I ended up with, after adding rules until the gap hit zero:

{
  "permissions": {
    "deny": [
      "Read(./**/.env)",
      "Read(./**/.env.*)",
      "Read(./**/.dev.vars)",
      "Read(./**/*.p8)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./**/google-services.json)",
      "Read(./**/Keys.plist)",
      "Read(./**/*token*)",
      "Read(./secrets/**)"
    ]
  }
}

Re-running the audit now exits zero with nothing left over.

  ./**/.env       -> 1 file(s)
  ./**/.env.*     -> 3 file(s)
  ./**/.dev.vars  -> 1 file(s)
  ./**/*.p8       -> 1 file(s)
  ./**/*.pem      -> 0 file(s)
  ./**/*.key      -> 0 file(s)
  ./**/google-services.json -> 1 file(s)
  ./**/Keys.plist -> 1 file(s)
  ./**/*token*    -> 2 file(s)
  ./secrets/**    -> 1 file(s)

== Secret-looking files no deny rule covers ==
  none

Notice that ./**/*.pem and ./**/*.key sit there matching zero files, and I kept them anyway.

There are no such files right now. The value of a rule is not the count it matches today; it is that it will fire on its own the day such a file appears. A zero-match rule is not dead weight, it is a reservation.

The corollary matters more: when this script shows you a rule matching nothing, do not read that as permission to delete it. I nearly did. The only time pruning is the right call is when the ruleset has grown large enough that per-turn matching cost becomes the problem — a separate concern I covered in why sessions with stacked permission rules get heavier every turn.

August 2026 changed one of my assumptions

There was an unspoken assumption underneath all of this: that deny rules exist to guard the territory outside what you allowed.

In Claude Code v2.1.236, the handling of wildcard read-deny rules on macOS changed. A rule like **/.env now takes precedence even inside a directory you granted read access to. Matched directories have their contents covered too, and renaming a file to slip around a rule got considerably harder.

Which tells you something about how it worked before: the inside of an allowed directory was the weak spot. That is exactly the territory tools/backup/.env.bak was sitting in when I found it.

Looking at my configuration again after the change, it reads differently. Deny rules are not an exceptional door you close off; they are a locked drawer you keep inside a room you have opened. Given that framing, erring on the side of writing them too finely feels like the right trade to me.

How far deny rules follow you when you add a working root mid-session is a separate question, which I worked through in the boundary audit for directories added later.

Not leaning on deny rules alone

Matching on names alone will never carry the whole load. After the audit, the first changes I made were to the tree, not to the config.

1. Move backups out of the working tree. I dropped the habit of parking old configuration in places like tools/backup/ and now pull values from storage when I need them. This was the single most effective change: no rule required, because the target is simply gone.
2. Pass values through the process, not through files. Build scripts no longer read those files directly; the values arrive as environment variables. If no read happens, no denial is needed.
3. Write rules for whatever is left. Once only the files that genuinely must live in the tree remain, the ruleset shrinks and each line has an obvious reason to exist.

The order is what matters. Thicken the deny list first and you lose all motivation to tidy the tree. Tidy first and the necessary rules narrow down on their own. I had that order backwards for half a year, and the backup file at the top of this article is what it cost me.

Verifying it under unattended runs

For scheduled or background sessions, you need a way to confirm the configuration was loaded at all.

An interactive session can open /permissions and look. An unattended one has nobody watching. I put the audit script at the front of the job and let a non-zero exit stop the work before it starts.

# Audit first; refuse to start the job if anything is uncovered
python3 tools/scan_deny.py . .claude/settings.json || {
  echo "Gaps found in deny rules. Aborting."
  exit 1
}

There is also the case where the settings file itself is malformed and never loads. The script returns 1 when it finds zero rules, so that path stops here too. What Claude Code does when its configuration is broken is covered in the safe-mode behaviour of a broken settings.json.

What to do next

Run the script at the top of whatever tree you are working in right now. It takes a few seconds.

If it reports zero gaps, that is zero gaps as of today. Run it again in three months and something will almost certainly have appeared. When it does, my suggestion is to resist adding a rule first and ask instead why that file is sitting there at all.

Hardening the defence feels productive. Reducing what needs defending pays better over time.