Claude Code：acceptEdits模式会自动批准rm、rmdir、mv这类文件系统Bash命令，而默认分类器不会审查针对rm -rf /或rm -rf ~这类关键路径的删除，在“省掉权限弹窗”和“防止一次误删毁掉半天工作”之间，权限模式到底该怎么选？

1. 问题的提出：一次自动批准可能意味着什么

设想一个并不罕见的场景：开发者让 Claude Code 帮忙"清理一下项目里不再使用的构建产物和临时目录"。代理理解任务后，生成了一条 rm -rf ./dist ./tmp，在 acceptEdits 模式下，这条命令不需要人工确认即被执行。如果路径拼写正确，一切正常；但如果代理在推理中把相对路径算错，或者把变量展开成了 $HOME，后果就不再是"清理构建产物"，而是"清空用户目录"。更极端的情形是 rm -rf /——在多数现代系统上它会因权限与保护机制失败，但在容器内以 root 运行、或挂载了宿主目录的开发环境中，它并非总是安全的。

这里的关键矛盾并不在于"代理是否可能犯错"——任何自动化系统都会犯错——而在于错误的代价是否与放行决策的粒度匹配。acceptEdits 的设计初衷是降低交互摩擦：让文件编辑、读取、常规命令不再逐条弹窗，从而把人的注意力留给真正需要判断的环节。这个目标本身是合理的。问题出在分类器对"哪些命令属于低风险"的界定上：把 rm、rmdir、mv 当作"普通文件系统操作"自动批准，等于把不可逆破坏与可逆编辑放进了同一个信任桶。

本文的核心判断是：权限模式的选型不应以"弹窗数量"为优化目标，而应以"单次误操作的期望损失"为约束条件。acceptEdits 不是不能用，而是必须配合确定性的关键路径保护与可回滚环境，才能把期望损失压到可接受区间。

为了把讨论落到可验证的层面，本文先还原 Claude Code 权限系统的基本结构，再分析 acceptEdits 的判定逻辑为何会在关键路径上失效，随后提出一个可操作的二维风险模型，并给出三套互补的工程方案。全文的分析主线是：破坏半径（blast radius）与可逆性（reversibility）共同决定一条命令应获得的信任等级，而模型分类器只能作为辅助信号，不能作为关键路径删除的唯一闸门。

2. 背景：AI 编码代理的权限模型演进

2.1 从"补全"到"代理"：权限问题的诞生

早期的代码补全工具（如 GitHub Copilot 的初代形态）只输出文本，是否采纳由人决定，工具本身不执行任何副作用操作，因此几乎不存在权限问题。当工具演进为"代理"（agent）——能够读写文件、执行命令、调用外部服务——权限就成为核心工程问题。这一转变在学术界被概括为"从语言模型到语言代理"的能力跃迁，随之而来的是副作用管理问题（Wang 等，2023；Xi 等，2023 的代理综述）。

本文评述：代理能力的本质变化不是"更聪明"，而是"能动手"。能动手意味着错误不再停留在建议层面，而会转化为文件系统、网络、云资源上的真实状态变更。因此代理安全的第一性问题不是"模型会不会说错"，而是"说错之后能不能撤销"。这一视角直接支撑了后文的可逆性维度。

2.2 业界主流权限范式

目前主流的代理权限范式大致可归为四类，它们在"自动化程度"与"安全边界"之间做了不同取舍：

Claude Code 同时提供上述多种机制：默认的逐条确认、settings.json 中的 allow/deny 规则、acceptEdits 模式、以及通过钩子（hooks）实现的自定义拦截。理解这些机制的组合方式，是选型的前提。

2.3 最小权限原则在代理场景的再表述

最小权限原则（Principle of Least Privilege, PoLP）由 Saltzer 与 Schroeder 在 1975 年的经典论文中系统提出，原意是"每个程序与用户应仅获得完成其任务所必需的最小权限"。在 AI 代理场景下，这条原则需要一次再表述：权限不仅应按"主体"授予，还应按"操作类型 × 目标对象 × 可逆性"动态收窄。因为代理的"任务"是自然语言描述的、边界模糊的，静态的全局权限无法匹配其动态行为。

