很多人在配置 OpenClaw 的 Exec 能力时，都会卡在几个相似的问题上：

•ask 到底控制什么？

•为什么把 ask 设成 off 了，命令还是受限？

•配置明明改了，为什么没有生效？

•本地、团队、生产环境，到底该怎么选？

这篇文章不绕概念，直接把 OpenClaw Exec 配置里最关键的逻辑讲清楚：谁决定要不要审批，谁决定能不能执行，以及最常见的配置误区是什么。

核心判断：ask

 决定“要不要问你”，security 决定“能不能执行”。

一、先记住一句话：ask 管审批，security 管边界

Exec 配置里，最关键的就是两个参数：

•ask：控制是否触发审批

•security：控制命令执行边界

很多配置问题，本质上都是把这两件事混在了一起。

二、ask 是审批开关，不是权限总开关

ask 常见有 3 种模式：

1）off

表示关闭审批弹窗。

适合：

•个人本地开发

•高频执行命令

•环境可控、风险清楚的场景

提醒

ask: off 只是不再弹审批，不代表命令一定都能执行。

2）on-miss

表示未命中允许规则时再触发审批。

适合：

•团队协作环境

•半信任环境

•希望常用命令顺畅执行，同时保留人工确认的场景

常规命令直接执行，特殊命令再审批。

3）always

表示每次执行都审批。

适合：

•生产环境

•高审计要求环境

•风险控制优先的场景

它的代价是效率降低，但在高风险环境里，这种“慢”往往是必要的。

三、security 才是真正决定“能执行什么”的核心

如果说 ask 解决的是“问不问”，那 security 解决的就是“放不放”。

1）full

表示不对命令做额外限制。

适合：

•本地开发

•完全信任环境

•需要较高灵活度的个人场景

前提是：你明确知道当前环境可信、隔离、可控。

2）allowlist

表示只允许执行明确放入 safeBins 的命令。

适合：

•团队环境

•有边界要求的协作场景

•希望限制命令范围的环境

这时真正重要的是：命令是否在允许列表里。

3）deny

表示直接禁止 Exec。

适合：

•临时禁用执行能力

•高安全要求场景

•故障排查或止损阶段

如果你的目标是“先锁住，再检查”，这是最保守的一种方式。

四、最常见误区：ask: off 不等于完全放开

这是很多人最容易理解错的一点。

只要把 ask 设成 off，Exec 就完全放开了。

其实不是。

ask: off 只代表：不弹审批。

如果 security 仍然是 allowlist，那不在允许列表里的命令，依然会被限制。

也就是说，下面这组配置：

{   "tools": {     "exec": {       "ask": "off",       "security": "allowlist",       "safeBins": ["ls", "cat", "grep"]     }   } }

它的含义是：不审批，但仍然只允许执行白名单中的命令。

而典型的“无审批、无额外限制”组合，则是：

{   "tools": {     "exec": {       "ask": "off",       "security": "full"     }   } }

高风险提醒

如果你不确定当前环境是否足够安全，不要直接使用 ask: off + security: full。

这组配置更适合个人、本地、可信、可回退的环境，而不是共享环境或高风险环境。

五、几种常见组合，分别意味着什么？

组合 1：ask: off + security: full

效果：不审批，不做额外命令限制

适合：

•本地个人开发

•完全信任环境

风险提示：

•执行效率高

•同时也更依赖操作者判断

•不适合环境边界不清的场景

组合 2：ask: off + security: allowlist

效果：不审批，但仍受白名单限制

适合：

•想减少审批打断

•但又不希望命令范围完全放开的场景

它不是“完全放开”，只是“关闭审批”。

组合 3：ask: on-miss + security: allowlist

效果：常规命令直接执行，超出白名单时再审批

适合：

•团队协作

•半信任环境

•想兼顾效率与控制的场景

这通常是比较稳妥的平衡方案。

组合 4：ask: always + security: full

效果：每次都审批，但命令本身不做额外限制

适合高审计要求环境，或希望每次执行都保留人工确认的场景。

组合 5：security: deny

效果：直接禁用 Exec

适合临时止损、风险不明时的保守处理，以及排查期的锁定策略。

六、如果你只是想先配置好，可以按这个顺序操作

第 1 步：找到配置文件

Exec 配置通常写在 OpenClaw 的配置文件里。

           下面路径以 macOS 为例：/Users/你的用户名/.openclaw/openclaw.json

如果你使用的是 Windows 或 Linux，请按本机实际安装路径调整，不要直接照抄。

第 2 步：找到 tools 配置段

{   "tools": {     "profile": "full"   } }

第 3 步：加入 Exec 配置

如果你是在个人本地开发环境，并且明确确认当前环境可信，可以使用：

{   "tools": {     "profile": "full",     "exec": {       "ask": "off",       "security": "full"     }   } }

如果你更希望稳妥一点，建议先从下面这组开始：

