OS sandbox / gondolin 该停在官方 example、权限门，还是 #169 Security seam？

[tt-a1i]

一句话问题：OS sandbox / gondolin 该停在官方 example、OpenPI 权限门（#497），还是 #169 的 Security seam？

这不是 commit 计划。倾向 Discuss。本轮未安装、未运行社区 sandbox 包。不提议新安装器。Pi 继续拥有 install / update / uninstall。

本帖讨论的是 OS 隔离，不是 #497 的 allow/ask/deny policy。两件事不要合成一个实现。

为什么目录里这个机制看起来有趣

冻结身份（last-seen 2026-09-08）：

包 / 来源	版本 / 日期	说明
官方 sandbox/ example	upstream example	@anthropic-ai/sandbox-runtime
官方 gondolin/ example	upstream example	Linux micro-VM；earendil-works/gondolin
pi-sandbox（carderne）	npm 0.6.8（2026-09-08）	https://www.npmjs.com/package/pi-sandbox · https://github.com/carderne/pi-sandbox
@erichll/pi-sandbox	npm 0.17.1（2026-09-07）	https://www.npmjs.com/package/@erichll/pi-sandbox · https://github.com/erichll/pi-packages

官方 examples 已经提供 OS 隔离缝。社区包把 seatbelt / bwrap / 交互批准打成产品。OpenPI 若再自研一套 isolation language，会变成 #169 明确不想做的 in-house Security 产品。

和 OpenPI 已有能力的重叠

• runtime: 试点全局 allow/ask/deny，不引入社区权限包依赖 #497：policy 门（学 permission-system，不 merge）。
• workspace-cleanup-guard：路径删除门，不是 OS sandbox。
• capabilities: 定义 Browser、Web、GitHub、Computer 与 Security 的外部 Provider Seam #169：外部 Security 走 seam，不把 OMP/社区安全产品做进树内。
• @amaster.ai/pi-computer-use（npm 0.1.14，2026-09-02）是高特权桌面自动化，应保持 out-of-tree，不和 sandbox 讨论绑在一起。

六问（AGENTS.md）

1. 哪条 Pi seam？ 官方 sandbox / gondolin examples，以及 Pi Trust。OpenPI 不应再拥有第三套隔离运行时。
2. 模型判断还是运行时不变量？ 隔离、逃逸失败、取消清理是运行时不变量。不能靠 prompt「请在沙箱里跑」。
3. 正交机制还是工作流？ OS 边界是正交的。若做成「安全产品 + 策略语言 + UI」就是工作流。
4. 更强模型会不会直接用 Pi 原语？ 更强模型不能替代隔离。这是少数「模型变强也不消失」的不变量——但所有权仍可能属于官方 example，而不是 OpenPI。
5. 成功 / 失败证据？ 成功：被拒的 syscall / 路径有收据。失败：sandbox 起不来必须 fail-closed，不能静默回退到无隔离 bash（这是 @quintinshaw/pi-dynamic-workflows 式 fail-open，OpenPI 不接受）。
6. 权限如何停和清？ VM / seatbelt 进程必须可停、可回收、可审计。child 不得获得比 parent 更宽的隔离豁免。配置若需要，只进 /openpi-setup，不新开命令。

结论倾向

Discuss，不是 Adopt。 默认倾向：先用官方 example + #497 policy；只有官方缝明显不够时，才把 OS isolation 写进 #169 seam 的兼容合同。不 merge 社区 pi-sandbox。

关联：#169、#497、#299、#314、#312。研究记录：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md。