← cc-safe-setup

Does your permissions.deny actually protect your secrets?
A Claude Code deny coverage checker

Bottom line: putting .env or keys in permissions.deny is a note on the front door, not a wall. It does not stop the back doors — cat, less, or a python -c subprocess. Paste your deny rules below and see what is actually covered and what slips through. Everything runs in your browser; nothing is sent anywhere.

"I added Read(.env) to deny but it still got read" is a real report. It is less a bug than a consequence of deny being best-effort, not a hard sandbox. Paste your rules and find the gaps.

Paste your deny rules

Either the permissions.deny block from settings.json, or a plain list of Read(...) rules.

No request is made — processed only in this page

How to read the result

The principle. Truly read-sensitive secrets (production keys, credentials) should be protected by OS permissions and scope, not by deny. Keep them outside the working directory and out of scope. Use deny as one layer of defense in depth — never assume it alone protects a secret.
There is also a free tool to check whether a received repo's .claude/settings.json is dangerous before you trust it.
→ .claude/ config trap scanner
The free hook set that stops irreversible actions before they run is cc-safe-setup.
Basis: deny applies to Read/Grep/Glob and to recognized file-reading Bash commands, but a Bash rule matches the command string, not the file path, and arbitrary subprocesses (python/node) are out of scope (official docs).
cc-safe-setup ・ other safety tools ・ trap scanner