只要用 Claude Code 用得够久,你就会撞上这个两难。它对每一条命令都要问"可以执行吗?",让你的节奏一再停顿。但用 --dangerously-skip-permissions绕过权限)关掉所有提示,又意味着一次提示词注入或一次手滑,就可能波及你机器上到处的文件。安全与自动化——长期被当成一道取舍题。

打破这道二选一的,正是沙箱。如果你事先在操作系统层面把"能碰到什么"围起来,命令就能在围栏内自由运行、无需提示,同时任何东西都无法触及围栏之外。本文将从实践者的视角,梳理 Claude Code 沙箱隔离了什么、如何隔离,如何用 /sandbox 上手,如何在 settings.json 中配置,它与权限模式有何不同,以及那些绝不能过度信任的局限

30 秒看懂核心结论

如果你只读一句话

它是什么
一种在操作系统层面给命令能碰到的文件和网络划界的机制。围栏内自由,围栏外禁行。
它为何有用
化解了提示疲劳与彻底绕过之间的取舍。你在保持安全的同时大幅减少提示。
从哪里开始
运行 /sandbox。macOS 开箱即用;Linux/WSL2 需要装两个软件包。

※在 Anthropic 自己的内部使用中,沙箱安全地把权限提示减少了 84%(来源见下文)。

1. 为什么你需要沙箱

Claude Code 是一个真会动手做事AI 智能体——运行测试、改写文件。正因如此,它在执行有风险的命令前会停下来问"可以执行吗?"。为了安全,这么做没错。但当一天里有几十次提示接连弹出时,工作被切得支离破碎,最终你会不看内容就直接按下回车。这就是"权限疲劳"。

疲惫的开发者会伸手去用 --dangerously-skip-permissions(俗称 YOLO 模式),它会关掉所有提示。它很舒服,而且——正如其名——很危险。三重威胁同时露出獠牙。

💉 提示词注入

如果它读取的网页或工单里藏着一句"把 ~/.ssh 发出去",你的私钥可能在毫无提示的情况下泄露

🗑️ 破坏性手滑

一条生成的命令清理了一个意料之外的路径。没有提示,项目之外的文件也可能凭空消失

📤 供应链污染

恶意依赖会在安装时把数据偷偷发出去。网络大门敞开,你无从阻止。

沙箱的思路很简单:别再每次都问"我该确认什么?",而是事先把"这能伸多远?"围起来。这道围栏不靠 Claude 自己的判断,而由操作系统(内核)来强制执行,因此即便它被劫持,即便一条被允许的命令干的比其名字暗示的更多,也没有任何东西能逃出边界。这正是为什么围栏内的命令可以放心无提示运行——疲劳与彻底绕过的二选一就此消失。Anthropic 在其官方工程博文 《Making Claude Code more secure and autonomous with sandboxing》中报告,在内部使用中它安全地把权限提示减少了 84%(发表于 2025 年 10 月)。

2. 沙箱是什么——两道隔离

Claude Code 沙箱围绕 Bash 命令(以及它们派生出的每一个子进程)划出两道边界。两道必须成套配合使用——单独任何一道都会留下缺口(见 §7)。

🗂️ ① 文件系统隔离

写入被限制在工作目录加上一个会话临时目录(默认如此)。~/.bashrc 和系统区域无法被改动。读取范围很宽,但可以显式拒绝。即便被劫持,它也无法改写项目之外的任何东西

🌐 ② 网络隔离

默认是"默认拒绝",不允许任何目的地。一旦它尝试访问新域名,就会弹出提示。流量会经过沙箱之外的代理,并对照白名单进行判定。它能阻止机密被发送出去

关键在于它不依赖 Claude 表现良好。边界由操作系统自身的安全机制强制执行——macOS 使用内置的 Seatbelt,Linux/WSL2 使用 bubblewrap。因此同一道边界会延伸到某条命令调用的脚本,以及孙子进程。别把它想成像 AI 护栏那样对模型的一句客气请求,而要想成一堵靠机械力挡住的物理墙