{   "tools": {     "profile": "full",     "exec": {       "ask": "on-miss",       "security": "allowlist",       "safeBins": ["ls", "cat", "grep", "head", "tail", "find", "pwd"]     }   } }

这组更适合先跑常用命令，又不希望执行边界完全放开。

第 4 步：保存配置后，请主动重启 Gateway

关键动作

保存配置后，请主动重启 Gateway，确保配置生效。

例如可手动执行：

openclaw gateway restart

不要把“保存文件”理解成“一定会自动生效”。更稳妥的做法是：修改后主动重启，再验证。

第 5 步：做一次简单验证

配置完成后，不要直接假设已经全部正常，建议按下面 5 项做一次最小验证。

1.先确认配置文件里保存的值就是你刚刚修改后的内容，没有写错字段名，也没有改到错误环境。

2.主动重启 Gateway，避免出现“文件已保存，但实际运行仍是旧配置”的情况。

3.执行一个常用且安全的命令，观察它是否符合当前的审批策略，比如该直接执行还是该弹出审批。

4.如果当前用了 allowlist，再额外测试一个白名单外命令，确认它会被限制或触发审批，而不是被意外放行。

5.最后回看一次实际结果，确认“审批行为”和“命令边界”都符合你的预期，再把这套配置用于正式环境。

做到这一步，你就能同时确认两件事：配置已经真正生效，实际执行行为也与预期一致。

七、最容易配错的 3 个点

1）把 ask 当成权限总开关

ask 只决定审批流程，不决定命令范围。真正控制执行边界的，是 security。

2）以为保存配置就一定已经生效

不少问题不是“配置写错”，而是“配置还没真正应用”。更稳妥的做法始终是：保存配置、主动重启 Gateway、再做验证。

3）在不清楚环境边界时直接用 ask: off + security: full

这组配置效率很高，但也最容易被误用。

•当前是否为个人独占环境

•是否存在共享主机或多人使用

•是否具备回退与隔离能力

•是否接受更高的误执行风险

不确定时，优先从更保守的组合开始。

八、为什么改了配置却还是不对？

1）配置没有真正生效

最常见。处理方式：保存后主动重启 Gateway，再验证。

2）理解错了 ask 和 security 的分工

比如你把 ask 设成 off，却忘了 security 还是 allowlist。结果就是：不弹窗，但命令依然受限。

3）白名单没配对

如果当前是 allowlist 模式，重点不是“为什么没放开”，而是：

•命令是否真的在 safeBins 里

•写进去的是不是可执行命令

•是否把 shell 内建行为误当作独立命令

例如 cd 就不适合作为 safeBins 示例项。更合适的是 ls、cat、grep、head、tail、find、pwd 这类明确可执行的工具。

九、不同环境，建议用不同策略

1）本地开发环境

推荐前提：

•个人独占

•环境可信

•能接受更高操作自由度

{   "tools": {     "exec": {       "ask": "off",       "security": "full"     }   } }

但再次强调：仅在你明确确认环境安全时再使用。

2）团队协作环境

{   "tools": {     "exec": {       "ask": "on-miss",       "security": "allowlist",       "safeBins": ["ls", "cat", "grep", "head", "tail", "find", "pwd"]     }   } }

这样做的好处是：

•常用命令不必频繁打断

•超出边界的操作仍然会被拦住

3）生产或高风险环境

{   "tools": {     "exec": {       "ask": "always",       "security": "allowlist",       "safeBins": ["ls", "cat", "grep", "head", "tail", "find", "pwd"]     }   } }

核心原则不是“快”，而是“边界清楚、风险前置、可审计”。

十、如果配错了，怎么回退更稳妥？

方案一：回到更保守的白名单模式

{   "tools": {     "exec": {       "ask": "on-miss",       "security": "allowlist",       "safeBins": ["ls", "cat", "grep", "head", "tail", "find", "pwd"]     }   } }

方案二：直接禁用 Exec

{   "tools": {     "exec": {       "security": "deny"     }   } }

这时先锁住执行能力，再排查更稳妥。

结语

OpenClaw Exec 配置真正容易让人混乱的地方，不是参数多，而是很容易把两个问题混在一起：

•到底要不要审批？

•到底允不允许执行？

只要把这两个问题拆开看，配置思路就会清楚很多：

•ask 管审批流程

•security 管执行边界

•ask: off 不等于完全放开

•保存配置后请主动重启 Gateway

•本地、团队、生产环境，应该采用不同策略

先确认环境边界，再决定配置强度。

不确定环境是否安全时，宁可先保守一点，也不要直接把审批和边界一起放开。

如果你正在配置 OpenClaw Exec，真正需要先想清楚的，不是哪组参数“看起来最强”，而是你的环境边界、协作方式和风险容忍度分别是什么。

把这个前提想明白，再去选择 ask 与 security 的组合，很多误判都会自然消失，配置也会更稳。

先厘清边界，再决定审批强度；先确保可控，再追求效率。这才是配置 Exec 时最值得坚持的顺序。