权限分析、审批与单调 Guard

结论：授权是分层的，只有最终否决具有单调性

1. 六个容易被相似产品文案混为一谈的概念

最反直觉的是 approval/policy = never：它表示“永不弹出询问；凡需审批的动作一律拒绝”，而不是“不询问就批准”。全访问预设之所以无需询问，是因为沙箱本身已经开放，并非 never 构成授权。

2. 端到端决策图有两个审批入口

模型工具调用
  → durable tool/call 已存在
  → 参数脱离原引用并冻结
  → tools/pre-execute waterfall ── 拒绝 ─────────────→ 错误结果
              │
              ├─ ask → ApprovalService → allowed-once / 拒绝
              │
              └─ 允许
                   ↓
             全局 + scoped 单调 guard ───────────────→ 错误结果
                   ↓
             around wrapper → 工具体
                                  │
                                  └─ shell（bash/pwsh）或 fs sandbox_permissions
                                     → 严格扩权检查
                                     → ApprovalService
                                     → 仅为本次调用标记更宽模式
                                  ↓
                           有外部效果的后端执行
                                  ↓
                         post 策略 → 持久结果

通用入口在 guard 与工具体之前询问。沙箱入口位于 shell（bash/pwsh）或 fs 工具体内部，但仍发生在进程启动或文件变更之前。因此，通用 pre 监听器与工具特定的扩权请求可能对同一次调用各问一次；组合方应避免重复策略。反过来，guard 也可以在工具特定弹窗出现前，根据冻结后的扩权参数直接拒绝。

3. 风险由各层提出，并未被中心化评分

PreToolDecision 只有 allow、deny(reason) 与 ask(reason?)。内建代码里没有风险等级、数值分数、通用命令分类器或带特权的“批准 token”。waterfall 末端默认允许，所以需要广泛风险分类的部署必须组合自己的监听器；内建沙箱工具采用的则是一对显式参数：sandbox_permissions 与非空 justification。

4. 为什么 tools/pre-execute 是可扩展策略，而不是不可绕过的闸门

pre 阶段是异步且按 scope 路由的 waterfall。监听器可以调用 next 继续下游、替换下游决策，或直接短路。因此注册顺序与 prepend 会影响结果。这个特性适合 hook、部署策略与机器审查器，但也意味着：若把“绝对拒绝”写成普通监听器，更靠前的监听器可以不调用下游、直接返回允许，从而绕过它。

5. ApprovalService 是封闭且 fail-closed 的询问边界

在 ToolRuntime seam 上，缺少 ApprovalService 或调用没有 Agent 也会拒绝，因为此时不存在可审计的 Session 和路由身份。只有精确的 allowed-once 分支继续；rejected、cancelled 与 unavailable 保留不同错误文案，便于诊断。APPROVAL-ASK-MAPPING

6. 审计事件对可持久重放，但在线等待本身不可重放

开放 turn
  → append approval/asked { 新 id, toolName, callId?, reason? }
  → 等待回答器 waterfall
  → append approval/decided { 同一 id, 封闭结果 }
  → 返回结果

审批请求只能发生在开放 turn 内，因为 turn 是 Session 日志的提交与重放边界。请求刻意不重复携带参数：callId 将它链接到已经记录、已经呈现的工具调用，避免两份参数发生漂移。两个审计事件均为 log-only，不是模型 transcript block。模型通过 runtime context 得知常驻策略，并最终收到工具结果。APPROVAL-AUDIT-EVENTSAPPROVAL-REQUEST-SHAPEAPPROVAL-AUDIT-REQUEST

7. 取消具有明确的竞态语义

若请求 signal 已中止，审批会在回答器分派前得到 cancelled。否则服务令回答器与 signal 竞速；取消立即结算，之后到达的回答成为无效操作。回答器计算会被隔离，但不会被强制杀死。

