Mac 反复索要 Screen Recording 权限：真正有效的修复方法

你打开 Zoom，点击共享屏幕，macOS 弹出了和上个月一模一样的对话框，问你是否允许 Zoom 录制屏幕。你上次已经点过同意了。你打开 System Settings，它就在那里：Zoom 明明白白列在 Screen & System Audio Recording 列表中，开关是打开的。什么都没坏。可你还是又被问了一遍。

一周后，另一件事发生了。你的备份工具读不到 Mail 文件夹。你检查 Full Disk Access，这个 App 也在列表里，开关也打开着，一切都符合预期。但这个 App 的表现，就像它压根没有权限一样。这不是同一个问题，尽管它带给你的感受完全一样。

你能找到的绝大多数建议，都把这两种情况当成同一件事来处理——这正是那些建议大多无效的原因。前者是有意为之：Apple 在屏幕捕获权限里内置了周期性的重新确认，而且没有任何开关可以关掉它。后者是一个货真价实的故障，有明确且可查证的成因，而且几乎总是归结到一件事：macOS 不再相信磁盘上的这个 App，还是你当初授权的那个 App。

本文把这两者拆开，解释它们背后共同的子系统，并分别给出正确的修复方法。文章还会说明，为什么这个话题下最常见的那条建议——用 chmod 改文件权限，或者跑某种「权限修复」——和这里涉及的系统毫无关系。下文演示的所有内容，均在一台运行 macOS 26.5.2（版本号 25F84）、开启了 System Integrity Protection 的 Mac 上实测。

核心要点

• 两个不同的问题顶着同一张脸 —— 屏幕捕获的定期重新提示是设计使然、无法关闭；而「已授权却不生效」则是有真实成因的真实故障。
• TCC 把权限绑定到 App 的代码签名身份，而不是路径 —— 这就是为什么一次更新、一次移动，或者磁盘上存在同一个 App 的两份副本，都会让权限悄无声息地失效。
• tccutil reset 是 Apple 提供的唯一命令 —— 你无法从 Terminal 授予任何权限，而不带 bundle identifier 直接跑 reset，会抹掉这台 Mac 上所有 App 的该项权限。
• 那两个隐私数据库连 ls 都读不了 —— 在一台开启 SIP 的测试 Mac 上，列出任一 TCC 目录都会返回 Operation not permitted，这是「它不是普通文件权限」最有力的证明。
• Apple 从未公布服务名列表 —— ScreenCapture、SystemPolicyAllFiles 这类名称属于社区知识，任何把它们当成官方文档呈现的指南，都是在猜。

TCC 是什么，又不是什么

决定某个 App 能否录制你的屏幕、读取你的 Mail 文件夹、使用麦克风或控制其他 App 的那个子系统，叫做 TCC，全称 Transparency, Consent and Control（透明、同意与控制）。你点过的每一个「App 想要访问……」对话框都是它弹出来的，System Settings 里 Privacy & Security 下的每一份列表也都是由它填充的。

Apple 为这一领域唯一的命令行工具写的 man 手册页，用一句话概括了它。NAME 一节写的是「tccutil – manage the privacy database」，DESCRIPTION 展开为：「The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data.」

请仔细读这句话，因为措辞非常精确，它揭示了整个系统的形状。TCC 存储的是决定。它是一份同意记录。它描述的不是某个文件，而是某个应用程序与某一类受保护数据之间的关系。

隐私数据库不是文件系统

这是浪费时间最多的一个误解，所以值得立刻处理掉。

传统 Unix 文件权限是存储在文件本身上的属性：一个所有者、一个组，以及读/写/执行位，用 chmod 和 chown 修改。它们回答的问题是「哪些用户账户可以碰这个文件？」

TCC 回答的是一个完全不同的问题：「用户同意了让哪个应用程序读取这一类数据？」主体不是用户账户，而是应用程序。The Eclectic Light Company 的 Howard Oakley 在 2025 年 11 月那篇讲权限与隐私的解析文章里，把这个区别说得很到位：「privacy protection operates outside of file attributes, using a rule-based system applied to each app.」

实际后果是绝对的。你的用户账户本来就拥有 ~/Library/Mail，POSIX 位也早就允许你读它。这恰恰解释了为什么以你的身份运行的终端命令能读它，而以你的身份运行的 GUI App 却不能：文件权限从来就不是障碍，TCC 才是。

所以再多的 chmod 也修不好 TCC 问题。任何「修复权限」流程也一样——那是 APFS 之前的时代针对 receipts 数据库的概念，Apple 早在多年前就把它从 Disk Utility 里移除了。为了一个屏幕录制弹窗而对主文件夹跑 sudo chmod -R 755 不会有任何帮助，反而可能损坏你的 Library 文件夹。不要这么做。

那两个连列目录都做不到的数据库

TCC 有两个数据库。属于每个用户的那个位于 ~/Library/Application Support/com.apple.TCC/，保存作用于你账户的决定。系统级的那个位于 /Library/Application Support/com.apple.TCC/，保存作用于整机的决定，包括管理员或 MDM 描述文件可以设置的那些。

下面这个演示可以终结争论。在测试 Mac 上、SIP 开启的状态下，尝试了这两条命令：

ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/

两条都返回了 Operation not permitted。注意不是 permission denied——那才是 POSIX 失败的样子——而是 System Integrity Protection 直接阻断访问时内核给出的回应。SIP 已确认处于开启状态：csrutil status 返回 System Integrity Protection status: enabled.

你无法列出这些目录、无法读取其中的数据库、也无法编辑它们。如果某篇指南教你用 SQLite 浏览器打开 TCC.db 然后插入一行记录，那它描述的是一台关闭了 SIP 的机器；而为了绕过一个权限弹窗去关闭 SIP，等于拿你 Mac 防御体系的一大块去换一个对话框。本文不会告诉你怎么做这件事。

你能做的是：通过 System Settings 界面授予权限、用 tccutil 重置某个决定，或者让 MDM 描述文件代你写入决定。就这三扇门，没有第四扇。

为什么要这样设计

如果 TCC 的决定保存在一个普通的可编辑文件里，那么任何对你主文件夹有写权限的 App，都能悄悄给自己授予屏幕录制、摄像头访问，以及对 Mail 文件夹的完全支配权。这层保护就一文不值了。所以 Apple 把这些决定放在了 SIP 后面，让唯一受支持的写入路径变成「用户与系统绘制的对话框交互」，并且只给了命令行工具一个动词：reset。

这是一套自洽的设计；而站在深夜 11 点修一个坏掉的权限的人的角度看，这也是一个非常小的工具箱。本文的大部分内容，就是教你把它用好。关于 macOS 如何把 Gatekeeper、公证、SIP 和 TCC 分层叠加起来的更宏观背景，我们的macOS Tahoe 安全与隐私完全指南覆盖了周边架构。

