别让 Claude Code 误删代码：这 5 层安全护栏必须配好

Claude Code 一旦拿到文件修改、命令执行和 Git 操作权限，效率会大幅提升，风险也会同步放大。一条错误的 rm、一次误触发的数据库重置，或一次绕过检查的强制推送，都可能造成难以挽回的损失。

只靠提示词告诉它“不要执行危险操作”远远不够。真正可靠的方案，需要从执行环境、原生权限、动态 Hook、工程规则到远程仓库，建立一套层层兜底的安全机制。

本文将拆解 Claude Code 的 5 层安全护栏，并给出可直接落地的 deny、ask、allow 配置与命令分级清单，让 Agent 在安全边界内尽可能自主执行。

三层硬防线（沙箱 → 权限规则 → PreToolUse Hook），加两层软护栏（工程规则 → 远程门禁），以下从强到弱排列。

第一层：OS 沙箱与凭据隔离

最底层。限制文件系统、网络、密钥和执行环境。Claude Code 原生支持 sandbox.filesystem，作用于所有子进程（kubectl、terraform、npm 等），不是只拦 Claude 自己的工具调用。

这层搞定了，后面几层才有意义。

第二层：原生权限规则 — deny / ask / allow

最可靠的命令控制层。Claude Code 原生权限系统，匹配顺序是 deny → ask → allow。

直接封死（deny）

需要确认（ask）

直接放行（allow）

原生权限是真正的硬边界，优先于 Hook。Hook 适合需要动态上下文判断的策略，不适合当唯一防线。

第三层：PreToolUse Hook — 动态策略

原生权限处理「固定规则」，Hook 处理「要看上下文才知道」的判断——比如当前分支、目标 ref、命令参数组合。

脚本（共用核心）

关键修正：matcher 必须覆盖 Bash|Read|Edit|Write，只匹配 Bash 拦不住文件工具。

固定字符串匹配容易被绕过（rm -r -f /、git push -f、bash -c ‘…’ 等）。Hook 是策略辅助，不是安全沙箱。强约束放原生 deny。

Claude Code 配置 — .claude/settings.json

Claude Code 的 PreToolUse 支持通过 JSON 返回 permissionDecision: “allow” | “deny” | “ask”。exit code 2 等效 deny。ask 会弹出确认框。

Codex 配置 — .codex/hooks.json

Codex 的 PreToolUse 支持通过 JSON 返回：

也兼容旧格式 {“decision”: “block”, “reason”: “…”}。exit code 2 同样生效。但 permissionDecision: “ask” 当前尚不支持——返回后会标记 Hook 失败并继续执行。

Hooks配置参考文章

Vince 聊开发@vincemask·May 13 Article从 0 开始：用 Hooks 打造自动化 Claude Code 工作流你让 Claude Code 写功能、补测试、格式化文件，最后顺手提交。 它功能写了，测试也补了大半，格式化跑了两个文件，但偏偏漏了一个。然后它很自然地告诉你：“搞完了。” 你一看：没提交，格式也没完全对齐。…1882370134K

第四层：工程规则 — CLAUDE.md / .claude/rules/

权限防灾难，规则防技术债。

.claude/rules/ 下每条一句：

示例：

• 禁止内联 Validation Schema，统一放 types/ 目录

• 禁止跨 domain 建依赖

• 认证逻辑只读，不准重新设计

• 写新函数前先搜 shared packages

• 保护 .husky/ 和相关配置文件，不准改

可参考文章

Vince 聊开发@vincemask·May 19 ArticleClaude Code 工程化指南：高效组织 .claude/ 目录为什么结构很重要？ 大多数 Claude Code 用户知道 .claude/ 文件夹的存在，但很少有人认真思考它的组织方式。项目小的时候，一个…86122530K

第五层：远程门禁 — CI + 分支保护

本地 Hook 和 Agent 护栏只是第一道防线。下面这些才是最终控制点。

Husky（本地质量门禁，可绕过）

Husky 可以通过以下方式绕过：git commit –no-verify、git push –no-verify、HUSKY=0 git commit、git -c core.hooksPath=/dev/null commit。

所以必须配合：

• 原生权限封禁 –no-verify 参数

• 远程 CI 重新跑 lint + test

• 分支保护要求 CI 必须通过

远程仓库策略（不可绕过）

GitHub/GitLab branch protection:

• 禁止 force push
• 要求 PR review
• 要求 CI status checks 通过
• 禁止直接 push main

「feature 分支可以 push，main 不行」这条策略，靠的是远程分支保护规则，不是本地 Agent 配置。

命令风险分级速查

git add 修改 index、git checkout -b 创建分支、gh pr create 创建远程 PR——都不是只读操作，不能放进无脑放行清单。

双工具适配：Claude Code + Codex 共用

Bash 命令检测的核心脚本可以复用。两边 PreToolUse Command Hook 都从 stdin 收 JSON，exit code 2 都能阻止调用。

落地建议

Deny List 和 Allow List 保持一致，但分别维护薄适配层。不要假设两边所有 Hook 事件和决策字段长期保持完全兼容。

怎么起步

• 先配原生 permissions.deny，覆盖最危险的操作

• 加 permissions.ask，覆盖需要确认的远程副作用操作

• 加 permissions.allow，放行只读和本地可逆操作

• 用 PreToolUse Hook 补动态判断（分支检测、参数组合等）

• 工程规则放 CLAUDE.md / rules

• 远程 CI 和分支保护做最终兜底

如果这篇对你有帮助：1、先收藏。2、更多Claude code实践。关注@vincemask

如果这篇对你有帮助：

1、先收藏。

2、更多Claude code实践。关注@vincemask

更多文章推荐阅读

• Claude Code 高阶用法：10 个插件搭起完整开发工作流

• 如何用 5 个工具 + 自定义 Hooks 把 Claude Code Token 消耗砍掉 90%+

• Antigravity CLI 入门指南：从安装到第一次运行

• claude-code-setup 插件实战指南：让 Claude Code 真正读懂你的项目

• Claude Code 工程化指南：高效组织 .claude/ 目录

• Claude Code 斜杠命令全解：14 条实用指南

• 从 0 开始：用 Hooks 打造自动化 Claude Code 工作流

• 写好 CLAUDE.md 的 8 条经验：让 Claude Code 更懂你的项目

• Claude Code 项目的 MEMORY.md 使用指南