Auto-review 权限模式系统性 review:Codex 侧名不副实(实为 Full access)、默认档过激进、模式显示不稳定等问题与改进需求

[zqchris]

背景

用户反馈 Auto-review 模式"不定期自己切回 default、非常不稳定",排查后对整个 Auto-review / 权限模式功能做了一次系统性 review,并与 Claude Code 原生 auto mode、Codex 原生 Auto 档做了对比。结论:除了显示层的同步 bug,Codex 侧的 Auto-review 存在语义层面的根本问题。本 issue 汇总全部发现与改进需求,供跟进。

核心事实

同一个 "Auto-review" 标签,两个 agent 下语义相反:

	Claude 侧 auto	Codex 侧 auto
实际行为	透传 'auto' 给 cc 二进制,由模型分类器逐动作审查(真有 review)	approval_policy: never + sandbox: danger-full-access,零审查、零沙箱、网络全放开
与 Full access(bypassPermissions)的区别	有实质区别	无任何功能区别,仅图标/配色/文案不同

• 映射代码:packages/maker-core/src/agents/codex/index.ts:266-286(mapPermissionToCodex),注释自认 "auto 直接对齐 bypass 的底层权限形态"。
• 历史(git 历史已随迁仓压平,仅存注释 :271-282):Codex auto 原为 on-request + workspace-write + 客户端自动代答提权;因 Codex app-server 内部安全裁决模型抖动时会卡死 Feishu/WebFetch/Bash 且不可恢复,为了可用性把整条审查通道拆掉,直接给到 never + danger-full-access,名字没改。
• 对比:Codex 官方 Auto 档 = workspace-write + on-request(保沙箱,workspace-write 下网络默认关闭);Claude Code 官方 auto mode(2026-03 上线)= 独立分类器模型逐动作审查 + 大量默认拦截规则 + 连拒 3 次/累计 20 次自动回退人工审批。Cindy 的 Codex "Auto-review" 比两家原生的自动档都激进,等同官方带 danger- 前缀、需显式 flag 的档位。

问题清单

P0

1. 默认档 = 无审查全权限。桌面(apps/desktop/src/renderer/state/newMakerDraft.ts:120,130、hooks/useCCSessions.ts:165)、手机(apps/mobile/app/sessions/new.tsx:1657)、IM bot(apps/desktop/src/main/im/defaultSessionSettings.ts:81)、远程主机会话(RemoteHostDetail.tsx:314)的新会话默认全是 auto——对 Codex 即 danger-full-access。切入 auto/bypass 无任何确认或警告(对比:cc 进 bypass 首次有责任确认弹窗)。hook 后台工作区默认更是 bypassPermissions(hookWorkspacePrefsLogic.ts:89)。
2. "Auto-review" 标签对 Codex 用户构成安全误导。橙色 Sparkles + "自动审批"文案让用户以为比红色 "Full access" 安全一档,实际权限范围一模一样。i18n 描述里虽写了"权限范围与完全访问相同",但标签本身承诺的"审查"并不存在。

P1

3. 模式显示不稳定 bug(用户可感知的"自己跳回 default"):permissionMode-only 的 sessions:update 不广播 sessions:patched(apps/desktop/src/main/localDb/ipc/sessions.ts,广播仅覆盖 projectTarget/cleared/pinned),侧栏列表缓存永远停在旧值;CCAgentSessionView.tsx 每次 sessionId effect 把 serverSession 置 null 再异步重取(失败静默吞),窗口期 UI 回退到过期缓存;ChatInput.tsx 的 ?? 'acceptEdits' 兜底对 Codex 是非法值,被 PermissionSelector.normalizeMode 折叠成第一项 ask。后果不只是烦人:显示 Default、runtime 实际还是 auto,显示与实际权限脱钩。
4. 跨 agent 语义割裂:同一标签下 Claude 有审查、Codex 没有,用户换 agent 心智模型失效。
5. stale in-code 描述:codex/index.ts:587 仍写"工作区内可读写"(workspace-write 时代旧文案),与实际映射及 i18n 矛盾,i18n key 缺失时会把错误描述暴露给用户。
6. 收紧模式的脆弱兜底:auto/bypass 为 never 档,turn 内本地拦不住,切回 ask 只能中断当前 turn + 10s ack 超时(codex/index.ts:4062-4069,TIGHTEN_INTERRUPT_ACK_TIMEOUT_MS);Codex 侧也没有 Claude canUseTool 那样的本地 fail-closed 分支。
7. ask 模式审批能力弱:无 app 级持久 allowlist、无 per-project 规则;Codex 的审批卡片连 "Always allow for session" 都没有(SDK 不回 session-scoped suggestions),逐次确认的摩擦把用户推向 auto/bypass。
8. PermissionMode 类型是裸 string(userPreferences.types.ts:7),无编译期约束。

