第 20 章：Anthropic sandbox-runtime——给本地命令加边界

它与前三个工程的关注点不同

sandbox-runtime 提供 srt 命令行与 TypeScript 库，可以把一个命令及其子进程放在文件与网络限制之下。[14] 它不要求你先建立远程沙箱服务，但也不自动替你提供集群调度、镜像分发、多用户计费和持久工作空间管理。

适用的学习场景是：你已经有一个本地编码工具或 MCP 服务，想理解它调用的命令如何受到约束。跨用户运行陌生代码的云服务则还需要更完整的系统边界。

各操作系统怎样实施

本次 README 描述 macOS 使用 sandbox-exec 与生成的 Seatbelt 规则，Linux 使用 bubblewrap、命名空间及相关机制，Windows 使用专用本地账号、受限令牌、ACL 和 WFP 出口限制。三个平台的机制与限制不同，不应假设行为完全相同。

网络访问通过受控代理处理，代理检查目标域名规则。本地代理本身属于可信边界的一部分；如果应用还拥有另外的远程工具或外部服务通道，srt 不会自动替你限制所有工具。

最容易看错的默认值

当前 README 明确说明：默认允许读取，写入采用允许列表，网络采用允许列表。也就是说，“不能写”和“不能联网”不等于“看不见主机上的敏感文件”。你仍需为不该读取的路径配置 denyRead，并理解 allowRead 的例外语义。

CLI 没有配置文件时有内建默认写入路径；自定义配置中的空写入允许列表则不能简单理解成同一种配置。必须区分“未提供”“空值”和“显式规则”。配置读取失败时也应看程序实际如何退出，不能假设自动继续运行。

用源码印证调用顺序

sandbox-manager.ts 中可以找到 initialize、wrapWithSandbox 和平台分派逻辑；macos-sandbox-utils.ts 与 linux-sandbox-utils.ts 对应底层包装。initialize 准备配置与代理，wrap 生成受限命令或参数，调用方仍需要启动进程并处理退出和清理。

同一实现中还能看到 filesystem.disabled 的分支。这个选项跳过文件系统限制规则生成，意义远大于“少打一条日志”。类似的 weaker、disabled、allowNestedUserNamespaces 选项，应按当前版本文档理解，不能作为遇到报错后的通用修复。

一个适合新手的观察任务

先使用官方示例配置，运行只输出文字的固定命令。然后分别观察写允许目录、写拒绝目录、访问未允许域名的结果。所有文件都使用临时演示数据；本书不要求你把私人目录暴露给测试进程。

完成后写下三个答案：限制覆盖哪些子进程？默认能读什么？命令退出后是谁清理代理？这三问能帮你区分“命令跑通”与“边界理解清楚”。