两个不同的问题

现在来做本文后续内容所依赖的那个区分。

问题一：有意为之的重新提示

在 2024 年 macOS 15 Sequoia 的 beta 周期中，Apple 为屏幕与音频捕获引入了周期性的重新确认。任何捕获你屏幕的 App 都会被要求按一定周期重新确认，且无法选择退出。

最初的 beta 行为是每周一次，而且每次重启后还会再问一遍。这招致了大量公开批评。MacRumors 在 2024 年 8 月报道称「popups for screen recording app permissions have been showing weekly up throughout the beta testing process, but Apple has tweaked the frequency in response to user feedback」，并称 beta 已改为每月重新授权。9to5Mac 和 iDownloadBlog 也从同一个 beta 中报道了相同的变化。每次重启都提示的行为在同一时间被取消。对话框提供了一个「Allow For One Month」按钮和一个打开 System Settings 的选项，MacRumors 当时指出「it does not appear that there is a way for users to permanently give screen recording access to recording functionality, but a monthly popup is at least more convenient than a weekly popup.」

接下来是诚实的部分。我无法从任何权威来源核实 macOS 26 这一代的当前周期。 Apple 自家关于这个面板的支持页面——macOS Tahoe 26 Mac 使用手册中的「Allow apps to use screen and audio recording」——只说明了如何打开该面板、如何应答对话框，对周期性重新批准只字未提。讨论 macOS 26 的二手来源彼此矛盾，有的说每周重新提示，有的说每月，而且没有一家给出出处。

所以，能确定的和不能确定的分别是这些。**已确认：**周期性重新提示是在 Sequoia 周期引入的，适用于屏幕与系统音频捕获，提供一个月的授权期限，且没有面向用户的关闭开关。**已确认：**Apple 当前关于该面板的支持文档完全没有提到它。**未确认：**macOS 26 这一代的确切间隔。如果你的 Mac 大约每月提示一次，那与 Apple 在 Sequoia 中发布的行为相符。如果提示频率远高于此，请阅读下文的故障诊断部分，因为频繁重新提示是另一个问题。

关于问题一，最有用的一点是：**它不是故障，也没有任何东西需要修。**点一下 Allow 只需一秒，而且对话框本身就是那次重新确认，所以你不需要回到 System Settings 去重新拨动任何开关。任何教你在收到月度提示后去重置、重装或编辑什么东西的指南，都是在给一个健康的病人卖药。

有一个开发者侧的例外。Apple 有一个名为 com.apple.developer.persistent-content-capture 的授权（entitlement），可以抑制这个循环提示，Michael Tsai 的博客在 2024 年 8 月汇总了围绕它的开发者讨论。这是一项面向远程控制和 VNC 类应用的受管能力：开发者必须向 Apple 申请并获批。作为用户，你无法启用它。它只能解释为什么少数远程访问类 App 从来不烦你。

问题二：授权授不牢

这一个是货真价实的故障。它的表现是：App 明明列在面板里、开关也开着，行为却像完全没有权限；或者 App 在一次更新后从面板里消失了；或者权限一直有效，直到你退出并重新启动；或者出现两个同名条目；或者某个工具即使你用 + 添加了也始终不出现在面板里；又或者每次启动都提示，而不是每月一次。

这些都有各自的成因，而且大多数共享同一个成因。那是下一个主要章节的内容。

有一件事不属于这个列表，尽管它看上去很像：Mac 反复索要你的登录钥匙串密码。那是钥匙串子系统，不是 TCC，本文的任何内容都修不好它。如果这是你的症状，登录钥匙串密码提示修复指南才是对的方向。

你遇到的是哪个问题

症状	属于哪个问题	该怎么做
屏幕捕获提示大约每月一次，点 Allow 后 App 正常工作	设计如此	点 Allow。没有任何问题。
每次启动都提示	故障	签名身份或重复副本问题。见下文。
面板里开关已打开，App 仍然做不了那件事	故障	陈旧条目绑定在旧身份上。做一次干净的重新授权。
更新后 App 从面板中消失	故障	签名变了。重新授权。
面板里出现两个同名条目	故障	磁盘上有两份副本。找出来删掉一份。
命令行工具能用，但从不出现在面板中	已知的 macOS 26.1 bug	见命令行章节。
提示弹出，你点了 Allow，却什么也没发生	故障	通常是 App 从未被完全退出。做一次干净的重新授权。
开关变灰并带有描述文件说明	受管理的 Mac	联系管理这台设备的人。
非捕获类权限每月重新提示	故障	只有屏幕捕获才有计划内的重新提示。

在 macOS 26 这一代，各项权限分别在哪里

所有这些面板都位于同一个根目录下。打开 System Settings，在侧边栏点击 Privacy & Security，然后选择对应类别。与本文相关的类别有：

• **Screen & System Audio Recording。**在 macOS 26 这一代改了名，之前叫 Screen Recording。Apple 的描述只有一行：「Allow apps to record your screen and audio, or just your audio. The listed apps have access.」
• **Full Disk Access。**覆盖全系统的受保护用户数据：Mail、Messages、Safari 数据、Time Machine 备份，以及其他 App 的容器文件夹。
• **Accessibility。**控制你 Mac 的能力：移动指针、点击、读取窗口内容、驱动其他应用程序的界面。
• **Automation。**某个特定 App 向另一个特定 App 发送 Apple 事件的权利。它是唯一一个按「配对」而非扁平列表来组织的面板。
• **Files and Folders。**细粒度的文件夹访问：桌面、文稿、下载、可移动卷和网络卷。已获得 Full Disk Access 的 App 不需要这里的任何条目。
• **Input Monitoring。**让某个 App 在不处于最前台时也能看到按键输入。
• Camera 与 **Microphone。**字面意思。如果你的问题专门出在麦克风上，输入权限链条有它自己的一些怪癖，详见修复 macOS Tahoe 26.5 上 Mac 麦克风失灵这篇指南。
• **Local Network。**较新的一项，也是常见的困惑来源，因为被拦截的本地网络权限所产生的症状，看上去一点也不像隐私问题。停止响应的打印机就是经典案例，AirPrint 与本地网络隐私修复一文对此有完整走查。

有两个结构性事实在后文很重要。你看到的列表是数据库的一个渲染结果，而下文描述的 macOS 26.1 bug 证明了：渲染可以是错的，而数据库是对的。另外，用 - 按钮移除条目是删除那个决定，而不是拒绝该 App，所以下次这个 App 请求时你会收到一个全新的提示。这个区别正是「干净重新授权」流程的基础。

为什么已授予的权限会失效

机制如下。只要你理解了这一点，这一领域里大部分令人困惑的行为都会变得可预测。

