20 Mar 2026 17 min read 折腾日记

OpenClaw 权限设置教程（2026）：exec、shell、危险操作怎么限制

我把 OpenClaw 里最容易混的权限层级拆开了：sandbox、tool policy、exec approvals、allowlist、/exec、/elevated。看完你就知道 exec、shell 和危险操作到底该怎么限制。

我最近在翻 OpenClaw 站内数据的时候，发现一个挺明显的信号：很多人已经不是卡在“装不上”，而是卡在“装好了以后我敢不敢真让它干活”。

这个问题很现实。因为 OpenClaw 不是普通聊天机器人，它真的能读文件、改文件、跑命令、调浏览器、做自动化。也正因为它能做这些，权限边界就不能含糊。权限收太死，它没法干活；权限放太大，你又容易心里发毛，怕它一脚踩到宿主机上。

我这两天专门把官方文档里和这块相关的内容重新过了一遍，重点看了 4 份：

Exec Tool
Exec Approvals
Elevated Mode
Sandbox vs Tool Policy vs Elevated

看完以后我最大的感受是：很多人嘴里说的“OpenClaw 权限设置”，其实不是一个开关，而是 3 到 5 层东西叠在一起。 你只盯其中一个，基本都会越配越乱。

所以这篇我不聊空的安全理念，也不讲“建议重视风险”这种废话。我直接把 OpenClaw 里最容易混淆的权限层，按真实使用顺序拆开讲：sandbox、tool policy、exec、allowlist、审批、/exec、/elevated。你看完至少能搞清楚两件事：

OpenClaw 到底能动你的机器到什么程度
你应该怎么配，才能让它既有用，又别乱来

大多数人真正想问的，其实是这几个问题

我把后台搜词和用户常见困惑放一起看，发现最后其实都绕不开下面这些问题：

OpenClaw 会不会乱执行 shell 命令？
exec 权限到底怎么开、怎么关、怎么限？
security=deny、allowlist、full 分别是什么意思？
ask=on-miss 和 ask=always 到底差在哪？
/exec 和 /elevated 是不是一回事？
我只想让它做安全点的命令，应该怎么配？
我想提高效率，但又不想一步走到“完全放开”，有没有中间方案？

如果你现在搜这篇，也是为了搞清这些，那下面这套理解框架基本就够你用了。

先别急着改配置，先分清 OpenClaw 的 3 层权限逻辑

我一开始也容易把这些词混在一起，后来重新对照文档，才发现很多坑其实都出在“你以为改的是权限，其实改的是另一个层”。

最值得先记住的，是下面这 3 层：

第一层：Sandbox —— 决定工具在哪儿跑

Sandbox 管的是运行位置。它决定 OpenClaw 的工具是在沙箱里跑，还是直接在宿主机上跑。

off：不走沙箱，直接在宿主机跑
non-main：只有非主会话进沙箱
all：所有会话都进沙箱

这个层只回答一个问题：它在哪儿执行。不是“它能不能执行”。

你可以把它理解成地理边界。沙箱像一个隔离房间，宿主机像你自己的客厅。先决定是在隔离房间里动，还是直接进客厅动。

第二层：Tool Policy —— 决定哪些工具能不能用

Tool policy 管的是工具可用性。比如：

exec 能不能调用
browser 能不能调用
read / write / edit 开没开放

这一层是硬边界。只要工具策略把 exec 禁了，你后面再去折腾 /exec 或 /elevated，都没用。

官方文档对这点写得很直白：tool policy 是硬 stop，/exec 不能绕过被禁用的 exec 工具。

第三层：Elevated —— sandbox 里的 exec 要不要提到宿主机

这层最容易被误解。很多人第一次看到 /elevated，会以为这是“超级管理员模式”。其实不是。

Elevated 本质上是一个只影响 exec 的宿主机执行通道：

/elevated on：把 exec 提到 gateway host 运行，并保留 exec approvals
/elevated ask：和 on 一样，也是在 gateway host 运行，并保留 exec approvals
/elevated full：把 exec 提到 gateway host 运行，并跳过 exec approvals

按当前官方文档，/elevated on 和 /elevated ask 在行为上是同一档：都会在 gateway host 上执行，同时继续受 approvals / security / allowlist 这套判断约束。真正明显更激进的是 full。