工具准备阶段会在策略前、审批后和分派前再次检查调用方取消。如果正是取消导致审批取消，结果是 ABORTED_BEFORE_DISPATCH；已经完成的策略拒绝可能作为信息更充分的结果保留。同进程工具体一旦开始，ToolRuntime 会等待它达到静止点，然后把原本成功的结果改为 aborted。工具作者必须把 signal 传给子进程或 provider。APPROVAL-CANCEL-DISPATCH

8. 预设是覆盖两个独立 knob 的持久常驻意图

预设表条目包含机器 key、沙箱模式、审批策略与可选呈现文本。custom 保留给派生状态：两个有效 knob 不匹配任何条目时才出现；它不能被配置或选择。若 shell 不声明约束能力、默认值无法解析，或组合默认值不匹配任何预设且又未显式指定默认值，服务会在加载期失败。APPROVAL-PRESET-CONFIG

当前值由真实 knob 状态派生。如果上次记录的选择仍匹配，它会在多个同 bundle 名称中获胜；否则选择表中第一个匹配项，仍无匹配才是 custom。选择预设时先 append 意图事件，只为确实变化的 knob 写事件。APPROVAL-PRESET-DERIVEAPPROVAL-PRESET-WRITE

9. “未来 Session 默认值”与“当前 Session”是两种不同变更

真正新建的 Session 会读取最新用户设置，并在同步 session/created 发布期间固定全部三个权限事实；这早于创建返回、Agent 发布和首次 prompt，但不是早于 SessionStore 入表。带 seed、resume 或仅部分初始化的 Session 会保留自身有效权限，只补充缺失事实。因此，之后修改 Settings 只影响未来 Session，不会改变现有 Session。APPROVAL-PRESET-PIN

可选 permissions projection 暴露预设表选项与有效当前值；projection key 不存在意味着该能力未被组合，客户端应隐藏控制项。裸 /permission 命令报告当前值与可用值；/permission <key> 校验 key，并与 UI 共享同一个服务写入路径。APPROVAL-PRESET-PROJECTION

10. 单次沙箱授权必须严格更宽、明确提出且转瞬即逝

schema 公布封闭目标词表，但运行时会相对本次调用的有效常驻模式检查“严格更宽”。两个扩权字段必须成对出现，理由不能为空。同级或收窄请求会在弹窗前失败。APPROVAL-ESCALATION-LADDER

随后 resolver 要求 ApprovalService 与 Agent 都存在，把目标模式与理由记入审批 reason，并且只接受 allowed-once。返回模式只是单次调用的局部值；它不会 append sandbox/mode，也不会改变预设。APPROVAL-ESCALATION-FLOW

11. Shell 与文件系统共享审批编排，再由不同后端真正执行约束

Bash 与 PowerShell 都先校验参数、解析常驻策略，在提出扩权时等待审批，把返回模式标到请求，然后才启动前台进程或提交后台 job starter。因为对象 schema 是开放的、呈现并不等于执行，未公布的扩权字段在当前 executor 不支持沙箱时仍会由工具体拒绝。APPROVAL-BASH-EXECUTIONAPPROVAL-PWSH-EXECUTION

文件系统变更工具使用共享 controller，执行同样的字段配对、常驻策略解析、审批与单次标记。provider 返回沙箱拒绝时，它会转换成结构化错误标记和“精确重试”提示；其他 provider 错误保持原样。APPROVAL-FS-ESCALATION

12. 被委派的 child 不继承 parent 的单次授权

创建 child 时，运行时同步捕获的只有 parent 的显式 Session 沙箱覆盖值——既不捕获部署默认值，也不捕获单次授权——并且只要审批能力存在，就把 child 的审批策略固定为 never。这些带 delegation source 的事件写在任何 fork seed 之后，因此旧 seed 无法重新开放 child。child 还会收到模型可见说明：需要审批的操作会被拒绝。APPROVAL-CHILD-PIN

13. Web 审批是稳定的 server request，不是新的 unary RPC

