Home / Blog / 1 in 6 public Claude Code configs contains a permission…
Tech News

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

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 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

🔎 More interesting news

5-min tech signal

Weekday briefing for engineers who skip the noise.

No spam · Unsubscribe anytime

Advertisement

✈️ CareerPilot

Your AI job-search copilot

Match your resume against live Ashby, Greenhouse & Lever openings — fit scores, job-specific resume optimization and email alerts.

Find matching jobs →

Free Tools

Browse all tools →