也就是说，Elevated 不是“给更多工具权限”，而是“让 exec 往宿主机那边提”。

这一层和前两层不是替代关系，而是叠加关系：

Sandbox 决定默认在哪跑
Tool policy 决定 exec 这个工具能不能用
Elevated 决定 sandbox 下的 exec 要不要提到宿主机

这三层混清楚以后，很多配置问题就不会再看着像天书了。

真正决定危险程度的，是 exec 这 3 个参数：host、security、ask

如果你只想抓主线，那就抓 exec。OpenClaw 里最该盯的危险面，基本都集中在这。

官方文档里，exec 的关键参数其实就 3 个：

host
security
ask

1）host：命令到底在哪儿跑

sandbox：在沙箱里跑
gateway：在网关宿主机跑
node：在节点机器上跑

这回答的是“地点问题”。地点越真实、权限越大，风险自然越高。

尤其是 gateway 和 node，这已经不是“模拟执行”了，而是往真实机器上落。

2）security：命令边界开到哪

deny：拒绝所有 host exec 请求
allowlist：只允许白名单里的可执行文件
full：全部放开

这是权限边界的核心。我的理解很简单：

deny 是最保守
full 是最放飞
allowlist 是最值得大多数人长期用的平衡点

3）ask：要不要让我确认

off：不问
on-miss：白名单没命中才问
always：每次都问

如果你一直记不清这些词，最简单的记法就是：

security 决定它理论上能做多大
ask 决定你中间要不要插手确认

这两个组合起来，才是你真正体感到的“危险程度”。

官方文档里有一页，我觉得所有人都该先看一遍

OpenClaw 权限设置：exec approvals 文档截图，包含 security、ask、allowlist 说明 — 我最喜欢这页的地方，是它把 exec approvals 的逻辑写得很死：policy + allowlist + user approval 三层一起判断。

这页对我最大的帮助，不是让我记住了几个新词，而是把逻辑钉死了：policy、allowlist、用户审批，是一起生效的，不是谁替代谁。

这点非常关键。因为很多人会天然觉得：

“我开了 allowlist，应该就够安全了吧？”
“我开了 ask=always，就没事了吧？”

其实都不对。OpenClaw 这里不是单选题，而是叠加题。

你把它想成一道闸门会更容易理解：

tool policy 先看这个工具本身让不让用
security 再看 host exec 让不让走
allowlist 再看这个二进制是不是你明确认可的
ask 再决定要不要你本人点头

最后几层都过了，命令才真会跑起来。

/exec 和 /elevated 到底有什么区别

这个问题我觉得值得单独讲，因为太多人混了。

我先给一句最省脑子的结论：

/exec 解决的是“怎么执行”
/elevated 解决的是“要不要提到宿主机执行”

官方文档里，/exec 是用来设置会话级默认参数的，比如：

/exec host=gateway security=allowlist ask=on-miss node=mac-1

这条命令本质上是在说：后面这场对话里，默认按这个执行方式来。它会改会话默认值，但不会写回全局配置，也不等于“授予新的工具权限”。

而 /elevated 则是另一套逻辑：

/elevated on
/elevated ask
/elevated full

它主要影响 sandbox 下的 exec 行为，尤其是要不要把命令提到 gateway host 上跑。

这里最容易踩坑的一点是：/elevated on 不等于彻底放开，/elevated full 才是危险程度明显上升的那个选项。

更准确地说，官方文档表达的是：

on / ask 模式下，security、allowlist 和 approvals 的判断逻辑仍然生效
只有 full 才会跳过 exec approvals，并把行为提升到更接近“完全放开”的状态

所以很多人把 /elevated 当“一键管理员模式”，这是不对的。它更像一个严格 gated 的宿主机执行通道。

这张图也值得看，因为它专门解释了 elevated

OpenClaw elevated 模式说明截图，展示 /elevated on ask full 的区别 — 这页里最重要的一句，不是 on/ask/full 的区别，而是 elevated 只影响 exec，不会凭空给你更多工具权限。

我自己最在意的是文档里那句潜台词：Elevated does not grant extra tools.

翻成人话就是：它不会凭空给你更多工具权限，也不会绕过已经被禁掉的工具策略。

所以如果你当前环境里：

exec 被 tool policy 禁掉了
或者 tools.elevated.enabled 本身没开
或者发送者不在 allowFrom 白名单里