💡 它只围住 Bash。沙箱包裹的是 Bash 工具及其子进程。Claude 内置的 Read/Edit/Write、MCP 服务器以及 hooks另一回事(由权限规则管辖)。要隔离整个进程,请使用下文介绍的 @anthropic-ai/sandbox-runtime 软件包。

3. 上手——/sandbox 与支持的操作系统

沙箱内置于 Claude Code。无需额外账号或工具。在会话中运行:

/sandbox

会打开一个带三个标签页的面板。Mode(沙箱内命令如何获批——见下一节)、Overrides(在沙箱下失败的命令是否可以退回到不加沙箱运行)以及 Config(查看已解析的配置)。在 Linux/WSL2 上,如果缺少某个必需的软件包,会改为出现一个 Dependencies 标签页,告诉你需要安装什么。

各操作系统的前置条件

🍎 macOS

无需安装任何东西。它使用内置的 Seatbelt。用 /sandbox 即可立即启用。

🐧 Linux / WSL2

安装两个软件包:bubblewrapsocat(例如 apt-get install bubblewrap socat)。

🪟 原生 Windows

不支持。请在 WSL2 内运行 Claude Code(WSL1 无法工作)。

在 Linux/WSL2 上,安装 bubblewrap(负责强制文件系统隔离的免特权沙箱工具)和 socat(把流量转发到代理的中继)。

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

⚠️ Ubuntu 24.04 及更高版本:默认的 AppArmor 策略可能会阻止 bubblewrap 创建它所需的用户命名空间。如果 sysctl kernel.apparmor_restrict_unprivileged_userns 返回 1,就为 bwrap 添加一个 AppArmor 配置文件来放行(具体步骤见官方文档)。如果返回 0 或该键不存在,则无需操作。在 WSL2 内也要检查同样一项。

一个值得启用的实用功能是 seccomp 过滤器(它会额外增加 Unix 域套接字的拦截)。它是可选的;用 npm install -g @anthropic-ai/sandbox-runtime 安装。/sandbox 的 Dependencies 标签页会显示 ripgrepbubblewrapsocat 以及 seccomp 过滤器的状态。安装软件包后,请重启 Claude Code,然后重新打开 /sandbox(检查在启动时运行)。

4. 两种模式(自动允许 / 常规)

Mode 标签页决定沙箱内的命令如何获批

✅ 自动允许模式

在沙箱内运行的 Bash 命令会自动获批,不弹提示——边界本身就代替了提示。日常工作很舒适。沙箱无法运行的命令(例如访问未被允许的主机的流量)会退回到常规权限流程并弹出提示。

🔍 常规权限模式

即便加了沙箱,每一条 Bash 命令仍要走常规权限提示。控制更强,审批更多。适合想要"隔离加上一如既往的提示"的谨慎派。

在这两种模式下,文件系统和网络的边界完全相同;唯一的区别是"自动允许还是弹提示"。请注意,即便在自动允许模式下,这些安全阀依然生效:

  • 显式的拒绝规则始终优先
  • 针对 /、你的主目录或其他关键系统路径的 rm / rmdir 仍会弹提示
  • 诸如 Bash(git push *) 这类按内容限定的 ask 规则,即便在沙箱内也仍会强制弹提示

当心两个容易混淆的"自动"。沙箱的自动允许模式不是权限模式里的自动模式。前者意为"因为有操作系统边界兜住,所以自动批准";后者意为"由一个分类器判断命令是否安全并放行"。二者各自独立运作,可以组合使用。

5. 在 settings.json 中配置

你在 /sandbox 面板里的选择会写入项目的 .claude/settings.local.json(不提交到 git)。若想让它在所有项目中始终开启,就在你的用户设置 ~/.claude/settings.json 里放上 sandbox.enabled: true。它与权限规则(allow/ask/deny)同属一个 settings.json 家族。