本文评述：PoLP 的原始语境是操作系统与多用户系统，其威胁模型是"恶意或出错的主体"。代理场景的威胁模型更接近"善意但可能误判的主体"——它没有恶意，但会在语义模糊处做出高破坏性决策。因此单纯缩小权限集合不够，还需要在执行时刻根据具体命令参数做二次判定，这正是后文钩子方案的理论依据。

3. acceptEdits 的判定逻辑与失效机理

3.1 模式定位：它到底批准了什么

acceptEdits 的定位是"自动接受文件编辑类操作"。在 Claude Code 的工具抽象中，文件编辑（Edit、Write）与 Bash 命令是两类不同的工具。acceptEdits 的语义边界本应聚焦于前者，但由于 Bash 命令在工程实践中承担了大量文件操作（rm、mv、cp、mkdir），分类器在判定时会把一部分"看起来像常规文件操作"的 Bash 命令也纳入自动批准。

从公开的配置文档与社区讨论看，acceptEdits 依赖一个基于规则与模型判断的混合分类器：它对命令做词法/语法层面的解析，识别命令名与参数，再结合上下文判断风险等级。问题在于，这种判定是逐命令的、局部的，它评估的是"这条命令看起来危不危险"，而不是"这条命令在当前工作目录、当前用户、当前挂载下会造成多大破坏"。

3.2 失效的三个层次

笔者认为，acceptEdits 在关键路径删除上的失效可以拆成三个层次，分别对应不同的技术根因：

层次一：命令名与风险的非单调映射

rm 这个命令名本身携带的风险信息极少。真正决定破坏力的是参数：rm file.txt 与 rm -rf / 在命令名上完全一致，风险却相差若干个数量级。分类器若以命令名为主要特征，就必然在参数维度上失明。这是特征选择导致的系统性盲区，不是调参能解决的。

层次二：路径语义的上下文依赖

rm -rf ./build 在项目根目录下是常规清理，在 / 目录下执行则是灾难。同一条命令字符串，破坏力取决于当前工作目录（CWD）、符号链接解析结果、挂载点。分类器若只看命令字符串而不解析真实路径，就无法区分这两种情形。更隐蔽的是 ~、$HOME、$(pwd) 等需要展开才能确定目标的写法。

层次三：命令组合与间接执行

Bash 允许 ;、&&、管道、命令替换、xargs、find -exec 等大量组合手段。一条被判定为"低风险"的命令，可能通过管道把危险参数传递给另一条命令；find . -name "*.tmp" -delete 表面上不含 rm，实际却在删除文件。分类器若只做浅层词法匹配，这类间接执行就是天然的绕过通道。

三个层次共同指向一个结论：基于命令字符串的风险分类，在原理上无法可靠覆盖关键路径删除。这不是实现质量问题，而是信息不足问题——分类器缺少 CWD、挂载、符号链接、参数展开结果等执行期信息。

3.3 一个形式化的失效描述

设命令字符串为 c，执行环境为 e（含 CWD、用户、挂载、环境变量），真实破坏集合为 D(c, e)。分类器 f 的输入只有 c（或部分上下文），输出风险等级 r = f(c)。当存在 e₁ ≠ e₂ 使得 D(c, e₁) 极小而 D(c, e₂) 极大，但 f(c) 相同，则分类器在该命令上必然误判。关键路径删除正是这类命令的典型：破坏力完全由 e 决定，而 f 看不到 e。

本文评述：这个形式化并非为了学术化，而是为了指出修复方向——要么让 f 获得 e（在钩子中解析真实路径），要么把判定从"概率分类"改为"确定性规则"（黑名单路径）。两者都不依赖模型能力，因此更可靠。

4. 分析主线：破坏半径 × 可逆性二维模型

4.1 两个维度的定义

为了让权限决策可比较、可配置，本文提出一个二维模型。它不是全新的理论，而是把安全工程中已有的"影响范围"与"恢复成本"概念，针对代理场景做了操作化定义：

破坏半径（Blast Radius，记作 B）：一次操作可能影响的对象范围与关键程度。可操作化为三个子项——受影响文件数量级、是否触及系统/用户关键目录、是否跨出项目工作区。B 越大，越需要人工确认。

