> ## Content Index > Fetch the complete content index at: https://tbbbk.com/llms.txt > Use this file to discover other available public pages before exploring further. # OpenClaw 权限设置教程（2026）：exec、shell、危险操作怎么限制 - URL: https://tbbbk.com/openclaw-permissions-exec-shell-dangerous-ops-guide-2026/ - Published: 2026-03-20T05:44:09.000Z - Updated: 2026-03-20T05:44:09.000Z - Description: 我把 OpenClaw 里最容易混的权限层级拆开了：sandbox、tool policy、exec approvals、allowlist、/exec、/elevated。看完你就知道 exec、shell 和危险操作到底该怎么限制。 - Author: TuBaiBai - Tags: OpenClaw, 折腾日记, #Import 2026-07-20 07:13 我最近在翻 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 说明](https://tbbbk.com/content/images/2026/03/openclaw-exec-approvals-doc.png) 我最喜欢这页的地方，是它把 exec approvals 的逻辑写得很死：policy + allowlist + user approval 三层一起判断。 这页对我最大的帮助，不是让我记住了几个新词，而是把逻辑钉死了：**policy、allowlist、用户审批，是一起生效的，不是谁替代谁。** 这点非常关键。因为很多人会天然觉得： - “我开了 allowlist，应该就够安全了吧？” - “我开了 ask=always，就没事了吧？” 其实都不对。OpenClaw 这里不是单选题，而是叠加题。 你把它想成一道闸门会更容易理解： - tool policy 先看这个工具本身让不让用 - security 再看 host exec 让不让走 - allowlist 再看这个二进制是不是你明确认可的 - ask 再决定要不要你本人点头 最后几层都过了，命令才真会跑起来。 ## /exec 和 /elevated 到底有什么区别 这个问题我觉得值得单独讲，因为太多人混了。 我先给一句最省脑子的结论： - `/exec` 解决的是“怎么执行” - `/elevated` 解决的是“要不要提到宿主机执行” 官方文档里，`/exec` 是用来设置**会话级默认参数**的，比如： ```bash /exec host=gateway security=allowlist ask=on-miss node=mac-1 ``` 这条命令本质上是在说：后面这场对话里，默认按这个执行方式来。它会改会话默认值，但不会写回全局配置，也不等于“授予新的工具权限”。 而 `/elevated` 则是另一套逻辑： ```bash /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 的区别](https://tbbbk.com/content/images/2026/03/openclaw-elevated-doc.png) 这页里最重要的一句，不是 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 配置： ```bash openclaw approvals get openclaw approvals get --gateway openclaw approvals get --node ``` 第二条是直接往 allowlist 里加条目： ```bash 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： ```bash 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 权限设置的理解，已经越来越简单了： > 重点不是“一刀切全禁”，也不是“图省事全放开”，而是按你的真实使用场景，把它限制在**刚好够用**的范围里。 如果你只是想让它帮你查日志、跑固定命令、做一点自动化，那就只给这些能力。别让一个本来是来帮忙的工具，最后变成你自己都不敢放手的隐患。 感兴趣的可以继续看看下面这些文章： - [OpenClaw 进阶配置教程（2026）](https://tbbbk.com/openclaw-advanced-config-guide/) - [OpenClaw 安全配置实操指南：保护你的 Mac/PC 不被 AI 搞坏](https://tbbbk.com/openclaw-security-guide-local-mac-pc/) - [OpenClaw CLI Commands 完整指南（2026）](https://tbbbk.com/openclaw-cli-commands-guide/) - [OpenClaw 多 Agent 配置指南](https://tbbbk.com/openclaw-multi-agent-config-guide/)