Docker Sandboxes 工作区怎么接：Direct、Clone 和它们的边界
内容提要
本文介绍Docker Sandboxes工作区的两种挂载模式：Direct模式将工作区读写挂入沙箱，改动实时同步，适合有人在场协作，但Agent可破坏工作区；Clone模式提供私有副本，改动需主动fetch，适合无人值守，删除前必须保存提交。建议无人值守优先验证Clone模式，两者代表不同信任模型。
延伸解读
信任模型决定挂载方式
Direct 和 Clone 模式本质上是两种信任模型：Direct 信任“人在场”，依赖你实时监督 Agent 的改动；Clone 则信任 Git 的 fetch/push 边界，将 Agent 的改动隔离在私有副本中。选择哪种模式，取决于你是否能持续关注工作区变化。若无人值守，Direct 模式的风险敞口与裸跑本地 Agent 相差无几，仅权限收窄到单一目录。
Clone 模式的硬约束
使用 Clone 模式时，删除 sandbox 前必须执行 git fetch，否则 Agent 在容器内提交的改动将永久丢失。sbx rm 会打印警告，但已 fetch 的分支会镜像到 refs/sandboxes/<name>/ 下，可随时恢复。此外，--clone 只能在主仓库的 checkout 中创建，无法从次级 worktree 使用，这一限制容易踩坑。
Direct 模式的实时性代价
Direct 模式通过 virtiofs 实现双向实时同步，Agent 的改动立即出现在宿主机，便于边跑边看 diff。但这也意味着 Agent 能直接删除或污染工作区，且没有额外隔离层。因此，Direct 模式适合人在场协作，但若无人值守，其安全边界消失，风险等同于本地直接运行 Agent。
Q&A
Docker Sandboxes 工作区有哪两种挂载模式？
Docker Sandboxes 工作区有两种挂载模式：Direct 模式和 Clone 模式。Direct 模式是默认模式，将工作区以读写方式挂入沙箱，改动实时同步；Clone 模式通过 --clone 参数启用，宿主机仓库只读挂载，Agent 在沙箱内的私有副本中修改，需要主动 fetch 才能获取提交。
Direct 模式有什么优缺点？
Direct 模式的优点是改动实时双向同步，Agent 修改的文件立刻出现在宿主机上，方便人在旁边协作和查看 diff；缺点是 Agent 也能删除或污染工作区，因为工作区内部没有额外隔离，风险敞口与裸跑本地 Agent 类似。
Clone 模式下如何获取 Agent 的提交？
在 Clone 模式下，Agent 在沙箱内的私有 clone 中修改并提交，宿主机不会实时看到变化。需要主动执行 git fetch sandbox-<name> 来获取提交，然后可以用 git log 查看，并用 git branch <name> sandbox-<name>/main 落地为本地分支。
删除 Clone 模式的 sandbox 前需要注意什么？
删除前必须 fetch 未保存的提交，否则这些提交会丢失。sbx rm 会警告未 fetch 的提交会丢失；已 fetch 的分支会被镜像到 refs/sandboxes/<name>/*，删除后仍可恢复。
Direct 和 Clone 模式分别适合什么场景？
Direct 模式适合人在旁边、需要同步协作的场景，比如边跑边看 diff；Clone 模式适合无人值守、批量任务或多个 Agent 同时操作一个仓库的场景，因为 Agent 的改动被隔离在私有副本中，不会影响宿主机工作区。
为什么官方建议无人值守时优先验证 Clone 模式？
因为 Direct 模式的安全边界依赖人在场，一旦人不在，Agent 可能破坏工作区；而 Clone 模式通过 Git 的 fetch/push 边界隔离了 Agent 的改动，更适合无人值守场景。
Clone 模式有哪些限制？
Clone 模式必须在主仓库的 checkout 中创建，不能从次级 Git worktree 创建；另外，删除 sandbox 前必须 fetch 未保存的提交，否则会丢失。
