权限决策点

权限要解决什么问题

痛点：LLM 可能在误解任务后执行危险操作，导致不可逆损失。

必须在工具执行前加入独立的权限层由 runtime做最终决定。

权限决策点在循环哪里

① LLM 输出 tool_use
② runtime 解析
③ runtime 查注册表
④ runtime 执行工具 ← 权限决策点在这里！⑤ 包成 tool_result 喂回

权限检查插在 step 执行之前。step 内部分四层：

step 实际结构：
┌───────────────────────────────────────────┐
│ 4a. PreToolUse hook 检查 ← 自定义拦截 │
│ 4b. 权限决策 ← 本章主要 │
│ ├─ 允许 → 继续执行 │
│ ├─ 拒绝 → 跳过执行。返回拒绝结果 │
│ └─ 询问 → 弹窗让使用者决定 │
│ 4c. 执行工具实现 │
│ 4d. PostToolUse hook ← 执行后回调 │
└───────────────────────────────────────────┘

权限决策是 runtime 强制执行的，LLM 无法绕过。

三种决策结果

ask 的三种使用者响应：

• 点击“允许” → 本次放行
• 点击“拒绝” → 本次阻止
• 点击“总是允许” → 写入 settings.json ➜ permissions.allow，后续自动放行相同调用

决策依据这方面，三层来源

┌───────────────────────────────────────┐
│ . 命令行 flag │ ← 最高优先级
├───────────────────────────────────────┤
│ . settings.json 的 permissions 字段 │
│ ├─ allow: // 白名单 │
│ ├─ deny: // 黑名单 │
│ └─ ask: // 必问 │
├───────────────────────────────────────┤
│ . 当前模式的默认行为 │ ← 兜底
└───────────────────────────────────────┘

关键认知：*模式*其实是第三层兜底——当 flag 与 settings 都没有明确规则时由模式决定默认行为：

• 默认模式的观点是。 危险工具默认 ask
• Plan 模式：所有写操作默认 tag deny*
• Auto 模式：所有工具默认 tag allow*

两层 settings 的区别 

permission rule 语法

规则的基本格式 

工具名

• 工具名：Bash、Read、Edit、WebFetch 等。说起来，
• 参数模式：`` 中描述该工具调用的 input 必须满足何种条件才匹配。
• *没有括号*的规则等价于匹配该工具所有调用。老实说，

三类规则容器 

{
"permissions": {
"allow":。"deny":,"ask":
}
}

• *allow* – 白名单，匹配即放行。
• *deny* – 黑名单，匹配即拒绝。怎么说呢，
• *ask* – 必问。即使 Auto 模式也会弹窗确认。

从参数模式来看，精确匹配 vs 通配 

*通配符* *​​​​​*: 匹配任意字符。程序会检测过宽规则并给出警告（

通配符粒度示例