那你发 /elevated 也不一定能生效。

这其实是好事。因为它说明 OpenClaw 这套权限系统不是一层纸，而是故意做成多层互卡的。

allowlist 到底白的是什么

如果说前面几层解决的是“概念混乱”，那 allowlist 这一层解决的就是“实操误解”。

很多人看到 allowlist，第一反应是：

“哦，那我是不是白一下 rg、python3、bash 这些命令名就行了？”

不是。

官方文档写得很明确：manual allowlist 匹配的是实际解析到的二进制路径，不是随便写个 basename 就行。文档里的例子也是这种：

/opt/homebrew/bin/rg
~/.local/bin/*
~/Projects/**/bin/peekaboo

这个设计非常重要，因为它把信任从“一个名字”收缩成了“某个路径上的某个可执行文件”。

我自己的理解是：allowlist 的本质，不是让 OpenClaw 更自由，而是把信任从“所有命令”收缩到“你明确认可的那些工具”。

这也是为什么我一直觉得，大多数人不应该一上来就追求 full。如果你真正想要的是“能干活，但边界还在”，那 allowlist 才是最像正路的东西。

如果你要用 allowlist，官方给了两条实际可用的路

第一条是直接看或改 approvals 配置：

openclaw approvals get
openclaw approvals get --gateway
openclaw approvals get --node <id|name|ip>

第二条是直接往 allowlist 里加条目：

openclaw approvals allowlist add "~/Projects/**/bin/rg"
openclaw approvals allowlist add --agent main --node mac-1 "/usr/bin/uptime"
openclaw approvals allowlist remove "~/Projects/**/bin/rg"

这些命令我很喜欢，因为它们不是讲理论，是明确告诉你：allowlist 是可以按 host、按 node、按 agent 管的。

这就意味着什么？意味着你完全可以做到：

主 agent 的边界紧一点
某个专门跑分析任务的 agent 宽一点
node 上只白你真正信任的固定工具

这比“所有 agent 一刀切同一套权限”靠谱多了。

safeBins 和 allowlist 不是一回事，别为了偷懒把解释器塞进去

这次我重看文档时，觉得最值得拎出来提醒的一点，就是 safeBins。

官方把它定义成 stdin-only 的窄权限工具。这里的“stdin-only”不是一句口号，而是有一串具体限制：它会拒绝位置型文件参数和 path-like token，只允许把输入流当主要输入；很多会破坏 stdin-only 行为的 flag 也会被拦下；并且 argv 里的文本会按字面量处理，不给你顺手做 glob 展开或 $VARS 扩展。像这些默认就比较适合：

jq
cut
uniq
head
tail
tr
wc

为什么它比 allowlist 更窄？因为它不是简单说“这个二进制可信”，而是连参数形态都在收窄。除了不能随便带文件参数、不能顺手走危险 flag，它还有几个容易被忽略的限制：

默认只信任极少数安全目录里的 safe-bin 可执行文件；如果你的二进制在 /opt/homebrew/bin、/usr/local/bin 这类位置，还得显式加到 safeBinTrustedDirs
allowlist 模式下，shell chaining 只有在每个顶层 segment 都满足 allowlist / safe-bin 规则时才可能通过
redirections 仍然不支持，命令替换 $() / 反引号也会被拒

这套东西特别适合做文本处理，但不适合当万能白名单。

官方文档还特地强调了一点：不要把 python3、node、ruby、bash、sh、zsh 这种解释器/运行时扔进 safeBins。

这个提醒特别关键。因为这种命令天生就能执行代码、读文件、拉子进程，根本不该当“窄权限工具”看。

如果你真的需要这类能力，应该老老实实走：

明确 allowlist
保留审批
或者用更清晰的 host 边界来兜底

别图省事把 safeBins 变成一个假装安全的大口子。

想排查自己到底被哪一层卡住，最值得先跑的是这个

如果你现在已经在用 OpenClaw，而且经常碰到“我以为能跑，结果没跑起来”的情况，我建议先用官方当前文档里的这组检查命令看 effective state：

openclaw sandbox explain
openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work
openclaw sandbox explain --json

这组命令的价值很高，因为它不是让你猜“是不是 sandbox 的锅”，而是直接把下面这些东西吐出来：

当前是不是 sandboxed
effective sandbox mode 是什么
tool allow / deny 是从哪层继承来的
elevated gate 到底有没有开