可逆性（Reversibility，记作 R）：操作后恢复到原状态的成本。可操作化为——是否有版本控制覆盖、是否有快照/备份、是否可通过简单命令撤销。R 越低（越不可逆），越需要人工确认。

两者组合形成四象限。本文建议的默认策略是：只有"低 B × 高 R"象限允许自动批准；其余三象限至少需要规则拦截或人工确认。

4.2 为什么这个模型能指导选型

acceptEdits 的问题，用这个模型一句话就能说清：它把"高 B × 低 R"象限的 rm/mv 操作，错误地归入了"低 B × 高 R"的自动批准桶。而修复思路也随之明确——不是关掉 acceptEdits（那会牺牲效率），而是把误分类的那部分操作重新拉回正确象限，用确定性规则处理。

本文评述：这个二维模型的价值在于它把"要不要弹窗"这个模糊问题，转化为两个可测量的量。B 可以通过路径解析与目录统计估算，R 可以通过检查是否在 git 仓库、是否有快照来判断。两者都不依赖模型，因此可以写成确定性代码，作为分类器之外的独立闸门。这与安全工程中"纵深防御"（defense in depth）的思想一致——不指望单一机制完美，而是让多个独立机制互为补充。

4.3 期望损失框架

可以把权限决策写成期望损失最小化问题。设自动批准的概率为 p（由分类器给出），单次误批准的损失为 L，单次人工确认的成本为 C。则自动批准的期望成本约为 p·L，人工确认的成本为 C。当 p·L > C 时，应当选择人工确认。

对关键路径删除，L 极大（可能是数天工作量、不可恢复的数据），即使 p 很小，p·L 仍可能远超 C。这就是为什么关键路径必须拦截——不是因为模型经常错，而是因为错一次的代价太高，任何非零概率都不可接受。这个论证不依赖对模型准确率的假设，因此更稳健。

5. 关键路径删除为何最难防：语义与统计的双重盲区

5.1 语义盲区：自然语言任务的模糊性

用户说"清理一下"，代理需要推断清理范围。这个推断过程涉及对项目结构、构建配置、版本控制状态的理解，任何一步出错都可能导致范围扩大。"清理构建产物"与"清理整个目录"在自然语言层面只差几个字，在执行层面却是天壤之别。这是任务语义的固有模糊性，不是模型能力不足。

本文评述：既然语义模糊无法根除，就不能指望"让模型更谨慎"来解决问题。可行的方向是让破坏性操作默认不可逆性可见——例如在执行前打印将被删除的文件清单与总大小，让用户或钩子有机会介入。这与数据库领域"先 SELECT 再 DELETE"的工程惯例同源。

5.2 统计盲区：长尾命令的分布问题

分类器若基于统计学习，其性能依赖于训练分布。而危险命令恰恰是长尾：rm -rf / 在正常开发中极少出现，因此在训练数据中占比极低，模型对它的"风险感知"可能反而不如常见命令稳定。这是分布偏移与长尾问题在安全场景的体现。

学术界对长尾与分布外（OOD）检测已有大量研究（如 Hendrycks 与 Gimpel 的基线工作，以及后续的 OOD 检测综述）。但笔者认为，把安全关键判定寄托在统计模型上本身就是错配：安全规则需要的是可证明的覆盖，而统计模型只能提供经验性的概率。前者适合黑名单路径，后者适合辅助排序。

5.3 一个可操作的判定清单

综合上述分析，本文给出一份可直接用于钩子实现的关键路径判定清单。它的设计原则是"宁可误拦，不可漏放"，因为误拦的成本只是多一次确认：

• 目标路径解析后等于 /、~、$HOME、/etc、/usr、/var 或其父级；
• 目标路径是项目工作区之外的绝对路径；
• 命令包含 -rf、-r 且目标为目录；
• 命令通过 find -delete、xargs rm、命令替换等方式间接删除；
• 命令涉及 mv 覆盖已存在文件，且目标在版本控制之外。

6. 工程路径一：分层权限矩阵与 settings.json 配置

6.1 分层设计原则

