bug: codex 0.152.1 升级后 /review 无法执行任何命令

[MagicLizi]

问题描述

把随包 codex 从 0.145.0 升级到 0.152.1 后，/review 的 Reviewer 任务无法执行任何命令。

0.152.1 新增了一层命令策略：在 approvalPolicy: 'never' + 受限沙箱的组合下，命令被直接拒绝，而不是升级去请求审批。/review 用的正是这个组合（packages/maker-core/src/agents/codex/index.ts:5148）：

if (reviewMode) return { approvalPolicy: 'never', sandbox: 'read-only' };

0.152.1 的工具清单里没有独立的读文件工具（只有 exec_command / write_stdin / request_user_input / view_image），Codex 读代码依赖 exec_command。命令被拒等于 Reviewer 读不到任何东西，无法满足 docs/product-rules/review-product-direction.md §1.3「Reviewer 必须重新读取成果并验证结论」与 §1.5「必须同时验证代码路径和真实交付结果」。

期望：Reviewer 在只读沙箱内仍可执行只读命令。
实际：命令被策略拒绝，Reviewer 无法读取任何成果。

环境

• Cindy: main @ 6e114a3（codex 升级目前是本地未提交改动）
• 平台: Windows 11 Pro 26200 / win32-x64
• codex: 0.145.0（当前随包）→ 0.152.1（升级目标）

复现步骤

1. 用 0.152.1 真二进制起 app-server 会话，thread/start 传 /review 的权限组合（approvalPolicy: 'never' + sandbox: 'read-only'）。
2. 让模型调用 exec_command 读工作目录下的一个文件。
3. 命令被拒，工具输出为策略拒绝错误；换 0.145.0 同样步骤可正常执行。

实测矩阵（Windows，真二进制 + app-server）

权限组合	对应 Cindy 模式	0.145.0	0.152.1
never + read-only	/review	✅ 执行	❌ blocked by policy
never + workspace-write	—	✅ 执行	❌ blocked by policy
never + danger-full-access	Full access	未测	✅ 执行
on-request + workspace-write（host 批准）	手动审批	未测	✅ 执行
on-request + workspace-write + auto_review	Auto-review	未测	⚠️ 未被硬拒，升级给内置 reviewer（未端到端确认）
untrusted + read-only（host 批准）	候选修复	未测	✅ 执行

拒绝原文：

exec_command failed for `"...powershell.exe" -Command "..."`:
CreateProcess { message: "Rejected(`...` rejected: blocked by policy)" }

已排除的干扰项：不是 CODEX_HOME 位于系统临时目录导致的（把 CODEX_HOME 移出临时目录后结果一致）。

影响面

• Full access、手动审批：不受影响
• Auto-review：不受影响（有审批通道，升级给 Codex 内置 reviewer）
• /review：受影响
• 现有用户：不受影响 —— 该 codex 升级尚未提交、未发版，问题在发布前被 e2e 顶出来

第二处阻塞

即使把 reviewMode 的 approvalPolicy 换成 untrusted，index.ts:7226 仍会拒掉升级上来的请求：

if (reviewMode) return { decision: 'decline' };

这行在原设计下无害（never 不会产生审批请求），属防御性写法。

建议方案（需产品裁决）

1. reviewMode 权限改为 { approvalPolicy: 'untrusted', sandbox: 'read-only' }（实测该组合在 0.152.1 上可正常执行命令）。
2. commandExecutionApproval 在 reviewMode 下不再无条件 decline，改为接受。

安全边界不变：沙箱层面仍是 read-only，写入依然不可能；host shell policy 检查仍在前面生效。变动的只是「reviewMode 不接受任何审批升级」这条实现假设 —— 它成立的前提（never 下不产生审批请求）在 0.152.1 已失效。

按 review-product-direction.md §5，这属于改动「已裁决」部分，请 @zqchris 裁决是否照此修改，或选择押后 codex 升级。

同一次升级的另一个问题（已修，待提 PR）

0.152.1 开始把本地生成的 item id 回传进 Responses input（0.145 一律不带 id）。Cindy 的 exec custom→function 适配器只改写 type 不改写 id，导致自建 Responses provider 返回 400：

{"error":{"code":"invalid_value","message":"Invalid 'input[6].id': 'ctco_…'. Expected an ID that begins with 'fc'.","param":"input[6].id","type":"invalid_request_error"}}

修复：方言翻转时同步翻转 id 前缀（ctco_→fco_、ctc_→fc_），认不出的前缀退回不带 id（0.145 形态）；同时给 codexExecFunctionAdapter e2e 的假上游加 prefix↔type 校验，让后续 bump 能自动发现同类 wire 形状变化。

未覆盖