TCC 绑定的是代码签名身份，不是路径或名称

当你给某个 App 授权时，macOS 记录的并不是「位于 /Applications/Foo.app 的这个文件可以录屏」。它记录的是一个与该 App 的代码签名身份绑定的决定：它的标识符，以及描述「谁签的名」的那条加密要求（requirement）。Apple 的技术说明 TN3127「Inside Code Signing: Requirements」是这些要求如何构造的参考文档。

由此产生的后果是没人告诉你的那件事：**如果签名身份变了，macOS 会把这个 App 当成一个从未被授予过任何权限的、不同的应用程序。**旧条目仍然留在面板里，看起来是已授权状态，描述的却是一个「以数据库记住的形态」已不复存在的 App。你看到的是一个打开的开关，系统看到的是一个陌生人。

你可以自己检查一个 App 的身份。在测试 Mac 上：

codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app

输出中包含一行 Identifier，也就是系统使用的 bundle identifier（Terminal 是 com.apple.Terminal）；一串 Authority 行，指明为它签名的那些证书；以及一行 TeamIdentifier。对于 Apple 自家随系统附带的 App，TeamIdentifier 显示为 not set，因为 Apple 为其系统软件签名所用的授权链，与第三方开发者使用的不同。对于第三方 App，你应该看到一个十位字符的团队标识符，以及一条包含 Developer ID 证书的授权链。

那个团队标识符就是稳定的锚点。以 ad hoc 方式签名、没有团队标识符的 App，只能靠它的代码哈希来识别，而代码哈希每构建一次就会变一次。用 Developer ID 签名的 App 拥有能在更新中存活下来的稳定团队身份。这就是为什么有些 App 每次更新后都要重新提示，而大多数不会。

现在来看具体的几种情况。

情况一：App 更新了，而且换了签名方式

这个 App 发布了新版本。新构建使用了不同的证书签名，或者开发者从 ad-hoc 签名改成了 Developer ID（或者反过来），又或者他们的证书过期了，用新证书重新签了名。

**如何识别：**时间点与一次更新精确吻合，并且这个 App 要么从面板中消失，要么多出了第二个条目。

**修复：**移除陈旧条目并重新授权。没有别的事可做；就 TCC 而言，这个 App 确实是一个全新的 App。

情况二：磁盘上有同一个 App 的两份副本

这是「开关开着却不工作」这一症状最常见的成因，也是最容易被漏掉的一个。

你下载了一个 App，从 ~/Downloads 运行了一次并授予了权限，之后又把它拖进了 /Applications。或者 Homebrew Cask 装了一份，而你本来就已经有一份。又或者你在 /Applications 放正式版、在 ~/Applications 放 beta 版。面板只显示一行带有该 App 名称和图标的记录；它不会告诉你这一行指的是哪一份副本。你看到的是 ~/Downloads 里那份副本的授权，而你启动的是 /Applications 里的那份。

**如何识别：**把磁盘上所有副本都搜出来。

mdfind "kMDItemKind == 'Application'" -name "AppName"

或者，用一次可以覆盖 Spotlight 可能未索引到的副本的扫描：

find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null

如果返回了不止一个路径，那就是答案。

**修复：**删掉你不想要的那些副本，只保留一份，然后对幸存的那一份做一次干净的重新授权。不要跳过删除这一步；磁盘上留着第二份副本，意味着一个月后你还会回到这里。

情况三：授权之后 App 被移动了

与情况二相关但不同。只有一份副本，但它被移动了。有些 App 能干净地挺过这一关，有些不能，取决于它们的签名要求怎么写，以及内嵌辅助程序的路径是否被固化进了父级结构中。

**如何识别：**App 原本工作正常，你重新整理了应用程序文件夹，或者从迁移中恢复了系统，然后它坏了。

**修复：**在新位置做一次干净的重新授权。如果它被移进了 /Applications 内的某个子文件夹，先试着把它移回顶层；少数带自更新机制的 App 在子文件夹里表现很糟。

情况四：一次不完整的更新让签名失效了

更新被中断了，某个同步工具动过这个 bundle，某个杀毒产品隔离并还原了其中的一个文件，或者一次备份恢复不完美地重建了这个 bundle。签名不再通过校验。

如何识别：

codesign --verify --deep --strict --verbose=2 /Applications/AppName.app

健康的 bundle 会产生一份简短报告，结尾声明该 App 在磁盘上有效并满足其指定要求。受损的 bundle 会指出具体是哪个文件校验失败。如果你在这里看到失败，再怎么折腾权限都没用，因为 macOS 根本不会信任这个 bundle。

**修复：**从开发者的原始下载渠道重新安装。这是少数几种「重装 App」确实是正确答案、而非敷衍了事的情形之一。同一底层损坏还有一种更显眼的表现形式，就是「app is damaged and can't be opened」对话框，我们在 Gatekeeper 与隔离属性修复指南中做了详细讲解。

情况五：Sparkle 式自更新程序替换掉了自己的 bundle

许多在 App Store 之外分发的 Mac App 使用 Sparkle 框架或类似机制自我更新：下载新版本，并在运行状态下把自己的 bundle 原地替换掉。

当这一切正常工作时，新 bundle 携带相同的团队标识符，TCC 会继续认得它。当它不正常时——因为更新用了不同的签名，或者替换过程留下了一个只写了一半的 bundle，又或者 App 把自己替换到了一个略有不同的路径——你下次使用受保护功能时，就会遇到重新提示或静默失败。

**如何识别：**这个 App 在 App Store 之外自我更新，而权限问题恰好集中出现在它更新的那个时间点前后。

**修复：**等更新完成后做一次干净的重新授权。如果每次更新都发生，那就是开发者的签名配置有问题，值得向他们反馈，因为这在他们那一端是可以修的。

通用诊断

面对任何「已授权但不工作」的情况，按顺序问三个问题：磁盘上这个 App 有几份副本（mdfind）？这个 bundle 能通过校验吗（codesign --verify）？它是不是在一次更新之后立刻坏掉的？这三个答案几乎每次都能指向上面五种情况之一。

Terminal 工具：tccutil 能做什么、不能做什么

这个子系统只有一个命令行工具，而且它的能力比大多数指南暗示的要窄得多。

reset 是唯一的命令

在 macOS 26.5.2 上不带任何参数运行 tccutil，它会打印用法字符串：

tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]

这就是全部接口。Apple 的 man 手册页明确写着「one command is currently supported」，并这样描述它：

reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. If a bundle identifier is specified, the service will be reset for that bundle only.

Apple 在手册页里给出的示例是 tccutil reset AddressBook 和 tccutil reset All com.apple.Terminal。

