Electrolux_blog04 — 沙箱、执行策略与安全边界
为何沙箱是「核心」问题
Agent 会执行任意 shell、读写仓库、可能访问网络。若仅在 UI 提示「请谨慎」，无法防御恶意 prompt 或依赖供应链。策略必须在 core 层强制执行，与具体 UI 无关。
codex-core README 按平台列出 硬依赖（macOS sandbox-exec、Linux bwrap/Landlock、Windows 多后端），并描述 fail-closed 场景：当新策略无法映射到旧 Windows 后端语义时，拒绝运行而不是悄悄降级。
SandboxPolicy 与文件系统策略
协议层定义 FileSystemSandboxPolicy、NetworkSandboxPolicy 等（见 codex_protocol::permissions），在 Op::UserTurn 中随回合传入，实现 每轮可变的沙箱视图（例如临时放宽某次命令的写权限由审批流完成，而非改全局配置）。
Linux：Landlock 与 Bubblewrap 的分流
README 说明（摘要）：
- 旧版 Landlock 路径仍在部分配置下使用。
- 当 split filesystem policy 需要细粒度 carve-out（只读岛、可写子路径重开等）且无法无损 round-trip 到旧模型时，走 bubblewrap。
- 若系统
bwrap过旧缺少--argv0，走兼容路径；缺失则使用 内置 vendor bubblewrap 并 通过通知系统 告警而非在 helper 里直接 println。
设计原因：在 安全、可移植、用户体验 三角中，优先保证 语义正确 与 可审计，其次才是「少一个依赖」。
macOS Seatbelt
要点（README）：workspace-write 策略在允许写入配置根的同时，将 .git、解析后的 gitdir、.codex 等保持只读，降低 篡改版本控制元数据 / 本地密钥 的风险。
ExecPolicy（执行策略）
用户文档入口在 docs/execpolicy.md（指向官网）。代码侧 codex-execpolicy / codex-core::exec_policy 与 命令是否允许、是否需审批 相关，与 沙箱能否执行 是互补维度：
- 沙箱：能访问哪些路径/网络。
- Exec policy：哪些命令模式在策略上被禁止或需人工确认。
MCP 与沙箱状态
codex-core 导出 MCP_SANDBOX_STATE_* 与 SandboxState（lib.rs），用于 MCP 能力协商：远程工具需要知道 当前会话沙箱视图，否则工具侧假设会与 agent 侧不一致。
自测题示例
Q：为什么 Linux 不只用 Landlock？
A： Landlock 表达力不足以覆盖所有「可写根下的只读 carve-out + 子路径可写重开」组合；错误降级会导致 假安全。因此引入 bwrap 作为更强隔离层，并在无法映射时 fail-closed（见 core README）。
Q：沙箱策略为何放在 Turn 而不只是全局 config？
A： 同一 Thread 可能在不同任务下切换 cwd/模式；与模型、审批策略并列传入可保证 请求级一致性，避免并发 Turn（若存在）或 UI 竞态导致工具使用了错误环境。
延伸阅读
- 05 apply_patch
- 11 Arg0（linux-sandbox 子进程入口）