Claude Code 桌面控制权限报错排查

Claude Code 在 Mac 上提示权限「尚未授予」，不一定是你漏点了开关。原文整理了同一报错背后的三类原因：授权对象不对、CLI 没重新读取权限，以及运行版本缺少配套 helper。

这份排查指南的价值在于顺序明确：先查授权给了谁，再查进程是否重启，最后检查版本配套。它来自问题线程中的用户报告，可以缩小排查范围，但还不能算覆盖所有环境的官方结论。

开关都开了，为什么还说没权限

启用 computer use 后，Claude 调用 request_access，可能返回：

macOS Accessibility and Screen Recording permission(s) not yet granted

原文引用的 Claude Code 问题记录包括 #50735 及多个重复报告，涉及 CLI 2.1.104 到 2.1.263，系统覆盖 Sonoma、Sequoia 和 Tahoe。同一句错误提示，背后却可能是不同故障。

第一种情况最容易误判：你授权了 Terminal、iTerm、Warp，甚至 Claude.app，却没有授权实际运行的 claude 二进制文件。

按原文对内置 computer-use server 的描述，它运行在 CLI 进程内部，macOS 检查的是这个二进制文件的权限。终端应用的授权不能替代它。

这也解释了一个迷惑现象：在 shell 里执行 screencapture 可以成功，MCP 仍然受阻。前者能使用终端的授权，不能证明 Claude Code 已具备同样权限。

下面两条命令用于找到真实文件，并在 Finder 中显示它：

readlink -f "$(which claude)"            # 真实二进制文件，而不是符号链接
open -R "$(readlink -f "$(which claude)")"   # 在 Finder 中显示它

重点是第一行解析出的真实路径，别只盯着命令入口或符号链接。

接着，把该文件拖入「系统设置 → 隐私与安全」中的「辅助功能」和「屏幕与系统音频录制」，分别打开开关。原文提到，权限窗口的搜索框可能找不到 /opt/homebrew 下的文件，直接从 Finder 拖入更方便。

npm 安装的文件在 macOS 上也可能以 .exe 结尾。原文将其解释为构建产物，提醒不要双击运行。

授权以后，必须重新启动哪一个进程

第二种原因更简单：按原文整理的报告，CLI 只在启动时读取授权，正在运行的会话看不到刚添加的权限。

因此，操作重点是完全退出 Claude Code，再重新启动。需要接回工作时，可以使用 claude --resume。

作者还引用了 Anthropic 的排障说明：授予 Screen Recording 后，要完全退出 Claude Code，并确认终端应用已列入授权名单。若这两步已经完成，才继续检查前面的二进制授权和后面的 helper 问题。

授权状态变了，不代表当前 CLI 会话已经读到了变化。

与其继续反复切换开关，先确认旧 CLI 进程已经退出，更符合这份指南的排查逻辑。

权限没问题，也可能卡在版本配套上

如果真实二进制已授权，CLI 也重启了，原文建议检查运行版本和本地 helper 目录：

claude --version
ls ~/Library/Application\ Support/Claude/claude-code/

第一行确认当前 CLI 版本，第二行查看配套目录。要关注运行版本是否有对应的 helper 文件夹。

#50735 中的用户将检查关卡追踪到了这个按版本保存的目录，其中涉及 claude.app 和 .verified 标记。用户 matteocirca 在 2026 年 9 月报告：Claude desktop app 会为其捆绑的 CLI 版本写入 helper，而原生 CLI 独立自动更新。CLI 先升级后，运行版本可能没有对应 helper，却仍返回 TCC 权限错误。TCC 是 macOS 管理这类隐私授权的机制。

该用户报告有效的办法有两个：从 Claude desktop app 的 Code 视图启动会话，使用它捆绑的版本；或者直接运行已有 helper 的版本，例如 ~/.local/share/claude/versions/<version-that-has-a-helper-folder> --resume <session-id>。

同一报告中，在 /mcp 禁用再启用 computer use、执行 claude install、切换桌面端 computer use、重新启动桌面端，都没有解决问题。把旧版本目录复制成新版本号也遭到拒绝。

但另一个用户表示，helper 落后几个版本，在修复二进制授权后仍能正常工作。

版本不一致只是线索，不能单独证明故障原因。

另外还有一种需要分开的症状：request_access 直接返回 denied，完全不出现授权提示。原文引用 #103373 的近期报告，将它与从 claude.ai Projects 线程远程启动的会话联系起来；同样请求在桌面端启动的会话中可以工作。遇到这种情况，应先用本地会话复现。

我的判断

这份指南最有用的地方，是把笼统的权限错误拆成了可检查的对象：文件、进程、版本目录，以及会话来源。对日常 AI 编程来说，这比不断重装更容易得到明确反馈。

不过，三类原因的证据强度并不相同。helper 的生成机制和版本关系，主要来自个别用户追踪，原文没有给出源码验证、完整版本矩阵或对照实验。它适合作为后续排查方向，不能据此断言「升级必然导致失效」。

作者团队还开发了同样依赖屏幕权限的 MCP 产品 Auten。这能解释他们为何关注此类问题，但产品介绍不能充当排障结论的验证。原文也没有比较 Auten 与内置 computer use 的故障率，无需据此更换工具。

能拿来做什么

• 给 Mac 上的 AI 编程环境整理权限记录时，同时记下终端应用和 claude 真实二进制路径，避免把终端截图成功当成完整验收。
• 调整权限后，完全退出 CLI，再用 claude --resume 恢复会话，确认新进程读取到授权。
• 前两步无效时，再对照 claude --version 和 helper 目录，尝试桌面端 Code 视图提供的捆绑版本，并记录结果。
• 如果完全没有授权弹窗，先检查会话是否来自远程 Projects，在本地执行相同任务后，再决定是否继续排查系统权限。