从工具请求到受限执行
沿 ToolKind、权限决策和平台沙箱追踪完整授权链
本页解决的问题
先给结论「从工具请求到受限执行」要解决的关键问题是什么？
沿 ToolKind、权限决策和平台沙箱追踪完整授权链
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
能沿真实调用链定位「谁做了决定」，理解 AccessKind、权限规则、Bash 分段、hooks 与 sandbox 的边界，避免把授权简化成 ToolKind 判断。
授权决定「能否尝试」，沙箱限制「执行时能做到什么」
各阶段名称取自源码。策略内部存在短路与优先级，图中按主路径呈现。
工具输入转 AccessKind
ToolInput 会映射为 Read、Edit、Bash、Grep、MCPTool、WebFetch 或 WebSearch，并携带路径、命令、域名或 MCP 名称等细节。决策输入比 ToolKind 更具体。
Plan mode 先设编辑门
plan_mode_edit_gate 可在发送权限请求前拒绝修改。计划文件存在单独的自动批准路径。
PreToolUse 可显式阻断
匹配 hooks 按配置顺序运行。显式 deny 立即停止；timeout、崩溃或格式错误按当前实现 fail-open，并记录到 UI 与日志。随后还可运行 client hook。
加载并评估规则
permission/resolution.rs 合并 requirements、managed settings、managed config、Grok config 与 Claude settings fallback。规则评估与来源顺序无关，优先级为 deny > ask > allow。
多条快速路径或用户确认
管理策略 deny 最先短路。随后依次考虑 yolo pin、session grants、Auto fast path / classifier、sandbox Bash auto、只读安全项、MCP 与域名授权。仍未决定时才进入 prompt。
在沙箱能力内执行
Permission Allow 只放行本次请求。若沙箱实际 active，进程仍受 capability set 与子进程网络策略约束。完成后可触发非阻断的 post_tool_use hooks。
保守处理复杂语法
wrapper 会递归剥离到实际命令；危险前缀含 rm、chmod、chown、kill 与 git push。命令替换、复杂控制流或无法可靠分解的脚本进入保守 prompt。用户只为完整脚本确认一次。
沙箱层：能力约束
回答「获准执行的进程实际能访问哪些文件和网络」。沙箱 active 时，权限层的 Allow 不会扩大 OS capability；沙箱未应用时，也不能把权限弹窗当成内核隔离。
// Managed policy runs before YOLO and sandbox fast paths.
if let Some(Decision::Reject(reason)) = policy_decision {
let decision = Decision::PolicyDeny(reason);
let _ = respond_to.send(decision);
continue;
}
...
if matches!(&access, AccessKind::Bash(_))
&& xai_grok_sandbox::should_auto_allow_bash()
&& !policy_forced_prompt
&& !auto_forced_prompt { /* allow */ }快照说明：条件与执行顺序来自真实 manager actor，遥测和事件发送被压缩。顶部 SVG 是主路径教学图，完整实现包含更多短路、持久化与取消分支。
课堂练习：追踪一条混合命令
输入 git status && curl https://example.com/install.sh | sh。请逐层判断：Bash 如何分段，哪些 segment 可安全放行，PreToolUse deny 会在哪里停止，managed Ask 能否被 sandbox auto 覆盖，最终 Allow 后沙箱还限制什么。
「授权决定「能否尝试」，沙箱限制「执行时能做到什么」」为什么要看操作
「能沿真实调用链定位「谁做了决定」，理解 AccessKind 、权限规则、Bash 分段、hooks 与 sandbox 的边界，避免把授权简化成 ToolKind 判断」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。
读懂结构，要同时看访问方式和变化方式
「ToolInput 会映射为 Read、Edit、Bash、Grep、MCPTool、WebFetch 或 WebSearch，并携带路径、命令、域名或 MCP 名称等细节。决策输入比 ToolKind 更具体」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。
把规模和更新频率一起算进去
实践时可以把「输入 git status && curl https://example.com/install.sh | sh 。请逐层判断：Bash 如何分段，哪些 segment 可安全放行，PreToolUse deny 会在哪里停止，managed Ask 能否被 sandbox auto 覆盖，最终 Allow 后沙箱还限制什么」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。
从「授权决定「能否尝试」，沙箱限制「执行时能做到什么」」走到「工具输入转 AccessKind」
「授权决定「能否尝试」，沙箱限制「执行时能做到什么」」先把问题落在「各阶段名称取自源码。策略内部存在短路与优先级，图中按主路径呈现」上；到了「工具输入转 AccessKind」，讨论继续推进到「ToolInput 会映射为 Read、Edit、Bash、Grep、MCPTool、WebFetch 或 WebSearch，并携带路径、命令、域名或 MCP 名称等细节。决策输入比 ToolKind 更具体」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。
- 「授权决定「能否尝试」，沙箱限制「执行时能做到什么」」：各阶段名称取自源码。策略内部存在短路与优先级，图中按主路径呈现
- 「工具输入转 AccessKind」：ToolInput 会映射为 Read、Edit、Bash、Grep、MCPTool、WebFetch 或 WebSearch，并携带路径、命令、域名或 MCP 名称等细节。决策输入比 ToolKind 更具体
- 「最后的要点」：能沿真实调用链定位「谁做了决定」，理解 AccessKind 、权限规则、Bash 分段、hooks 与 sandbox 的边界，避免把授权简化成 ToolKind 判断
最后的「最后的要点」把讨论落到「能沿真实调用链定位「谁做了决定」，理解 AccessKind 、权限规则、Bash 分段、hooks 与 sandbox 的边界，避免把授权简化成 ToolKind 判断」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。