Claude Code 沙箱安全边界详解：读写权限的取舍

Anthropic 为 Claude Code 推出了操作系统级的沙盒。如果你在一个你在意的代码仓库上运行 agent，理解清楚具体发生了什么值得花时间——因为相当一部分评论把它解读成了"agent 现在被隔离了"，但文档里可不是这么写的。

我仔细读了文档，部分原因是我的工作领域与之相邻，我需要知道自己是不是突然被替代了。简短的答案：没有。更长的答案更有意思，而且先从一句好评开始：文档对其自身的局限性出奇坦诚。大多数我接下来写的内容不是我自己发现的——而是 Anthropic 自己写下来的，只是应该有更多人读到。

它实际做了什么

沙盒使用了操作系统原语——macOS 上的 Seatbelt，Linux 和 WSL2 上的 bubblewrap。默认情况下，沙盒化的命令只能写入你的工作目录和会话临时目录。没有预批准的网络域名：命令第一次需要访问新主机时你会收到提示，批准后本次会话有效。

关键在于，这是由操作系统在运行中的进程上强制执行的，而不是靠模型正确理解某个命令。文档说得很好：无论模型选择执行什么，边界都会保持生效，即使一个被允许的命令做了远超其名称所暗示的事情。这比"礼貌地请求 agent 收敛"是真正的改进，而且它选对了层次来解决这个问题。

文档中提到的动机和我在实际场景中反复看到的一样：减少人们不再阅读的权限提示。审批疲劳是病症；这是对部分症状的真正治疗。

使用前值得知道的五件事

它仅限 Bash。沙盒约束的是 Bash 命令及其子进程。Claude Code 自己的 Read、Edit 和 Write 工具不走这条路径——它们走的是权限系统。"沙盒开着"意味着 shell 命令被隔离，而不是所有文件操作都被隔离。

你的工作目录在边界内部是设计如此。默认的写入范围是当前工作目录加上会话临时目录。这正是让 agent 有用的原因——它必须编辑你的代码。但这也意味着沙盒没有保护许多开发者以为它会保护的东西。一个被限制在你项目内的破坏性命令，仍然只是被限制在你项目内。

有一个值得注意的例外，而且方向是让人安心的：即使在自动允许模式下，针对 /、你的主目录或其他关键系统路径的 rm 和 rmdir 仍会触发提示或分类器检查，明确的拒绝规则始终被遵守。Anthropic 对灾难性路径做了特殊处理。你工作目录内的所有内容保持允许，这是刻意为之。

读取范围远宽于写入范围。默认读取权限是除少数被拒绝目录外的整台计算机——文档直言不讳地说这仍然允许读取凭据文件，如 ~/.aws/credentials 和 ~/.ssh/。如果想保护这些文件，你需要配置 sandbox.credentials（deny 或 mask）或将它们加入 denyRead。没有内置的凭据拒绝列表。这是我会首先采取行动的一项。

有一个逃生舱，默认开启——但有权限控制。当命令因沙盒限制而失败时，Claude 可能会用 dangerouslyDisableSandbox 重试。重要的是，那次重试会经过正常的权限流程：默认模式下是确认提示，自动模式下是分类器。所以这不是一个静默的绕过——而是一扇有门铃的合规门。如果你想把门封死，allowUnsandboxedCommands: false 启用面板所称的"严格沙盒模式"。

它会 fail open。如果沙盒无法启动——缺少 bubblewrap、不支持的平台——Claude Code 会发出警告并以非沙盒模式运行命令，除非你设置了 failIfUnavailable: true。这是一个站得住脚的默认（一个安全层在让你的 agent 瘫痪和然后保护不了任何人之间选择了前者；我在自己的工具里也做了同样的选择）。但 fail-open 有一个阴影：这个东西可以在一切看起来正常的时候根本不工作。我在这方面付出过代价——一个 hook API 重命名让我的工具在四个小版本里静默地什么都没拦，测试套件完全绿灯。

在原生 Windows 上完全不运行。Windows 用户被指向 WSL2。如果你在 Windows 上原生运行 Claude Code——大有人在——沙盒不在你的选项里。

功过簿：文档自己承认了局限性

