1 in 6 public Claude Code configs contains a permission rule that does nothing
I'll pull the source gist so the paragraphs stick to documented facts only.A public audit by **sfox100** found that **1 in 6** public **Claude Code** configs…
By Dillip Chowdary • Aug 04, 2026 • Source: HN Claude/Codex/Fable
I'll pull the source gist so the paragraphs stick to documented facts only.A public audit by **sfox100** found that **1 in 6** public **Claude Code** configs ships a permission rule that never fires. Across **149** public `.claude/settings.json` files on GitHub (**134** with permission rules, **3,132** rules total), **21 of 134 configs (16%)** held at least one dead path rule — **50** dead rules in all. The finding was published as a gist, reported upstream on **anthropics/claude-code#75315**, and surfaced on Hacker News with **1** point and **0** comments at listing time.
Claude Code file permission checks only consult **Edit(path)** and **Read(path)** rules. Path rules on **Write**, **Glob**, **NotebookEdit**, or the legacy **MultiEdit** are accepted and never matched. A real public pattern like `deny: ["Write($HOME/.ssh)", "Write(**/*.pem)"]` protects nothing; the working form is **Edit($HOME/.ssh)**, which covers the write-family tools. The behaviour is documented in the permissions docs and the **v2.1.210** changelog, and recent versions print a startup warning naming the rule and the fix. Verification was against **Claude Code v2.1.220** (August 2026).
Advertisement
Tech Pulse Daily
Get tomorrow's pulse first
Join engineers who read Tech Pulse before stand-up. Free, weekday mornings.
Of the **50** dead rules, **34** sat next to a working **Edit**/**Read** twin — clutter, not an open hole. The other **16** had no twin, so the intended guardrail was simply not active. **8** of those were **deny** rules aimed at credentials (`.ssh`, `.kube`, `.aws`, `secrets/`, `*.pem`, `*.key`). One config used `deny: Write(rm -rf *)` — a Bash-shaped rule on a file tool that no warning catches. Builders who treat permission config as the real control plane for autonomous agents can believe SSH keys and certificates are write-protected when they are not.
The misconfiguration persists because the warning only reaches a useful place in some surfaces. Interactive CLI keeps it in scrollback. Piped or CI runs (`2>/dev/null`) route it to a debug log by design. The VS Code extension surfaces it only under View → Output → "Claude VSCode", and the CLI **[WARN]** is downgraded to an **[info]** line with no toast or panel banner (checked live on **v2.1.220**). The Agent SDK gives no warning. That stack of choices leaves extension, script, CI, and SDK users with dead credential rules and no signal.
Convert **Write**/**Glob**/**NotebookEdit**/**MultiEdit(path)** rules to **Edit(path)** for the write family and **Read(path)** for Glob. Remember path syntax: a single leading `/` is project-relative, `//` is absolute, `~/` is home. Write-capable **allow** rules into `.git`, `.claude`, `.vscode` and similar are inert because the protected-path check runs first. **sfox100** published **claude-permission-audit** — zero dependencies, exit **1** on findings for CI — which also reports the twin analysis the startup warning does not: which dead rules are clutter and which are unprotected guardrails. Watch whether Anthropics hardens warning delivery outside interactive CLI, and audit any shared or CI-driven Claude Code config that still uses Write-shaped path denies.
Advertisement