维护者确认：#3339 Auto 档拦截破坏性 find

[MagicLizi]

需要维护者确认的点

PR #3339 在 Auto-review 的 PreToolUse hook 里、内置只读放行之前硬拒绝 find … -delete / -exec。

这是 maker-core 权限边界的行为变化：Auto 档下破坏性 find 从「可能被只读集静默放行」变成 hook 硬拒绝，用户必须换命令或降到 Ask。请维护者确认：

1. 诊断会话里这条硬拒绝是否就是当前产品口径；
2. 只拦引号外命令位、不扩 Bash(find:*) 前缀是否足够；
3. 标题/描述格式门尚未过（缺 type 前缀与标准段落），放行后作者仍需补齐。

如何放行

• 同意：直接在 PR 上 Approve。
• 要改：在 PR 上 Request Changes。

---

关联 PR:#3339(作者 @PraiseZhu);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的技术架构调整,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断

Auto 模式下不应让 find -delete、find -exec 等有副作用的命令被上游“只读命令”快路径静默执行；如果真实会话已经证明该快路径绕过 Cindy 的 canUseTool，这里确实需要修复。

当前不建议按 #3339 的实现直接放行。现有 Cindy Auto-review 核心已经对 find 做了按目标范围和载荷风险分层，而该 PR 在 PreToolUse 阶段把相关形态统一硬拒，用户只能改写命令或切换到 Ask。这个行为不是现行共享策略的自然延伸，而是新的产品收紧；同时，当前 PR 审查已经指出合法只读查询可能被误拒。

行动

建议对 #3339 Request Changes，按以下顺序推进：

1. 先增加一个真实 Claude Auto 会话回归，固定“SDK 将破坏性 find 当作只读并在 canUseTool 前放行”的最小复现。需要同时断言命令确实执行、canUseTool/Cindy reviewer 未收到请求，而不只以“Bash completed with no output”推断。
2. 修复应复用现有 normalizeBuiltinToolForAutoReview()、reviewAction() 和 Auto decision/interaction 流程，使 PreToolUse 与正常审批入口得到相同 verdict；不要新增一套只返回 deny 的 find 专用产品策略。
3. 保留现有分层语义：
   • 普通 find -print 等只读查询继续静默放行；
   • 可证明受限于工作区子目录的 find build -delete、受限 -exec 进入灰区审阅；
   • 清空整个工作区、区外/系统范围删除及高影响载荷继续要求明确同意；
   • reviewer 判定为 block 或不可用时，仍可按 Auto 现行口径拒绝并给出原因。
4. 修复当前词法检测的误拒：不能仅扫描 find 后所有 token 中是否出现未锚定的 -delete/-exec 字样；需区分 action、谓词参数和文件名模式。PR 最新自动审查已明确指出，作为 -name 等谓词参数出现的相同文本仍可能硬拒合法只读查询。
5. 在上述行为和测试稳定前，不建议增加 Bash(find:*) 之类宽前缀；宽前缀只会扩大绕过 Cindy 细粒度裁决的范围。PR 还需要补齐 type 标题前缀和仓库标准描述段落。

代码核对

基于 main@17c9604c28f91dd8d6a4e1c8854ca3b5ed783d9a：

1. Cindy 共享核心已经识别破坏性 find

packages/maker-core/src/agents/shared/auto-review.ts 中：

• SAFE_READONLY_BINS 包含 find，但只读判定会显式排除 -exec、-execdir、-ok、-okdir、-delete、-fprintf、-fls；
• findDeleteRoots() 会提取删除遍历根；
• findExecCommands() 会提取 -exec/-execdir/-ok/-okdir 的命令载荷；
• findHasDynamicRoots() 处理 -files0-from 等静态不可证明的根；
• 删除范围和内层写目标最终进入共享的工作区、系统路径及高影响执行判定。

因此，Cindy core 本身并不存在“把任意 find -delete/-exec 当只读”的能力缺口。待修的是上游 SDK 快路径是否绕过了该 core，而不是重新定义 core 的风险档位。

2. 当前测试明确锁定了分层行为

packages/maker-core/src/agents/shared/auto-review.test.ts 已包含以下契约：

• find build -delete → prompt；
• 在 /repo/build 执行 find . -delete → prompt；
• 在工作区根执行 find . -delete → prompt-each-time；
• find / -delete、find / -exec rm -rf {} + → prompt-each-time；
• find build -exec rm -rf {} + → prompt；
• find . -printf ...、find . -name x -ls → auto-approve；
• -fprintf、-fls → 至少升级为 prompt；
• 引号拼接、反斜杠拆分、参数展开等 -exec/-delete 形态已有回归覆盖。

统一硬拒会把这些有意区分的 prompt 与 prompt-each-time 压成同一种 deny，改变现行产品语义。

3. Desktop 自己注入的 allowedTools 不包含 Bash

