openinterpreter (codex-rs) 权限请求提示模板解析：on_request_rule_request_permission 如何指导 Agent 请求沙箱内加宽权限与升级执行

本篇围绕 codex-rs 权限提示模板 on_request_rule_request_permission.md 展开，它告诉模型在 on-request 审批策略下应当如何"先请求沙箱内加宽权限、再请求完整升级执行"。读完本文，你能掌握该模板的完整指令内容、它在 权限提示组装逻辑 中的加载与选择条件、sandbox_permissions 取值与 SandboxPermissions 枚举 的对应关系，以及命令分段（segmentation）规则对审批判定的影响。

模板的定位：审批策略家族中的一员

该模板位于 codex-rs/prompts/templates/permissions/approval_policy/ 目录下，与同目录的三个模板共同构成"审批策略（approval policy）"提示家族：

• never.md：never 策略，明确禁止提供任何 sandbox_permissions，命令一律被拒绝；
• unless_trusted.md：unless-trusted 策略，除有限的只读安全命令白名单外，多数命令都会升级请求用户批准；
• on_request.md：on-request 策略的"基础版"，以"完整升级执行（require_escalated）"为主要请求模式；
• on_request_rule_request_permission.md：本文主角，on-request 策略的"扩展版"，在基础版之上引入"沙箱内加宽权限"这一更优先的请求模式。

从源码结构看，四个模板在 permissions_instructions.rs 中通过 include_str! 编译期嵌入二进制：

const APPROVAL_POLICY_ON_REQUEST_RULE: &str =
    include_str!("../templates/permissions/approval_policy/on_request.md");
const APPROVAL_POLICY_ON_REQUEST_RULE_REQUEST_PERMISSION: &str =
    include_str!("../templates/permissions/approval_policy/on_request_rule_request_permission.md");

也就是说，这套提示模板不是运行期读取的文件，而是随 prompts crate 一起编译分发的静态资源。

什么时候会选中"扩展版"模板

在 approval_text 函数 中，模板的选择逻辑是：

let on_request_instructions = || {
    let on_request_rule = if exec_permission_approvals_enabled {
        APPROVAL_POLICY_ON_REQUEST_RULE_REQUEST_PERMISSION.to_string()
    } else {
        APPROVAL_POLICY_ON_REQUEST_RULE.to_string()
    };
    // ...
};
let text = match approval_policy {
    AskForApproval::Never => APPROVAL_POLICY_NEVER.to_string(),
    AskForApproval::UnlessTrusted => with_request_permissions_tool(APPROVAL_POLICY_UNLESS_TRUSTED),
    AskForApproval::OnRequest => on_request_instructions(),
    AskForApproval::Granular(granular_config) => granular_instructions(...),
};

关键条件有两个：

1. 审批策略为 OnRequest（或 Granular 中允许沙箱审批），且 exec_permission_approvals_enabled 为 true 时，才使用本文的 on_request_rule_request_permission 模板，否则回退到更简单的 on_request 模板；
2. 若 request_permissions_tool_enabled 为 true，还会追加一段 request_permissions 工具的说明（见下节）。

此外，当 approvals_reviewer 为 auto_review 且策略不是 Never 时，所有策略文本末尾还会追加 AUTO_REVIEW_APPROVAL_SUFFIX：说明 require_escalated 的升级请求会先经过自动审查，被拒绝后 Agent 只能采用"实质更安全的替代方案"或向用户说明风险后再请求批准。

核心指令一：优先使用沙箱内加宽权限（Preferred request mode）

模板原文的第一部分给出了首选的请求模式：

命令可能需要用户批准后才能执行。优先请求"沙箱内加宽权限"，而不是请求在沙箱外完整运行。

具体做法是调用命令时携带：

• sandbox_permissions: "with_additional_permissions"
• additional_permissions 参数，可包含以下任一项：
  • network.enabled：设为 true 以启用网络访问；
  • file_system.read：需要读访问的路径列表；
  • file_system.write：需要写访问的路径列表。

同时模板明确约束：直接使用 request_permissions 工具时，只能请求 network 和 file_system 两类权限。这一约束与源码中该工具提示段的描述一致（见 request_permissions_tool_prompt_section）：

fn request_permissions_tool_prompt_section() -> &'static str {
    "# request_permissions Tool\n\nThe built-in `request_permissions` tool is available in this session. Invoke it when you need to request additional `network` or `file_system` permissions before later shell-like commands need them. Request only the specific permissions required for the task."
}

这一设计的安全含义在模板中被点明：执行仍然停留在当前沙箱策略之内，只是为这一条命令临时增加所请求的权限；只有当 exec-policy 的 allow 规则适用并授权时，命令才会在沙箱外运行。

对应的 Rust 类型定义在 protocol/src/models.rs，SandboxPermissions 是一个三值枚举（serde 序列化时为 snake_case，即模型看到的字符串取值）：

/// Controls the per-command sandbox override requested by a shell-like tool call.
pub enum SandboxPermissions {
    /// Run with the turn's configured sandbox policy unchanged.
    #[default]
    UseDefault,
    /// Request to run outside the sandbox.
    RequireEscalated,
    /// Request to stay in the sandbox while widening permissions for this
    /// command only.
    WithAdditionalPermissions,
}

三个取值与模板的对应关系一目了然：

