AI·系统·创造·人将如何自处

Sandboxing 入门

9分钟阅读

⚠️ 源单薄性声明 本条目主体来源是 Anthropic 官方 sandboxing.md（330 行）。没有第三方安全审计、没有真实被绕过的事故。 已讲清楚：sandbox 是什么、macOS/Linux 怎么启、文件+网络双隔离原则 还没听到：sandbox 被绕过的实例、企业真实配置、Windows/WSL1 相关坑 这是起步级安全认知，不是安全工程指南。

一句话

Sandboxing = 用操作系统级的隔离（macOS Seatbelt / Linux bubblewrap），给 Claude 的 bash 工具划一个”只能在这里面动”的笼子。

为什么会有这东西

来源：sandboxing.md 的 “Why sandboxing matters” 段。

传统的权限模式（见 plan-mode 里的 5 种权限模式）问每一条 bash——官方原话三个坏处：

  • Approval fatigue：一直点 approve 最后开始不看内容就点
  • Reduced productivity：反复被打断
  • Limited autonomy：Claude 不能自主干活

Sandbox 换了思路：不一条条问，而是上来定好边界——

  1. Define clear boundaries:指定 Claude 能访问哪些目录、哪些网络域名
  2. Reducing permission prompts：边界内的安全命令不用再问
  3. Maintaining security：越界立即通知
  4. Enabling autonomy：边界内 Claude 可以更自由干活

两道隔离（都要有才算数）

sandboxing.md 明确警告：

Effective sandboxing requires both filesystem and network isolation. 只有文件隔离没网络 → 泄 SSH key；只有网络隔离没文件 → 系统文件被改。

文件系统隔离

  • 默认写：当前工作目录及其子目录
  • 默认读：除少数 denied 目录外整台机器
  • 越界：阻止或要权限
  • 可扩展：sandbox.filesystem.allowWrite 加白名单

底层实现：macOS 用 Seatbelt / Linux + WSL2 用 bubblewrap（WSL1 不支持，因为缺内核特性）。

这些是 OS 级的，所有子进程自动继承——包括 kubectl / terraform / npm 这些 Claude 的 bash 工具起的进程。

网络隔离

  • 通过沙盒外的代理服务器控制
  • 只有允许的域名能访问
  • 新域名触发确认弹窗（开 allowManagedDomainsOnly 则直接拒）
  • 支持自定义代理规则

怎么起步

macOS（开箱即用）

macOS 上 Seatbelt 是系统自带的，不用装东西。

Linux / WSL2（要装 bubblewrap）

# Debian/Ubuntu
sudo apt install bubblewrap
 
# Fedora/RHEL
sudo dnf install bubblewrap

启用（所有平台）

在 settings.json 里加 sandbox 段，具体字段看 sandboxing.md 的”Getting started”部分——官方 doc 是权威配置参考，这里不复述（随版本变）。

场景

下面这几段不是第三方事故报告，而是按官方边界规则能直接落地的真实工作流场景。目的不是吓人，而是让你知道：sandbox 到底在哪一刻救命，在哪一刻其实救不了你。

场景 1：没开 sandbox，.env 真会被误删；开了之后同样动作会被挡

典型场景不是 .env 就放在当前工作目录，而是团队把真实密钥放在工作区外，比如 ../shared/.env、~/.config/myapp/.env，项目里只留 .env.example。Claude 看到测试报错，可能会自作主张试一把：

rm ../shared/.env && cp .env.example ../shared/.env

没开 sandbox 时，这类 bash 真可能跑通；开了默认 sandbox 之后，Claude 只能写当前工作目录及其子目录，像 ../shared/.env 这种越界写会直接被 OS 层拦住。
但这也顺手说明一个边界：如果你的真实 .env 就躺在当前工作目录里，默认 sandbox 不一定能救你。 这时要么把 secrets 挪出工作区，要么额外配 sandbox.filesystem.denyRead / denyWrite，别把”机密文件”和”Claude 的施工区”混成一个目录。

场景 2：sandbox + agent teams，把”并行干活”变成”并行但不串门”

多人最容易上头的玩法是：主 Claude 负责编排，几个 teammate / subagent 分头跑测试、改文档、查依赖，甚至开多个 worktree 并行推进。问题不在”会不会并行”，而在一个 agent 出错时，会不会横着把别人的 checkout、你的 ~/.ssh/、~/.aws/、~/.zshrc 一起拖下水。

Sandbox 的价值就在这里：边界是跟着 bash 子进程一起继承的，不是只约束主 agent 的嘴上承诺。于是你可以把每个并行 worker 都锁在自己的工作目录里，再加允许域名白名单。这样即使某个 agent 因为提示注入或误判断，突然想 curl 一个陌生域名、改另一个 worktree、或者去读家目录的 key，它也不是”最好别做”，而是物理上做不了。这时多 agent 还是快，但风险不会跟着并行数线性放大。

Sandbox vs. 权限模式 vs. deny 列表

三件事不要混：

工具做什么关系
Permission mode控制 Claude 问不问 你（default/acceptEdits/plan/auto/dontAsk/bypassPermissions）每条命令的交互策略
allow/deny 列表在 settings.json 里明确列”不用问”和”永远不做”的命令命令级白/黑名单
SandboxOS 级强制——越界命令根本执行不了最终防线

Sandbox 是最硬的——前两种都是 Claude 选择要不要做（好 Claude 会守规矩，被越狱的就未必），sandbox 是物理上做不了。

陈彬视角

对好朋友社群来说：

  • Mac 用户：起手就可以打开 sandbox，无成本。把 ~/.ssh/ 和 ~/.aws/ 加进 deny 路径，防 Claude 误读 key。
  • 个人项目：用 acceptEdits + 基本 sandbox 配置就够。
  • 接触企业代码：一定开 sandbox，配置 allowManagedDomainsOnly 防泄露。

一个不那么显眼的价值：API Key 的安全管理 里说”Claude 能用 Bash(cat .env) 绕开 deny Read”——sandbox 开了之后绕不开，因为 bash 本身受 OS 级限制，cat 读不到沙盒外的东西。

但别把 sandbox 当成万能——沙盒是降低风险的一层，不是”开了就安全”。真的处理敏感数据还是得走专门的隔离环境（VM / 容器 / 专用机）。

踩坑记

最常见的反例不是”安全没开”，而是”安全开太死，Claude 合法任务都跑不动”。 官方文档自己就点了几个典型坑：kubectl、terraform、npm 这类工具常常要写 ~/.kube、/tmp/build 一类工作区外路径；docker 天生就不适合在 sandbox 里跑；jest 还可能卡在 watchman。

正确放权顺序是：

  1. 先给精确白名单：用 sandbox.filesystem.allowWrite 放开一两个必要目录，而不是整块家目录。
  2. 再给精确网络域名：只允许包管理器、制品库、公司 API 真需要的 host。
  3. 确认就是工具不兼容：再考虑 excludedCommands，让 docker 这类命令走正常权限流。
  4. 最后才是允许 unsandboxed fallback：而且最好只在你知道自己在放开什么时才开。

一句话：别因为一个合法任务被卡，就把整台机器从玻璃缸里放出来。 sandbox 的正确姿势不是”全开或全关”，而是逐项加边界、逐项放权。

关联

needs_sources（明确待补）

  • 被绕过的事故/报告
  • Linux/WSL2 下的 bubblewrap 实战坑
  • 企业级配置实例

关系图谱

反向链接