很多“我明明配了为什么不生效”的问题，真不需要脑补半天，直接看 effective state 最快。

普通用户最该用的，其实就 3 套权限思路

如果你不想把自己搞进文档迷宫里，那我建议直接按使用场景来选。

方案一：保守型 —— 先别让它碰宿主机

适合这几类人：

刚装好 OpenClaw，还在观察它到底稳不稳
机器里有重要文件，不想一开始就冒险
当前主要需求是读写工作区、整理文本、做轻量辅助

这套思路就是：

尽量保留 sandbox
host exec 尽量用 deny
如果确实要开，只开很窄的 allowlist
ask 尽量保持 always 或 on-miss

这套配置缺点是“没那么爽”，优点是你不容易一上来就被吓到。

方案二：日常实用型 —— 我最推荐大多数人从这里起步

这是我觉得最平衡的一套：

security=allowlist
ask=on-miss
只白少数你长期会用、你也真信得过的 CLI

比如你只是让它：

查日志
跑固定脚本
做文本清洗
处理明确可控的命令行工具

那这套就很舒服。白名单命中的事情能顺畅做，没命中的事情会提醒你判断，不会直接裸奔。

说白了，这套最像“既想要效率，又还记得自己在操作真实机器”。

方案三：高自由度型 —— 只建议在你能完全兜底的环境里用

这类配置大概长这样：

security=full
ask=off
或者直接 /elevated full

效率当然高，但本质上你已经是在把 OpenClaw 当一个能真动宿主机的执行代理了。

这套只适合：

测试环境
实验机
你清楚自己机器里有什么、坏了你能兜底的环境

如果你电脑里有重要文件、跑着生产服务、或者根本没想好 rollback 怎么做，那我不建议你图爽这么配。

这不是高手配置，很多时候只是把保险丝拆了。

如果你问我最推荐哪套，我会明确说：allowlist + ask=on-miss

如果你不是专门拿一台空机子折腾，我会很明确地建议：先从 allowlist + ask=on-miss 开始。

原因很简单：

它已经足够让 OpenClaw 做很多正经活
又不会因为一次奇怪命令就直接放飞
你可以在真实使用过程中，慢慢往 allowlist 里补需要的工具
而不是一上来就用 full 把边界全拆掉

我现在越来越觉得，权限这件事最怕的不是“开不够”，而是“你根本没想清楚自己为什么要开”。

如果你只想让 OpenClaw 帮你做 3 件事，那就只给它做这 3 件事的能力。别为了省一次确认，把整台机器一起送出去。

几个特别常见的误区：

误区一：以为 /exec 就是在“开权限”

不是。/exec 改的是当前会话默认执行参数，不是权限总开关。真正能不能跑，还得看 tool policy、security、allowlist、ask、elevated 这些层一起怎么判。

误区二：以为 /elevated on 就等于彻底放开

也不是。on / ask 只是让 exec 往 gateway host 那边走，审批和 allowlist 逻辑仍然可能继续生效。真正危险程度明显升高的是 full。

误区三：以为开了 sandbox 就绝对安全

如果你把危险目录 bind 进去了，或者把 /var/run/docker.sock 这种东西挂进去了，沙箱边界一样会被打穿。沙箱不是护身符，粗暴绑定照样会把风险带回来。

误区四：把 safeBins 当通用白名单

这是特别容易犯的偷懒错误。safeBins 适合窄权限文本处理，不适合解释器、运行时、能执行代码的工具。你图省事，后面吃亏的大概率还是你自己。

误区五：以为 ask=always 就一定比 allowlist 更安全

这两个不是替代关系。ask=always 解决的是“每次都让你确认”，但它没有帮你缩小命令边界。真正把边界收窄的，是 allowlist 和 host / security 这些层。

说得直白一点：老是弹确认框，不等于边界设计得更好。

把这篇压缩成一句话

我现在对 OpenClaw 权限设置的理解，已经越来越简单了：

重点不是“一刀切全禁”，也不是“图省事全放开”，而是按你的真实使用场景，把它限制在刚好够用的范围里。

如果你只是想让它帮你查日志、跑固定命令、做一点自动化，那就只给这些能力。别让一个本来是来帮忙的工具，最后变成你自己都不敢放手的隐患。

感兴趣的可以继续看看下面这些文章：