你的OpenClaw能替你说「是」吗?一次把权限配置说清楚

配权限把我人都配傻了，主要是更新后问题很多。

OpenClaw 的权限体系是怎么运作的

先说清楚整体结构。 OpenClaw 的 shell 命令执行（ exec 工具）有两层把关：

第一层： tools.exec.* 配置，写在 openclaw.json 里，决定工具调用时的行为。

第二层： exec-approvals.json，在 ~/.openclaw/ 目录下，是本地审批策略。两层同时生效，取更严格的那个。

简单说： config 决定"默认怎么跑"， approvals 决定"具体某条命令能不能跑"。

三种安全模式： deny / allowlist / full

这是 tools.exec.security 能填的三个值，我一个个说。

deny ：最严，关门

"security":"deny"

所有 host exec 请求直接拒绝， agent 发 exec 调用直接报错。这个适合完全不需要 shell 执行的高安全场景，或者只想让 agent 做纯阅读/写作类任务。

但说实话， deny 基本等于"自废武功"——OpenClaw 相当多自动化能力建立在 exec 之上。

allowlist ：白名单，只有名单里的命令能跑

"security":"allowlist"

只允许执行明确在白名单里的可执行文件路径。路径匹配是 glob 模式，比如：

"allowlist": [   { "pattern": "C:/Users/Administrator/.openclaw/workspace/skills/**" } ] 

注意是精确匹配二进制路径，不接受 basename 模糊匹配。 allowlist 也是目前最推荐的生产环境模式——需要手动维护，但安全边界清晰。

allowlist 模式下还有个配套机制：safeBins，是给 stdin-only 的流式过滤器用的（ cut 、 head 、 tail 、 tr 、 wc 之类），不需要写入白名单就能跑。这个单独拎出来是因为这类命令只操作管道输入、没有任何副作用。

full ：全开，等于 root

"security":"full"

没有任何限制， agent 想跑什么跑什么。这不是漏洞，是设计——full 模式等价于"信任这个 Gateway 上的 operator"。

我的配置：

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

host 是 gateway ， security 是 full ， ask 是 off——三层叠加，意思是 exec 跑在 Gateway 进程上，完全不触发审批。这是什么概念呢？ agent 执行 exec 时没有任何拦截，发出去就立刻执行。

适合自己用、不接陌生人的场景。一旦 shared 出去，这个配置就需要重新评估。

ask 参数：每次都问 / 名单 miss 了才问 / 从不问

tools.exec.ask 控制的是"在 full 和 allowlist 模式下，要不要弹审批提示"。

有个容易踩坑的地方：ask 参数只对 host 执行生效，在 sandbox 里 exec 是被 sandbox 本身约束的，不走这套审批流。

还有 askFallback：如果需要提示但 UI 不可及， fallback 决定怎么处理——deny 直接拒， allowlist 走名单， full 放行。我的配置：

// exec-approvals.json"defaults":{"security":"full","ask":"off","askFallback":"full"}

askFallback 也是 full——没 UI 就默认全过。

Gateway Nodes ：更细的阻断

在 gateway.nodes.denyCommands 里可以配置黑名单，这是在 Gateway 层面的阻断：

"gateway":{"nodes":{"denyCommands":["camera.snap","camera.clip","screen.record","contacts.add","calendar.add","reminders.add","sms.send","sms.search"]}}

这些都是涉及硬件、隐私的高危命令。即使 security=full ，这些命令也会被 gate 拦住。

飞书频道的权限配置

飞书是大多数人接 OpenClaw 的入口，这块配置有自己的权限体系，独立于 exec 。

群组策略： open / allowlist / deny

"channels":{"feishu":{"groupPolicy":"allowlist","dmPolicy":"open","allowFrom":["*"]}}

groupPolicy 控制群聊， dmPolicy 控制私聊。我的配置是群组 allowlist 、私聊 open 。

踩坑点：如果设了 groupPolicy: "allowlist" 但 allowFrom 里没加自己的飞书 ID ，会导致自己发消息 OpenClaw 完全没反应。 ID 一般在飞书对话 URL 里找，或者先切成 open 模式确认能通，再收紧到 allowlist 。

完整飞书配置示例

"channels":{"feishu":{"enabled":true,"appId":"cli_xxxxxx","appSecret":"xxxxxx","connectionMode":"websocket","domain":"feishu","streaming":true,"blockStreaming":false,"groupPolicy":"allowlist","groupAllowFrom":["ou_你的飞书openid"],"dmPolicy":"open","allowFrom":["*"]}}

groupAllowFrom 是关键——填飞书 open_id ，不是名字或邮箱。多人协作的话，把大家的 open_id 都加进去。

飞书机器人的 exec 审批

如果飞书群里有人想让 OpenClaw 执行 shell 命令，需要走 exec 审批。配置审批转发：

"approvals":{"exec":{"enabled":true,"mode":"session","agentFilter":["main"],"sessionFilter":["feishu"]}}

这样飞书里的 exec 请求会转成审批 prompt ，群里用 /approve <id> allow-once 审批。

我的完整权限配置

直接贴我的 openclaw.json 里权限相关部分：

// openclaw.json"tools":{"exec":{"host":"gateway","security":"full","ask":"off"}}"gateway":{"mode":"local","nodes":{"denyCommands":["camera.snap","camera.clip","screen.record","contacts.add","calendar.add","reminders.add","sms.send","sms.search"]}}"channels":{"feishu":{"enabled":true,"appId":"cli_xxxxxx","appSecret":"xxxxxx","connectionMode":"websocket","groupPolicy":"allowlist","groupAllowFrom":["ou_xxxxxx"],"dmPolicy":"open"}}

对应 exec-approvals.json：

{"defaults":{"security":"full","ask":"off","askFallback":"full","autoAllowSkills":true},"agents":{"*":{"allowlist":[{"pattern":"C:/Users/Administrator/.openclaw/workspace/skills/**"}]}}}

autoAllowSkills 打开后， skill 目录下的可执行文件走技能自己的权限路径，不占用审批流。 agents 里用了通配符 *，意味着所有 agent 共享这份配置。

实际怎么配：我的经验

自己用、不 shared： security=full + ask=off + askFallback=full ，飞书 dmPolicy=open 。用起来最顺。

多人共享、或者接了飞书/Telegram 群： security=allowlist + ask=on-miss ， groupPolicy=allowlist + 精确填写 allowFrom 。 autoAllowSkills 打开减少日常摩擦。

接了公网访问：把 gateway.bind 从 loopback 改成 lan 或 all，同时 security 必须收紧到 allowlist ，控制 UI 的 origin 也要严格限制。

还有一个被低估的参数：strictInlineEval。如果打开了 allowlist 模式但又 allow 了 python/node 这类解释器，建议把这个设成 true——它会让 -c "..." 这种内联代码形式每次都需要审批，防止通过 python -c 绕过路径检查。

一句话总结