各保护层覆盖与遗漏的范围
各层判断所依据的信息不同，因此每一层都会漏掉其他层能拦住的情况。操作系统沙箱的工作方式
各平台的沙箱实现不同，常见基础机制包括 macOS Seatbelt 和 Linux bubblewrap。默认设置通常允许广泛读取，只允许向当前工作目录和临时目录写入，并限制或关闭网络访问。沙箱和审批策略是两项独立控制。沙箱限制进程能接触的资源，审批策略决定智能体何时必须先征得许可。不同的保护层
编码智能体沙箱的限制
沙箱限制你可以向何处写入，但不判断进程在该范围内做什么。Claude Code 的沙箱文档默认把写入限制在工作目录内，因此针对你项目的git reset --hard 和 rm -rf . 都落在允许的路径上，操作系统看到的只是被允许的写入。git push --force 通过网络改写远程仓库，本地什么都不写，文件系统的写入范围本来就覆盖不到它。以下命令沙箱全都允许：它们在当前工作目录内写入、读取沙箱允许的文件，或访问允许的远程端点。
这些命令自动运行还是需要确认，取决于智能体的沙箱模式和审批策略。
git push --force 等依赖网络的命令还取决于允许的域配置。沙箱把
git reset --hard 视为安全操作，因为它只修改当前目录内的文件。但你的编码智能体刚刚丢掉了你全部未提交的工作。~/.aws/credentials 和 ~/.ssh/ 是它仍允许读取的文件。CC Safety Net 无需任何配置即可阻止对这些路径的内容访问。
同样的差异也适用于命令代理。代你运行命令的工具，在两个保护层看来都只是一个不透明的可执行文件；但在你用 cc-safety-net rule wrapper add <command> 声明它之后，CC Safety Net 会穿透它看到可见的子命令，并应用相同的规则。沙箱则完全不检查子命令，只限制整个进程树可以接触的对象。
何时更适合使用沙箱
如果你主要关注以下威胁，沙箱是正确的工具：- 提示注入攻击：通过限制出站网络域来降低数据外泄风险
- 恶意依赖：限制不可信软件包的文件系统写入和网络访问
- 不可信代码执行：操作系统级隔离从根本上强于命令文本分析
- 网络控制：CC Safety Net 完全不提供网络保护
CC Safety Net 无法提供帮助的范围
CC Safety Net 解读受支持的工具调用，但不会隔离进程。以下每一项都需要靠隔离来解决，而不是靠语义分析：- 通过网络外泄数据。 运行时评估不发出网络请求，管线也不检查出站流量。域名允许列表是沙箱的工作。
- 读取已识别集合之外的内容。 敏感路径保护覆盖一个有界模式集，包括
.env及其变体、SSH 密钥、云凭证存储、编码 CLI 凭证文件以及你配置的拒绝路径，并覆盖受支持的 command、path、search 和 patch 形式。完整目录见机密保护参考。它不是通用的读取边界，因此凭证若位于未识别的文件中就得不到保护。沙箱则会限制所有读取，无需知道哪些文件重要。 - 隐藏在二进制文件内的行为。
some-tool --task destructive-cleanup在命令文本中看似无害；而如果某个代理改写子命令，而不是执行一个可见的子命令，那么即使把它配置为透明包装器，也无法展开它。 - 完整的文件系统强制约束。 拒绝只会中止工具调用，并不强制实施权限。当你需要的是完整保护而不是尽力拦截时，请使用可信写入代理、操作系统权限或沙箱。
权限提示与批准分类器
离你最近的一层是会开口询问的那一层。Claude Code 的权限模式文档这样描述它：在 Manual 模式下，Claude Code “stops and asks you before most actions that edit files, run shell commands, or reach the network”；在 auto 模式下，“a second model, the classifier, reviews actions instead of you”。分类器默认阻止的操作清单里包含 “git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, or git stash clear, which the classifier presumes would discard uncommitted changes”。
这道审查是一次判断，而且可以关掉。Anthropic 公布了 Claude Code auto-mode 分类器在真实过激操作上 17% 的漏报率，并称它 “not a drop-in replacement for careful human review”。同一份权限模式文档把 bypassPermissions 下无需询问就会运行的范围写作 “Everything”，并建议这一模式只用于 “Isolated containers and VMs only”。
切换模式不会让确定性检查失效。同一页写明 “Deny rules block in every mode, including bypassPermissions”。CC Safety Net 的拒绝也是如此：经 Claude Code 2.1.251 验证，PreToolUse 拒绝在 default、auto 和 bypassPermissions 模式下都仍会触发（项目仓库中的 tests/e2e-live/protection.test.ts）。这是针对特定版本的结果，不是长期保证，因此该测试套件会在每次发布和宿主升级时重新运行。deny rule 覆盖的是你事先想到并写下的命令，而且要按每个 CLI 各自的格式来写；CC Safety Net 横跨 13 个 CLI 应用同一份策略，并留下同一份审计记录。
容器、虚拟机与检查点
一台用完即弃的机器是真正的隔离，也是关掉提示之后那份权限模式文档指向的去处：bypassPermissions 只适用于 “Isolated containers and VMs only”。机器可以丢掉，里面的工作不会因此改变。云端会话会在真实分支上 clone 你的仓库、commit，然后 push 回真实的远端。在那里对未提交的工作执行 git reset --hard，损失的工作量和本地一模一样；git push --force 落在的也是队友会 pull 的分支。同一个会话的凭据一侧见云端环境。把工作树挂载进来的本地容器也是一样：挂载是可写的，未提交的工作就在里面。
检查点能收窄这个缺口，但不能封住它。Claude Code 的检查点文档说，检查点会 “automatically captures the state of your code before each user prompt”，随后写明了限制：“Checkpointing does not track files modified by bash commands.”。文档在那里举的例子是 rm file.txt、mv old.txt new.txt 和 cp source.txt dest.txt。对于这些改动，该页写道：“These file modifications cannot be undone through rewind. Only direct file edits made through Claude’s file editing tools are tracked.”。破坏性 git 命令是作为 bash 命令运行的，因此它丢掉的工作不在 rewind 能恢复的范围内。同一页把检查点定位为 “quick, session-level recovery”，并要求 “continue using version control, such as Git, for commits, branches, and long-term history”。
将沙箱与 CC Safety Net 一起使用
沙箱在操作系统级限制智能体能做什么，以此应对未知威胁；CC Safety Net 在命令执行前拦截命令，以此应对已知的破坏性模式。两者结合，可以覆盖各自单独使用时留下的缺口。 其他几层也是这样叠加的。分类器会在静态检查无法判定的场合去权衡意图。用完即弃的机器和检查点能限制并部分撤销漏过去的操作。而在确定性检查负责的那类情况上，这两者都不成立。 沙箱和允许列表本身也会被攻破。CVE-2026-25725 通过settings.json 逃逸了 Claude Code 的 bubblewrap 沙箱，CVE-2026-22708 绕过了 Cursor 的命令允许列表。请把你手上的每一层都跑起来。