请推出大多数指南跳过的那个结论：**没有 grant 命令。**你无法从 Terminal 批准一项权限。reset 是让系统忘掉一个决定，好让 App 再问一次；它不会替你说「是」。说「是」的方式只有两种：System Settings 界面，以及 MDM 配置描述文件。如果你看到某篇指南声称有某条 tccutil 咒语能授予 Full Disk Access，那它是错的。

最要紧的那条 bundle ID 警告

这是整个 Terminal 章节的实操核心，所以单独给它一块地方。

# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture

# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appname

bundle identifier 在语法上是可选的，在实践中是必需的。省略它，就等于你告诉 macOS 忘掉这台机器上所有的屏幕录制决定。Zoom、Slack、Discord、Teams、你的截图工具、你的录制软件、你的远程支持客户端：下次用到它们时，每一个都会来问你。没有什么会被永久破坏，但你为了修一个 App，给自己制造了一下午的对话框。

不带 bundle identifier 的 tccutil reset All 更糟，它会忘掉所有 App 的所有服务的所有决定。如果哪篇指南教你把这个当作第一步来跑，关掉那篇指南。

**永远附上 bundle identifier。**每一次，无一例外。

参数校验顺序，以及它为什么会掩盖一个拼写错误

这一点经过了直接测试，而且这个行为会影响你怎么读错误信息。tccutil 校验 bundle identifier 的时机早于服务名。同时给它一个假的服务名和一个假的 bundle ID：

tccutil reset ZZZNotAService com.example.nonexistent.zzz

它返回：

tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)

它抱怨的是 bundle，而不是那个明显无效的服务名。给它一个假的服务名，完全不带 bundle ID：

tccutil reset ZZZNotAService

它返回：

tccutil: Failed to reset ZZZNotAService

实际后果是：bundle identifier 里的拼写错误总会给你一个清晰、具体的报错，这很好。但服务名里的拼写错误可能被掩盖掉——当 bundle identifier 也写错时，工具根本走不到抱怨服务名的那一步。如果你收到 -10814 错误，先修正 bundle identifier，然后重新运行命令，再看看服务名是不是也写错了。

推论就是：在动手拼命令之前，先核实 bundle identifier。

如何查找一个 App 的 bundle identifier

有两种可靠方法。第一种在测试 Mac 上验证过，osascript -e 'id of app "Terminal"' 返回 com.apple.Terminal，osascript -e 'id of app "Safari"' 返回 com.apple.Safari：

osascript -e 'id of app "AppName"'

把 App 的名称按它在 Finder 中显示的样子替换进去。这是最快的方法，也是 Howard Oakley 的读者在他那篇隐私保护综述的评论区里提出、并被他认可的方法。

第二种方法直接读取 bundle，当 App 不在标准位置、或者 AppleScript 无法解析其名称时很有用：

defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifier

或者使用代码签名视图，它能同时告诉你签名机构，读它的 Identifier= 行即可：

codesign -dv --verbose=2 /Applications/AppName.app

用哪个都行，但一定要用其中一个。不要根据 App 的名称去猜标识符。反向 DNS 命名是一种惯例，不是规则，而且有大量 App 的标识符和你猜的完全不沾边。

服务名属于社区知识，不是 Apple 文档

在这里，诚实比完整更重要。

Apple 从未公布 tccutil reset 接受的服务名列表。 man 手册页恰好给了两个例子：AddressBook 和 All。这就是 Apple 在这个主题上的全部文档。

流传在外的那些名称来自社区。Howard Oakley 在他 2025 年 3 月那篇隐私保护综述中发布了一份列表，其中包括：

Accessibility、AddressBook、All、AppleEvents、AudioCapture、BluetoothAlways、Calendar、Camera、ContactsFull、ContactsLimited、DeveloperTool、FocusStatus、MediaLibrary、Microphone、Motion、Photos、PostEvent、Reminders、RemoteDesktop、ScreenCapture、SpeechRecognition、SystemPolicyAllFiles、SystemPolicyDesktopFolder、SystemPolicyDocumentsFolder、SystemPolicyDownloadsFolder、SystemPolicyNetworkVolumes、SystemPolicyRemovableVolumes。

其中有两个对应本文最关心的面板：ScreenCapture 对应 Screen & System Audio Recording，SystemPolicyAllFiles 对应 Full Disk Access。

我刻意没有在测试 Mac 上暴力测试这些名称。一次成功的 tccutil reset 会抹掉这台机器上真实的权限，所以确认某个名称有效的唯一途径，就是毁掉你原本想保住的东西；而测试那些会失败的名称什么也说明不了。上面这份列表是来源可靠的社区知识，与从业者在实际工作中使用的一致。它不是 Apple 文档，我宁愿把这一点说清楚，也不愿把它当作权威来源呈现。

由此有两点推论。如果一次 tccutil reset 看上去什么都没做，在断定系统坏了之前，先考虑服务名是不是写错了。另外，能走 System Settings 路线时就走，因为面板从来不会有拼写问题。

命令行二进制文件与辅助工具

在这个领域，「一个 App 对应列表里一个条目」的模型崩塌得最彻底，而且一个有充分记录的 macOS 26 bug 曾让情况在一段时间内糟糕得多。

纯可执行文件没有 bundle identifier

一个 .app 是一个 bundle：具有既定结构的目录，其中包含一个 Info.plist，声明了包括 CFBundleIdentifier 在内的若干信息。而躺在 /usr/local/bin 里的一个编译后的二进制文件什么都没有。它只是一个 Mach-O 可执行文件。

TCC 的模型是围绕 bundle 构建的。纯可执行文件仍然可以被授予权限，但它没有可供索引的 bundle identifier，这就是为什么它可能不会像 App 那样出现在面板里，也是为什么 tccutil reset Service bundle.id 对它无从下手。

macOS 26.1 显示 bug，以及它教会了所有人什么

2025 年末，Apple Developer Forums 上出现了一批帖子，在不同权限上报告了同一件事。这件事值得走一遍，因为 Apple 自己的工程师确认了诊断，而结论告诉了你一件关于「面板与数据库之间关系」的、经得起时间检验的事。

第 807898 号帖子《Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe)》报告称：一个请求屏幕录制的纯可执行文件仍然会收到正常提示，被授权后仍然能正确捕获屏幕，却从不出现在 System Settings 列表中。发帖者的总结是：「macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list.」同样的代码打包成 .app bundle 后就正常出现了。Apple 的 DTS 工程师 Quinn「The Eskimo!」回复确认了这一点：「IMO this is a bug and I encourage you to file it as such.」

