先看两组数字
@ericmiao 转述了一份对 GitHub 上约 1.4 万份 AI 编程工具配置的扫描：85% 的 Claude Code 配置一条 deny（禁止）规则都没有。@itsmatthager 给出的拆分是：团队配置里 17.6% 写了 deny 规则，个人配置只有 12.4%，组织名下的仓库也只有 21%。这些是第三方统计，口径不一定完全一致，但结论一样：大多数人没给 Claude 划禁区。
更值得注意的是写了的人。@cgranier 说，一次 Claude Code 更新后，他写的 Write(路径) 形式的 deny 规则（包括挡 .env 的那几条）变成了无效写法，唯一的迹象是扫描日志里的警告。他的总结是：失效的 deny 规则等于放行，所以每次升级后都要重测防护。
官方文档怎么说
Configure permissions 里有一段专门讲这个：Claude Code 检查文件权限时只看 Edit(path) 和 Read(path) 规则。如果你给 Write、NotebookEdit、Glob 或旧的 MultiEdit 写了路径规则，Claude Code 会接受这条规则，但从来不会用它，只在启动时给一个警告。正确写法是用 Edit(docs/) 代替 Write(docs/)，用 Read(...) 代替 Glob(...)。
文档还提到几点相关行为：
Read的 deny 规则会同时拦住同一路径上的 Edit 和 Write（Write 部分需要 v2.1.228 以上），所以挡.env用一条Read(./.env)就够了。- deny 或 ask 规则里的工具名如果对不上任何已知工具，启动时会警告，用来抓拼写错误。
- 带括号的
mcp__规则写在 settings 文件里会被跳过，会出现在启动时的无效设置提示和claude doctor输出里。
自查和重测清单
- 搜一遍旧写法。 在
~/.claude/settings.json和各项目的.claude/settings.json里搜Write(、MultiEdit(、Glob(，改成Edit(或Read(。 - 升级后看警告。 每次升级后，留意启动时的设置警告，并跑一次
claude doctor。 - 用假密钥做金丝雀测试。 在测试项目里放一个内容是假值的
.env，让 Claude 读取它，确认被拒绝，再让它改写这个文件，同样应被拒绝。 - 记住规则的边界。 文档说明 Bash 规则只匹配命令文本，
/bin/rm、sh -c这类变体不会被Bash(rm *)挡住；需要硬边界时要配合沙箱。
小结
deny 规则不是写完就一劳永逸的配置，而是要随版本回归测试的防线。花五分钟做一次金丝雀测试，比事后发现规则早已失效要便宜得多。
如果你想把 Claude Code 放在一台常开、整机独享的新加坡 Mac mini 上长期运行，可以了解 Zumac.Ai，咨询 Telegram @singatao。