枚举值	序列化名	语义
UseDefault	use_default	不修改本轮配置的沙箱策略，直接按默认执行
RequireEscalated	require_escalated	请求在沙箱外运行，触发用户审批（或自动审查）
WithAdditionalPermissions	with_additional_permissions	留在沙箱内，仅为本命令加宽权限

模板正是引导模型在需要更多权限时优先选第三列的方案，而不是动辄申请"出沙箱"。

模板还补充了一条优先级规则：如果命令已经匹配 exec-policy 的 allow 规则，则无需额外提示即可自动批准，此时 exec-policy allow 的行为（包括可能附带的沙箱绕过）优先于本模板描述的请求流程。已批准的命令前缀会以 ## Approved command prefixes 小节形式拼进提示（见 approved_command_prefixes_text）：

if let Some(prefixes) = approved_command_prefixes_text(exec_policy) {
    sections.push(format!(
        "## Approved command prefixes\nThe following prefix rules have already been approved: {prefixes}"
    ));
}

这意味着模型在下发命令前可以先比对已批准前缀，命中即无需任何权限请求。

核心指令二：完整升级执行（Escalation Requests）

模板第二部分规定了"最后手段"——当沙箱内加宽权限无法满足任务时才使用完整升级：

• sandbox_permissions: "require_escalated"
• 必须携带 justification 参数，内容是一个简短的、征求批准的问题（例如"是否允许下载并安装依赖？"）；
• 可选携带 prefix_rule，向用户建议一条可复用的 allow 前缀规则，便于后续会话免去重复审批。

这条链路的背景在姊妹模板 on_request.md 中有更详尽的展开（例如 git pull | tee output.txt 会被拆成 ["git", "pull"] 与 ["tee", "output.txt"] 两个独立分段分别评估；使用重定向、变量赋值、通配符等"高级 shell 特性"的命令不参与规则匹配，以限制已批准规则的作用范围；以及对 prefix_rule 的负面清单：禁止为 rm 等破坏性命令、heredoc/herestring 命令提供 prefix_rule，避免 ["python3"] 这类过宽前缀）。本文的扩展版模板将其压缩为三条要点，作为"加宽权限"模式不可用时的兜底路径，体现了"最小权限优先、升级执行兜底"的分级审批设计。

值得注意的分支：当 approvals_reviewer 是 auto_review 时，require_escalated 请求不会直接弹给用户，而是先由审查器按策略审查；被拒绝后模型只能走"更安全的替代方案"或向用户说明风险再请求批准（AUTO_REVIEW_APPROVAL_SUFFIX，见前文）。

核心指令三：命令分段提醒（Command segmentation reminder）

模板第三部分提醒模型：

命令字符串会在 shell 控制运算符处被拆分为独立的命令分段，包括管道（|）、逻辑运算符（&&、||）、命令分隔符（;）以及子 shell 边界（(...)、$()）。每个分段都会独立评估沙箱限制与审批要求。

这条规则的实际意义在于：一条 a && b 中只要任一分段需要升级执行，整条命令就会进入审批流程；权限请求的粒度也是"每条命令"而非"每个分段"，因此模型应把需要不同权限的段落在请求时考虑清楚。on_request.md 中给出的 git pull | tee output.txt 示例直观说明了分段结果；而扩展版模板在引入 with_additional_permissions 后进一步暗示：若只是"多要一点读/写路径或网络"，不必把整条命令升级到沙箱外。

模板如何被拼装进最终的开发者提示

完整组装流程在 PermissionsInstructions::from_permission_profile 中：

1. 从 PermissionProfile 推导沙箱模式（danger_full_access / workspace_write / read_only）与网络访问状态，渲染对应的沙箱模式模板（templates/permissions/sandbox_mode/ 下的三个文件）；
2. 调用 approval_text 按审批策略选择本文的审批模板，并按需追加 request_permissions 工具段与已批准前缀段；
3. 追加可写根目录列表（The writable roots are ...）与"被禁止读取的路径/ glob"（## Denied filesystem reads，并提示不要为这些路径申请升级权限）；
4. 产物以 developer 角色、<permissions instructions> 标记包裹，作为上下文片段注入会话。

此外，在 Granular 细粒度审批策略下，若 exec_permission_approvals_enabled && sandbox_approval 允许，granular_instructions 同样会复用本文模板（APPROVAL_POLICY_ON_REQUEST_RULE_REQUEST_PERMISSION），也就是说"沙箱内加宽权限"的这套指令是 on-request 与细粒度策略共用的通用能力。

小结

on_request_rule_request_permission.md 用不到 35 行文字定义了 openinterpreter codex-rs 权限体系中最关键的行为准则：

• 分级请求：with_additional_permissions（沙箱内加宽）优先于 require_escalated（完整出沙箱），把"最小权限"写进了模型的行为规范；
• 参数契约：sandbox_permissions 的取值与 SandboxPermissions 枚举 一一对应，justification / prefix_rule 构成了用户审批体验的文案与复用规则；
• 评估粒度：命令按 shell 控制运算符分段、逐段独立评估，模型在组合命令时必须意识到审批与沙箱限制是按分段生效的；
• 规则优先：命中 exec-policy allow 规则（已批准前缀）时免提示直接放行，避免无谓打扰用户。

理解这个模板，就理解了该代码库"沙箱默认、加宽次之、升级兜底、自动审查可选"的完整权限请求语义。