夜雨聆风很多人装好 OpenClaw 以后，真正开始慌的，不是“它会不会用”，而是：
它会不会乱动我电脑？
这个担心很正常。
因为 OpenClaw 跟普通聊天机器人不一样。它不是只会陪你聊两句，它是真的能：
读文件
改文件
跑命令
调浏览器
做自动化
也正因为它能干活，权限边界这件事就不能糊弄。
权限开太小，它什么也干不了。权限开太大，你又会担心它一脚踩到宿主机上，把东西搞乱。
所以这篇我不讲空的安全理念，直接讲最实际的问题：
OpenClaw 的 exec 权限怎么控制？
shell 命令能不能限制？
/exec和/elevated到底有什么区别？allowlist、ask=on-miss、full这些词，到底该怎么理解？普通用户到底该怎么配，既能干活，又不至于失控？
如果你也刚好卡在这里，这篇就是写给你的。
一、很多人以为“权限设置”只有一个开关，其实不是
OpenClaw 的权限问题，最容易把人搞糊涂的地方就在这：
它不是一个开关，而是几层东西叠在一起。
最值得先分清的，是下面这 3 层。
1）Sandbox：决定工具在哪跑
这一层管的是：
OpenClaw 的工具到底是在沙箱里跑，还是直接在宿主机上跑。
你可以把它理解成“运行地点”。
off：不走沙箱，直接在宿主机跑non-main：只有非主会话进沙箱all：所有会话都进沙箱
这层解决的是“在哪儿执行”，不是“能不能执行”。
2）Tool Policy：决定哪些工具能不能用
这一层管的是工具本身。
比如：
exec能不能调用browser能不能调用read / write / edit能不能用
这一层是硬边界。如果 tool policy 已经把 exec 禁了，那你后面再折腾 /exec 或 /elevated，都没用。
说白了：
tool policy 决定这把刀给不给你。
3）Elevated：决定 sandbox 里的 exec 要不要提到宿主机
这个词很多人第一次看到都会误会。
/elevated 不是“超级管理员模式”，也不是“给你更多工具权限”。
它本质上是：
一个只影响 exec 的宿主机执行通道。
按当前官方文档：
/elevated on：把 exec 提到 gateway host 跑，保留 exec approvals/elevated ask：和on一样，也保留 exec approvals/elevated full：提到 gateway host 跑，并跳过 exec approvals
这点一定要记住：
on 和 ask 不是彻底放开，真正激进的是 full。
二、真正决定危险程度的，是 exec 这 3 个参数
如果你只想抓主线，那就抓 exec。
因为 OpenClaw 真正容易让人不放心的地方，基本都在这里。
exec 这块最核心的就是 3 个参数：
hostsecurityask
1）host：命令在哪儿跑
sandboxgatewaynode
这个很好理解，就是地点问题。
地点越接近真实机器，风险自然越高。
2）security：边界开到哪
这一层最关键。
deny：直接拒绝 host execallowlist：只允许白名单里的可执行文件full：全部放开
你可以这么理解：
deny：最保守allowlist：最适合普通人长期用full：最自由，也最危险
3）ask：要不要你确认
off：不问on-miss：白名单没命中才问always：每次都问
这两个参数配合起来，基本就决定了你的使用体感：
security决定它理论上能做多大ask决定你中间要不要插手确认
三、/exec 和 /elevated，别再混了
这两个词，很多人一直分不清。
最简单的理解方式是：
/exec：解决“怎么执行”/elevated：解决“要不要提到宿主机执行”
比如：
/exec host=gateway security=allowlist ask=on-miss这条命令本质上是在改当前会话的默认执行参数。
它不是在“授予新权限”，也不会写回全局配置。
而：
/elevated on
/elevated ask
/elevated full
这是在控制 exec 要不要走宿主机通道。
这里最重要的一句是：
on / ask 模式下，security、allowlist 和 approvals 的判断逻辑仍然生效；只有 full 才会跳过 exec approvals。
这才是更准确的理解。
四、allowlist 到底白的是什么
很多人一看到 allowlist，第一反应是：
“那我是不是白一下 rg、python3、bash 这些名字就行了？”
不是。
OpenClaw 的 allowlist，匹配的是：
实际解析到的二进制路径
不是你随便写个命令名就完事。
比如文档里的例子是这种：
/opt/homebrew/bin/rg~/.local/bin/*~/Projects/**/bin/peekaboo
所以 allowlist 的本质，不是“让 OpenClaw 更自由”。
而是：
把信任从“所有命令”，收缩到“你明确认可的那几个工具”。
这也是为什么我会觉得，大多数人没必要一上来就追求 full。
如果你真正想要的是：
能干活，但边界还在
那 allowlist 才是更像正路的东西。
五、safeBins 是什么？为什么不能乱塞解释器
这一块也特别容易误解。
safeBins 不是通用白名单。
它是官方定义的一组：
stdin-only 的窄权限工具
比如默认比较适合的有：
jqcutuniqheadtailtrwc
所谓 stdin-only，不是一句空话，而是真的有限制：
拒绝位置型文件参数和 path-like token
会拦掉会破坏 stdin-only 的危险 flag
按字面量处理，不给你顺手做 glob 或
$VARS扩展还会限制可信目录来源
所以它特别适合做文本流处理，但不适合被你拿来当“万能白名单”。
尤其是这几个，别乱塞进 safeBins：
python3noderubybashshzsh
因为这些东西本身就能执行代码、读文件、拉子进程。你把它们塞进去，就等于自己给自己开后门。
六、普通用户到底该怎么配？
如果你不是专门拿一台测试机折腾，我其实建议很明确：
第一档：保守型
适合刚装好 OpenClaw，还不太放心的人。
思路是：
先保留 sandbox
host exec 尽量
deny真要开，也只开很窄的 allowlist
ask保持always或on-miss
优点是稳。缺点是没那么爽。
第二档：日常实用型
这是我最推荐大多数人从这里起步的方案。
security=allowlistask=on-miss
再加上少量你明确认可的 CLI。
这样配的好处是：
常用可信命令能顺畅跑
不在白名单里的命令会卡住，提醒你判断
既不是完全锁死，也不是直接裸奔
如果你只想让 OpenClaw 帮你：
查日志
跑固定脚本
做文本处理
做明确可控的命令行任务
这套其实就很舒服了。
第三档：高自由度型
这种就很直接了：
security=fullask=off或者直接
/elevated full
效率当然高。但这已经是把 OpenClaw 当成能真动宿主机的执行代理在用了。
如果你的机器里有重要文件，或者跑着生产服务，我不建议为了图省事这么配。
这不是高手配置。很多时候只是把保险丝拆了。
七、如果你问我最推荐哪套
我会很明确地说：
先从 allowlist + ask=on-miss 开始。
原因很简单：
它已经足够让 OpenClaw 做很多正经活
又不会因为一条奇怪命令就直接放飞
你可以在真实使用过程中慢慢补 allowlist
不需要一上来就
full
权限这件事最怕的，不是开不够。
而是：
你根本没想清楚自己为什么要开。
如果你只想让它做 3 件事，那就只给它做这 3 件事的能力。
这才叫可控。
八、几个最常见的误区
误区 1：/exec 就是在开权限
不是。/exec 改的是当前会话默认执行参数，不是权限总开关。
误区 2：/elevated on 就等于彻底放开
也不是。on / ask 下，security、allowlist、approvals 仍然生效。真正更危险的是 full。
误区 3：开了 sandbox 就绝对安全
不是。如果你把危险目录 bind 进去了，或者把 docker.sock 这种东西挂进去了，沙箱边界一样会被打穿。
误区 4：safeBins 可以当通用白名单
不行。它适合的是窄权限文本处理，不是解释器和运行时。
误区 5：ask=always 一定比 allowlist 更安全
也不对。ask=always 解决的是“每次都让你确认”，但真正缩小命令边界的，是 allowlist 和 host / security 这些层。
简单说：
老是弹确认框，不等于边界设计得更好。
九、把这篇压缩成一句话
OpenClaw 权限设置最重要的，不是“一刀切全禁”，也不是“图省事全放开”。
而是：
按你的真实使用场景，把它限制在刚好够用的范围里。
这样它才会是助手。而不是隐患。