模型会自主决定调 Bash 跑命令、调 Edit 改文件。但模型可能判断错、也可能被恶意输入诱导。权限系统就是"在工具真执行前踩一脚刹车"——高风险操作停下来问你，低风险的放行，还能按规则批量允许/禁止。

Day 07 L08 讲过：执行管线里"权限检查"排在 tool.call() 之前（第 6 关）。今天钻进那关。核心文件 src/utils/permissions/permissions.ts，文件系统相关在 filesystem.ts（Day 08 见过危险清单），Bash 在 bashSecurity.ts（Day 08 的 tree-sitter）。

你用 Shift+Tab 切换的就是这些模式（src/types/permissions.ts:15）：

除了模式，还有规则——三种行为 allow/deny/ask，可精确到工具甚至参数。配在 settings.json：

{
  "permissions": {
    "allow": ["Read", "Bash(git status)"],   // 整工具 或 参数级
    "deny":  ["Bash(rm *)", "Edit(/etc/**)"],
    "ask":   ["Bash(git push*)"]
  }
}

规则来源有优先级（permissions.ts）：userSettings / projectSettings / localSettings / flagSettings / policySettings / cliArg / command / session——企业策略（policy）最高。它们最终落到权限上下文的 alwaysAllowRules/alwaysDenyRules/alwaysAskRules。

入口 hasPermissionsToUseTool（permissions.ts:473）→ 内部 hasPermissionsToUseToolInner（:1179）。源码里用注释标了 step 编号，逐条过。看开头两步的真实代码（:1190）：

// 1a. Entire tool is denied
const denyRule = getDenyRuleForTool(appState.toolPermissionContext, tool)
if (denyRule) {
  return { behavior: 'deny', ... }        // ← 命中 deny 规则，直接拒绝（最先、最硬）
}

// 1b. Check if the entire tool should always ask for permission
const askRule = getAskRuleForTool(appState.toolPermissionContext, tool)
if (askRule) {
  // ...（sandbox 自动放行是例外）
  return { behavior: 'ask', ... }         // ← 命中 ask 规则，弹窗询问
}

完整过闸顺序（源码 step 编号）：

很多人以为 bypassPermissions = "全放行"。不对。由 L04 的顺序（deny/ask/safetyCheck 都在 2a 之前）可知，即使 bypass 模式，这几类仍然拦得住：

• deny 规则（1a/1d）：你明说"绝不许"的红线，永远禁止。
• ask 规则（1b/1f）：你明说"要确认"的，仍会问。
• safetyCheck（1g）：动 .git/.claude/.bashrc/.mcp.json 等危险文件仍会问（Day 08 那份清单）。
• 需要用户交互的工具（1e）：如 AskUserQuestion。

判定出 ask 后，怎么变成你看到的那张权限卡、并"等你点"？hasPermissionsToUseTool 只产出决策，真正弹 UI + 等待的是 useCanUseTool（src/hooks/useCanUseTool.tsx:52）。真实代码：

return new Promise(resolve => {           // ← 创建一个 Promise，先不 resolve
  const ctx = createPermissionContext(tool, input, ...);
  if (ctx.resolveIfAborted(resolve)) return;

  const decisionPromise = hasPermissionsToUseTool(tool, input, ...);  // 算出 allow/deny/ask
  return decisionPromise.then(async result => {
    if (result.behavior === 'allow') { ... resolve(...) }   // 直接放行
    // 若是 ask：把一个 {tool, input, onAllow, onReject} 压进确认队列，
    //          等用户点"允许/拒绝"时才 resolve 这个 Promise
  });
});

权限卡组件是 PermissionRequest（components/permissions/），内部按工具类型分派到 BashPermissionRequest / FileEditPermissionRequest 等具体样式。

auto 模式（permissions.ts:519 附近）不弹窗，改用一个 AI 分类器自动判断这次操作安不安全。判定路径：

1. 先试 acceptEdits 快速路径（工作目录内编辑直接过）。
2. 查"安全工具白名单"（如只读工具直接放）。
3. 都不满足 → 调分类器（一个小模型）判"这个操作危险吗"，据此 allow/deny。

✋ 动手：对着真实代码读一遍

# 1. 权限模式定义
sed -n '15,45p' src/types/permissions.ts

# 2. 判定顺序 step 1a/1b（L04，真实代码）
sed -n '1179,1228p' src/utils/permissions/permissions.ts

# 3. bypass 免疫的注释（L05）
sed -n '1083,1090p' src/utils/permissions/permissions.ts

# 4. "await 一个 Promise" 的审批（L06）
sed -n '46,104p' src/hooks/useCanUseTool.tsx

# 5. 亲身体验：起 dev，Shift+Tab 切模式，让它改个文件看弹窗
bun run dev