第 807323 号帖子《Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1)》从另一个角度报告了同样的症状。一个调用 CGRequestScreenCaptureAccess() 的后台 Unix 可执行文件在 26.0.1 上工作正常，到 26.1 就不再出现在界面里了。发帖者指出，用 + 按钮手动添加该可执行文件「grants permission internally, but the executable still doesn't show in the UI」，因此用户「cannot verify or revoke permissions」。那个帖子没有得到 Apple 的回应，只有另一位开发者的佐证。第 809549 号帖子就 Full Disk Access 提出了同样的问题，报告称命令行二进制文件「fail to appear under the FDA settings, even after selection」；Quinn 把它引导到了既有的汇总帖，随后版主锁帖。

那个汇总帖，第 806187 号，才是结论所在。关键发现是：权限自始至终都被正确记录着。数据库是对的，列表是错的。正如一位参与者所说：「CLI apps can have full disk access or other permissions, but you cannot see it in the list.」26.1 中新增的一项「Background Security Improvements」功能，把设置界面改成了只显示打包成 bundle 的应用程序。

临时的变通办法是「drag the binary from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list.」而经得起时间检验的建议来自另一位 DTS 工程师 Kevin Elliott：「The better solution is to embed that tool inside an app bundle. I don't mean 'make your command-line tool act like an app', I mean 'take your command-line tool and stick it inside an app bundle, then use it exactly the way you were using it before'.」

多位参与者确认这个显示 bug 已在 macOS 26.3 beta 中修复，第 807898 号帖子里也有人报告，该问题在 Accessibility 上的对应版本（存在于 26.1 和 26.2 beta 中）同样在 26.3 中得到了解决。

**即使你已经过了 26.1，这件事为什么仍然与你有关：**面板是数据库的一个视图，而视图会撒谎。如果某个 App 或工具明显拥有某项权限却不出现在列表中，不要假定权限缺失。先测试实际行为，再开始重置任何东西。

为什么从 Terminal 启动的程序会继承 Terminal 的权限

这一点让开发者们反复栽跟头，而一旦你知道了规则，它就不再神秘。

TCC 并不是简单地问「是哪个二进制文件在发起这个请求？」它会沿着 Howard Oakley 所说的「an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied」向上追溯。系统寻找的是负责的进程，通常是用户启动的那个 App，而不是调用链最深处的那个进程。

所以当你从 Terminal 运行一个程序时，Terminal 通常就是那个负责的进程。你程序的屏幕捕获请求会变成 Terminal 的屏幕捕获请求。如果 Terminal 有这项权限，你的程序就能工作；如果没有，提示框上写的就是 Terminal 而不是你的程序。这正是第 807898 号帖子的发帖者观察到的现象：当从另一个 App（例如 VS Code 或 Terminal）启动时，「the parent app appears in the list instead, not the executable itself.」

日常使用中有三个后果。给你的终端模拟器授予某项权限，意味着你在其中运行的每一个工具都会继承这份授权——这既方便，也是一次实打实的权限扩张，随手授予之前值得想一想。同一个脚本，从 Terminal 启动、从 LaunchAgent 启动、以及从双击的 App 封装启动，行为会各不相同，因为每种情况下负责的进程不同。而更换终端模拟器意味着一切从头再来，因为 iTerm2、Ghostty、Warp、Kitty 和 Terminal.app 各自都是独立的身份。

辅助工具、XPC 服务与登录项

一个现代 Mac App 往往由多个可执行文件组成：主 App，可能还有位于 /Library/PrivilegedHelperTools 下的特权辅助程序，可能有嵌入在 bundle 内的 XPC 服务，也可能有一个在登录时运行的启动代理。

嵌入在正确签名的 bundle 内部的 XPC 服务，通常在父 App 的归属之下运作，因为归属链会解析到那个 App。而单独安装的辅助程序和启动守护进程往往不是这样：它们在 App 的进程树之外、以自己的身份运行，需要各自的授权。这就是为什么有些 App 会让你批准同一项权限两次，一次给 App、一次给它的辅助程序；也是为什么以 root 身份安装的辅助程序，可能需要在系统数据库而非你的每用户数据库里有一条记录。

如果某个 App 只工作了一半——界面有响应，但某个后台功能悄无声息地失败——那么「一个没有权限的辅助程序」是重点嫌疑对象。要知道哪个辅助程序需要什么权限，最快的途径是查阅该 App 自己的支持文档，因为你无法从面板里判断出来。

专门谈谈 Screen Recording

面板位置是 System Settings → Privacy & Security → Screen & System Audio Recording。Apple 的原文描述是：「Allow apps to record your screen and audio, or just your audio. The listed apps have access.」

这项权限特有的几个要点：

**它是唯一有计划内重新提示的权限。**没有任何其他 TCC 类别会按定时器重新询问。如果你的摄像头权限或 Full Disk Access 每月来问你一次，那不是设计中的行为，你遇到的是故障。

**切换它通常需要重启 App。**许多 App 只在启动时读取一次捕获能力。在 App 运行期间打开开关，它可能直到重新启动才会注意到。仅这一条就能解释大量「我启用了，但什么也没发生」的报告。

**系统音频与屏幕被归在一起，但并不等同。**这个面板同时覆盖两者。有些 App 只请求音频。如果某个 App 屏幕捕获正常却录出一片静音，看看它到底有没有请求系统音频捕获，并检查这个 App 自己的音频设备设置，因为缺少虚拟音频设备与 TCC 问题完全是两码事。Mac 屏幕录制完全指南对音频那一侧有详细走查。

**一个如实报告的现实硬骨头。**Microsoft Q&A 上的一个帖子记录了 macOS Tahoe 26.4（版本号 25E246）上的 Teams for Mac 在屏幕共享权限提示上陷入死循环。报告此事的管理员核实了一个人所能核实的一切：由 MDM 部署、针对 com.microsoft.teams2 并带有正确代码要求的 PPPC 描述文件；系统级 TCC 记录显示 kTCCServiceScreenCapture 的 auth_value=2；用户级记录显示相同结果；System Settings 显示 Teams 开关已打开，并附有该设置由描述文件配置的说明。他们清理过缓存、移除过旧的 com.microsoft.teams 标识符、通过 MDM 重装过、杀掉并重启过进程，也重启过机器。

给出的答复是标准的补救流程：「fully quit Teams, remove and re-add or re-toggle the Teams entry in Screen Recording, then restart Teams and re-attempt sharing so macOS can re-prompt and re-bind the permission」，若仍不奏效，则带上客户端日志升级给 Microsoft 支持。三周后，报告者表示没有得到任何可行的解决方案，他们改用网页版了。有时候权限在每一层都确实已经授予，而问题出在应用程序自身的 bug 上。知道什么时候该停手，也是这门手艺的一部分。

专门谈谈 Full Disk Access

Full Disk Access 是系统中范围最广的权限。备份工具、迁移实用程序、安全软件，以及用于管理工作的终端模拟器，需要的都是它。

