官方定义里沙箱模式只管一件事：文件系统效果。网络与进程可见性不在这套词汇里——这一点很重要，别以为收紧沙箱就顺便限制了联网。
| 模式 | 允许做什么 | 典型用途 |
|---|---|---|
| read-only | 只允许必要的写入汇（例如 /dev/null）。工作区也不能写 | 只读分析、审代码、查资料 |
| workspace-write | 允许在工作区根目录与后端给的临时区域写入 | 绝大多数日常任务：改文件、生成产物 |
| danger-full-access | 绕过隔离，直接启动原始进程 | 明确知道在做什么、且需要越过工作区时 |
官方文档明确写：只有前两种模式会发给提供方，danger-full-access的消费方直接spawn原始argv，根本不调ctx.sandbox。所以它不是「更宽的沙箱」，而是「没有沙箱」。
同一条配方，两种权限下的差别
拿一条会写文件的配方（例如「生成一份索引 .md」）分别在两种模式下跑，观察点在于：
- read-only：产物不会出现。表现可能是报错，也可能是它写完报告成功但文件不存在——两种都要留意，后者更危险。
- workspace-write：产物出现在工作区里，工作区外的路径仍然失败。
- danger-full-access：工作区外也能写。这时候「它有没有越界」这个问题就没有机制来回答了，只能靠你自己看。
还有一个容易被忽略的事实：强制执行可能是部分的
官方文档写了 SandboxEnforcement 有 full 与 partial 两档。partial意味着当前后端或较旧的内核ABI只管控了承诺效果的一个子集——已知情形包括较旧的Landlock ABI，以及Windows ACL后端的Everyone与硬链接边界。
实用结论：如果你需要「绝对写不进工作区外」这种保证，就得确认后端是full；partial下不能把它当成硬边界。这一条比模式名字本身更值得记。