Claude Code 底层沙箱开源，无需容器

让 AI 编程助手少弹权限确认框，靠的可以是一套预先划好的执行边界。MarkTechPost 介绍的 Anthropic sandbox-runtime，简称 srt，会限制进程能访问的文件和网络地址，不需要启动容器，也可以用于自己的 Agent、本地 MCP 服务和普通命令行程序。

它最值得关注的结论是：把权限控制落到操作系统层，可能同时减少打断和误操作。不过，原文最醒目的「权限提示减少 84%」来自 Anthropic 内部使用数据，不能直接当成所有团队都能获得的收益。

不用容器，srt 把限制放在哪里

按原文信息，npm 包 @anthropic-ai/sandbox-runtime 的版本为 v0.0.81，解包后约 11.4 MB，采用 Apache-2.0 许可证，需要 Node.js 22.12+。安装命令是 npm install -g @anthropic-ai/sandbox-runtime，使用时在原命令前加上 srt。

它同时提供 CLI 和 TypeScript 库。这里的「沙箱」就是给程序划定活动范围，而且限制覆盖整棵进程树：脚本再启动子进程，也要继续受约束。

各平台的执行方式不同：

• macOS 使用 sandbox-exec，动态生成 Seatbelt 配置，只额外需要 ripgrep。
• Linux 使用 bubblewrap 隔离网络，还需要 socat 和 ripgrep。
• Windows 使用专门的 srt-sandbox 账户、Windows Filtering Platform 出站网络限制及显式文件 ACL，目前处于 alpha 阶段。

网络访问则统一经过宿主机上的 HTTP、SOCKS5 代理，再由代理检查域名规则。Linux 把代理对应的 Unix socket 挂载进沙箱；macOS 的 Seatbelt 配置只允许连接一个 localhost 端口。

srt 的关键价值，是让文件和网络规则约束实际执行的进程及其子进程。

为什么文件权限和网络权限必须一起管

原文引用 Anthropic 团队的判断：只守住一个边界不够。允许任意联网，受到提示注入的 Agent 就可能把 SSH 密钥传出去；缺少文件系统限制，又可能给突破网络边界留下机会。

因此，srt 的默认策略并不对称：文件默认可读，除非明确禁止；文件默认不可写，除非明确允许；网络默认不可访问，除非域名进入允许名单。

这里容易误解的是「默认可读」。启用沙箱，并不等于敏感文件自动不可见，仍然需要配置禁止读取的路径。

原文给出的配置存放在 ~/.srt-settings.json，解决的是允许项目内写入、拦住敏感文件，并只开放指定网络目标：

{
  "network": { "allowedDomains": ["api.github.com", "*.npmjs.org"], "deniedDomains": [] },
  "filesystem": { "denyRead": ["~/.ssh"], "allowWrite": ["."], "denyWrite": [".env"] }
}

要重点看 denyRead 和 denyWrite 两行：~/.ssh 被禁止读取，而 .env 只是禁止写入，配置没有禁止读取它。限制修改和限制泄露，是两件需要分别处理的事。

接入 MCP 服务时，原文建议把 .mcp.json 里的启动命令从 npx 改成 srt，再把原命令作为参数传入。自行开发 Agent，则可以通过 SandboxManager 调用 initialize(config) 启动代理，再用 wrapWithSandbox() 取得包装后的命令字符串，交给进程启动逻辑执行。

真正难的是允许名单要开多大

编程 Agent 不只修改文件，还会安装依赖、获取文档和调用 API。域名卡得太严，npm install 可能失败；放得太宽，数据仍可能流向允许访问的服务。

原文列出的几个机制，都是为了让这条边界更容易维护：

• 支持 *.npmjs.org 这样的通配符，以及 api.example.com:443 这样的域名加端口规则。
• 对尚未匹配规则的主机调用 Ask callback，并可返回让模型读取的理由。
• 按单次命令临时开放允许名单，例如只为一次执行开放软件源。
• 通过 --control-fd 在命令运行期间更新网络名单。
• 检查域名解析后的地址，拦截允许域名指向 loopback 或云元数据 IP 的情况。
• 给拒绝访问附带原因，引导 Agent 使用获准的替代方案，例如 HTTPS git remote。

这些能力减少了「遇到失败就永久放宽规则」的压力，但配置仍需要人判断。允许访问某个域名，只能证明目的地符合规则，不能证明传过去的内容合适。

84% 的数字也应放在这个上下文里理解。Anthropic 自报，内部 Claude Code 使用中，沙箱使权限提示减少了 84%。它衡量的是打断次数，原文没有提供攻击拦截率、任务成功率或外部对照实验。

提示更少，是使用体验的证据，不能直接当成安全强度的证据。

我的判断

我认同它针对的问题：频繁点「允许」会让审批逐渐失去作用。预先定义稳定边界，让 Agent 在范围内执行，在触及边界时再处理，比反复确认相似命令更有操作价值。

但它的前提，是团队能维护合理的文件规则和网络名单。项目依赖来源复杂、外部服务经常变化时，维护成本不会凭空消失。原文也明确标注，srt 仍是 beta research preview，Windows 支持为 alpha。

和替代方案相比，原文把 Codex CLI 也归为操作系统原语隔离，区别是 srt 面向任意进程提供 CLI 和库；Docker Sandboxes、E2B 则使用 microVM，前者在本地运行，后者支持云端或 BYOC。选择时，首先要看工作负载运行在哪里、需要什么隔离边界，以及是否要接入现有 Agent。

原文没有给出这些方案的统一性能或安全测试，因此「不用容器」只能说明部署形态，不能据此判定谁更安全、更快。跨产品表格中的配置和支持状态，也应视为原文记录，落地前还需要核对。

能拿来做什么

• 给本地 MCP 服务加边界时，可以从启动命令入手，把原命令交给 srt 包装，并明确列出禁止读取的敏感目录。
• 给前端或 Node 项目配置权限时，分别审查项目写入范围、.env 的读取权限和依赖下载域名，不要把「禁止修改」当成「禁止读取」。
• 自建 Agent 时，可以评估通过 SandboxManager 统一包装命令执行，再用单次命令允许名单处理临时联网需求。
• 试用时同时记录权限提示次数、任务完成情况和规则维护成本。84% 可以作为待验证的参考值，不宜直接写成团队收益承诺。