OpenClaw macOS 应用要哪些系统权限：屏幕、麦克风、语音、自动化、辅助功能逐项对照
在 Mac 上装一个能替你操作电脑的 Agent，最先卡住人的往往不是模型也不是网关，而是系统权限。你点了安装，应用起来了，某个功能就是不动，也不报错——多半是某一项授权没给，或者给了之后系统没有把它算在这个应用头上。
OpenClaw 的 macOS 应用是一个菜单栏形态的伴侣程序，官方文档把它的职责写得很直白：原生托盘界面、macOS 权限提示、通知、WebChat、语音输入、Canvas，以及跑在 Mac 上的节点工具（例如 system.run）。也就是说，这个应用本身就是”权限的持有者”——很多能力不是网关给的，是这台 Mac 授权给这个应用的。
这篇按官方 macOS 应用文档把权限这件事捋一遍：它会申请哪几类、在哪一步申请、事后从哪里补、除了权限对话框还有哪些地方会弹系统提示。需要先说明一点：官方还有一篇专门的 macOS 权限页（处理签名与 TCC 层面的恢复），不在本文引用的文档范围内，所以本文只讲 macOS 应用文档里白纸黑字写了的部分，没写的地方直接标注”官方本页未说明”。
文档明确列出的五类权限提示
官方在”应用负责什么”一节里列了一句关键的话：这个应用负责 screen（屏幕）、microphone（麦克风）、speech（语音）、automation（自动化）、accessibility（辅助功能）这五类 macOS 权限提示。
这五项的含义值得单独强调一下：它们是由 macOS 应用来弹、由 macOS 应用来持有的，不是 CLI 或网关持有。文档里紧接着还有一条更明确的说法——应用会以”应用上下文”执行已批准的 shell 命令，目的就是保留这个应用的 macOS 权限归属，而共享的节点策略仍由 CLI 运行时负责。翻译成实际场景：同一条命令，从应用这边走和从别的进程走，在系统眼里的权限主体可能不是同一个。
授权发生在首次运行的哪一步
官方给的首次运行流程一共五步：
- 安装并启动 OpenClaw.app；
- 选择 This Mac 用本机网关，或者连到一个远程网关；
- 等应用装好配套的 CLI 运行时；本地模式下它还会安装并启动网关；
- 用一次真实的模型调用确认推理链路可用；如果应用复用了你不想用的登录态，成功横幅上的 Choose a different AI 会重新打开选择器，包含 API key 方式；
- 完成后进入 dashboard，由 OpenClaw 在一次对话里引导剩下的设置——记忆导入、渠道、权限。
注意第 5 步：权限不是在安装阶段一次性索要完的，而是被放进了引导对话里。文档同时给了一个随时可用的入口：Settings → Permissions，任何时候都可以从这里授予 macOS 权限。所以”装完发现某个功能不动”的正常处理顺序是先回这个入口看一眼，而不是重装。
还有一个容易踩空的分支：如果应用连上的是一个已经配好模型的现存网关，它会认为这个网关已经完成设置，跳过供应商引导直接进 dashboard。跳过的是模型引导，不是系统权限——权限该给还得给。
能力和权限的对照清单
文档没有逐项写明”哪个权限对应哪个功能”，但它分别列出了权限清单和这个应用所拥有的能力清单。把两份清单并排放，能少走一些弯路：
| 官方列出的权限项 | 官方列出的、由这个应用承担的能力 |
|---|---|
| screen（屏幕） | 一个 Mac 节点，包含原生 Canvas、摄像头/屏幕捕获、通知、位置、电脑控制 |
| microphone（麦克风） | 语音输入；菜单栏应用提供的 WebChat 与悬浮 Quick Chat 栏 |
| speech（语音） | 同上，语音相关能力由应用侧提供 |
| automation（自动化） | Mac 侧命令的执行审批提示；已批准 shell 命令的应用上下文执行 |
| accessibility（辅助功能） | 电脑控制类能力；节点侧的 system、browser、plugin、skill、MCP 命令由 CLI 节点宿主提供 |
这张表是把官方两段并列信息放在一起看，不是官方给出的映射关系。真要精确定位某个功能缺哪一项授权，还是得看官方那篇专门的权限页。
另外有一处细节值得记住：在应用内嵌的控制界面里，Settings → Notifications 显示的是这个应用的原生通知权限，而不是浏览器推送权限——因为通知是应用原生发的。如果你按浏览器推送的思路去排查收不到通知，方向就偏了。
除权限对话框外，还有两处会弹系统提示
只盯着那五项权限，会漏掉两个同样属于”系统要你确认”的场景，都跟浏览器登录态有关。
第一处是导入浏览器 Cookie。 当应用连的是本机网关、且这台 Mac 上存在带 Cookie 的 Chrome 系配置文件时，浏览器侧边栏第一次打开会出现一条可关闭的横幅，提示把这些 Cookie 复制到一份隔离的托管配置文件里供 Agent 浏览使用。文档明确写了：从对应配置文件的 Import 控件发起导入时可能需要 Touch ID；只复制 Cookie，密码绝不离开源浏览器。关掉横幅会记住这个选择，之后从 Settings → General → Browser login → Import… 可以再次发起。底层流程和 browser.allowSystemProfileImport 这个开关的说明在浏览器文档里。
第二处是把 Cookie 同步到另一台机器。 导入只在本机复制一次；如果网关和 Agent 浏览器跑在另一台电脑上（独立主机、无头 Linux、云容器），才需要打开 Cookie 同步。入口是 Settings → General → Cookie sync，默认关闭，且只在应用处于远程模式时生效。要配三样东西：打开”同步 Cookie 到远程电脑”、在 Domains 白名单里加上要保持登录的站点（官方举例 github.com 和 accounts.google.com）、设置接收的 Target profile（远程网关上的托管配置文件名，默认 imported）。
开启后应用会在后台管住这条命令：
openclaw browser cookie-sync --watch
官方对这条链路的安全边界写得比较细，值得原样记住：Cookie 在本机解密（每个会话会有一次 macOS 钥匙串或 Touch ID 提示），通过应用已有的加密网关连接推送到远程配置文件；只有白名单里的域名会被发送；Cookie 值不会写进日志；白名单为空则什么都不同步。还有一个例外：部分 Google 会话使用设备绑定的会话凭据（DBSC），它绑在这台 Mac 上，同步之后仍可能要求重新认证；这类站点官方建议改用浏览器节点代理，直接在这台 Mac 上驱动浏览器。
本地网关和远程网关，权限面不一样
选哪种网关模式会直接影响这台 Mac 上要处理多少权限。官方给的选择表是这样的：
| 模式 | 什么时候用 |
|---|---|
| Local | 这台 Mac 自己跑网关，并用 launchd 保活 |
| Remote | 网关在另一台主机上，这台 Mac 通过 SSH、局域网或 Tailnet 控制它 |
两种模式都需要装好 openclaw CLI，因为应用要复用它的节点宿主运行时。全新的 Mac 上应用会自动安装配套 CLI；本地模式接着启动网关向导，远程模式则连到指定网关，不会再起第二个本地网关。远程模式下应用负责的是 SSH 隧道或直连网关。
从权限角度看差别在于：无论哪种模式，这台 Mac 上的那五类系统权限该给还是要给（Canvas、捕获、通知、位置、电脑控制这些能力是 Mac 节点提供的）；而 Cookie 同步这一项相反，只有远程模式才有意义。远程访问本身的几条路子可以另看远程访问的三种方式。
更新流程会动到哪些东西
更新和权限的交集在于：签了名的应用可能持有那个由 launchd 托管的本地网关。dashboard 上的更新卡片会写清楚这次要更新什么：
- Update Mac app + Gateway：说明这个签名应用拥有本地 launchd 网关。Sparkle 先更新应用，重启后应用会自动把网关更新并重启到匹配版本，再验证连接。
- Update Gateway：说明应用连的是远程网关、手动管理的本地网关，或者别的它不拥有的安装，这时按钮走的是那个网关自己的更新流程，不动 Mac 应用。
两个按钮都会先要确认，卡片只有在你选了 Update Mac app and restart 之后才把更新交给应用，避免误点直接触发 Sparkle。失败的协同更新会停在设置样式的窗口里提供重试。官方还写明：自动修复不会把更新的网关降级，也不会覆盖 extended-stable 的通道锁定；Sparkle 遵循网关的 update.channel 设置，beta 和 dev 会进入 beta 应用构建，extended-stable 只接受 extended-stable 的应用发布，stable、缺失值和未知值都留在稳定版。更新与回滚的完整策略见更新、回滚与卸载。
命令执行的审批是另一层，别和系统权限混起来
系统权限解决的是”这个应用能不能碰麦克风/屏幕”，命令能不能跑是另一套机制。文档把它单列为应用职责之一：Mac 侧命令的执行审批提示由应用负责弹，已批准的 shell 命令以应用上下文执行以保留权限归属，而共享的节点策略由 CLI 运行时管。
所以一条命令被拦下来，可能是两种完全不同的原因：审批没过，或者系统权限没给。这两层的边界，以及沙箱、工具策略、提权三者怎么划分，可以另看沙箱、工具策略与提权的边界。安装方式本身也会影响这层——用哪种方式装 CLI 的取舍见四种安装方式怎么选。
这篇没解决的部分
说清楚边界比多写两段更有用：
- 权限与功能的精确映射，官方本页未给出。上面那张对照表是并列推演，不是官方结论；缺哪一项授权导致哪个功能不动，得看官方专门的 macOS 权限页。
- 签名与 TCC 层面的疑难恢复不在本页范围，文档只是把这类问题指向了权限专页。
- 拿不到 macOS 应用安装包的情况。官方说明有些发布版本只带 CLI、evidence 或 Windows 资产；如果最新版本没有 macOS 应用资产，就退回到最近一个带该资产的版本，或者从源码构建。安装包命名规则是
OpenClaw-<版本号>.dmg（优先）和OpenClaw-<版本号>.zip，只从 OpenClaw 的 GitHub releases 页面获取：https://github.com/openclaw/openclaw/releases。 - 这个应用不替代网关文档。官方明确写了，网关配置、供应商、插件、渠道、工具和安全都在各自的文档里，别指望在 macOS 应用这一页找到答案。
如果你只需要 CLI 和网关、根本不打算用菜单栏应用，那这五类权限大部分都用不上——官方在开头就给了这条分流：只要 CLI 和网关的话，从入门文档走那条路即可。权限这件事的成本，本质上是你想让这个 Agent 在这台 Mac 上能做多少事换来的。
延伸阅读
- 从头读起：OpenClaw 架构总览：网关、Agent、渠道、节点、插件五层各管什么，出问题该往哪查
- 本专题共 40 篇，完整分组目录见专题页
- OpenClaw 更新失败怎么救、回滚分几层、卸载要清掉哪些目录
- OpenClaw 网关起不来怎么办：锁文件、端口占用与后台进程的三层排查
本文依据 OpenClaw 官方仓库（github.com/openclaw/openclaw）docs/ 下的官方文档整理，核对日 2026-08-17。
我们没有安装或运行过 OpenClaw，因此不涉及界面外观、操作手感与实测耗时的任何描述；
文中的默认值、命令与配置项均为文档口径，不构成对实际运行结果的保证。
该项目迭代很快，请以仓库最新内容为准。接入即时通讯平台前，请自行确认所在平台的规则与合规要求。