跟进 #129：Auto 档下只读操作与工作区外 skill 读取仍逐个弹窗，希望提供持久 allowlist 或默认放行只读

[bagbag16]

现象

Claude Code 会话，权限档选「自动审批（Auto）」后，以下操作仍逐个弹确认，摩擦严重：

• 纯只读工具：Read / Grep / Glob；
• 只读 Bash：ls / cat / head / grep / find / wc 等；
• 读工作区外的 skill 源码（如 ~/.claude/skills/...），每次都触发「工作区外」审批。

用户不得已手写全局 ~/.claude/settings.json，加 permissions.allow 只读白名单 + additionalDirectories 才缓解 —— 这不该是用户自己补的活。

根因（参考 #129 已诊断）

#129 问题清单第 7 条已指出：无 app 级持久 allowlist、无 per-project 规则，逐次确认把用户推向 auto/bypass。当前 Cindy 不生成也不维护 settings.json，「记住的命令」跨会话清零。

诉求（三选一或组合）

1. 让「自动审批」真正落地为持久 allowlist，至少默认放行只读工具 + 只读命令；
2. 在设置里提供一等的 allowlist 管理（勾选「记住只读命令」），而非让用户手改 JSON；
3. 默认把 ~/.claude/skills（或整个 ~/.claude）设为受信目录，读 skill 不该弹。

关联

• 锚点：Auto-review 权限模式系统性 review:Codex 侧名不副实(实为 Full access)、默认档过激进、模式显示不稳定等问题与改进需求 #129（已关闭，其中改进需求第 5 条即「补持久 allowlist」）
• 相邻：[Bug] 切换 agent 后自动审批权限不生效并在首次请求时回退 #831 / 🐛 Bug: 自动审批(Auto)模式对话过程中被静默降级为默认权限(ask) #1077 / Auto 档对 MCP 工具完全绕过 AI 审阅，只走 server 级静态白名单 #1576 / Codex 模式下 GPT-5.6-SOL/GPT-5.5-AUTO 自动审批频繁弹出确认 #204

[dash-s-cindy]

判断

这个问题值得处理：Auto 下的日常只读操作应尽量无打扰，skill 源码也需要一条安全、可发现的只读访问路径。进一步检查发现，当前实现已经具备只读分类、附加只读目录以及 Claude 原生 settings 透传；真正需要确认和补齐的是不同审批路由下的行为一致性、skill 目录的窄范围授权，以及统一授权管理能力，而不是直接增加一个覆盖所有场景的全局白名单。

行动

1. 先按路由复现并定位逐次弹窗来源：分别覆盖 Claude 官方 OAuth 的原生 Auto reviewer，以及第三方/网关使用的 Cindy fallback。记录每次请求的工具名、参数、当前 workspace roots、裁决来源及最终 verdict。
2. 普通只读在 Cindy fallback 下仍弹窗时按回归修复：不要用持久 allowlist 掩盖。当前确定性规则已经承诺工作区内 Read/Grep/Glob/LS 和明确只读 Bash 静默放行，应优先修 adapter、路由或参数归一化。
3. 为 skill 读取设计窄只读 grant：建议复用 Cindy 已扫描出的 canonical skill 文件/目录，仅允许读取已发现的 skill 内容；处理 realpath/symlink 边界，并继续保护 .claude 下的认证、配置和其他敏感内容。不要默认信任整个 ~/.claude。
4. 持久授权另走统一权限基建：先建立 Claude Code、Codex、Pi 共用、用户可见、可查询和可清除的 session grant 契约；稳定后再决定跨会话、per-project 作用域及设置 UI。不要直接恢复 reviewer 自己的持久 allow 缓存。

源码核对

基于 origin/main@1d3c652ef3b1ad2fc32b022086b766e086a40849：

1. 常见只读操作在 Cindy fallback 中本来就应静默放行

packages/maker-core/src/agents/claude-code/auto-review-policy.ts 将：

• Read、Glob、Grep、LS、NotebookRead 映射为 read；
• Bash 映射为 exec；
• 其余未知动作保守升级。

packages/maker-core/src/agents/shared/auto-review.ts 的确定性绿灯包含常见只读命令，包括 ls、cat、head、tail、wc、grep、rg、find 等。对应测试位于：

• packages/maker-core/src/agents/claude-code/__tests__/auto-review-policy.test.ts

测试明确断言上述普通只读工具和命令为 auto-approve。因此，如果 Cindy fallback 路由下工作区内这些操作仍逐次弹窗，现有实现与预期不一致，应作为路由/接线/参数回归处理，而不是新增一层永久白名单。

需要区分的边界是：

• 单文件 Read 读取普通区外文件，当前规则仍可直接放行；
• 目录级 Grep/Glob/LS 的根位于所有 workspace roots 之外时，会进入灰区审阅，因为它可能递归遍历到区外凭证；
• 凭证路径和明确高风险命令会强制逐次确认。

2. Claude Auto 存在两条实际审批路径