Claude Code 的权限配置支持 allow、deny、ask 等规则，可按工具与命令模式匹配。合理的做法不是"全开"或"全关"，而是按第 4 节的象限分层：

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Read",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm run lint:*)",
      "Bash(npm test:*)"
    ],
    "ask": [
      "Bash(rm:*)",
      "Bash(rmdir:*)",
      "Bash(mv:*)",
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf /:*)",
      "Bash(rm -rf ~:*)",
      "Bash(rm -rf $HOME:*)",
      "Bash(:(){ :|:& };:)"
    ]
  }
}

这段配置的要点在于：把 rm、rmdir、mv 放进 ask 而非 allow，即使用 acceptEdits 也强制确认；同时对最危险的几条命令直接 deny。注意 deny 的匹配是字符串模式，无法覆盖所有变体，因此它只是第一道防线，真正的兜底在钩子。

本文评述：allow/deny 规则的局限在于它是静态字符串匹配，无法处理路径展开、命令组合、间接执行。因此它适合做"已知危险命令"的黑名单，不适合做"未知危险命令"的通用防护。把静态规则与动态钩子结合，才是完整方案。

6.2 项目级与用户级配置的分工

Claude Code 支持项目级与用户级配置。建议的分工是：用户级配置放"个人偏好"（如允许某些只读命令），项目级配置放"团队安全基线"（如禁止 rm 自动批准）。项目级配置随仓库分发，能保证团队成员获得一致的保护，也便于在代码评审中审查权限变更。

这一点在团队协作中尤其重要：如果权限只存在于个人机器，那么新成员、CI 环境、临时容器就处于"裸奔"状态。把安全基线纳入版本控制，本质上是把权限配置当作基础设施即代码来管理。

7. 工程路径二：PreToolUse 钩子与确定性规则兜底

7.1 钩子的作用点

Claude Code 提供 PreToolUse 钩子，允许在工具执行前运行自定义脚本，并根据脚本输出决定放行、阻止或要求确认。这是实现"确定性规则兜底"的关键机制：钩子脚本可以用任意语言编写，能访问完整的命令参数与环境信息，因此可以弥补分类器的信息不足。

钩子的设计要点是：对 Bash 工具做命令解析，提取命令名与参数，解析真实路径，再套用第 5.3 节的判定清单。若命中关键路径，返回阻止或要求确认；否则放行。整个过程不调用模型，因此结果确定、可审计。

7.2 一个可落地的钩子脚本骨架

下面是一个 Python 钩子骨架，演示如何解析命令并拦截关键路径删除。它刻意保持简单，便于读者按需扩展：

import json, os, re, sys

DANGER_ROOTS = {"/", os.path.expanduser("~"), "/etc", "/usr", "/var", "/bin", "/sbin"}

def normalize(p):
    # 展开 ~ 与环境变量，再取绝对路径
    p = os.path.expandvars(os.path.expanduser(p))
    return os.path.realpath(p)

def is_dangerous(cmd):
    # 仅处理删除/移动类命令
    if not re.search(r'\b(rm|rmdir|mv)\b', cmd):
        return False
    # 提取明显的关键路径参数
    for token in cmd.split():
        if token.startswith("-"):
            continue
        target = normalize(token)
        for root in DANGER_ROOTS:
            if target == root or target.startswith(root + os.sep):
                return True
    return False

def main():
    payload = json.load(sys.stdin)
    cmd = payload.get("tool_input", {}).get("command", "")
    if is_dangerous(cmd):
        # 返回非零退出码即阻止执行
        print(json.dumps({"decision": "block",
                          "reason": "关键路径删除需人工确认"}))
        sys.exit(2)
    sys.exit(0)

if __name__ == "__main__":
    main()

这个骨架的局限也要说清楚：它用简单的 split() 分词，无法正确处理带空格的路径、引号、命令替换、管道。生产环境应使用真正的 shell 解析器（如 bashlex、tree-sitter-bash）构建 AST，再遍历节点提取命令与参数。本文评述：钩子的价值不在于它多完美，而在于它独立于模型——即使模型完全失控，钩子仍能拦截已知的危险模式。这是纵深防御的核心。

7.3 钩子与分类器的职责划分

一个常见的误区是让钩子承担所有判定，导致钩子逻辑复杂、维护困难。更合理的划分是：分类器负责"宽泛的、经验性的"风险排序，钩子负责"窄的、确定性的"关键路径拦截。分类器可以放行大部分常规操作，钩子只在少数高危模式上介入。这样既保留了效率，又守住了底线。

