Codex 在 OpenSpec Workbench 里怎么跑：一次文件写入失败暴露的沙箱配置问题

作者在用 OpenSpec Workbench 驱动 Codex CLI 时发现：agent 报告退出码 0，但文件根本没写进去，因为工作区被当成只读。文章复盘了这次踩坑，讲清了 stage 如何决定沙箱模式、原生 CLI 与 ACP bridge 两种适配器的差异，以及如何用 CLI 命令检查运行记录。

一次 exit code 0 但文件不存在的失败

• Codex CLI 0.164.0 在 2026 年 10 月 24 日的试运行中，agent 声称工作区只读，写入没有发生，但适配器只看进程退出码，把这一轮当成了成功
• 问题根源是两个默认值没显式配置：Codex 需要明确知道能在哪里写，Workbench 需要读取每一轮实际发生了什么

沙箱模式由 stage 决定

• 在 Harness Settings 里，一个 stage 可以指定 codex-cli 作为 agent，并选择模型和 reasoning effort
• Propose、update、apply、verify 四类 stage 使用 workspace-write 沙箱，因为验证阶段要写构建产物和缓存
• Review 阶段使用 read-only，防止审查过程改动代码
• Workbench 会在启动 agent 前解析工作目录：如果变更有自己的 worktree，就从那里运行，Codex 再对子进程强制执行自己的文件系统沙箱

实测验证沙箱边界

• 试运行中 workspace-write 模式允许在 worktree 内写入，拒绝写入其父目录，允许写入系统临时目录
• 所选模式是 Workbench 检查调用的一部分，避免配置与实际执行不一致

两种适配器，两种传参方式

• 原生适配器运行 codex exec --json，输出流里带回合结果、消息、命令退出码、变更文件和 token 用量，Workbench 能看到失败的回合
• 选择 codex-cli-acp 则走单独安装的 @agentclientprotocol/codex-acp 桥接：会话打开时桥接列出可用选项，Workbench 校验请求的模式、模型和 effort 后再发 prompt
• 如果请求了不支持的模型或 effort，stage 会直接报错并列出桥接实际支持的选项；首次 apply 实测用的是 bridge 2.2.2，成功返回了文件变更和用量
• 两条路径共享同一套 stage 到沙箱的策略，桥接还能在 stage 运行中发送上下文更新

动手试一遍

• 挑一个小改动放在独立 worktree 里，在 Harness Settings 中把 Codex 分配给 Review 和 Apply，按顺序运行这两个 stage
• 打开 run 输出查看每个 stage 做了什么；装好 CLI 后可用 openspec-ui-cli show agents 查看注册的适配器，用 openspec-ui-cli show run <runId> 查看持久化的运行记录
• 实现决策和实测细节记录在 ADR 0051 和 ADR 0052 中