测试在说什么
@ClaudeCodeRev 做了一组对照：针对 force-push 和 推到 main 的 22 种命令变体（换写法、加参数、绕过常见字符串匹配），Claude Code 的 deny 规则只硬拦住其中 7 种；而同一场景下，一条 PreToolUse hook 拦住了 全部 22 种，同时仍放行普通功能分支上的正常 git push。
数字来自该帖的实验分享，不是 Anthropic 官方基准；但对「我只在 settings 里写了几条 Bash deny」的人，已经够说明问题。
为什么 deny 容易漏
权限规则通常按工具名 + 模式匹配。换一种等价写法（不同 flag、通过脚本封装、先改远程再推），字符串规则就对不上。官方也反复强调：hooks 跑在模型外面，是「到点就执行」的闸门，不是再给模型看一遍的提示词（见 Hooks）。
另外，文件类路径 deny 还有「写法被接受但不生效」的坑（见Write 路径 deny 失效）。推送、删库、生产部署这类高风险动作，更适合用 hook 做明确 allow / deny，而不是只堆 deny 字符串。
可以怎么落地
- 对
git push --force、git push origin main（以及你们仓库真正的默认分支名）写 PreToolUse 命令 hook：匹配到就 deny，并打印清晰原因。 - 用你们日常会用的变体做一次金丝雀（换 flag、换 remote 名），确认 hook 仍拦、普通功能分支仍通。
- hook 自身要失败即拦（fail closed），避免脚本缺依赖时静默放行（见hook 崩溃仍放行）。
- 定期打开
/permissions看 Recently denied，确认拦到的是你以为的那条命令。
小结
- deny 规则有用，但挡不住「同义改写」的力推。
- 关键保护的写操作，用 PreToolUse（或同等闸门）补一层。
- 测过再上无人值守，别只凭「我写过 deny」心安。
如果你想在一台常开、整机独享的新加坡 Mac mini 上固定 Claude Code 的 hooks 与仓库权限策略，可以了解 Zumac.Ai，咨询 Telegram @singatao。