做得好、应保留的部分

• 高风险 MCP 内置操作(删除/合并类)的 forcePrompt 强制逐次确认,auto/bypass 也不放行,且拒绝切模式时的批量放行(codex/index.ts:2466-2483, 2522-2527)。
• Claude 侧 settings.json 权限规则纯透传(settingSources: ['user','project','local']),保留 cc 原生 protected paths、rm -rf 熔断等机制。
• 切模式时挂起审批卡的 dismiss 语义清晰(切宽松放行/切严格拒绝)。

改进需求(按优先级)

1. 恢复 Codex auto 的实质区分。最小改法:auto 改为 workspace-write + never——保沙箱、去审批,工作区内全自动、出界操作被沙箱直接挡掉,auto(有沙箱兜底)与 bypass(无沙箱)形成真实差异,回到 Codex 官方 Auto 档的安全水位。更完整的改法:回到 on-request + workspace-write + 客户端自动代答,对当年"安全模型抖动卡死"的问题改用裁决超时兜底(N 秒无响应按预设策略放行/弹窗),而不是拆掉整条通道。
2. 改名或补审查,二选一。短期不做审查就别叫 Auto-review(改"自动执行/Full auto"并考虑与 bypass 合并);长期方向:在 maker-core 的 awaitApprovalDecision 处补 Cindy 自建裁决层(复用已有模型通道做 pre-approval 分类),对齐 Claude auto 语义,让 Auto-review 全线名副其实。
3. 默认档与进入门槛收敛:新会话默认降到 ask(或至少 Codex 侧降档);首次切入 auto/bypass 加一次性确认弹窗(记住选择不重复弹)。
4. 修显示同步 bug:sessions:update 对设置类字段补 sessions:patched 广播(或选择时乐观 patchLocal);ChatInput 的 'acceptEdits' 兜底改为 per-agent 默认值。
5. 小项:删 codex/index.ts:587 stale 描述;PermissionMode 收紧为字面量联合;验证 Claude auto 在账号不满足 cc auto mode 门槛(plan/model/管控开关)时的实际表现并做 UI 降级;中期补 per-project 持久 allowlist 降低 ask 摩擦。

注意事项

• 需求 1/2/3 动 maker-core 权限映射与默认行为,按 AGENTS.md 规则 10 属需实测评估的高风险路径;标签/文案改动涉及四语言 i18n 同步(规则 18);"Auto-review 为默认档"可能是产品有意取舍,动手前建议先与 Lizi 对齐方向。
• 权限模式在 device-link / mobile 均有通道(maker:set-permission-mode),上述任何语义调整需同步核对远程/手机形态(规则 26)。

[dash-s-cindy]

是的，我昨天也发现这个问题了

来自 Slack #makecindy

[dash-s-cindy]

改动比较复杂，我找 <@U08GQAA1VUZ> 来改这个。

来自 Slack #makecindy

[dash-s-cindy]

<@U0BJ87U4URG> (Cindy) 你搜一下我们之前的聊天记录，以及我发过的 issue，关于自动审查，不止是 Codex，Claude下也有很多问题。是个待处理的系统性大工程。还需要很多关键决策，你都帮我们整理一下列一下。

来自 Slack #makecindy

[dash-s-cindy]

本评论由 Cindy 从 Slack 频道 #makecindy 自动同步而来。

---

可以。建议把范围扩成“跨模型的 Auto-review / 权限模式系统性 review”，而不是只修 Codex 映射。关键决策至少包括：

1. 各模式的统一语义，以及 Claude/Codex 的能力映射
2. 新会话默认档位与高权限模式的进入条件
3. Auto-review 是真实逐动作审查，还是受限沙箱执行
4. 权限状态的单一事实源、广播、缓存与异常兜底
5. 桌面、移动端、IM bot、远程主机的行为一致性
6. 确认/警告 UX，以及模式名和实际运行状态的展示
7. 旧会话兼容、迁移与灰度回滚方案
8. 审计日志、测试矩阵和安全验收标准

我会按“历史问题 → 当前行为 → 风险 → 待决策选项 → 建议优先级”去重整理。若有私聊或不易检索到的旧 issue，也请补链接，避免遗漏。

[horizon554]

这次改了什么

Fixes #129。