apps/desktop/src/main/maker-host/mcp-tool-approval-policy.ts 的 getDesktopClaudeReadOnlyAllowedTools() 只从精确的只读 MCP 工具表派生 mcp__<server>__<tool> 名称；其测试也明确断言结果不包含 Bash。

packages/maker-core/src/agents/claude-code/index.ts 会把这份列表传给 SDK，但没有添加 Bash 或 Bash(find:*)。因此，如果破坏性 find 确实被静默执行，最可能需要修的是 Claude SDK 自身的内置只读判定与 Cindy 回调之间的顺序，而不是 Cindy Desktop 已配置了一个宽 Bash 白名单。

4. #3339 当前实现仍有已知误拒

#3339 最新自动审查给出 3/5，并明确认为尚不适合合并：当前检测对 find 后 token 使用未锚定的破坏性标志匹配，没有正确建模 -name 等会消费后续参数的谓词，因此文件名模式或谓词参数中的 -delete 字样也可能触发硬拒。

由于结果是 PreToolUse deny，这类误判不会进入 reviewer 或确认卡，而会直接中止命令；在修复前不适合作为新的权限边界上线。

实施建议

更稳妥的结构是让“SDK 快路径防绕过”只负责确保调用进入 Cindy 已有裁决，而不自己决定所有破坏性 find 都必须 deny：

1. 抽取目前 canUseTool 中对内置工具执行 Auto review 的公共函数；
2. PreToolUse 对可能被 SDK 内置只读短路的 Bash 调用调用该公共函数；
3. auto-approve 返回 continue；
4. prompt 继续走当前轻量 reviewer 的 allow/block/ask 三态；
5. prompt-each-time 走现有逐次确认；
6. block、投递失败和超时使用现有结构化拒绝原因，不新增无解释的硬拒路径；
7. 确保同一次工具调用不会被 PreToolUse 与 canUseTool 重复审阅，可通过同调用身份的有界去重或统一 dispatcher 解决。

如果 SDK hook 接口无法表达 reviewer/确认流程，而只能 allow/deny，那么这就是实现方案的真实阻塞点：在维护者明确接受“Auto 中所有破坏性 find 永久硬拒”之前，不应把接口限制直接升级为产品口径。可以先保留现有权限链，或把审批桥接能力作为前置改动。

验证建议

至少覆盖：

场景	预期
find . -print	静默放行
find . -name '*-delete*' -print	不因参数文本误拒
find build -delete	进入现有灰区审阅，不统一硬拒
在工作区子目录执行 find . -delete	进入灰区审阅
在工作区根执行 find . -delete	明确同意或按现有无人值守策略拒绝
find / -delete	明确同意，不可被记忆为普通 allow
find build -exec rm -rf {} +	按遍历根和载荷范围裁决
find / -exec rm -rf {} +	明确同意
find . -exec printf '%s\n' {} +	不与删除载荷等价处理
引号内 echo 'find . -delete'	不误拒
引号拼接、反斜杠、变量/brace 形成 action	不能绕过
Claude 官方路由与网关/fallback 路由	verdict 语义一致
本地与 SSH 会话	使用各自真实 cwd、platform 和 workspace roots

除纯函数测试外，需要至少一条真实 Claude SDK 集成测试证明：修复前命中 SDK 快路径，修复后调用进入 Cindy 裁决且不会重复审阅。

相关记录

• Auto 档下 find -delete 不再被内置只读集静默放行 #3339：本 Issue 的直接实现 PR；确认了拟新增的 PreToolUse 硬拒路径，同时其最新审查记录了合法只读查询误拒。
• feat(maker-core): Auto-review 改用 Cindy 确定性审查核心,统一 Claude/Codex 两 harness #964：已合并并确立 Claude/Codex 共用 Cindy 确定性审查核心，以及 auto-approve / prompt / prompt-each-time 的分层语义。本修复应接回该核心，而不是建立平行的 find deny 策略。
• fix(auto-review): 保留宿主审批并用当前模型静默兜底 #1227：已合并并进一步明确 Auto 的产品语义：安全动作静默放行，灰区由 reviewer 裁决，高风险动作可能拒绝或要求确认；跨会话永久授权不在该范围。它不能支持“所有破坏性 find 一律硬拒”的结论。
• fix(ios-simulator): 让 shell 守卫匹配它声明的威胁模型，停止误拒普通命令 #2414：已合并的 shell 守卫重构。该记录提供了直接经验：尝试用不断扩张的文本解析覆盖 shell 语义曾造成真实开发命令误拒，最终维护者接受了按明确威胁模型收窄判据。Auto 档下 find -delete 不再被内置只读集静默放行 #3339 当前另写轻量词法器时应避免重复这类问题。

[PraiseZhu]

关联 PR #3339 已按 owner 指示关闭，本确认 issue 一并关闭。

[zqchris]

关联 PR #3339 已合并/关闭,讨论随之关闭。