24 讲路线 · 与 S03 配对
D03: Permission Model 深挖 · 权限模型
本讲在 S03 主线之上，聚焦实现细节、边界条件与自测；导图与主线相同模块，便于对照。
建议：先读完 S03，再按下方顺序走读源码与练习。
🔬 深挖目标
权限不是 UI 弹窗那么简单，而是策略函数 + 会话模式 + 审计轨迹。你要能回答：同一操作在 default / acceptEdits / bypassPermissions 下分别走哪条分支。
📊 策略维度（建议自建表）
打开源码后，建一张二维表：工具类型 × 风险等级 × 当前 PermissionMode → 结果（auto / ask / deny）。不必一次填满，先覆盖：文件写、bash、网络、MCP 调用。
| 模式 | 心智模型 | 实现侧需警惕 |
|---|---|---|
default | 高风险默认打断用户 | 「高风险」列表是否完整？有无绕过路径？ |
acceptEdits | 编辑类自动放行 | 与 bash / 删除类是否仍隔离？ |
bypassPermissions | 全放行（yolo） | 是否仍有硬熔断（例如某些环境变量禁运）？ |
🔍 代码走读抓手
- 重建源码中与 auto-mode / 解释器相关的硬读摘录见 专题 · 权限硬读（
AutoModeRules、explain_command）。 - 搜索
canUseTool、PermissionMode、bypassPermissions，找唯一真相源：哪个函数把策略结果转成 UI？ - 跟踪「用户点允许一次」vs「记住规则」：会话状态落在内存还是配置文件？
- 审计：日志里能否还原「谁、在何模式、对哪条工具、做了什么决定」？若不能，说明审计链断裂。
⚠️ 边界案例清单
- 工具参数含路径穿越或敏感目录时，策略是否在解析后路径上判定？
- 并行 tool 调用：若一个被拒一个通过，部分成功如何反馈给模型？
- 模式切换发生在工具执行中途：是否用快照模式还是实时读取？
📖 走读顺序
- 从 S03 的
PermissionMode类型出发，列出所有枚举值在 UI 层的入口。 - 画一张「tool 请求 → 策略 → 用户/自动 → 执行」的流程图，与页面顶部 Mermaid 对照查漏补缺。
- 刻意用
bypassPermissions跑一条高危命令（隔离环境），验证是否仍有硬拦截。
✏️ 自测 1 · 参考答案：dontAsk vs bypassPermissions
题干
用三句话说明二者差异（语义与实现位置）。
参考答案（三句话版）
dontAsk通常表示「本类操作不要再弹窗确认」，但仍受策略与硬规则约束，不是法外之地；实现上多在策略/会话记忆或 per-tool 规则里。bypassPermissions是更激进的「跳过常规权限闸门」模式（yolo），往往用于受控环境；实现上在canUseTool入口短路，但仍可能被硬熔断（高危命令、企业策略）拦截。- 产品文案上必须区分：前者是减少打扰，后者是信任升级；混用文案会导致用户误以为「不再询问 = 绝对安全」。
✏️ 自测 2 · 参考答案：workspace 内写 — 权限层还是工具层？
题干
「只允许 workspace 内写」挂在权限层还是工具层？
结论
两层都要，硬校验放在工具层（或共享路径库），策略放在权限层。
- 权限层：根据模式决定 ask/auto/deny，并写审计；但若只有策略没有路径解析，攻击面仍在「工具接受任意路径」上。
- 工具层：在
Write/Edit/Bash内对解析后的绝对路径做path.resolve+ workspace 根前缀校验，防../与 symlink 跳出；这是最后防线，防模型或配置绕过 UI。