**它和 Files and Folders 里的条目不是一回事。**Files and Folders 授予的是某个特定文件夹。Full Disk Access 授予的是整机范围内的受保护数据：Mail、Messages、Safari 浏览数据、Time Machine 备份，以及其他应用程序的容器目录。已获得 Full Disk Access 的 App 在 Files and Folders 里不需要任何条目。

**它几乎总是要求重启 App。**比任何其他权限都更甚，Full Disk Access 往往是在进程启动时被评估的。授予之后，请退出并重新启动这个 App。许多 App 会弹出对话框叫你正是这么做；相信它们。

**它无法通过提示框来请求。**App 无法弹出一个「点了同意就获得 Full Disk Access」的对话框；它只能把你导向那个面板。这就是为什么需要它的 App 会显示操作说明而不是系统对话框，也是为什么「我点了 Allow 但还是不行」是一种常见反馈：根本就没有 Allow 可点。

**对终端模拟器而言，这份授权范围很广。**给 Terminal 或 iTerm2 授予 Full Disk Access，意味着你在其中运行的每一条命令都通过前面讲的归属链拥有同样的触及范围。这往往正是管理员想要的。请明白你正在做的是什么。

命令行工具受到了上文所述的 26.1 显示 bug 影响，修复落在了 26.3 beta。如果你在 26.1 或 26.2 上，添加了某个 CLI 工具却始终不出现在列表中，那就是这个已知 bug，而这个工具很可能已经拥有了权限。测试实际行为，而不是相信那份列表。

专门谈谈 Accessibility 与 Automation

把这两个放在一起讲，是因为它们会造成同一类困惑。

Accessibility 授予 App 控制你 Mac 的能力。窗口管理器、文本扩展工具、剪贴板管理器、键盘重映射工具、自动化工具，以及远程支持软件都需要它，而 macOS 也把它当作一项强大的授权来对待。

它的独特行为是：许多 App 需要完全退出并重新启动，有些还需要把开关关掉再打开，改动才会生效。如果某个依赖 Accessibility 的 App 在一次更新后停止工作，请先检查前面讲的代码签名身份那几种情况。Accessibility 也是受 macOS 26.1 显示 bug 影响的面板之一，第 807898 号帖子中有报告称 Accessibility 那一版问题「has now been fixed in 26.3 Beta.」

Automation 在结构上与其他任何面板都不同。它不是一份 App 列表，而是一份配对列表：「App A 想要控制 App B」，每一对都是一个独立的决定。如果你的脚本控制三个应用程序，你就有三个决定和三个条目。

由此有两点推论。一个失灵的 Automation 权限，往往意味着若干配对中有一对缺失，而面板是你唯一能看出是哪一对的地方。另外，用 tccutil reset AppleEvents com.example.controller 重置 Automation 会一次性清除该控制方的所有配对，所以下次脚本触及每个目标时，你都要重新批准一遍。这往往是从卡死的 Automation 状态中脱身最快的办法，但要做好连续应对一串提示的准备。

有一个坑值得点名：从 Terminal 运行 AppleScript，记录下来的授权是「Terminal 控制目标 App」，而不是「你的脚本控制它」。把脚本换到另一个终端模拟器，或者把它封装成 App，你就得再批准一次。这是归属链在按设计工作，但这并不会让你第一次遇到时少吃一惊。

干净的重新授权流程

当你确认遇到的是真实故障时，就按这个流程来。按顺序执行。每一步的存在都有理由，跳过其中一步，正是人们得出「这套办法根本没用」结论的原因。

1. 完全退出这个 App。

不只是关掉它的窗口。用 Cmd-Q 退出，然后确认没有残留：

pgrep -fl "AppName"

如果还有进程存在，它们正持有着旧的权限状态，你接下来做的一切都会被拿去和一个陈旧的内存中决定作比较。

**为什么：**正在运行的进程会缓存自己的权限状态。在一个活着的进程之下重置数据库，会产生不一致的行为，把你送上追逐幻影的路。

2. 确认磁盘上恰好只有一份该 App 的副本。

mdfind "kMDItemKind == 'Application'" -name "AppName"

删掉你不用的任何副本。

**为什么：**如果存在两份副本，你可能重新授权了错误的那一份，最后回到原点。这一步正是人们会跳过的那一步，也是这套流程对他们失效的原因。

3. 确认 bundle identifier。

osascript -e 'id of app "AppName"'

**为什么：**错误的标识符往好了说会给你一个 -10814 错误，往坏了说会诱使你干脆把标识符从 reset 命令里去掉——而那是那条毁灭性的路。

4. 从面板中移除这个 App 的条目。

打开 System Settings → Privacy & Security → 对应面板，选中该 App，点击 -。如果系统要求管理员身份验证，请提供。

**为什么：**这是通过受支持的界面删除那个陈旧决定。它与把开关拨到关闭不是一回事——后者记录的是一次拒绝，而不是移除决定。一次拒绝意味着这个 App 不会再被允许来提示你。

5. 针对该 bundle identifier 重置对应服务。

tccutil reset ScreenCapture com.example.appname

请替换成正确的服务名和标识符。Full Disk Access 用 SystemPolicyAllFiles，Accessibility 用 Accessibility，Automation 用 AppleEvents。

**为什么：**面板和数据库可能不一致，26.1 那个 bug 已经确凿地证明了这一点。同时做界面移除和命令行重置，无论系统实际参考的是哪一个，你都覆盖到了。这里 bundle identifier 不是可选项。

6. 重新启动这个 App。

**为什么：**得到一个没有缓存决定、也没有上一次运行残留的全新进程。

7. 触发需要该权限的那个操作。

发起一次屏幕共享。打开那个文件夹。发送那个 Apple 事件。不要回到 System Settings 去预先把开关打开。

**为什么：**提示框正是把当前签名身份与决定绑定在一起的那个机制。这个绑定就是整个流程的全部意义所在。在面板里预先拨动开关，有时会写入一个未被正确绑定的决定，这正是人们报告「开关开着、App 却不工作」的原因。

8. 在提示中批准。

点击 Allow；如果这个 App 属于无法直接提示的那一类（例如 Full Disk Access），则点击打开 System Settings 并在那里启用。

9. 再退出并重新启动这个 App 一次。

**为什么：**许多 App 只在启动时读取一次自己的能力集合。这一步把「已授予」转化为「真的能用」，并消除了整个流程中最常见的假阴性。

如果做完第九步 App 仍然失败，那问题就不在权限上了。请转到下一节。

当一切都不奏效时

用一个全新的用户账户测试

在 System Settings → Users & Groups 中创建一个新的管理员账户，登录进去，安装或启动那个 App，并在那里授予权限。

这一个测试能干净利落地把问题空间一分为二：