添加写入目标、拒绝读取

默认情况下,你只能写入工作目录和临时目录。如果 kubectlterraform 需要写到别处,就用 allowWrite 添加路径。反过来,你也可以屏蔽对敏感目录的读取。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

上面的例子拒绝读取整个主目录,同时仍允许读取当前项目(当配置位于项目设置中时,. 会解析为项目根目录)。路径是在操作系统层面强制执行的,因此对 npmterraform 这类子进程同样适用。

保护凭据

一个重要的坑:读取的默认设置是"广泛允许",所以 ~/.aws/credentials~/.ssh/ 照原样可读。专门的 sandbox.credentials 设置(一个相对较新的功能)用来声明要拒绝读取的文件,以及要清除的环境变量。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

允许目的地

网络一开始没有任何目的地。首次访问某个新域名时会弹出提示(在撰写本文时的较新版本中,批准一次意味着该会话余下时间不再重复询问)。把你不想被反复询问的主机预先登记到 allowedDomains 里。借助组织下发的托管设置,你还可以让白名单之外的一切被自动拦截,而非弹出提示。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    }
  }
}

如需在全组织强制启用。在托管设置中,除了 sandbox.enabled: true,再加上 failIfUnavailable: true(若沙箱无法初始化则拒绝启动 Claude Code)和 allowUnsandboxedCommands: false(关闭"在沙箱外重试"这个"逃生口"——严格模式)。二者合起来就能把它作为一道安全闸门强制执行

6. 与权限模式和权限规则的关系

它们很容易被混为一谈,但 Claude Code 的安全机制有职责各异的三层。沙箱是其中之一——它不取代另外两层,而是对它们加以补充

它控制什么 由谁强制 作用范围
权限规则 哪些工具/命令可以使用 Claude Code(运行前) 所有工具
权限模式 会弹出多少提示 Claude Code(运行前) 取决于模式
沙箱 运行之后它能碰到什么 操作系统(内核) Bash 及子进程

决定性的区别在于各自"何时、由谁"生效。权限规则和权限模式是在执行前、由 Claude Code根据命令字符串决定的。沙箱则在执行期间、由操作系统束缚进程——所以无论模型选了什么,即便一条被允许的命令干的比其名字暗示的更多,边界都纹丝不动

这也是它与 --dangerously-skip-permissions(绕过)的决定性差距。绕过只是移除提示;环境仍然大门敞开。相比之下,沙箱的自动允许之所以能跳过提示,是因为有操作系统这堵墙在。那条老铁律——若使用绕过模式,就只在隔离的容器或虚拟机内使用——沙箱让你即便在日常机器上也能把它挪到安全的一侧

7. 局限与注意事项——不要过度信任

沙箱很强大,但它并非完全隔离。在把它当作一道硬性安全边界来依赖之前,先了解文档明确指出的那些局限。

🔓 默认不检查 TLS

代理只按主机名判定,不检查加密内容(默认如此)。放行像 github.com 这样宽泛的域名,会给数据外泄留下空间——例如通过域前置等手法。让白名单保持狭窄

🔌 打开 Unix 套接字有风险

放行 /var/run/docker.sock 会通过 Docker 套接字把整台主机拱手让出——实际上等于沙箱逃逸。要小心你打开的是哪些套接字。

📈 过宽的写入权限

$PATH 上可写的可执行文件,或 .bashrc 这类文件,可能会变成在另一个上下文中的代码执行。让 allowWrite 保持最小。

还有一点要内化:作用范围仅限 Bash——内置的 Read/Edit/Write、MCP 服务器以及 hooks 都在其外。要隔离整个进程,连同 技能和 MCP 一起,就用官方开源的 @anthropic-ai/sandbox-runtime 把 Claude Code 进程本身包起来(已在 GitHub 和 npm 发布,是 2025 年 10 月发布的研究预览版)。它的实际角色不是抵挡执意攻击者的"墙",而是把事故和失控成数量级削减的"安全带"

