openJiuwen 没有 OS 级沙箱(格子说明仓库内检索不到 seatbelt / landlock / bwrap),防线是一套策略层规则引擎:内置 YAML 规则库、shell AST 解析(shell_ast.py)、路径匹配器与参数规则命中,最终把每次工具调用归结为 PermissionLevel 的 ALLOW / ASK / DENY 三档,PermissionResult 带 matched_rule 和 reason,多条规则命中时取最严格的一档。
codex 的沙箱模式是协议层的带数据枚举 SandboxPolicy,序列化为 kebab-case 传给所有前端,不是描述性标签——codex-rs/sandboxing 下有 seatbelt(macOS,含 .sbpl 策略文件)、landlock 与 bwrap(Linux)、windows.rs 的真实实现,另有独立的 execpolicy 与 shell-escalation。WorkspaceWrite 分支携带 writable_roots 和 network_access 两个字段,权限边界是结构化数据,不是一个布尔开关。
deepseek harness 的 SANDBOX_MODES 是 ['read-only', 'workspace-write', 'danger-full-access'],与 codex 的三个模式名逐字相同,但状态模型是反过来的:切换沙箱模式不写配置文件,而是往会话日志追加一条 sandbox/mode 事件;当前生效值等于 fold(events) ?? 部署默认值。源码注释点出这样做的收益:重启后靠重放日志恢复,不需要追赶机制;两个会话永远看不到对方的状态;也就不存在外部配置存储。
pi 的内核里同样没有沙箱:OS 级隔离只以示例扩展形式存在于 examples/extensions/sandbox/,bash-executor.ts 全文检索不到 sandbox 字样。取而代之的是目录级信任:formatProjectTrustPrompt 在首次进入项目目录时弹出确认,用户授权后才加载该目录配置、安装缺失依赖、执行项目扩展——隔离责任被显式交还给用户和运行环境。
编辑判断
codex 和 deepseek harness 共享同一套模式命名,容易让人误以为两家的沙箱实现是同一件事,但格子里能看到的落地方式完全不同:codex 的三档背后是 seatbelt / landlock / bwrap / windows.rs 这些真实的操作系统级实现,deepseek harness 的三档背后是一套事件日志折叠出来的状态值,格子本身没有写明这个状态值最终如何在操作系统层面被强制执行。名字相同不代表防线的位置相同,这是本站的编辑提醒。另外,openJiuwen 与 pi 都没有内核级 OS 沙箱,但选择的补偿方式相反——前者建一整套规则引擎自己判定,后者把判断交还给用户的一次性信任决定——这也是编辑判断,不是任一项目的官方表述。