策略即代码

确定性强制机制并非 OpenClaw 独有——Claude Code、Codex 和 Goose 都在代码中控制审批。在多渠道助手（而非终端）中进行结构性工具门控更为少见：权限模式 决定了哪些工具根本存在。对于 OpenClaw 管理的工具，read-only 会话会省略 edit、write 和 apply_patch，并且其 exec 工具在调用边界处解析为拒绝策略。原生 harness 可以保留自己的工具表面，并单独应用原生权限控制（Codex 运行时策略）。full 需要 operator.admin，并且作用域在分发之前从请求参数中派生（操作员作用域），因此带有特权参数的方法仍然需要特权作用域。

三个控制项分别管理不同的决策（沙箱、工具策略与 elevated 的对比）。沙箱决定工具在哪里运行。工具策略决定哪些工具存在；拒绝始终优先。常规策略过滤器诊断会在调试级别指明已配置的层和匹配的拒绝条目；持久审计账本 单独记录被阻止的结果，而不包含匹配的规则。tools.elevated 是仅限 exec 的逃生通道，无法覆盖拒绝。

Exec 审批 将已批准的运行绑定到其规范命令、cwd、环境哈希以及内容哈希的文件操作数，并在批准后出现任何漂移时拒绝。受支持的管道和命令链可以使用强制执行的执行计划。对于 OpenClaw 无法建立所需执行和文件绑定的 shell 形式或解释器调用，将被拒绝。当无法访问审批 UI 时，默认结果为拒绝，并且严格情况（内联 eval、heredocs）无法通过任何回退设置放宽。

mermaid actions={true} placement="top-right" flowchart LR MODE["Permission mode"] -->|"read-only: mutation tools absent"| REG["OpenClaw-managed tools"] REG --> TP["Tool policy: deny wins"] TP --> PLACE["Exec placement: gateway host, sandbox, or node"] PLACE -->|"approval required"| APR["Bind approved command, cwd, environment, file operands"] PLACE -->|"no approval required by policy"| RUN["Run"] APR -->|"valid approval and binding"| RUN APR -->|"drift or required binding unavailable"| DENY["Deny"] APR -->|"no approval UI"| FALLBACK["Configured fallback: deny by default; strict cases always deny"]

工具策略按名称过滤，而不是按副作用过滤：允许 exec 同时拒绝 write 并不会使 shell 命令变为只读。如文档所述，限制副作用是沙箱的职责。