host 发送带稳定 rpcId 的 approval/requested，其中包含 Session id、approval id、工具名、可选 call id 与 reason。客户端响应复用相同 rpcId，并且只能提交 allowed-once 或 rejected；cancelled 与 unavailable 仍由 host 产生。APPROVAL-WIRE-CONTRACT

proxy 回答器会认领最新、匹配、未决定且未被其他 pending 项认领的 approval/asked 事件。如果找不到这条审计事实，它会交给下游，而不是凭空创建可回答请求。pending 项能跨浏览器断线保留；打开新 mux 时会用同一 id 重放。abort 与 proxy teardown 会将其结算为 cancelled。APPROVAL-WEB-REGISTRYAPPROVAL-WEB-REPLAY

响应先按 rpcId 路由，再经过解析，并且必须回显完全相同的 Session 与 approval id。第一个合法响应删除 pending 项；畸形、外来、过期与迟到响应都会被拒绝。APPROVAL-WEB-RESPOND

14. 审批面板是一次性的，但它展示的证据并不自包含

请求 pending 时，对话 UI 会用可滚动卡片替换 composer，显示 reason、可选命令、“拒绝”与“仅允许一次”。首次点击后按钮锁定；传输失败时重新启用；收到 resolved frame 后面板消失。只有当 root running tool call 的 JSON 参数包含字符串 command 时，界面才会解析并展示命令；参数畸形、嵌套、无法配对或非 shell 调用都不显示命令行。APPROVAL-UI-PANEL

15. 权限选择器提供便利与风险确认，但不是执行边界

当前 Session 选择器过滤 custom 并提交 /permission <key>；可选命令弹窗执行同一路径；Settings 行用 expected revision 写入未来 Session 的 defaultPreset。APPROVAL-PERMISSION-SETTINGS-WRITE三者都消费服务端公布的选项，但其风险对话框只由一个硬编码机器 key 触发：danger-full-access。APPROVAL-PERMISSION-COMPOSERAPPROVAL-PERMISSION-DECORATIONAPPROVAL-PERMISSION-SETTINGS

16. 浏览器请求信任防御 origin 混淆，但源码明确说明它不是身份认证

每个 /api 请求都必须通过 Host 校验、显式 cross-site Fetch Metadata 拒绝，以及 Origin 存在时的同 authority 校验。这能阻止 DNS rebinding 与普通恶意网页的跨站请求。源码明确把网络可达性和身份认证留在范围外。APPROVAL-WEB-TRUST

17. ACP 是带精确所有权与单次选项的机器回答器

只有当 ACP bridge 拥有完全相同的 Agent，且请求携带 call id 时，它才会认领审批。它只呈现两个选项——仅允许一次与仅拒绝一次——并显式映射取消；所有未知的非允许选项都变为拒绝。它绝不会把响应升级成持久授权。APPROVAL-ACP-ANSWERER

这体现了回答器架构的意图：Web UI、ACP 或其他 provider 可以占据同一个 waterfall seam，而 ApprovalService 统一拥有词表、持久审计、取消与不可绕过的 never 策略。

18. 测试编码了负向路径，而不只是成功弹窗

APPROVAL-TOOLS-TESTSAPPROVAL-GUARD-TESTSAPPROVAL-SERVICE-TESTSAPPROVAL-PRESET-TESTSAPPROVAL-ESCALATION-TESTSAPPROVAL-WEB-TESTS

19. 两处 README 描述已经落后于生产源码

APPROVAL-DOC-PRESET-DRIFTAPPROVAL-DOC-API-DRIFT

20. 与 Codex 的窄范围比较：分层方式相似，策略丰富度不同

本节只使用 OpenAI 公开的 Agent approvals & security 与 Subagents 文档，读取日期为 2026-08-13。DeepSeek 一侧是固定 commit 的源码级证据；Codex 一侧是截至读取日期的文档级证据。本节不推断私有服务或未公开实现。

21. 设计评价、加固优先级与验证状态