• **在新账户里能用：**故障出在你自己用户账户的状态里，最可能是每用户的 TCC 数据库、某个陈旧的偏好设置，或者某个干扰性的登录项。App 和系统都没问题。
• **在新账户里同样失败：**故障是系统级的，或者在 App 自身。你的账户不是问题所在，而你原本打算去试的那一大堆「删掉你的偏好设置」建议，只会浪费你一晚上。

这只需要五分钟，比一个小时的瞎猜更有价值。

什么时候彻底重装才真的是答案

重装是面对一切问题的条件反射，而它通常是错的。它在三种情况下确实是对的：

1. **codesign --verify 报告 bundle 已损坏。**签名无法通过校验；下游的一切都修不好。请从开发者的原始下载渠道重装，而不是从备份恢复，因为备份可能正是损坏的源头。
2. **这个 App 是从一个修改过它的渠道安装的。**重新打包的安装器、给 App bundle 打补丁的工具，以及某些企业部署机制，会留下一个签名与开发者不再匹配的 bundle。请从开发者那里获取一份干净的副本。
3. **这个 App 自己的支持文档针对你遇到的具体症状这么说。**有些 App 存在已知的权限状态问题，并附有记录在案的重装流程，其中包括清理它们自己状态目录的步骤。

除这三种之外，重装通常只会重新得到你已经有的那个 bundle；而如果签名身份没变，权限状况也不会变。

重启，但要为正确的理由重启

重启会清理进程状态、重新加载启动守护进程，并重置内存中的缓存。它确实能修好一类卡住的权限状态，尤其是那些涉及无法干净地重新加载的后台辅助程序的情况。它修不好代码签名不匹配、磁盘上的重复副本、损坏的 bundle，或者应用程序的 bug。早早地重启一次，然后回到诊断上来。

不要做什么

说明白一点，因为下面这些在搜索结果里层出不穷：不要关闭 SIP，那是为了绕过一个对话框而移除整个系统范围内的保护。不要编辑或删除 TCC.db——在 SIP 开启时你做不到，在 SIP 关闭时你也不该想做。不要对主文件夹跑 chmod -R，它碰不到这个子系统，却可能弄坏你的 Library 文件夹。也不要运行不带 bundle identifier 的 tccutil reset All，除非你想把这一天余下的时间都花在点 Allow 上。

受管理的 Mac

如果你的 Mac 由雇主或学校管理，规则就变了；而在你花一个小时去跟一个本来就赢不了的开关较劲之前，先弄清楚这是否适用于你，是值得的。

如何判断你的 Mac 是否受管理

三项检查。第一，查看 System Settings → General → Device Management。如果安装了描述文件，它会列在那里。第二，留意隐私面板里的那行说明：受管理的条目会显示「该设置已由描述文件配置」之类的文字，而且它的开关通常是灰色的。第三，从 Terminal：

profiles status -type enrollment

在未受管理的测试 Mac 上，这条命令返回：

Enrolled via DEP: No
MDM enrollment: No

受管理的 Mac 会在这里报告注册状态。

描述文件能做什么、不能做什么

MDM 通过一个 Privacy Preferences Policy Control 载荷（通常称为 PPPC 描述文件）来授予权限。它直接把决定写入系统级 TCC 数据库，这就是为什么一台受管理的 Mac 上会出现「没人点过任何东西却已经存在」的权限。

这里有边界，而屏幕捕获正是其中之一。Kandji 是一家 MDM 厂商，其关于 PPPC 变化的文章在 Mac 管理员群体中被广泛引用，它这样描述这一机制：对于屏幕捕获和输入监控，「IT can use MDM to pre-allow certain apps to be approved even by standard users to enable screen capture or input monitoring.」这使用的是一种把批准权委托给用户、而非静默授予的授权值。所以描述文件可以直接拒绝屏幕捕获，也可以让标准用户去批准它，但记录在案的行为是：它不会像对 Full Disk Access 或 Accessibility 那样静默地授予它。

请把这个细微差别拿得松一点，因为上文那个 Microsoft Q&A 案例中，管理员报告的是一条针对 kTCCServiceScreenCapture 的系统级 TCC 记录，其授权原因指向 MDM 策略。这两种说法并不能干净地放在一起，而我选择两个都报告，而不是挑那个更整齐的。

如果你在使用受管理的 Mac

不要试图绕过灰掉的开关。你不会成功，而且在许多部署环境中，这种尝试是会被记录的。对一个由描述文件管理的条目运行 tccutil reset，要么会失败，要么会在下一次管理签入时被重新应用。联系管理你们设备群的人；修复方法是他们那边改一下描述文件，一分钟就够了。

如果你是受管理 Mac 的管理员

让 PPPC 载荷中的代码要求，与 codesign 针对已部署版本的该 App 实际报告的内容相匹配。上文的 Teams 案例之所以有启发性，恰恰是因为那位管理员确实核实过这一点，却依然撞了墙：正确的描述文件是必要条件，但并不总是充分条件。当某个 App 跨版本更改了它的 bundle identifier（就像 Teams 那样）时，请把旧标识符从描述文件中移除，而不是把两个都留着。

常见问题排查

App 已列出且开关已打开，但仍然无法录制

**问题：**面板显示该 App 已启用。App 的表现却像完全没有权限。

**解决方案：**这个条目绑定的签名身份，已经和磁盘上的 App 对不上了。先运行 mdfind "kMDItemKind == 'Application'" -name "AppName" 检查是否存在第二份副本（这是最常见的成因），并删掉多余的那些。然后执行完整的干净重新授权流程，包括面板移除和带 bundle identifier 的 tccutil reset 两步。不要只是把开关关掉再打开；那记录的是一次拒绝加上一次未绑定的批准，而这正是你走到今天这一步的原因。

更新之后 App 从列表里消失了

**问题：**昨天还在面板里的 App，今天不见了，而唯一发生变化的就是一次更新。

**解决方案：**新构建的签名方式不同，所以 macOS 看到的是一个没有历史记录的新应用程序。没什么可修的：启动这个 App，触发那个受保护的操作，批准新的提示。如果这个 App 使用的是 Full Disk Access（它无法提示），就用 + 按钮把它加进去。如果每次更新都这样，说明开发者的签名配置不稳定，值得向他们反馈。

每次启动都提示，而不是每月一次

**问题：**屏幕捕获对话框在你每次打开这个 App 时都出现，而不是按预期的周期出现。

**解决方案：**这是故障，不是设计中的重新提示。可能的成因是：一个 ad-hoc 签名的 App，其代码哈希每次构建都会变；一个反复替换自己 bundle 的自更新程序；或者一条每次都不同的启动路径。对这个 App 运行 codesign -dv --verbose=2，看 TeamIdentifier 那一行。如果一个第三方 App 显示的是 not set，说明它没有用 Developer ID 签名，在开发者修好签名之前，稳定的权限是做不到的。