8. 工程路径三：沙箱、快照与可回滚执行环境

8.1 沙箱：把破坏半径限制在容器内

如果代理在容器内运行，且只挂载项目目录，那么 rm -rf / 的破坏范围就被限制在容器内，宿主机的用户目录不受影响。这是最直接、最有效的物理隔离。容器技术（Docker、Podman）与轻量虚拟机（如 Firecracker）都可用于此目的。

本文评述：沙箱的代价是配置复杂度与性能开销，且它不能防住"挂载目录内的误删"——如果项目目录以读写方式挂载，容器内的 rm -rf . 仍会删除宿主机上的项目文件。因此沙箱需要与"只读挂载 + 显式写目录"配合使用。

8.2 快照：把不可逆变成可逆

文件系统快照（如 ZFS、Btrfs 的 snapshot，或 APFS 的本地快照）可以在操作前创建时间点副本，操作后按需回滚。这把"低可逆性"操作转化为"高可逆性"，从根本上改变了风险象限。对于使用 git 的项目，git stash 或临时提交也能提供类似保护，但只覆盖已跟踪文件。

一个实用的工程习惯是：在让代理执行批量文件操作前，先 git add -A && git commit -m "checkpoint before agent run"，把当前状态固化为一个可回退的提交。这比任何权限规则都更可靠，因为它不依赖对命令的预判。

8.3 只读优先与写目录白名单

更细粒度的做法是把工作区划分为"只读区"与"可写区"：源码目录默认只读，构建产物目录、临时目录可写。代理的写操作被限制在白名单目录内，越界即拒绝。这与操作系统中的"写保护"机制同源，也与容器安全中的"只读根文件系统"实践一致。

9. 案例与数据：误删事故的形态与代价

9.1 公开事故的形态归纳

文件误删并非 AI 代理独有的问题。历史上，rm -rf 相关事故在运维领域屡见不鲜，其中一些因变量为空导致命令退化为 rm -rf / 的案例被广泛讨论。GitLab 在 2017 年的一次数据库事故中，因复制粘贴到错误终端导致数据目录被删，事后依靠备份恢复（GitLab 官方事故报告，2017）。这类案例的共同点是：破坏性命令与关键路径的组合，在人工操作中同样高发。

本文评述：AI 代理并没有创造新的风险类型，而是提高了风险的发生频率——因为代理可以在无人监督的情况下连续执行多条命令，且其"意图"与"实际命令"之间多了一层语义转换。因此，过去针对人工操作设计的防护（如二次确认、危险命令别名）需要针对代理场景重新设计。

9.2 代价的量化框架

误删的代价可以从三个维度估算：恢复时间（从备份恢复、重做工作）、数据损失（未备份的本地修改、未提交的代码）、连带影响（依赖该目录的其他服务、CI 流水线中断）。对于个人开发者，"半天工作"是常见量级；对于团队，可能是数人日。

需要说明的是，本文不提供虚构的统计数据。上述量级来自公开事故报告与工程常识的归纳，具体数值因项目而异。读者可用自己的项目规模代入第 4.3 节的期望损失框架做估算。

9.3 一个模拟的对比实验设计

为验证各方案的有效性，可以设计如下模拟实验（本文标注为模拟设计，非真实实验数据）：构造 100 条包含删除/移动操作的命令，其中 20 条针对关键路径（/、~、项目外目录），80 条为常规操作。分别测试三种配置的拦截率与误拦率：仅 acceptEdits、acceptEdits + deny 规则、acceptEdits + 钩子。预期钩子方案在关键路径拦截率上显著更高，误拦率可通过白名单控制。读者可在自己的环境中复现此设计，以获得项目特定的数据。

10. 对比与局限：各方案的能力边界

本文评述：没有单一方案能覆盖所有风险。合理的架构是分层组合——deny 规则挡住最明显的危险命令，钩子处理需要解析的命令，沙箱限制物理范围，快照提供最终兜底。四层各自独立，任一层失效不会导致全盘失守。这与网络安全中的"纵深防御"完全一致。

🔒 复制本站文章内容需登录并达到 L3。当前：未登录