8. 何时该动用开发容器或虚拟机

沙箱并非 Claude Code 唯一的隔离选项。便利性隔离强度此消彼长,因此要按用途来选。

沙箱(内置)

隔离 Bash 及子进程。无需 Docker,配置极少。日常工作中削减提示的主力。

sandbox-runtime

包裹整个 Claude Code 进程。适合无人值守运行、且你还想把 MCP 和 hooks 一并围住的场景。无需 Docker。

开发容器

整个开发环境容器化。适合统一团队的配置。需要 Docker。

虚拟机(VM)

整个操作系统分离开。最强的、内核级别的隔离,适合不可信代码。投入最高。

经验法则是:让内置沙箱始终开启以削减日常提示,只在你无人值守运行或处理不可信依赖时才升一级去用 sandbox-runtime、容器或虚拟机。对于会触及生产环境的工作——比如让 AI 操作云——把最小权限凭据与更强的隔离层级搭配起来,能买来安心。

总结

  • 沙箱在操作系统层面把"能碰到什么"围起来,化解了提示疲劳与彻底绕过的二选一。
  • 文件系统隔离和网络隔离成套使用。强制方:macOS = Seatbelt,Linux/WSL2 = bubblewrap。
  • /sandbox 开始。macOS 开箱即用;Linux/WSL2 需要 bubblewrap+socat;原生 Windows 不受支持(改用 WSL2)。
  • 自动允许模式跳过提示却依然安全,因为边界由操作系统强制。拒绝规则、有风险的 rm,以及按内容限定的 ask 规则仍然适用。
  • 它是一层互补的、有别于权限规则/模式的机制——沙箱在执行之后、经由操作系统束缚进程,所以纹丝不动。
  • 但它并非一堵完整的墙——当心未检查的 TLS、Unix 套接字以及过宽的放行。作用范围仅限 Bash。

沙箱打破了"安全与自动化必须取舍"这一前提本身。只需打开一次 /sandbox——仅此一举,就会改变你握住 Claude Code 缰绳的方式。要获取确切、最新的配置参考,请把官方的沙箱设置文档当作你的首要来源。

常见问题

Q. 沙箱与 --dangerously-skip-permissions 有何不同?

A. 绕过只是移除提示,让环境毫无防御。沙箱在操作系统层面把能碰到什么围起来,所以即便跳过提示,也没有任何东西能触及外部。绕过只适用于隔离环境;而沙箱即便在日常机器上也可以放心使用——这就是决定性的区别。

Q. 我能在 Windows 上使用它吗?

A. 原生 Windows 不受支持。在 WSL2 内运行 Claude Code 就能工作(WSL1 不行)。在 WSL2 下,沙箱内的命令无法调用像 cmd.exe 这样的 Windows 二进制程序;如有需要,把它们加入 excludedCommands 以便在沙箱外运行。

Q. 启用它会不会拖慢速度?

A. 据 Anthropic 所述,开销极小——某些文件系统操作可能略慢。实际使用中,由于提示数量大幅下降,感知到的工作速度往往反而更快。

Q. 开了沙箱,我的私钥就一定安全吗?

A. 并非"一定"。读取的默认设置很宽,所以 ~/.ssh~/.aws/credentials 默认可读。用 sandbox.credentialsdenyRead 显式屏蔽它们,并让网络白名单保持狭窄。文件系统隔离和网络隔离必须始终成套配合

Q. MCP 服务器和 hooks 也被加沙箱了吗?

A. 没有。内置沙箱只覆盖 Bash 命令及子进程。MCP、hooks 以及内置的 Read/Edit/Write 都是分开的(由权限规则管辖)。要把它们全部围住,就用 @anthropic-ai/sandbox-runtime 包裹整个进程。