在我展开论述之前，Limitations 部分值得完整阅读，因为它比大多数供应商的安全页面都更坦诚：

内置代理从客户端提供的主机名做出允许决策，默认情况下不终止或检查 TLS——因此允许像 github.com 这样的广泛域名可能为数据泄露创造路径，文档明确点名了域名前端。

allowUnixSockets 可能无意中授予主机访问权：允许 /var/run/docker.sock 实际上就授予了对主机系统的访问权。

macOS 上的 allowAppleEvents 消除了代码执行隔离。

enableWeakerNestedSandbox 大大削弱了安全性。

以及总结行：沙盒化降低风险，但不是完整的隔离边界。

这是供应商在告诉你他们的边界在哪里。按照他们说的来，而不是按照营销文案来。

真正重要的区别

隔离（Containment）、后果（Consequence）和恢复（Recovery）是三个不同的问题，工具往往只回答其中一个：

隔离问的是：这个进程能否触碰其箱子外的东西？这是沙盒、Docker、seccomp。空间中的一个边界。

后果问的是：这个特定命令运行的话会摧毁什么？五万行。三个有依赖关系的表。一个只存在于远程的提交。隔离边界对此没有意见，因为边界内一个被允许的命令只是一个被允许的命令。

恢复问的是：万一还是发生了，我能找回来吗？隔离和预测都把你带不到这里。这需要的是执行前拍摄的备份，以及一条回来的路。

我这一个月来收集的失败案例都落在第二和第三类。一个 agent 在 Windows.old 清理过程中跟随 NTFS junctions 走进了某人的活 Documents 文件夹。提示词配置规则——"不要碰 .env"——被忽略了，因为指令只是建议，执行路径不会读你的 CLAUDE.md。rm -rf ~/.crit/reviews/$SID，其中 $SID 已经被清空，所以展开为空并带走了父目录。

注意它们的共同点。都不是 agent 做了明显愚蠢的事。每一个都是一个看起来正确的命令，其真实范围与表面范围不同。隔离不能解决这类问题，因为那个命令在它运行的地方是被允许的。

把沙盒打开。它内置、操作系统强制执行，关闭了一个真实的威胁类别。在 Windows 上这意味着 WSL2 或者没有——在你假设自己被覆盖之前值得搞清楚。

然后把三个软默认转换成硬默认，每一个都是一行配置：

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ]
    }
  }
}

知道它坏了而不是假设它在工作；让边界保持住而不是商量；阻止沙盒化的命令读取你的密钥，因为默认读取策略允许这样做。

然后清醒地认识到你解决了隔离问题，而不是后果或恢复问题。对于那些：最小权限凭据——一个不能删除你生产表的 agent token 比任何要求它不要这么做的提示词都强——在执行前而非每夜 cron 时发生的备份，以及如果你想要的话，一个在仍有决策空间时展示爆炸半径的东西。

最后那部分是我做的（Termaxa，开源，Rust）。我显然不是中立的。但这个论点不靠它也站得住脚：供应商会持续做隔离，因为隔离是平台能够拥有的东西。后果和恢复在另一个层次，结构上，没有 agent 供应商会为竞争对手的 agent 构建那一层。Anthropic 不会限制 Cursor。Cursor 不会限制 Claude Code。如果你运行不止一个，那一层必须来自别处。

Claude Code 的沙盒是一个好的、真正的改进，一个问题回答得很好，三个问题中的一个。它仅限 Bash；读取远宽于写入且默认包含你的凭据；逃生舱开着但有权限控制；它 fail open；在原生 Windows 上根本不存在。

读一下局限性部分。把对你重要的标志从软转硬。并且保持备份——因为击中你的东西看起来不会危险。它会看起来像一个你会批准的命令。

本文于 2026 年 8 月对照 Claude Code 沙盒化文档核实。引用的事件来自过去两周的 r/ClaudeAI、r/ClaudeCode 和 r/cursor 的公开帖子。文档演进很快；如果本文与文档不符，以文档为准，本文已过时。Termaxa 采用 MIT/Apache 协议，cargo install termaxa——如果你能以我未记录的方式让一个 agent 绕过它，那是你能发给我的最有用的东西：issues 或 security@termaxa.com。