出现两个同名的 App 条目

**问题：**面板里同一个 App 出现了两次，有时图标还一模一样。

**解决方案：**磁盘上存在两份签名身份不同或路径不同的副本。用 find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null 把它们全找出来。保留一份，删掉其余的，移除面板中的两个条目，然后给幸存的那一份重新授权。如果你是有意在正式版之外保留一个 beta 通道，那就该预期并接受两个条目。

命令行工具不出现在列表里

**问题：**你用 + 按钮添加了一个二进制文件，但它不显示出来。

**解决方案：**在 macOS 26.1 和 26.2 上，这就是上文讨论过的、已被 Apple DTS 工程师确认、并据报在 26.3 beta 中修复的显示 bug。即使列表不显示，权限也极有可能已经被记录了，所以在进一步排查之前先测试实际行为。而在任何版本上，纯可执行文件都没有 bundle identifier，在这个界面里也从来不是一等公民。用 Kevin Elliott 在第 806187 号帖子里的话说，经得起时间检验的答案是：把这个工具放进一个 app bundle 里，然后完全照原来的方式继续使用它。

提示框写的是错误的应用程序

**问题：**你运行一个脚本，而权限对话框上写的是 Terminal、VS Code 或 Script Editor，而不是你的脚本。

**解决方案：**这是归属链在正确工作。负责的进程是你启动的那个 App，权限也就附着在它身上。要么把权限授予那个宿主应用程序，并接受你在其中运行的一切都会继承这份授权；要么把你的工具打包成它自己的 app bundle，让它成为负责的进程。请注意，更换终端模拟器意味着要重新授权一次，因为每一个都是独立的身份。

开关是灰色的

**问题：**你无法改动这个开关，旁边可能还有一条关于描述文件的说明。

**解决方案：**这个决定是由配置描述文件设定的。用 profiles status -type enrollment 确认，并检查 System Settings → General → Device Management。在受管理的 Mac 上，请联系你的管理员；这个改动必须在描述文件里进行。如果是一台个人 Mac 却显示出意料之外的描述文件，请仔细查看那里装了什么，因为一个你并非有意安装的描述文件值得警惕。

权限本来能用，睡眠或长时间使用后就失效

**问题：**一天开始时屏幕共享正常，Mac 睡眠过后就失败了。

**解决方案：**首先确认你看到的是不是那个周期性的重新确认对话框藏在了另一个窗口后面，因为一个你从未看见的提示，看起来和静默失败一模一样。把所有窗口都调到前台看一遍。如果确实没有提示，就完全退出这个 App，用 pgrep -fl "AppName" 确认，然后重新启动，因为唤醒后未能重新加载的辅助进程通常是罪魁祸首。如果问题持续，就把 Mac 重启一次。如果每天都发生，说明这个 App 有唤醒处理方面的 bug，应该报告给它的开发者。

常见问答

我能关掉周期性的屏幕录制提示吗？

不能。Apple 没有提供任何面向用户的设置来禁用它，也没有任何受支持的命令能压制它。唯一能去掉它的机制是 com.apple.developer.persistent-content-capture 授权，那是开发者必须向 Apple 申请的受管能力，面向远程控制类应用。这不是用户能启用的东西。

macOS 多久会重新索要一次屏幕录制权限？

Apple 从未记录过这个间隔。这个行为始于 Sequoia 周期，最初是每周一次，在那个 beta 期间因批评而被 Apple 改为每月一次，MacRumors 和 9to5Mac 在 2024 年 8 月对此有报道。Apple 当前的支持页面完全没有提到重新提示，而我也无法从任何权威来源核实 macOS 26 的周期。

重置权限会删除我的数据吗？

不会。tccutil reset 删除的是已记录的同意决定，仅此而已。不会触及任何文件、设置或 App 数据。代价是不便：每一个受影响的 App 在下次需要该权限时都会重新提示你。这个代价随你重置的范围大小而放大，而这恰恰就是你应该永远带上 bundle identifier 的原因。

为什么我的程序在 Terminal 里能用，单独运行就不行？

因为 TCC 把请求归属给负责的进程，而对于从 Terminal 启动的程序来说，那通常就是 Terminal 本身。你的程序是在借用 Terminal 的授权。单独运行时它没有权限；而如果它是纯可执行文件而不是 app bundle，它甚至可能压根不会出现在面板里让你去授权。

授予 Full Disk Access 危险吗？

它是 macOS 提供的范围最广的权限，覆盖 Mail、Messages、Safari 数据、Time Machine 备份，以及其他 App 的容器。只把它授予那些你愿意把这一切都托付给它的软件，并且注意：把它授予终端模拟器，等于把这份触及范围扩展到你在那里运行的每一条命令。

更改权限后需要重启 Mac 吗？

通常不需要。退出并重新启动受影响的 App 几乎总是足够的，而且这是必需步骤，因为许多 App 只在启动时读取自己的能力。完整重启在更狭窄的情形下有用：某个后台辅助程序或启动守护进程无法干净地重新加载。重启一次，然后回到诊断上来。

结语

这个领域的大部分挫败感，都来自把「权限」这一个标签当成一件事来对待。它至少是三件事：POSIX 文件权限，由 chmod 管辖，与这里的一切毫无关系；TCC 隐私决定，绑定到 App 的代码签名身份，存储在你读不了的数据库里；以及在受管理的 Mac 上，由描述文件写入的策略，它会覆盖你在本地能改动的东西。

一旦区分开来，决策树就很短了。按周期出现的屏幕捕获提示是有意为之，没有关闭开关，正确的反应是点 Allow 然后继续过你的日子。其余的一切都是故障，而故障有成因：磁盘上多出的第二份 App 副本、在一次更新中变掉的签名、一个不再通过校验的 bundle、一个需要自己那份授权的辅助程序，或者一条指向你的终端模拟器而非你的脚本的归属链。

工具确实很单薄。tccutil 只有一个动词，Apple 不公布它接受的服务名，而面板作为数据库的一个视图，已经被证明确实出过错——macOS 26.1 显示 bug 就是明证，当时 Apple 自己的工程师确认权限被正确记录着，而列表就是不肯显示它们。请在这样的约束下工作：拼命令之前先核实 bundle identifier，reset 后永远附上它，按顺序执行干净的重新授权流程，卡住时用一个全新的用户账户来测试。还要知道什么时候该停手。当你已经核实了授权、核实了签名、排除了重复副本，并在一个干净账户里测试过——就像那位在 macOS Tahoe 26.4 上报告 Teams 问题的人所做的那样——剩下的问题就不该由你来修了。报告它，然后在等待期间使用变通方案。

延伸阅读：macOS Tahoe 26.5 上 Mac 麦克风失灵 · macOS Tahoe 安全与隐私完全指南