• 保留 Codex Auto-review 的真实语义：untrusted + workspace-write，可信命令自动执行，非可信命令仍会询问；不会再等同于 Full access。
• 所有用户会话路径中的缺失或非法权限值 fail-closed 到 ask，避免静默放大权限。
• 从安全权限档进入 Full access 时，在桌面（含远程控制）、手机和 IM 入口增加一次明确确认；取消不会修改运行时、数据库或偏好。
• IM 权限切换采用运行时优先，持久化失败会回滚运行时并显示失败状态。
• Full access 下的内置高风险操作仍保留独立确认。

怎么验证的

• @lizi/maker-core Codex tests：155 passed
• @lizi/maker-shared permission tests：21 passed
• Desktop 定向权限 / device-link / i18n tests：60 passed
• Mobile 定向权限 / input projection tests：23 passed
• Desktop / Mobile typecheck passed
• git diff --check passed

风险

无数据库 migration、协议或原生层改动。取消 Full access 或权限持久化失败时保持旧权限；必要时回滚本 PR 即可恢复原入口行为。

后续范围

requested / effective / reviewStatus、自建统一 reviewer、持久 allowlist 等属于 Slack 所说的系统性工程，本 PR 只做止血，不纳入本次范围，可拆成后续任务。

[horizon554]

进度更新：PR 已合并

PR makecindy/cindy-temp#359 已于 2026-07-22 合并到 upstream/main。

• PR：fix: preserve Codex Auto-review semantics
• 合并提交：b95bed0876f90454260718cc45be34e4ef29c13f
• review 期间补充修复：手机端 Full access 确认文案按系统语言适配；新建会话自动默认、权限记忆恢复和切换 agent 路径均要求显式确认 Full access，取消时保留当前安全权限。
• 最终验证：Mobile 全量 2005 个测试通过，Mobile typecheck 通过，git diff --check 通过。

本 issue 的止血范围已完成。requested/effective/reviewStatus、统一 reviewer、持久 allowlist 等系统性工程仍建议拆分为后续 issue，不纳入本次修复。

[zqchris]

Claude 侧修复已在 #964 落地(head 2b295f2)。

做法:遵循本 issue 定的「harness 负责跑,review 归 Cindy」——不再依赖任一 CLI 的原生分类器,抽出一套 harness 无关的确定性审查核心(packages/maker-core/src/agents/shared/auto-review.ts),各 harness 只写薄 adapter 把工具调用/审批请求翻译成归一化动作,交同一套 core 裁决。Claude auto 改走 SDK default 让 canUseTool 生效后落到该 core;auto 从 moreOpen 摘除(切档挂起授权 fail-closed,与 Codex 侧对称)。这就是本 issue 想要的跨 agent 统一。

判定档(借鉴 Hermes green/red light,零 LLM 裁判):绿灯(只读/区内写/明确只读 shell)静默放行;红灯(越界写/外发/不确定)升级、可本会话记住;危险(destructive/凭证/RCE)必问不可记住。不确定一律 fail-closed 升级——解决了放纵型模型橡皮图章、也解决了 haiku 在 auto 下 fail-closed 拦死。

状态:所有 review thread 已 resolve,CI checks 绿,maker-core 1136 单测 + typecheck 全绿。经过九批对抗式安全评审加固,覆盖:凭证路径读写、SSRF(云 metadata / 整数·十六进制·八进制·缩写 IP / 重定向 / DNS 改路由 flag / URL glob / userinfo)、RCE(curl/wget/sort/rg/find/git 各类程序执行 flag、env 注入、git ext:: 传输、ls-remote config 劫持)、参数展开 / 花括号展开绕过、路径伪装、引号/反斜杠规避等。目前待最终人工复审(MagicLizi 那条 CHANGES_REQUESTED 停在修复之前的旧 commit)。

Codex 侧此前已有止血;至此两侧语义对称。

[zqchris]

✅ 已合并:#964 已由 MagicLizi 合入 main(merge commit ff43d786,2026-07-30)。

Claude 侧 Auto-review 改用 harness 无关的确定性审查核心落地,与 Codex 侧语义对称——本 issue 想要的跨 agent 统一达成。合并前经过多轮对抗式安全评审加固(凭证路径读写、SSRF 各类 IP 混淆/重定向/DNS 改路由/URL glob/userinfo/尾点、RCE 各类程序执行 flag 与 env 注入/git ext::传输/config 劫持、参数与花括号/ANSI-C 展开规避、路径伪装、远端会话平台 fail-closed 等);命令字符串层静态不可判的少数残口(PATH 解析、恶意 .git/config 的 textconv/pager 劫持、DNS 重绑定、符号链接)已在源码文件头集中存档,归网络出口/OS/会话信任层缓解。