• 只在 Windows 上验证，错误是 CreateProcess 形态，可能是 Windows 专有策略实现；macOS / Linux 未测。
• 用与 /review 等价的权限组合验证，未从新构建的 Desktop 点击 /review。按 review-product-direction.md §1.5，这两者必须区分记录。

[dash-s-cindy]

判断：/review 需要在发布前处理，否则升级到 Codex 0.152.1 后可能无法读取成果并完成复核；现有已发布用户暂不受影响。当前证据支持“Codex 新版本的权限策略行为与 Cindy Review 的既有假设不兼容”，但尚不足以证明该行为在所有平台一致，也不足以证明候选修复已完成 Desktop 端到端验证。\n\n进一步检查当前 main 快照 5d19150d52fbc550011f2c897599f4a7ae9b6d13：\n\n- packages/maker-core/src/agents/codex/index.ts:5147-5149 在 reviewMode 下仍返回 { approvalPolicy: 'never', sandbox: 'read-only' }。\n- Review 同时使用命名的 cindy-review-readonly 权限配置；该配置在 :4616 附近限制根目录、工作区和显式成果路径为只读，并拒绝 .git 与敏感凭据路径。也就是说，当前产品已经具备“独立 Review、只读成果范围、敏感路径拒绝”的安全结构，缺少的是新 Codex 策略下可靠的只读命令执行通路。\n- 当前测试 packages/maker-core/src/agents/codex/index.test.ts 的 Review 用例明确断言 thread/turn 使用 approvalPolicy: 'never'，并断言 commandExecutionApproval 在 Review 中返回 decline。这证明相关行为尚未在当前树中修复，也说明把 never 改成可升级策略时必须同步改测试和审批状态机。\n- index.ts:7226 与 :7306 仍存在 Review 下直接 decline 的审批分支。即便新策略把命令变成审批请求，只改 approvalPolicy 也会继续阻断请求。\n- 当前源码搜索未找到 Issue 所述 codexExecFunctionAdapter 或 item id 前缀翻转实现，因此 Responses id 前缀问题不能视为已落地修复；它应作为同一次 Codex bump 的独立兼容性门禁，而不是假定与本 Issue 一并解决。\n\n建议的推进方式：\n\n1. 先冻结版本升级发布：在候选修复和真实验收完成前，继续使用当前已验证版本，避免把现有可用的 /review 变成发布回归。Issue 提供的影响范围也表明 Full access、手动审批和 Auto-review 与该阻塞不同，当前没有证据要求改动它们。\n2. 先做产品确认，再改 Review 权限语义：产品规则 docs/product-rules/review-product-direction.md §1.3、§1.5 已明确 Reviewer 必须独立重读成果、验证代码路径和真实交付；因此 Review 不能通过“只依赖模型已有上下文”绕过命令读取。是否允许 Review 接受升级请求属于已裁决“只读 Review”实现边界的具体落地选择，需要明确确认，不能把 Issue 作者的候选方案直接当成产品决定。\n3. 若确认采用候选方向：将 Review 的 Codex 权限改为 approvalPolicy: 'untrusted' + 只读 sandbox/profile；在 Review 的 commandExecutionApproval 中接受新版本产生的只读命令请求，但不得扩大文件系统、网络或显式成果范围。保留现有 host shell policy、敏感路径拒绝和 file-change 拒绝逻辑；对 file-change、MCP、动态工具等非读取能力仍应维持 fail-closed。这里的“接受”必须基于实际请求类型和只读边界验证，不能简单移除所有 Review 拒绝分支。\n4. 补齐验证矩阵：至少覆盖 Codex 0.145.0 与 0.152.1、Windows/macOS/Linux、cat/ls/git diff 等只读命令、写入工作区、写入 Review 外路径、敏感文件读取、网络访问和命令审批请求；另外必须记录“等价 app-server 模拟”与“从新构建 Desktop 点击 /review”两类结果。当前 Issue 明确缺少后者，因此不能仅凭 app-server 复现宣称修复完成。\n5. 把 Responses id 前缀问题单独设为 bump gate：为 custom→function 适配器增加真实 wire 形状回归，确认 ctco_→fco_、ctc_→fc_ 以及未知前缀降级行为，并在自建 Responses provider 上验证 400 不再出现。若该修复尚无 PR 或提交证据，应与 Review 权限修复分别追踪。\n\n相关记录：\n\n- PR #2376：处理 /review 在真实工作区无法启动以及审错成果范围的问题；它与本 Issue 不是同一根因，但直接支持“Review 必须以真实交付链路和正确成果范围验收，而非只验证 wiring”的判断。\n- PR #2474：修复 Auto reviewer 故障时静默拒绝并降级给用户确认；它针对的是审核器不可用时的 Auto 流程，不解决本 Issue 的沙箱在审批前直接拒绝命令，因此不应作为本问题的替代修复。