当前 Claude 官方 OAuth 路由可优先使用原生 Auto reviewer；第三方/网关或原生 reviewer 失效后走 Cindy fallback。两条路径并不共享完全相同的分类实现。因此，“所有 Claude Auto 都由同一份只读白名单裁决”并不成立，复现时必须标明路由。

这也解释了为什么仅检查共享分类器单测不足以证明官方 OAuth 实机行为已经一致。

3. additionalDirectories 能力已经存在

当前产品已有一等的附加只读目录能力：

• sessions.extra_dirs 持久化会话的附加只读目录；
• StartSessionOptions.extraDirs 将其定义为附加只读引用目录；
• Claude 在每 turn 透传到 SDK options.additionalDirectories；
• Desktop 已有 ExtraDirsButton 入口。

相关位置包括：

• apps/desktop/src/main/localDb/schema.ts
• packages/maker-core/src/agents/base-agent.ts
• packages/maker-core/src/agents/claude-code/index.ts
• apps/desktop/src/renderer/components/new-chat/ExtraDirsButton.tsx

另外，普通 Claude 会话使用 settingSources: ['user', 'project', 'local']，所以用户手写的 Claude settings 会被加载。Cindy 确实不生成或管理该 JSON，但并非完全没有目录授权入口；当前缺口主要是 skill 场景没有自动、安全地接入已有目录能力，也没有统一的规则管理 UI。

4. ~/.claude/skills 仍弹窗有明确的现行策略原因

packages/maker-core/src/agents/shared/sensitive-credential-paths.ts 将整个 .claude 路径族列为敏感凭证路径。reviewAction 对敏感路径读取优先返回 prompt-each-time，这一判断发生在普通只读放行之前。

因此，仅把 ~/.claude/skills 加入 additionalDirectories 未必能解决 Cindy fallback 的弹窗；它仍可能先命中 .claude 敏感路径规则。另一方面，默认信任整个 ~/.claude 会同时放开认证和配置材料，当前没有产品意图或运行验证支持这样做，不建议采用。

更稳妥的实现是让 skill 扫描结果产生窄只读 grant：授权已发现的 canonical SKILL.md 和必要的同目录资源，而不是把整个配置根加入全局受信目录。是否允许 skill 目录内任意文件、是否跨项目共享，仍需作为明确的产品边界确认。

建议验证矩阵

至少覆盖以下组合：

路由	操作	预期
Claude OAuth 原生 Auto	工作区内 Read/Grep/Glob	不应逐次弹窗；若弹，记录原生 reviewer 原因
Cindy fallback Auto	工作区内 Read/Grep/Glob	auto-approve
Cindy fallback Auto	ls/cat/head/grep/find/wc	无危险参数时 auto-approve
两条路由	区外单文件普通 Read	核对是否一致；fallback 当前预期放行
两条路由	区外目录级 Grep/Glob/LS	允许进入灰区审阅，不应笼统视作普通工作区内只读
两条路由	~/.claude/skills/.../SKILL.md	当前可能因 .claude 敏感规则确认；新 grant 落地后应静默只读
两条路由	~/.claude 下认证/配置材料	继续强制确认或拒绝
skill grant	symlink 指向 grant 外部	不得继承信任

目前源码和单测能证明 Cindy fallback 的设计预期，但还缺官方 OAuth 与 fallback 两条真实会话的端到端复现记录；在拿到该记录前，不宜把所有弹窗归结为同一个持久化缺口。

持久授权方向

跨会话持久授权确实尚未形成产品能力，但不建议把 Auto 直接等同于永久 allowlist：

• Auto 是逐动作审阅策略；
• “本对话总是允许”是用户授权；
• 跨会话/per-project 规则又是更高一层的持久授权。

三者应共享执行接口，但不能互相替代。建议后续统一契约至少包含：作用域（会话/项目/用户）、agent/harness、工具及规则、工作区/路径边界、来源、查看与撤销、失效条件和审计信息。默认只读规则仍应留在确定性分类器中，不需要用户逐条“学习”。

相关记录

• Auto-review 权限模式系统性 review:Codex 侧名不副实(实为 Full access)、默认档过激进、模式显示不稳定等问题与改进需求 #129：最早明确列出持久 allowlist/per-project 规则缺口；后续 Auto 主链已完成，但该项未在收官范围内。
• fix(auto-review): 保留宿主审批并用当前模型静默兜底 #1227：已合并原生 reviewer 优先、Cindy fallback 的 Auto 路由，并明确跨会话永久授权不在该 PR 范围内；这是本次必须按路由复现的依据。
• fix(maker-core): 按实机语料修 Auto-review 分类器的确定性误报 #2106：已合并基于真实命令语料的 Auto-review 降噪，专门修复 grep、只读 sed、只读 gh、区内 cd、/dev/null 重定向等误报；若这些行为仍弹，应先检查发布版本和路由是否实际走到该修复。
• feat(maker-core): remember exact local review approvals #2255：曾实现跨轮次/跨会话的精确批准记忆，但最终未合并并主动关闭。关闭结论是该实现记住了 reviewer 的 allow，而不是三套 Harness 共用的用户授权；后续应先建设统一、用户可见、可查询/清除的 session grant，再设计跨会话持久化。