macOS完全磁盘访问权限与AI智能体：Apple说了什么

Apple就完全磁盘访问权限说了什么，这对AI智能体意味着什么？ 2026年10月2日，Apple发布了一则简短的开发者新闻“Updates to Full Disk Access in macOS”。其中写道，完全磁盘访问权限（Full Disk Access）“largely sidesteps”（在很大程度上绕过了）保护用户隐私数据的各项控制；“Some developers are using Full Disk Access in ways that could put users at risk”（一些开发者使用完全磁盘访问权限的方式可能让用户面临风险）；以及“Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action”（今后，我们将引入额外的控制，确保真正希望授予某个App这种非同寻常级别访问权限的用户，只能通过非常明确的用户操作来完成）。给出的理由是：“As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially”（随着AI智能体日益强大和自主，与这一级别访问权限相关的风险将大幅增加）。¹ 它没有给出任何macOS版本、日期、机制或App名称。对于在Mac上运行智能体的人来说，眼下真正重要的是智能体如何获得这种访问权限。命令行智能体运行在启动它的终端之下。在我读过的Apple文档中，并没有关于这一点的通用规则，但Apple的eslogger手册页写道，运行该工具“from an app, including Terminal.app or a third-party terminal emulator, requires the respective app to be authorized for Full Disk Access.”（如果从App中运行，包括Terminal.app或第三方终端模拟器，则需要相应的App已获得完全磁盘访问权限授权）。² 一位Apple支持工程师在论坛帖子中的说法是：“The tool’s responsible code is Terminal.”（该工具的责任代码是Terminal）。³ 只要给终端授予完全磁盘访问权限，在其中启动的每个智能体都能读取终端能读取的内容。按照Apple的列举，这包括Mail、Messages、Safari的数据以及时间机器（Time Machine）备份。⁴ 各厂商的沙盒在默认情况下并不会改变这一点。在我的Mac上，一次需要完全磁盘访问权限的读取在智能体的shell中成功了，在Codex的read-only沙盒和Anthropic的沙盒运行时内部也再次成功；只有当沙盒规则拒绝了那个确切的文件夹，或者我在终端之外启动同样的读取时，它才被拒绝。⁵

TL;DR

• Apple说了什么。 2026年10月2日，Apple告诉开发者，它“will introduce additional controls”（将引入额外的控制），使授予完全磁盘访问权限需要“very explicit user action”（非常明确的用户操作），并把AI智能体列为风险“will grow substantially”（将大幅增加）的原因。这则新闻没有给出版本、日期或机制。macOS 27.2 beta 3的发行说明中也没有任何相关条目。在10月11日的发布信息源和发行说明索引中，我都没有找到macOS 27.1的条目：信息源列出的是macOS 27.0.1（9月28日），它发布时没有开发者发行说明，随后是macOS 27.2 beta 3；27.2的测试版本身始于9月16日。¹⁶⁷⁸⁹
• 完全磁盘访问权限是什么。 它是隐私与安全性（Privacy & Security）中的一项设置，允许App“access all files on your computer”（访问电脑上的所有文件），包括来自Mail、Messages、Safari和“家庭”的数据、时间机器备份，以及“certain administrative settings for all users on this Mac”（这台Mac上所有用户的某些管理设置）。App无法弹出提示来请求它；只能由用户手动添加App，或由MDM描述文件授予。在我读到的材料中，Apple曾三次把它与备份和磁盘工具联系在一起：WWDC19、WWDC23，以及10月2日。^410211121
• 智能体如何获得它。 有两条路径。命令行智能体（Claude Code、Codex CLI、Gemini CLI、Hermes Agent、Aider）是以它所运行的App为准接受检查的，因此拥有完全磁盘访问权限的终端会把权限传给它；Apple只是逐个工具在手册页中、并通过论坛上的支持工程师说明这一点，从未把它作为成文的通用规则。桌面智能体App则拥有各自的条目；另有两家智能体厂商，即Hermes的Nous Research和OpenClaw，告诉用户授予完全磁盘访问权限，以便智能体读取Messages。²³¹³¹⁴
• 沙盒能做什么。 Claude Code、Codex、Gemini CLI和Cursor的Seatbelt沙盒都会限制写入；除Gemini CLI的默认配置文件外，其余也都限制网络；它们默认的读取范围都很宽。在我的Mac上，我运行的两个沙盒都没有改变完全磁盘访问权限的授权；而按照Apple支持工程师对强制访问控制的描述，没有哪个沙盒能增加授权。Claude Code的沙盒默认关闭，Codex的默认开启。在我的Mac上，一次受保护的读取穿过了Codex的read-only沙盒，也穿过了Anthropic的沙盒运行时；在沙盒内部，只有当我按名称拒绝该文件夹时，它才停下来。^151617185
• 在我的Mac上。 完全磁盘访问权限列表共有75行：三个终端，ChatGPT、Cursor和Xcode这几个App，30个带版本号的Claude Code二进制文件，node和四个Python解释器，SSH服务器的条目，等等。Ghostty中的智能体shell拥有实际生效的访问权限；同样的读取从上方没有终端的launchd任务发起时，被TCC拒绝。¹⁹⁵
• 现在该做什么。 查清谁拥有它；把它从运行智能体的终端上撤掉；绝不授予解释器；打开厂商沙盒并拒绝不需要的读取；读取Messages的智能体要放在单独的macOS用户下运行，或者干脆不用；凡是以你的名义发言的功能，保留逐条发送的审批。下面每一步都附有出处和代价。^420152122
• 可能会变什么。 Apple的措辞允许出现更严格的授权流程、更窄的范围、对从一个App传给其启动程序的授权采取不同处理，以及针对受管理Mac的变化。第7节逐一对照Apple自己在macOS 27和Xcode 27中已做出的相邻改动来解读，并给出每一种所依赖的条件。没有一项是预测。^1232425

1. Apple在10月2日说了什么，又没说什么

Apple的开发者新闻信息源把这条新闻的时间标为2026年10月2日（星期五）太平洋时间09:00:19，位于10月1日关于一个即将到期的Developer ID证书颁发机构的通知，与10月5日的iPhone Duo及App Store素材公告之间。²⁶ 这条新闻只有两段。我在10月11日保存了它，19分钟后又抓取了一次；除了弯撇号和直撇号的差别，两份副本完全相同，所以在我两次读取之间它没有变化。¹

第一段提出问题。Apple说它为开发者提供“powerful APIs to build incredible capabilities into their apps for Apple products, backed by a set of controls designed to protect users’ private data”（强大的API，用来在面向Apple产品的App中构建出色的功能，并由一套旨在保护用户隐私数据的控制作为支撑），接着写道：“Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac.”（为了让备份App在Mac上正常工作，完全磁盘访问权限在很大程度上绕过了这些控制）。下一句是指控：“Some developers are using Full Disk Access in ways that could put users at risk”（一些开发者使用完全磁盘访问权限的方式可能让用户面临风险），暴露“everything on their systems”（系统上的一切），Apple具体列为“files, mail, messages, and even browsing history”（文件、邮件、信息，甚至浏览历史），而且是“without users’ full knowledge and understanding”（在用户没有充分知情和理解的情况下）。这一段以从未同意过任何事情的人收尾：“For communication apps, this can also compromise the privacy of the people users are communicating with.”（对于通讯类App，这还可能损害与用户交流的那些人的隐私）¹

第二段是承诺和理由，全文引用如下：

“Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially. We are committed to ensuring users clearly understand these risks before granting such access, so they can make informed decisions about their own data and privacy.”（今后，我们将引入额外的控制，确保真正希望授予某个App这种非同寻常级别访问权限的用户，只能通过非常明确的用户操作来完成。解决这一问题至关重要。随着AI智能体日益强大和自主，与这一级别访问权限相关的风险将大幅增加。我们致力于确保用户在授予此类访问权限之前清楚了解这些风险，从而能就自己的数据和隐私做出知情的决定）¹

其中有三点值得慢慢读。

主语是授权，而不是API。 承诺中的每个动词都关乎用户授予访问权限的那一刻：用户“who genuinely wish to grant an app”（真正希望授予某个App），“very explicit user action”（非常明确的用户操作），以及“before granting such access”（在授予此类访问权限之前）理解风险。新闻中没有任何地方说完全磁盘访问权限的覆盖范围会缩小，或者持有它的App会被审查，或者它会被取消。我的解读，并且我明确标注它只是解读：这条新闻描述的是打开开关的方式将如何改变，至于开关打开后能解锁什么，它没有作出任何一方面的表态。

理由是智能体，对象却是App。 Apple只提到一次“AI agents”（AI智能体），把它作为风险“will grow substantially”（将大幅增加）的原因。它没有说如今滥用这种访问权限的App就是智能体；那句话说的是“Some developers”（一些开发者）。它也没有说，针对授予“an app”（某个App）的控制如何能触及智能体，而在Mac上，智能体往往根本不是App，而是在App中运行的命令行程序。第3节讨论的正是这道缝隙。

被点名会伤害他人的类别是“communication apps”（通讯类App）。 Apple没有点名任何App或开发者。新闻提到了两类软件：作为这种访问权限存在理由的备份App，以及与超出用户本人的伤害联系在一起的通讯类App，即对话另一端那些什么都没有授权的人。第3节会展示两家智能体厂商，其Messages集成在文档中写明需要完全磁盘访问权限；Apple心里是否想到其中任何一家，新闻没有说，我也不作此假设。

这条新闻没有说的

从缺失的内容来读，这条新闻：

• 没有macOS版本，也没有日期。 唯一与时间有关的词是“Going forward”（今后）。
• 没有机制。 没有提示设计、权利（entitlement）、API、App审核规则，也没有设备管理方面的变化。
• 没有提到现有授权。 它没有说已经在完全磁盘访问权限列表中的App能否保留位置，也没有说是否会再次询问用户。
• 没有提到受管理的Mac。 它没有提MDM，尽管如今MDM可以授予完全磁盘访问权限（第2节）。
• 没有要求开发者采取行动。 没有截止日期，没有文档链接，也没有App必须改变的日期。

我查看了Apple会公布机制的地方。10月11日读取的macOS发行说明索引中，恰好列出两个macOS 27条目：“macOS 27.2 Golden Gate Beta 3 Release Notes”和“macOS 27 Golden Gate Release Notes”。无论在该索引中，还是在同一天读取的Apple发布信息源中，我都没有找到macOS 27.1的条目；信息源列出的是macOS 27.0.1（26A434，日期9月28日），然后是27.2 beta 3。27.0.1更新没有开发者发行说明页面；我尝试访问这种页面应使用的地址时得到HTTP 404，27.1和27.1 beta的地址也一样。⁸⁷ 27.2 beta 3的发行说明（这个测试版的构建版本为26B5101f，在Apple发布信息源中的日期是10月5日，即新闻发布三天后）有六个部分（General、AppKit、Display Settings、Notifications、Shortcuts、StoreKit Testing in Xcode），没有一个提到完全磁盘访问权限、TCC或隐私与安全性；最接近的是AppKit中的一行，说一个与剪贴板隐私相关的开发者预览默认值“has been removed”（已被移除）。⁶⁷ Apple在新闻发布四天后推出的10月开发者通讯，内容涉及iPhone Duo的提交、实验室和文档，对完全磁盘访问权限和智能体只字未提。²⁷ Apple归入Privacy & Security类别的四个WWDC26视频，包括一个题为“Secure your app: mitigate risks to agentic features”的视频，也都没有提到完全磁盘访问权限。²⁸²⁹

Apple唯一另一份涉及智能体与文件访问的文本

确实有一份Apple文档谈到了AI智能体的文件权限，但它针对的是Xcode，而不是macOS。Xcode 27发行说明写道：“Coding Intelligence now includes a new security layer that monitors and controls filesystem access by coding agents and any processes they spawn. This can be enabled in Coding Intelligence settings.”（Coding Intelligence现在包含一个新的安全层，用于监控和控制编程智能体及其派生的任何进程对文件系统的访问。可在Coding Intelligence设置中启用）²⁴ 条目就这么多。它没有说这一层允许或阻止什么，是否默认开启（“can be enabled”的措辞暗示并非如此），与TCC是什么关系，也没有说是否覆盖Xcode之外的智能体。同一份说明还描述了一个预览版MCP服务器，让“code-signed agents”（经过代码签名的智能体）在某个目录树中使用项目，“for extended periods of time without being asked for additional permissions”（在很长时间内无需再被请求额外权限），以及一个标志--unsafe-always-allow-all-agents，Apple称其“is not a recommended configuration for at-desk use”（不是在桌前使用时推荐的配置）。²⁴ 两个条目都没有提到完全磁盘访问权限。

在我读过的Apple资料中，WWDC26关于智能体功能的那一场讲座最接近一个面向智能体的威胁模型。它引用了“Simon Willison’s Lethal Trifecta”（Simon Willison的“致命三要素”）：当智能体同时具备“access to private data, exposure to untrusted content, and the ability to externally communicate”（访问隐私数据、接触不可信内容、对外通信的能力）时，用户面临的危险最大。²⁹ 完全磁盘访问权限用一个开关就给出了三者中的第一项；这是我对10月这条新闻为何说风险随智能体而增长的解读，并非Apple陈述的理由。

2. 完全磁盘访问权限是什么

用Apple自己的话来说

完全磁盘访问权限是系统设置（System Settings）>隐私与安全性中的一行。面向macOS 27的Mac使用手册这样描述它：“Allow apps to access all files on your computer, including data from other apps (for example, Mail, Messages, Safari, and Home), data from Time Machine backups, and certain administrative settings for all users on this Mac.”（允许App访问电脑上的所有文件，包括其他App的数据（例如Mail、Messages、Safari和“家庭”）、时间机器备份中的数据，以及这台Mac上所有用户的某些管理设置）⁴ 它周围的几行写法不同。日历、通讯录、文件与文件夹（Files & Folders）以及大多数其他行的结尾都是“The listed apps have requested access.”（列出的App曾请求访问）。完全磁盘访问权限这一行写的则是“To add an app, click [the Add button] , select the app in the list, then click Open.”（要添加App，请点按添加按钮，在列表中选择该App，然后点按“打开”）。⁴ 区别正在于此：其他项目由App来请求，而这一项要用户自己去找。

《Apple平台安全》用表格表达了同样的意思。它关于控制App访问文件的页面列出了“Full internal storage access”（完整内部储存访问，即该文档对同一控制的叫法），在“User prompted by app”（由App提示用户）一栏下打叉，在“User needs to edit system privacy settings”（用户需要编辑系统隐私设置）一栏下打勾；相比之下，文件与文件夹由App发起提示。¹⁰ 写给管理员的设备管理参考把这项服务描述为访问“to all protected files, including system administration files”（所有受保护文件，包括系统管理文件），而Apple的部署指南将其列为“System Policy All Files”，说明为“Allows specified apps access to data like Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings for all users of the Mac.”（允许指定的App访问Mail、Messages、Safari、“家庭”、时间机器备份等数据，以及该Mac所有用户的某些管理设置）³⁰³¹

在推敲它之前，有三件Apple没有公布的事值得知道：

• 没有完整的受保护项目清单。 一位Apple开发者技术支持（Developer Technical Support）工程师在Apple开发者论坛上写道（这是员工帖子，不是文档）：“The exact list of file system locations protected by MAC is not documented and, as illustrated by the list above, can change over time.”（受MAC保护的文件系统位置的确切清单没有文档记载，而且正如上面的列表所示，会随时间变化）²⁰ 这里的MAC指强制访问控制（mandatory access control），即其底层机制。
• 它不是按用户划分的。 还是这位工程师：“Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access).”（有些MAC权限是按用户的（文件与文件夹），有些是系统范围的（完全磁盘访问权限））²⁰ 在一个账户登录时作出的授权，对该程序在所有账户中都有效。
• TCC是Apple在用、却几乎没有定义的名字。 保存这些决定的子系统是TCC。macOS 27 SDK的Endpoint Security头文件把它拼写为“Transparency, Consent, and Control (TCC)”，WWDC26上一个Apple小组说“TCC stands for transparency, consent and control”（TCC代表透明、同意和控制），这位支持工程师的帖子还补充说TCC“has no API surface”（没有API层面的接口）。³²³³²⁰ 在我Mac上TCC自己的数据库里，完全磁盘访问权限的行存储在服务名kTCCServiceSystemPolicyAllFiles之下。我查过的Apple文档、手册页和SDK头文件中都没有出现这个字符串；Apple有文档记载的名称是描述文件键SystemPolicyAllFiles和设置锚点Privacy_AllFiles。^19302534

它如何被授予

由用户手动授予。 用户打开完全磁盘访问权限这一行，点按添加，然后选择App。⁴ Apple没有记载任何让App为此弹出提示的方法。Apple文档提供的替代方案，是一个把用户带到正确面板的链接。对于具有Endpoint Security客户端权利的App（头文件要求调用es_new_client者具备com.apple.developer.endpoint-security.client权利），Endpoint Security头文件写道：“The only supported way to check if an application is properly TCC authorized for Full Disk Access is to call es_new_client and handling ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED,”（检查应用程序是否已正确获得TCC的完全磁盘访问权限授权，唯一受支持的方法是调用es_new_client并处理ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED），并说“To direct the user to the Full Disk Access section in System Settings,”（要把用户引导到系统设置中的完全磁盘访问权限部分），App可在macOS 13及更高版本上打开x-apple.systempreferences:com.apple.settings.PrivacySecurity.extension?Privacy_AllFiles。²⁵ 在WWDC19上，Apple描述过同样的模式：App“can test for authorization using FileManager or POSIX level APIs, and if necessary, can guide the user to the security and privacy preference pane, where the user can then approve the app if that’s what they want.”（可以用FileManager或POSIX层级的API测试授权，必要时引导用户前往“安全性与隐私”偏好设置面板，用户如果愿意，可以在那里批准该App）¹¹ 2018年，一位开发者在Apple论坛上请求“an API call that causes a prompt to the logged-in user to grant the app Full Disk access because there’s no way to trigger a prompt like that right now, and that’s what backup apps need”（一个API调用，能向已登录用户弹出提示，请其为App授予完全磁盘访问权限，因为现在没有办法触发这样的提示，而这正是备份App所需要的）；Apple的支持工程师回答：“Please do file an enhancement request.”（请务必提交功能改进请求）³⁵ 在我为本文读过的所有材料中，八年过去了，Apple文档描述的仍然只有那个链接。

有一项便利。从Catalina开始，因缺少完全磁盘访问权限而被拒绝的程序会以关闭状态预先出现在列表中：“executables that are denied access to files due to a lack of Full Disk Access approval are now prepopulated unchecked.”（因未获完全磁盘访问权限批准而被拒绝访问文件的可执行文件，现在会以未勾选状态预先填入列表）¹¹ 打开它的仍然是用户。

由MDM描述文件授予。 在受管理的Mac上，隐私偏好设置策略控制（Privacy Preferences Policy Control）负载（类型为com.apple.TCC.configuration-profile-policy，仅限macOS，自10.14起）可以授予它。eslogger手册页说得很直白：“MDM servers can grant Full Disk Access authorization using the Privacy Preferences Policy Control payload, identified by payload type com.apple.TCC.configuration-profile-policy, and its service dictionary key SystemPolicyAllFiles.”（MDM服务器可以使用负载类型为com.apple.TCC.configuration-profile-policy的Privacy Preferences Policy Control负载及其服务字典键SystemPolicyAllFiles，授予完全磁盘访问权限）²³⁶ 当某个App条目的Allowed键为true时，Apple的参考文档说“access is granted”（访问即被授予），并补充：“The user isn’t prompted and can’t change this value.”（不会提示用户，用户也无法更改此值）³⁷ Apple部署指南中这一负载的示例注释写着“Allows my organization’s app to interact with all files without prompting the user.”（允许我所在组织的App在不提示用户的情况下与所有文件交互）³¹ 这是一种真实存在的不对称：对于摄像头、麦克风、屏幕录制和键盘监听，Apple的参考文档说描述文件“can’t grant”（不能授予）访问权限，“can only deny it”（只能拒绝）。对SystemPolicyAllFiles，它没有这样说。³⁰

关于这一负载，Apple的两个页面说法不一，其中一个今年还有变化：

• 监督（Supervision）。 部署指南说“Supervision is required if you apply this payload using a device management service.”（如果通过设备管理服务应用此负载，则需要监督）。开发者参考的可用性表格则把“Requires supervision”（需要监督）列为N/A。³¹³⁶ 我两者都报告，不偏向任何一方。
• macOS 27弃用了按App划分的部分。 在当前参考中，每个服务条目（包括完全磁盘访问权限）都使用的Identity对象在macOS 27.0被标为弃用，它的每个键都写着“Deprecated: macOS 27+”。SystemPolicyAllFiles条目本身没有弃用标记。³⁷³⁰ Apple为其他服务指向的声明式替代方案，即App设置配置，提供了辅助功能（Accessibility）、蓝牙、摄像头、听写、本地网络、定位和麦克风的隐私默认值。它没有完全磁盘访问权限的键，而且其默认值以用户同意为前提：“When set, the app displays a consent prompt listing all the configured defaults.”（设置后，App会显示一个同意提示，列出所有已配置的默认值）³⁸³⁹ Apple没有把这一点与10月2日的新闻联系起来，我也不这样做；它只是摆在这件事旁边的一个事实。

它为何存在：三次都是备份App

在我找到的三处Apple说明完全磁盘访问权限为谁而设的地方，它提到的都是同一类软件。在WWDC19上描述两层受保护数据时，Apple把“things like mail or messages and Safari browsing history”（邮件、信息、Safari浏览历史之类的东西）放在第二层，并说它们“have a high barrier to access because the files are typically only accessed by specialized apps such as disk management or backup utilities.”（访问门槛很高，因为这些文件通常只被磁盘管理或备份工具之类的专用App访问）¹¹ 在WWDC23上介绍App容器保护时，Apple说“For backup utilities or disk-management tools that have already been granted Full Disk Access, no additional prompt will be shown at time of access, since people have already chosen to allow these apps access to all files.”（对于已获完全磁盘访问权限的备份工具或磁盘管理工具，访问时不会显示额外提示，因为用户已经选择允许这些App访问所有文件）¹² 10月2日，它说完全磁盘访问权限绕过数据控制，是“in order to allow backup apps to function properly on the Mac.”（为了让备份App在Mac上正常工作）¹ 智能体不是备份App。全部张力就在这一句话里。

它从何而来

Apple的大多数资料把完全磁盘访问权限的起点定在2018年的macOS Mojave。Apple 2018年6月4日的新闻稿说：“New data protections require apps to get user permission before using the Mac camera and microphone or accessing personal data like user Mail history and Messages database.”（新的数据保护要求App在使用Mac的摄像头和麦克风，或访问用户Mail历史和Messages数据库等个人数据之前，先取得用户许可）⁴⁰ 至今仍在线上的Mojave 10.14发行说明使用的名称是Application Data，2018年8月Apple论坛上一位开发者称它是早期测试版中的名称：³⁵“Apps can’t access protected storage unless they’re added to the Application Data category located in the Privacy tab of System Preferences > Security & Privacy.”（除非被添加到“系统偏好设置”>“安全性与隐私”的“隐私”标签页中的Application Data类别，否则App无法访问受保护的储存）⁴¹ 设备管理负载及其SystemPolicyAllFiles键被标注为在macOS 10.14中引入，Apple支持工程师的帖子也列出了“Full Disk Access (macOS 10.14 and later)”（完全磁盘访问权限（macOS 10.14及更高版本））。³⁶²⁰

有一个Apple页面给出了不同的时间。《Apple平台安全》说：“In macOS 10.13 or later, apps that require access to the full storage device need to be explicitly added in System Settings (macOS 13 or later) or System Preferences (macOS 12 or earlier).”（在macOS 10.13或更高版本中，需要访问整个储存设备的App必须在“系统设置”（macOS 13或更高版本）或“系统偏好设置”（macOS 12或更早版本）中明确添加）¹⁰ 我读到的其他所有Apple资料都说是10.14。我报告这一分歧，不偏向任何一方。

Catalina（10.15，2019年10月7日发布）扩大了受保护的范围。它的新闻稿说“new data protections require all apps to get permission before accessing user documents”（新的数据保护要求所有App在访问用户文稿之前先取得许可），在WWDC19上，Apple把桌面、文稿和下载文件夹、iCloud云盘、第三方云储存、可移除宗卷和网络宗卷加入了需要同意的列表，并说“the universe of data that requires preapproval for Full Disk Access has been expanded to include trash.”（需要预先批准完全磁盘访问权限的数据范围已扩大到包括废纸篓）⁴²¹¹ 后来的版本又加入了App容器保护（macOS 14）和App组容器保护（macOS 15），两者都针对App读取其他App的数据；对于前者，Apple说持有完全磁盘访问权限的App不会看到额外提示。²⁰¹²

macOS 27再次朝同一方向推进。它的发行说明写道，访问“other developer teams’ app data containers and app group containers no longer prompts the user for authorization; such accesses are denied by default and can be managed by the user in Privacy & Security settings,”（其他开发团队的App数据容器和App组容器时，不再提示用户授权；此类访问默认被拒绝，用户可在隐私与安全性设置中管理），“XProtect may now restrict access to app data that is commonly targeted by malicious software,”（XProtect现在可能会限制对常被恶意软件盯上的App数据的访问），并在TCC下写道“Apps can no longer access the local TCC database directly.”（App不能再直接访问本地TCC数据库）²³ 在一个已知问题中，Apple自己的说明把完全磁盘访问权限当作权宜之计来推荐：当没有bundle ID的进程无法获得对另一团队容器的访问权限时，“Workaround: Consider if the access is necessary. If required, grant Full Disk Access to the process for the duration of the requirement.”（变通办法：考虑这一访问是否必要。如果必需，在需要期间为该进程授予完全磁盘访问权限）²³ 这些变化的完整内容见macOS 27发行说明一文和跨团队容器一文。

3. 智能体如何获得它

Mac上的AI智能体能读取完全磁盘访问权限所保护的内容，途径有两条：要么运行在持有该授权的App里，要么它本身就是持有该授权的App。大多数命令行智能体走的是第一条，而且不需要任何人为智能体本身点按任何东西。

终端路径

当你在终端里输入claude或codex时，macOS不会询问Claude Code或Codex能否读取你的Messages，它问的是终端能否读取。Apple把被检查的程序称为“responsible”（负责的）程序；在我找到的Apple文档中，选出它的规则从未以通用形式表述过。Apple公布的是一组具体说法，全都指向同一个方向：

• eslogger(1)，随macOS 27提供：“eslogger requires the responsible process to have been authorized for Full Disk Access,”（eslogger要求责任进程已获完全磁盘访问权限授权），以及“Running eslogger from an app, including Terminal.app or a third-party terminal emulator, requires the respective app to be authorized for Full Disk Access in System Preferences > Security & Privacy > Privacy > Full Disk Access.”（从App中运行eslogger，包括Terminal.app或第三方终端模拟器，需要相应的App在系统偏好设置的完全磁盘访问权限中获得授权）²
• tmutil(8)：“Full Disk Access privileges can be granted to the Terminal application used to run tmutil from the Privacy tab in the Security & Privacy preference pane.”（可以在“安全性与隐私”偏好设置面板的“隐私”标签页中，为用来运行tmutil的终端应用程序授予完全磁盘访问权限）⁴³
• fdesetup(8)：自macOS 10.15起，从命令行启用FileVault时，除其他可选条件外，要求“The responsible application is authorized for”（责任应用程序已获授权）完全磁盘访问权限。⁴⁴
• Apple的设备管理参考：“Helper tools embedded within an application bundle automatically inherit the permissions of their enclosing app bundle.”（嵌入在应用程序包中的辅助工具会自动继承其所在App包的权限）³⁷

最直接的说法来自Apple开发者技术支持的工程师Quinn，他在2024年6月回复了一个关于命令行工具与完全磁盘访问权限的论坛帖子。这是Apple网站上的员工帖子，不是文档，我每次引用都会这样标注。他列出了四种情况。用户从Terminal运行的工具：“The tool’s responsible code is Terminal.”（该工具的责任代码是Terminal）。通过SSH运行的工具：“The tool’s responsible code is the SSH server.”（该工具的责任代码是SSH服务器）。由App启动的辅助程序：“The system treats the app as the responsible code.”（系统把该App视为责任代码）。对于launchd任务，通过SMAppService安装会使App成为责任代码；否则，他写道，任务的属性列表应当用AssociatedBundleIdentifiers指明该App。³ 在同一个帖子里，他加了一条对任何据此做规划的人都很重要的告诫：“The exact algorithm it uses for this is not documented, has changed in the past, and may well change in the future.”（它为此使用的确切算法没有文档记载，过去变过，将来也很可能会变）³ 在另一个帖子里，有人问TCC是否“is looking for parent process rights”（在查看父进程的权限），他以这“both complex and subject to change”（既复杂又可能变化）为由，没有展开。⁴⁵

发起2024年6月那个帖子的开发者已经测量过其效果：“When this program is built and executed in Terminal.app with Terminal having FDA, the file opens successfully. Conversely, when FDA is revoked from Terminal and granted to the program, an error occurs due to insufficient privileges.”（在Terminal拥有FDA的情况下，在Terminal.app中构建并运行这个程序，文件能成功打开。反过来，从Terminal撤销FDA并把它授予这个程序，就会因权限不足而出错）³ 这是开发者的报告，不是Apple的。它的前半部分与我在自己Mac上测得的结果（第5节）一致：在终端的启动链中有授权时，读取成功。后半部分我没有测试；我的对照实验改变的是读取从哪里启动，而不是哪个App持有授权。

由此得出两个推论，二者都不是智能体特有的。

在那个终端里启动的一切都会获得它。 智能体、它派生的shell、git、npm install、测试运行器、通过stdio启动的MCP服务器、模型一分钟前写的脚本：只要它们在终端之下运行，TCC检查的就是终端。Apple的支持工程师就解释器直接点明了这一点：“if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that.”（如果你有一个需要操作桌面上文件的脚本，你不会想把这项权限给解释器，因为那样一来任何脚本都能这么做）²⁰ 一个拥有完全磁盘访问权限的终端，是同一个问题在高一层的重现。

其他App可以借用它。 2022年，Jeff Johnson发表了附带源代码的“Every unsandboxed app has Full Disk Access if Terminal does”（只要Terminal拥有完全磁盘访问权限，每个未沙盒化的App就都拥有它）。他的观点是：“unsandboxed apps can open executable shell scripts in Terminal, and those scripts will execute with the permissions not of the opening app but rather with the permissions of Terminal, i.e. Full Disk Access.”（未沙盒化的App可以在Terminal中打开可执行的shell脚本，这些脚本将以Terminal而非打开它的App的权限执行，也就是以完全磁盘访问权限执行）他也指出，这一手法“doesn’t work for sandboxed apps”（对沙盒化的App无效）。⁴⁶ 我在自己Mac上检查过的每个智能体桌面App都没有沙盒化：Claude App和Cursor没有App Sandbox权利，ChatGPT App则把它设为false。⁴⁷ 这是我的解读，而非Johnson的说法：在终端持有完全磁盘访问权限的Mac上，这些App中的任何一个都可以用同样的方式够到它。

终端自己怎么说？我没有找到任何Ghostty或iTerm2文档说明终端持有完全磁盘访问权限时子进程会得到什么：在GitHub上用这个短语对Ghostty的文档和iTerm2的代码库做代码搜索，结果均为零。我没有用同样的方式搜索Apple的Terminal或Warp的文档。⁴⁸ 这些App所显示的，是它们替谁说话。我从Mac上已安装的App中读到的用途说明字符串，都是代表在其中运行的程序来写的：Ghostty的AppleScript提示是“A program running within Ghostty would like to use AppleScript”（Ghostty中运行的某个程序想要使用AppleScript），iTerm2的是“An application in iTerm2 wants to use AppleScript”（iTerm2中的某个应用程序想要使用AppleScript）。⁴⁷ 由于App无法为完全磁盘访问权限弹出提示，macOS没有为它设置用途说明字符串，但这些字符串显示了设计思路：被询问的对象是终端这个App。

内置智能体的编辑器也是同样的工作方式，只是偏移了一层。Cursor的文档写道“Cursor runs shell commands directly in your terminal”（Cursor直接在你的终端中运行shell命令），在编辑器内部，我把它理解为Cursor自带的集成终端。⁴⁹ 按照上面支持工程师的辅助程序情形（由App派生的工具记在该App名下），对于这些命令，TCC看到的App就是Cursor。这是我的推断；Cursor的文档并没有说TCC记在哪个App名下。³¹⁸

SSH路径

如果你通过SSH驱动智能体，责任代码就不是远端的终端，而是SSH服务器。Apple的支持工程师写道：“The tool’s responsible code is the SSH server. You can set Full Disk Access on that using System Settings > General > Sharing > Remote Login > Allow full disk access for remote users.”（该工具的责任代码是SSH服务器。你可以在“系统设置”>“通用”>“共享”>“远程登录”>“允许远程用户对磁盘进行完全访问”中为它设置完全磁盘访问权限）³ eslogger手册页也提到了同一设置。² OpenClaw的设置指南展示了SSH一侧的客户端在TCC中的样子，即/usr/libexec/sshd-keygen-wrapper，而在我的Mac上，正是这个客户端列在完全磁盘访问权限名单中。¹⁴¹⁹

智能体厂商让你做什么

有两个智能体项目在各自的文档中告诉用户授予完全磁盘访问权限，以便智能体读取Messages：

• Hermes Agent（Nous Research）。 Apple iMessage技能标为“Bundled (installed by default)”（内置，默认安装），其前提条件包括“Grant Full Disk Access for terminal (System Settings → Privacy → Full Disk Access)”（为终端授予完全磁盘访问权限）和“Grant Automation permission for Messages.app when prompted”（出现提示时为Messages.app授予自动化（Automation）权限）。¹³ 这是厂商在指示你把完全磁盘访问权限给终端，从而也给在终端中运行的一切。该智能体的其余部分见Hermes指南。
• OpenClaw。 它的iMessage设置说明写道：“Full Disk Access is required for the process context running OpenClaw/imsg”（运行OpenClaw/imsg的进程上下文需要完全磁盘访问权限）（用于Messages数据库），“Automation permission is required to send messages through Messages.app”（通过Messages.app发送信息需要自动化权限），以及“Permissions are granted per process context”（权限按进程上下文授予）。¹⁴ 同一页面还说，对于回应、编辑和撤回等高级操作，“System Integrity Protection must be disabled”（必须停用System Integrity Protection），而基本的收发不需要这样做。¹⁴ OpenClaw的macOS权限页面对桌面、文稿和下载文件夹给出了同样的规则：“grant access to the same process context that performs file operations (for example Terminal/iTerm, LaunchAgent-launched app, or SSH process).”（把访问权限授予执行文件操作的同一个进程上下文（例如Terminal/iTerm、由LaunchAgent启动的App，或SSH进程））⁵⁰

Anthropic记载的是一个更窄的情形。按照其智能体视图文档，Claude Code的后台会话运行一个宿主进程，它“requests access to protected folders separately from your terminal”（独立于你的终端，单独请求访问受保护的文件夹）；如果后台会话在受保护位置报告“Operation not permitted”，解决办法是“grant access in System Settings under Privacy & Security > Files and Folders, or enable Full Disk Access for the entry.”（在系统设置的“隐私与安全性”>“文件与文件夹”中授予访问权限，或为该条目启用完全磁盘访问权限）文档说，使用原生安装程序时，“the entry appears as Claude Code and the grant persists across updates.”（该条目显示为Claude Code，授权在更新后依然保留）⁵¹ 对于计算机使用（computer use），Anthropic让用户在屏幕录制下确认“your terminal app is listed and enabled”（你的终端App已列出并已启用），这又是终端路径，只不过针对的是另一项权限。⁵² Anthropic关于沙盒、权限和安全的页面都没有提到完全磁盘访问权限。¹⁵⁵³

桌面App路径

桌面智能体App在隐私与安全性中各有自己的行，请求的内容各不相同：

• ChatGPT for Mac（在我的Mac上，其bundle ID为com.openai.codex）。2026年8月20日，OpenAI添加了一个Apple Messages插件：“On Apple silicon Macs, the Apple Messages plugin in the ChatGPT desktop app can read and search iMessage, SMS, and RCS conversations and prepare or send messages through Messages.”（在搭载Apple芯片的Mac上，ChatGPT桌面App中的Apple Messages插件可以读取和搜索iMessage、SMS和RCS对话，并通过Messages准备或发送信息）⁵⁴ OpenAI的插件指南只说“Grant the requested macOS permissions before ChatGPT reads Messages.”（在ChatGPT读取Messages之前，授予它所请求的macOS权限）²² 我没有找到点明是哪项权限的OpenAI页面。MacRumors报道发布消息时写道：“For the Messages integration to work, ChatGPT needs Full Disk Access in System Settings, as well as access to contact names and automation tools”（要让Messages集成工作，ChatGPT需要系统设置中的完全磁盘访问权限，以及对联系人姓名和自动化工具的访问权限）；这是媒体报道，此处仅作为线索使用，并非OpenAI的说法。⁵⁵ 在我的Mac上，ChatGPT App列在完全磁盘访问权限表中。¹⁹ OpenAI的指南里还有一条我会放在最前面的警告：“Persistent approval removes your final chance to review a message before ChatGPT sends it as you.”（持续批准会让你失去在ChatGPT以你的身份发送信息之前审阅它的最后机会）²² 对于Computer Use，OpenAI请求屏幕录制和辅助功能，并说“File reads, file edits, and shell commands still follow the sandbox and approval settings for the task.”（文件读取、文件编辑和shell命令仍遵循该任务的沙盒和审批设置）⁵⁶
• Claude for Mac。 我没有找到请求完全磁盘访问权限的Anthropic页面。我Mac上这个App的Info.plist为桌面、文稿和下载文件夹以及Apple Events等声明了用途说明字符串（“Claude needs this so commands you run in Claude can control other apps”（Claude需要此权限，以便你在Claude中运行的命令可以控制其他App））。⁴⁷ 它的快速输入功能请求屏幕录制和辅助功能。⁵⁷
• Cursor。 我保存的两个Cursor页面，即Run Modes和Terminal，都没有请求完全磁盘访问权限；Cursor列在我Mac上的表中。¹⁹¹⁸⁴⁹
• Hermes Agent的计算机使用。 辅助功能和屏幕录制授予hermes computer-use doctor指明的身份，即一个独立的驱动App，而不是终端。⁵⁸
• 带智能体的VS Code。 我的Mac上没有安装；我没有找到Microsoft关于其智能体与完全磁盘访问权限的页面。⁴⁷⁵⁹

各智能体的路径

每个单元格的出处见第3节和第4节。^{51166022561361146217481859} 第二列中关于两个编辑器的内容，是我根据支持工程师的辅助程序情形作出的推断，并非厂商的说法。第三列里有规律可循。点名完全磁盘访问权限的两家厂商，都是为了触及Messages，而Apple说这类数据的暴露还会波及“the people users are communicating with”（与用户交流的那些人）；Apple没有点名任何智能体，我也不声称它指的就是这两家。其他所有命令行智能体在触及同样的数据时，文档中都没有说终端的授权会传给它们，因为授权属于终端。

4. 厂商沙盒能做什么，不能做什么

互不知晓的两层

凡是我读过其macOS沙盒文档的命令行智能体，都把沙盒建立在Seatbelt这一系统进程沙盒之上，并通过sandbox-exec驱动：Claude Code（“sandboxing uses the built-in Seatbelt framework”，沙盒使用内置的Seatbelt框架）、Codex（“On macOS, sandboxing works out of the box using the built-in Seatbelt framework”，在macOS上，沙盒借助内置的Seatbelt框架开箱即用）、Gemini CLI（“Lightweight, built-in sandboxing using”sandbox-exec，使用sandbox-exec的轻量内置沙盒）和Cursor（“Cursor uses Seatbelt through”sandbox-exec，Cursor通过sandbox-exec使用Seatbelt）。^15161718 完全磁盘访问权限属于TCC。Apple的支持工程师这样描述两者的关系：“App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure,”（App Sandbox和强制访问控制系统都是用macOS的沙盒基础设施实现的），但强制访问控制“is mandatory; it’s not an opt-in like the App Sandbox.”（是强制性的，不像App Sandbox那样需要主动选择加入）²⁰

这在实践中意味着两方面。Seatbelt配置文件无法把责任App所没有的TCC授权赋予某个进程，这一点源自Apple支持工程师的描述，即所有进程，“including those running as root”（包括以root身份运行的进程），都受MAC约束；我没有测试这一点。另一方面我在第5节中于自己的Mac上作了测量：没有哪个沙盒改变了终端的授权；配置文件只有在它自己拒绝了那条路径时才会阻止受保护的读取，而且是在TCC本会允许该读取的情况下，单凭配置文件自身阻止的。²⁰⁵ 一个运行在拥有完全磁盘访问权限的终端里的沙盒化智能体，只要其配置文件允许在那里读取，仍然可以读取Messages；而大多数默认配置文件几乎在所有地方都允许读取。

有一个命名陷阱：Codex自己的源代码中有一个名为has_full_disk_read_access的函数，当它返回true且没有配置不可读的根目录时，生成的Seatbelt配置文件会在所有位置允许file-read*；如果配置了这类根目录，它会构建一个排除它们的读取策略。⁶³ 这是Codex对宽泛Seatbelt读取策略的叫法。它不是Apple的完全磁盘访问权限，也不会授予该权限。

Claude Code（Anthropic）

• 沙盒：默认关闭。 “The sandbox is off by default. To turn it on, run /sandbox in a session, as Get started shows, or set sandbox.enabled to true in a settings file.”（沙盒默认关闭。要开启它，可按Get started所示在会话中运行/sandbox，或在设置文件中把sandbox.enabled设为true）¹⁵
• 开启后的默认值。 写入可以去往“The working directory, a per-user temp directory, and directories you’ve added.”（工作目录、每用户临时目录以及你添加的目录）。读取覆盖“Most of the machine, including credential files.”（机器的大部分，包括凭据文件）。网络“No direct route out”（没有直接向外的路由）；连接经过本地代理，其允许的域名“start empty”（初始为空）。¹⁵ 该沙盒构建于“the open source @anthropic-ai/sandbox-runtime package”（开源的@anthropic-ai/sandbox-runtime软件包）之上。¹⁵
• 两种沙盒模式。 自动允许和常规权限；“In both, the sandbox enforces the same filesystem and network restrictions; the difference is only in whether sandboxed commands are auto-approved or require explicit permission.”（在两种模式下，沙盒都执行相同的文件系统和网络限制；区别仅在于沙盒内的命令是自动批准还是需要明确许可）¹⁵
• 沙盒之外的部分。 内置的文件和网页工具“follow permission rules instead. A denyRead entry doesn’t stop the Read tool,”（转而遵循权限规则。denyRead条目不会阻止Read工具），而且“command hooks, local MCP servers, plugin monitors, LSP servers, and helper commands such as your status line command and apiKeyHelper run with your full access.”（命令钩子、本地MCP服务器、插件监视器、LSP服务器以及状态栏命令和apiKeyHelper等辅助命令，都以你的完整权限运行）¹⁵ 失败的命令可能会在沙盒外重试，除非allowUnsandboxedCommands为false。¹⁵
• 收窄读取范围。 sandbox.filesystem.denyRead和allowRead，或者，若要“deny sandboxed commands read access to home directories and mounted volumes while keeping the working directories readable, set permissions.blockReadsOutsideWorkingDirectories.”（在保持工作目录可读的同时，拒绝沙盒内命令读取主目录和已挂载宗卷，请设置permissions.blockReadsOutsideWorkingDirectories）¹⁵
• Apple Events。 “The sandbox blocks Apple Events by default,”（沙盒默认阻止Apple Events），而开启allowAppleEvents会“removes code-execution isolation.”（移除代码执行隔离）¹⁵
• 权限模式，这是另一项独立的控制：default（标为Manual）、acceptEdits、plan、auto、dontAsk和bypassPermissions。关于最后一个，Anthropic说“Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage.”（只在Claude Code无法造成损害的容器或虚拟机等隔离环境中使用此模式）⁵³

这些键所在的设置文件见Claude Code指南。

Codex CLI（OpenAI）

• 沙盒：默认开启。 “The default permissions mode applies sandboxing automatically,”（默认权限模式会自动应用沙盒），以及“The sandbox applies to spawned commands, not just to built-in file operations.”（沙盒适用于派生的命令，而不仅是内置的文件操作）¹⁶
• 三种模式。 read-only：“The agent can inspect files, but it can’t edit files or run commands without approval.”（智能体可以查看文件，但未经批准不能编辑文件或运行命令）。workspace-write：智能体可以“read files, edit within the workspace, and run routine local commands inside that boundary. This is the default low-friction mode for local work.”（读取文件，在工作区内编辑，并在该边界内运行常规本地命令。这是本地工作的默认低摩擦模式）。danger-full-access：“The agent runs without sandbox restrictions.”（智能体在没有沙盒限制的情况下运行）¹⁶
• 网络默认关闭。 “By default, the agent runs with network access turned off,”（默认情况下，智能体在关闭网络访问的状态下运行），而workspace-write会“keeps network access turned off unless you enable it in your configuration.”（保持网络访问关闭，除非你在配置中启用）⁶⁰
• 完全访问。 OpenAI把它定义为sandbox_mode = "danger-full-access"加上approval_policy = "never"，桌面App的菜单则把它描述为对“the internet and any file on your computer”（互联网和你电脑上任何文件）的不受限访问。¹⁶
• 文档没有写明读取范围。 OpenAI关于范围的唯一说法是，沙盒“limits what it can touch (typically to the current workspace)”（限制它能触及的范围（通常限于当前工作区））。⁶⁰ 它没有给出read-only或workspace-write的读取范围；在我的Mac上，run 2（read-only）和run 2c（我的配置，未设模式）读取了一个远在工作区之外、需要完全磁盘访问权限的文件。⁵ 源代码说明了原因：Seatbelt基础策略以(deny default)开头，并注明“child processes inherit the policy of their parent”（子进程继承父进程的策略），而在完全读取访问且没有不可读根目录时，配置文件会加入(allow file-read*)。⁶³ 收窄的手段是有的：权限配置文件可按路径设置"read"、"write"或"deny"，管理员还可以在requirements.toml中使用permissions.filesystem.deny_read，即“Admin-enforced filesystem read denials”（由管理员强制执行的文件系统读取拒绝）；OpenAI说“users cannot weaken them with local config.”（用户无法通过本地配置削弱它们）²¹

配置文件和审批策略的详细内容见Codex指南。

Hermes Agent（Nous Research）

• 没有macOS沙盒；有七种后端。 “Hermes supports seven terminal backends”（Hermes支持七种终端后端）：local、docker、ssh、modal、daytona、vercel_sandbox和singularity。⁶¹
• 默认：local，无隔离。 “The default. Commands run directly on your machine with no isolation,”（默认选项。命令直接在你的机器上运行，没有隔离），以及“By default, local tool subprocesses keep your real OS-user HOME.”（默认情况下，本地工具子进程保留你真实的操作系统用户HOME）⁶¹
• 命令规则不是沙盒。 “Deny rules are a shell-command policy, not a complete shell interpreter or an OS capability sandbox.”（拒绝规则是一种shell命令策略，既不是完整的shell解释器，也不是操作系统能力沙盒）⁶⁴
• 容器才是边界。 “For production gateway deployments, use docker, modal, daytona, or vercel_sandbox backend to isolate agent commands from your host system.”（在生产网关部署中，请使用docker、modal、daytona或vercel_sandbox后端，把智能体命令与主机系统隔离）⁶⁴

在默认后端下，Hermes智能体能读取其终端能读取的一切，而它内置的iMessage技能会要求你给那个终端授予完全磁盘访问权限。¹³

OpenClaw

• 沙盒：默认关闭，而且只针对工具。 “Sandboxing is off by default,”（沙盒默认关闭），以及“The Gateway process always stays on the host; only tool execution moves into the sandbox when enabled.”（网关进程始终留在主机上；启用后，只有工具执行会移入沙盒）。OpenClaw对此很坦率：“This is not a perfect security boundary, but it materially limits filesystem and process access when the model does something dumb.”（这不是一个完美的安全边界，但当模型做了蠢事时，它能实质性地限制文件系统和进程访问）⁶²
• 模式。 agents.defaults.sandbox.mode可取off（默认）、non-main或all；后端默认为docker，另有podman、ssh、openshell和crabbox可选；Docker的网络默认为none。⁶⁵
• 工作区访问。 none（默认）、ro或rw。⁶⁶
• 逃生口。 用OpenClaw的话说，tools.elevated是“an explicit escape hatch”（一个明确的逃生口），它在沙盒之外运行exec。⁶²

iMessage渠道的完全磁盘访问权限属于网关的进程上下文，而网关从不移入沙盒。¹⁴⁶²

其他几个，简要说明

• Gemini CLI。 除非用-s、环境变量或设置启用，否则关闭。在macOS上，默认的Seatbelt配置文件permissive-open“denies operations by default; confines writes to the project directory while allowing broad file reads and network access”（默认拒绝操作；把写入限制在项目目录，同时允许宽泛的文件读取和网络访问）；配置文件本身写着(allow file-read*)。strict-open和strict-proxied会增加读取限制。¹⁷
• Cursor。 对“the full subprocess tree”（整个子进程树）使用Seatbelt；网络“Blocked by default”（默认阻止）；但Read Access默认是System：“The agent can read files outside the workspace without approval. This is the default.”（智能体无需批准即可读取工作区以外的文件。这是默认设置）Read Access设置本身需要Cursor 3.23或更高版本。¹⁸
• VS Code。 chat.agent.sandbox.enabled仅适用于Copilot Agent Host会话，取值为off或on，默认off；Microsoft明确说明了它的局限：“Sandboxing is not a virtual machine or user-account boundary, and it does not replace endpoint security.”（沙盒不是虚拟机或用户账户边界，也不能取代端点安全）⁵⁹
• Aider。 没有文档记载的沙盒。⁴⁸

Seatbelt这一层也出过漏洞

Accomplish的研究人员针对智能体工具公布了五个沙盒逃逸，分载于2026年7月23日至9月15日的四篇文章。其中四个在公开前已修复；第五个报告给了Anthropic，被以“Informative”（仅供参考）结案。针对Claude Code，在开启沙盒并使用最严格权限模式的情况下，一条来自代码库的命令“ran on our Mac anyway, outside the sandbox, with no permission prompt”（仍然在我们的Mac上、在沙盒之外、没有任何权限提示地运行了）；Anthropic在2.1.247中修复了它。⁶⁷ 针对Cursor的CLI，根本原因相同：“the Seatbelt profile wraps only the shell tool, while the harness’s own internal git runs unsandboxed and honors repository-supplied core.fsmonitor hooks.”（Seatbelt配置文件只包裹了shell工具，而工具链自己内部的git在沙盒外运行，并会执行代码库提供的core.fsmonitor钩子）⁶⁸ 针对Codex，有两个在2026年8月12日报告的逃逸，“Both were fixed inside of eight days”（两者都在八天内修复）；其中一个是“launchd starts the application unsandboxed, outside Codex’s process tree.”（launchd在Codex进程树之外以非沙盒状态启动该应用程序）⁶⁹ 针对Claude Cowork的虚拟机，有一个逃逸到主机读写挂载的案例，借此“reads and writes the host Mac’s filesystem directly, as the logged-in desktop user.”（以已登录的桌面用户身份直接读写主机Mac的文件系统）⁷⁰ 四篇文章都没有读取完全磁盘访问权限保护的数据。这是我的解读，而非研究人员的说法：一个逃出Seatbelt但仍留在终端启动链中的进程，依然带着终端的TCC授权，因此在终端持有完全磁盘访问权限的Mac上，这类逃逸同样能触及完全磁盘访问权限保护的数据。我没有找到任何事后分析、安全公告或研究文章，记述某个智能体违背用户意愿、通过完全磁盘访问权限授权读取了Mail、Messages或浏览器数据。

5. 在我的Mac上：谁持有完全磁盘访问权限，我又是如何知道的

本节的所有内容，都是我在2026年10月11日从一个Claude Code会话中，在我自己的Mac上进行的测量：macOS 27.0，构建版本26A428，System Integrity Protection已启用。除两条命令外，其余都是只读的：一项测试提交了一个launchd任务，让它把输出写入两个文件，然后移除了该任务；另一项通过npx -y安装了Anthropic的sandbox-runtime 0.0.79来运行它，并为其运行写了两个临时设置文件。沙盒内的写入探测只是尝试，沙盒拒绝了它们；网络探测是失败的尝试，原因无法从记录中确定。我没有更改任何设置，也没有授予或撤销任何东西。¹⁹⁵ 我按App和服务名称来描述所见。凡证据显示某个程序在完全磁盘访问权限名单中，我说它“列在名单中”；只有当一次读取证明访问确实生效时，我才说它“拥有访问权限”。

智能体的启动链

Claude Code用来执行命令的shell是一个zsh，由claude启动，claude由我的登录shell启动，登录shell由login启动，login由终端App Ghostty启动；环境变量报告TERM_PROGRAM为ghostty。¹⁹ 按照Apple支持工程师的规则，这条链中任何东西的责任代码都是Ghostty。³

读取名单

在我核查的范围内，macOS没有记载任何可以列出完全磁盘访问权限持有者的命令：tccutil只有一个命令，reset。³⁴ 名单存放在TCC的数据库里。从智能体的shell中，每用户数据库无法打开，它所在的文件夹也没有出现在用户Application Support文件夹的目录列表里。我不知道原因。macOS 27发行说明写着“Apps can no longer access the local TCC database directly”（App不能再直接访问本地TCC数据库），这可能就是原因，但该说明没有指明是哪个数据库，所以我让它保持未解释的状态。¹⁹²³

系统范围的数据库可以打开。我只选取了服务和客户端两列，按完全磁盘访问权限服务过滤，从未读取记录各个开关是否打开的那一列。结果返回75行。¹⁹ 能打开它本身就是证据。2022年，Jeff Johnson展示了拥有完全磁盘访问权限的Terminal“can read or write any restricted files, including the TCC database itself”（可以读写任何受限文件，包括TCC数据库本身）；他演示的是每用户数据库，而下文的对照测试表明，在这台Mac上，系统数据库也是如此。⁴⁶⁵ 这也意味着，尽管有上面引用的那条发行说明，在macOS 27.0上，启动链持有该授权的进程仍然可以直接读取系统TCC数据库。¹⁹²³

我按类别对75行逐一套用一条规则，依次为：三个终端的bundle ID；任何指向带版本号Claude Code二进制文件的客户端路径；ChatGPT、Cursor和Xcode的bundle ID；任何node或python3.x解释器路径；SSH服务器的客户端；任何以com.apple.或/System/开头的客户端；我自己的开发构建；以及其余所有。¹⁹⁴⁷ 各组内容如下：

• 终端（3）。 Terminal、iTerm2和Ghostty都列在名单中。
• Claude Code（30）。 三十个独立的行，每行是指向某一版本Claude Code二进制文件的路径，从2.1.177到本次会话运行的版本2.1.296。¹⁹⁴⁷ Anthropic说，使用原生安装程序时，后台会话宿主的条目“appears as Claude Code and the grant persists across updates.”（显示为Claude Code，授权在更新后依然保留）⁵¹ 在这台Mac上，数据库为每个版本存储一行。我没有核查系统设置如何显示它们，也没有核查每个开关是否打开。我的解读，未经验证：这些是后台会话宿主的请求，每次更新一个。
• 智能体宿主（3）。 ChatGPT App（bundle ID为com.openai.codex）、Cursor和Xcode。¹⁹⁴⁷ Xcode归入此类，是因为Xcode 27可以承载智能体：它的发行说明写道“Agents in Xcode can now be extended with plugins that contain skills, MCP servers, and ACP agent configurations”（Xcode中的智能体现在可以通过包含技能、MCP服务器和ACP智能体配置的插件进行扩展），并加入了对Agent Client Protocol的支持。²⁴ TCC是否把这些智能体派生的进程记在Xcode名下，没有文档记载，而且Xcode的行为未必与终端相同。2024年，有人问为什么某个工具自己的授权只在由Xcode运行时才被认可，Apple的支持工程师回答：“Xcode runs the tool in a way that makes it clear to the system that Xcode is not the responsible code for this process”（Xcode运行该工具的方式会让系统清楚，Xcode不是这个进程的责任代码）；在Xcode调试器下查看进程链时，他写道“I expect that one of these is breaking TCC’s responsible code search”（我估计其中某一环打断了TCC对责任代码的查找），并补充说“I suspect that’s deliberate.”（我怀疑这是有意为之）³ 所以，Xcode列在名单中并承载智能体，但对于它运行的工具，Apple工程师描述的情况与终端规则恰恰相反。
• 解释器（5）。 一个Homebrew的node和四个Homebrew的Python解释器。Apple的支持工程师警告的正是这种情况：把权限给解释器，“then any script could do that.”（那么任何脚本都能这么做）²⁰ OpenClaw在辅助功能方面也对node作出同样的警告：要把这样的条目视为“as broad permission for that Node runtime, not as permission for one npm package.”（对那个Node运行时的宽泛授权，而不是对某一个npm包的授权）⁵⁰
• SSH（1）。 sshd-keygen-wrapper，即SSH服务器端的客户端，我认为它就是“Allow full disk access for remote users”（允许远程用户对磁盘进行完全访问）所控制的条目。¹⁹³
• 其他Apple（3）、我自己的构建（5）、其余所有（25）。 最后一组包括磁盘和清理工具、一款安全套件、VPN和云储存客户端、更新程序、打印机软件、游戏、一款视频会议App和一款即时通讯App。其中有几个是磁盘工具，即Apple提到的另一类软件；75行中没有一个是备份App。

75行中有42行是智能体可以在其之下或通过其运行的。其中没有一个是备份App。

七次运行：沙盒和授权是相互独立的两层

为了弄清是哪一层在作决定，我在不同条件下运行了同一个探测，即从那个系统数据库读取一行，另外在两个沙盒内各做了一次写入探测，在sandbox-runtime内做了一次网络探测。⁵

1. 智能体的shell，无沙盒。 读取返回了该行。
2. 在Codex CLI 0.154.0的Seatbelt沙盒内，read-only模式。 读取返回了该行。同一个沙盒以“Operation not permitted”拒绝了在工作区之外执行的touch（run 2b），所以沙盒在正常工作；它只是不在那里阻止读取。使用我自己的Codex配置（未设置沙盒模式，并开启了网络访问），读取同样返回了该行（run 2c）。
3. 在Anthropic的sandbox-runtime 0.0.79内，这是Claude Code沙盒所基于的软件包，不设读取拒绝（run 3a）：读取返回了该行，而向允许文件夹之外的写入被拒绝，网络请求失败（curl退出码56；记录未显示原因）。把denyRead设为TCC文件夹后（run 3b），读取以“authorization denied”失败。
4. 对照组。 同样的sqlite3读取，以launchd任务的形式提交，使Ghostty和Claude Code都不在其启动链中：“authorization denied”。⁵

正是这个对照组让其余结果有了意义。数据库文件归root所有，按其权限模式（-rw-r--r--）人人可读，所以拒绝run 4的不是文件权限，而是TCC。¹⁹⁵ 同一个二进制文件、同一个文件、同一个用户，从智能体的shell发起就成功，在其外发起就失败。智能体shell所拥有的，来自它的启动链。支持工程师的规则指明终端是这条链的责任代码。³ 有一个保留意见，凭这些数据我无法排除：链中还有一个claude进程，而Claude Code的二进制文件也列在名单中；在run 3a和3b中，sandbox runtime由一个node进程运行，而Homebrew的node也列在名单中，不过npx用的是哪个node并未记录。我的测量表明访问来自启动链，支持工程师的规则说是终端；但测量本身并不能单独证明TCC采用的是Ghostty那一行，而不是Claude Code或node的行。Apple的支持工程师说，这一算法没有文档记载。³

run 3b和run 4打印出完全相同的错误，尽管拒绝它们的是不同的层。操作者在智能体输出中看到“authorization denied”时，无法从这条消息判断说不的是沙盒还是TCC。⁵

在你自己的Mac上试一试

从你的智能体所用的shell中运行下面的命令：当该shell的启动链持有完全磁盘访问权限时，它会打印出完全磁盘访问权限名单；当启动链没有该权限，或像run 3b那样有沙盒规则拒绝该文件夹时，它会以“authorization denied”失败。它只读取两列，不做任何更改。结果是行，而不是开关状态。

# Run from the same terminal (or editor terminal) you run agents in.
sqlite3 -readonly "/Library/Application Support/com.apple.TCC/TCC.db" \
  "SELECT service, client FROM access WHERE service='kTCCServiceSystemPolicyAllFiles';"
echo "exit=$?"

这正是我在macOS 27.0上逐字运行的查询。¹⁹ 要查看TCC把一次访问记在哪个App名下，Apple的部署指南给出了一个日志流命令log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'，用于实时“to try to identify”（尝试识别）责任App或二进制文件。³¹ 我在这些测量中没有运行它，这也是第5节无法断定作决定的是Ghostty那一行还是链中其他行的原因。上面的数据库查询在以后的版本中可能会失效。Apple既没有记载这个文件，也没有记载其结构，而macOS 27的说明已经写明App“can no longer access the local TCC database directly.”（不能再直接访问本地TCC数据库）²³

6. 现在该做什么

截至我10月11日的读取，我没有找到关于新控制的任何已公布机制或发行说明，所以这里没有什么是迁移步骤。这是我今天在任何运行智能体的Mac上都会做的事，每一步都附有出处和代价。我自己的Mac也还没有全部做完；第5节就是“改动之前”的样子。

1. 查清谁持有完全磁盘访问权限。 打开“系统设置”>“隐私与安全性”>“完全磁盘访问权限”，读一遍名单。⁴ 留意终端、编辑器、智能体App、智能体二进制文件、解释器，以及任何你不认识的东西。在shell中，如果该shell已经拥有访问权限，第5节的查询会打印出名单，这同时也测试了你的智能体shell是否拥有它；失败也可能来自拒绝该文件夹的沙盒规则，就像run 3b那样。⁵ 代价： 无。请记住，列在名单中的App不一定已经开启。

2. 把它从运行智能体的终端上撤掉。 这是改变最大的一步。命令行工具的责任代码是终端，所以终端的授权就是智能体的授权。³² 如果你需要在命令行中用完全磁盘访问权限做备份或管理工作，这正是tmutil和fdesetup的文档所针对的用途，那就另备一个持有该授权的终端App，并且绝不在其中启动智能体。⁴³⁴⁴（最后这一点是我的建议，不是Apple的。Jeff Johnson用Apple的Terminal演示过，未沙盒化的App可以通过在其中打开脚本来借用它的授权；按我的解读，同样的情况也可能适用于会打开脚本的第二个终端App。⁴⁶）代价： 受保护的位置开始以“Operation not permitted”失败，“文件与文件夹”的提示会重新出现。Apple的按文件夹控制覆盖“Desktop, Documents, Downloads, network volumes, and removable volumes.”（桌面、文稿、下载、网络宗卷和可移除宗卷）¹⁰ Anthropic为Claude Code的后台会话记载了同样的失败及其解决办法，即为该条目授予“文件与文件夹”权限。⁵¹ OpenClaw建议把文件放在它的工作区内，以免逐个文件夹授权。⁵⁰

3. 检查智能体自己的条目。 Claude Code的后台宿主会“separately from your terminal”（独立于你的终端）请求访问，并可能持有自己的完全磁盘访问权限条目。⁵¹ 在我的Mac上，30个带版本号的Claude Code二进制文件列在名单中，我把它们解读为该宿主的条目，未经验证。¹⁹ 删除那些你并非有意授予的条目，在后台会话需要某个文件夹的地方，改为授予“文件与文件夹”权限。智能体App也各有自己的行；在我的Mac上，ChatGPT、Cursor和Xcode这几个App都列在名单中。¹⁹ 代价： 读取受保护文件夹的后台会话会失败，直到你授予更窄的访问权限。

4. 绝不把它授予解释器。 Apple支持工程师的原话是：“if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that.”（如果你有一个需要操作桌面上文件的脚本，你不会想把这项权限给解释器，因为那样一来任何脚本都能这么做）他的解决办法是“package your script as a standalone program that MAC can use for its tracking.”（把脚本打包成MAC可以用来跟踪的独立程序）²⁰ 解释器自己的那一行，在解释器成为责任代码的场合就会生效，例如以未关联任何App的launchd任务运行脚本；这时，通过该解释器以这种方式启动的每个Python或Node脚本，包括MCP服务器，都会获得完整授权。³² 代价： 对于确实需要该访问权限的脚本，他的“easiest solution”（最简单的办法）是把它打包成MAC可以跟踪的独立程序，他说用AppleScript很容易做到，用shell脚本则不然。²⁰

5. 打开厂商沙盒，并拒绝你不需要的读取。 默认读取范围很宽，所以打开沙盒是必要的，但并不充分。

• Claude Code： 先开启sandbox.enabled，再设置permissions.blockReadsOutsideWorkingDirectories（或sandbox.filesystem.denyRead规则），并设置"allowUnsandboxedCommands": false以取消沙盒外重试。¹⁵ 记住Read工具、钩子和MCP服务器都在沙盒之外。¹⁵ 代价： 需要其他路径或主机的工具会失败，直到你允许它们；每增加一个excludedCommands条目，都会重新打开缺口。¹⁵
• Codex： 保持在workspace-write或read-only；避免danger-full-access；在权限配置文件中添加"deny"读取规则，或者对团队而言，在由管理员强制执行的requirements.toml文件中设置permissions.filesystem.deny_read，使用户无法削弱它。¹⁶²¹ 代价： 需要网络的命令要经批准，或需要network_access。⁶⁰
• Gemini CLI： 用-s加上SEATBELT_PROFILE=strict-open或strict-proxied运行，这是文档描述为会限制读取的两个配置文件。¹⁷ 代价： 这两个配置文件既限制写入也限制读取，所以读取项目之外内容的工具会在其下失败，直到你选择更宽松的配置文件。
• Cursor： 把Read Access从System切换为Workspace；该设置需要Cursor 3.23或更高版本，而我Mac上的Cursor是3.19.7。¹⁸⁴⁷ 代价： 读取工作区之外的文件会先征求同意，沙盒内的命令只能看到工作区、你的Read Allowlist以及常用工具所需的系统路径。¹⁸
• VS Code： 开启chat.agent.sandbox.enabled；它只覆盖Copilot Agent Host会话，“not the Local chat harness or the custom terminal tool override.”（不包括本地聊天工具链或自定义终端工具覆盖）⁵⁹ 代价： 需要其默认范围之外的路径或工具的命令必须获得允许，而即便如此，Microsoft也说它“not a virtual machine or user-account boundary”（不是虚拟机或用户账户边界），并且默认不阻止出站网络，所以它只是收窄缺口，而不是封闭缺口。⁵⁹
• Hermes Agent和OpenClaw： 使用容器后端。Hermes推荐生产网关使用容器后端；OpenClaw的沙盒默认关闭，用它的话说“not a perfect security boundary”（不是一个完美的安全边界），不过它说沙盒“materially limits filesystem and process access”（实质性地限制文件系统和进程访问）。⁶⁴⁶² 代价： 在容器中运行的命令失去对主机的不受限访问（Hermes把这些后端描述为把“agent commands from your host system”（智能体命令与主机系统）隔离开），但挂载或同步的文件仍然可以触及：Hermes的Docker和Singularity后端使用绑定挂载，即“live host filesystem view”（实时的主机文件系统视图），它的docker_volumes设置会共享主机目录，而OpenClaw的工作区访问除了默认的none，也可以是ro或rw。⁶⁴⁶¹⁶⁶ 代价在于要显式提供任务所需的文件，并审计这些挂载。它覆盖不到的： OpenClaw的网关留在主机上，所以已配置的iMessage渠道保留着网关进程上下文的完全磁盘访问权限；把工具容器化并不能消除这一暴露。⁶²¹⁴ Hermes的iMessage技能列出了主机端的前提条件（已登录Messages、已安装imsg、终端拥有完全磁盘访问权限）；我没有找到Hermes关于该技能在容器后端下如何表现的页面。¹³

局限： 在我的Mac上，没有哪个沙盒改变了完全磁盘访问权限的授权；沙盒只有在其配置文件按名称拒绝该路径时才会阻止受保护的读取；而Claude Code、Cursor的CLI和Codex的Seatbelt层都曾有公开的逃逸，现已修复。^5676869

6. 让读取Messages的智能体使用单独的macOS用户，或者干脆不用它。 OpenClaw对其iMessage机器人的部署建议是“Use a dedicated Apple ID and macOS user so bot traffic is isolated from your personal Messages profile.”（使用专用的Apple ID和macOS用户，使机器人流量与你的个人Messages资料隔离）⁷¹ 把该用户设为标准账户：Apple说标准用户“can install apps and change their own settings, but can’t add other users or change other users’ settings.”（可以安装App和更改自己的设置，但不能添加其他用户或更改其他用户的设置）⁷² 在我的Mac上，按文件权限模式，我的用户Library、Mail和Messages文件夹只有我能读取，因此以另一个标准用户身份运行的进程，在咨询TCC之前就会被普通文件权限拒绝；这是我根据权限模式作出的推断，不是我运行过的测试。¹⁹ 有两个保留意见：Apple的支持工程师说完全磁盘访问权限是“system wide”（系统范围的），不是按用户的，所以在一个账户中被授予该权限的App在所有账户中都拥有它；而Apple的指南说该设置会触及“certain administrative settings for all users on this Mac.”（这台Mac上所有用户的某些管理设置）²⁰⁴ 代价： 第二个登录账户，第二套钥匙串和设置，以及一个除非你共享、否则看不到你主账户文件的智能体。

7. 如果不需要，关闭“Allow full disk access for remote users”（允许远程用户对磁盘进行完全访问）。 如果你通过SSH驱动智能体，SSH服务器就是责任代码，而这个设置就是它的授权。³ 在我的Mac上，它的客户端列在名单中。¹⁹ 代价： 远程shell将无法访问受保护的位置。

8. 对一切以你的身份说话的功能，保留逐项审批。 OpenAI：“Persistent approval removes your final chance to review a message before ChatGPT sends it as you. Use it only when you accept that risk.”（持续批准会让你失去在ChatGPT以你的身份发送信息之前审阅它的最后机会。只有在你接受这一风险时才使用）²² Anthropic：把bypassPermissions留给“isolated environments like containers or VMs.”（容器或虚拟机等隔离环境）⁵³ 代价： 点击次数更多，而这正是目的所在。

9. 如果你管理Mac，审计你的描述文件授予了什么。 隐私偏好设置策略控制描述文件可以把SystemPolicyAllFiles授予任何bundle ID或路径，终端也不例外，而且“The user isn’t prompted and can’t change this value.”（不会提示用户，用户也无法更改此值）²³⁷ 在macOS 27上，该负载中按App划分的部分被标为弃用，而声明式替代方案没有完全磁盘访问权限的键。³⁷³⁸ 我没有找到Apple记载的、让MDM报告用户手动授予的完全磁盘访问权限的方法。代价： 你找到的描述文件可能正支撑着某个备份或安全代理；Apple自己的示例就为组织的App授予了“without prompting the user”（无需提示用户）的访问权限。³¹

关于无人值守地运行智能体，见循环工程指南；当键盘前没有人阅读提示时，上面的每一步都更加适用。

7. 可能会变什么：一种附带条件的解读

本节的所有内容都是我对Apple措辞以及Apple已在其旁边推出的改动的解读。Apple没有宣布任何机制，我也不作任何预测。下面每一种形态，都是10月2日文本所容许的，附有使其更可信或更不可信的证据，以及它会影响智能体的条件。

更严格的授权流程。 文本自身的动词都关乎授权：用户“who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action,”（真正希望授予某个App这种非同寻常级别访问权限的，只能通过非常明确的用户操作来完成），并应当“clearly understand these risks before granting such access.”（在授予此类访问权限之前清楚了解这些风险）¹ Apple此前已经推出过附带解释的同意机制：macOS 27的声明式App设置在应用隐私默认值之前，会向用户显示一个同意提示，其中载有组织必须填写的理由说明。³⁹³⁸ 条件： 如果新控制只适用于新的授权，已经持有完全磁盘访问权限的终端会保留它，在其中运行的智能体在用户重置之前不受影响。如果它也适用于现有授权，那么每个持有完全磁盘访问权限的终端也都会受到影响。这条新闻对两种情况都没有说。

更窄的范围。 Apple可以让开关保持原样，而把数据从它下面移走。Apple以前就重新划过这些界线：Catalina把废纸篓加入了需要完全磁盘访问权限的范围，macOS 14和15分别为App容器和组容器加上了各自的保护，macOS 27则默认拒绝其他团队的容器，并让XProtect限制“app data that is commonly targeted by malicious software.”（常被恶意软件盯上的App数据）¹¹²⁰²³ 条件： 如果Apple把Mail、Messages或Safari数据移到完全磁盘访问权限覆盖不到的专门控制之下，那么即使终端保留着完全磁盘访问权限，终端路径也将无法再触及它们。这条新闻没有提到收窄范围；它所说的“this extraordinary level of access”（这种非同寻常级别的访问权限），描述的是授权的现状。

对继承授权的不同处理。 “grant an app”（授予某个App）与作为App子进程的智能体之间的缺口，正是本文的主题，而Apple手上已经有两块可以用来处理它的拼图。Xcode 27已经有了“a new security layer that monitors and controls filesystem access by coding agents and any processes they spawn,”（一个新的安全层，用于监控和控制编程智能体及其派生的任何进程对文件系统的访问），而macOS 27的Endpoint Security加入了es_new_descendants_client，它只监视“the entire subtree rooted at the calling process”（以调用进程为根的整个子树），并且按其头文件的说法“Does NOT require TCC approval,”（不需要TCC批准），但与es_new_client一样需要com.apple.developer.endpoint-security.client权利。²⁴²⁵ Apple的支持工程师在2026年9月18日把后者加进了他关于文件权限的帖子。²⁰ 这两份文本都没有与完全磁盘访问权限挂钩。条件（作为我的解读）： 针对“an app”（某个App）的控制会落在终端上，其中的每个智能体仍会继承其结果，除非Apple改变那位工程师所说的未记载、“subject to change”（可能变化）的责任代码归属方式，或者把新控制绑定到类似descendants客户端的东西上。两份文本都没有说它会这样做。

受管理的Mac。 如今，MDM可以在不提示用户的情况下授予完全磁盘访问权限。³⁷ 在macOS 27中，该负载按App划分的部分已被弃用，而它的声明式替代方案没有完全磁盘访问权限的键。³⁷³⁸ 条件： 如果“very explicit user action”（非常明确的用户操作）也适用于MDM授权，那么通过描述文件静默授权将不再可能；如果不适用，受管理的Mac就保留了这条静默路径。Apple在这两点上都没有表态，也没有把macOS 27的弃用与10月2日的新闻联系起来。

何时。 这条新闻说的是“Going forward”（今后）。在它发布三天后的测试版macOS 27.2 beta 3的说明中，没有任何相关内容；我在10月11日的发布信息源和发行说明索引中都没有找到macOS 27.1的条目：信息源列出的是27.0.1（9月28日），然后是27.2 beta 3，27.2的测试版始于9月16日，发行说明索引则只列出了27和27.2 beta 3。⁶⁸⁷⁹ Apple把今年的TCC弃用项“Apps can no longer access the local TCC database directly”（App不能再直接访问本地TCC数据库）放在了macOS 27发行说明的TCC标题之下。²³ 条件： 如果新控制随一个有开发者说明的版本到来，那么这些说明就是Apple放置今年TCC弃用项的地方，我会逐一阅读每个macOS 27.x测试版的说明来找相关条目。但macOS 27.0.1已经在完全没有开发者发行说明的情况下发布了，所以改动也可能出现在一个任何说明页面都没有一行记载的小版本更新中。⁷⁸ 如果它们随macOS 28到来，那么Apple以往描述此类改动的地方是WWDC讲座或测试版的发行说明：Catalina的保护措施见于WWDC19，今年的TCC弃用见于macOS 27的说明。¹¹²³ 无论哪种情况，第6节中的步骤都不取决于答案。

关键要点

如果你在Mac上运行智能体

• Apple在10月2日表示，授予完全磁盘访问权限将需要“very explicit user action”（非常明确的用户操作），并把AI智能体列为原因。它没有给出版本、日期或机制。¹
• 你的命令行智能体拥有你的终端所拥有的一切。Apple的手册页和其支持工程师都说终端是责任代码；Apple没有记载通用规则。²³
• 厂商沙盒不是完全磁盘访问权限的控制手段。在我的Mac上，一次受保护的读取穿过了Codex的read-only沙盒和Anthropic的沙盒运行时；只有针对确切文件夹的读取拒绝，或在终端之外启动，才能阻止它。⁵
• 把完全磁盘访问权限从运行智能体的终端上撤掉，绝不把它给node或python，并且要开启读取限制，而不仅仅是开启沙盒。²⁰¹⁵²¹
• 如果某个智能体读取Messages，就给它一个单独的macOS用户，并保留逐条发送的审批。⁷¹²²

如果你开发智能体或智能体App

• 不要让用户把完全磁盘访问权限授予他们的终端或智能体进程。如今有两家厂商为了Messages在这样做。¹³¹⁴
• Apple有文档记载的途径是一个通往设置面板的链接，而不是提示；开关属于用户，而Apple说打开它将需要非常明确的用户操作。²⁵¹
• 在文档中写明你的沙盒默认读取什么。Codex的文档说它的沙盒“limits what it can touch (typically to the current workspace)”（限制它能触及的范围（通常限于当前工作区））；它的源代码和我的运行结果表明，读取远远超出了工作区。⁶⁰⁶³⁵

常见问题

Mac上的完全磁盘访问权限是什么？

它是“系统设置”>“隐私与安全性”中的一项设置，允许App“access all files on your computer, including data from other apps (for example, Mail, Messages, Safari, and Home), data from Time Machine backups, and certain administrative settings for all users on this Mac.”（访问电脑上的所有文件，包括其他App的数据（例如Mail、Messages、Safari和“家庭”）、时间机器备份中的数据，以及这台Mac上所有用户的某些管理设置）App无法为此弹出提示；只能由用户用添加按钮添加App，或由MDM描述文件授予。⁴¹⁰²

Apple在2026年10月就完全磁盘访问权限宣布了什么？

在一则日期为2026年10月2日的开发者新闻“Updates to Full Disk Access in macOS”中，Apple说它“will introduce additional controls”（将引入额外的控制），使希望把这种访问权限授予某个App的用户“can only do so with very explicit user action”（只能通过非常明确的用户操作来完成），原因是“As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially.”（随着AI智能体日益强大和自主，与这一级别访问权限相关的风险将大幅增加）它没有给出macOS版本、日期或机制。¹

Claude Code或Codex会从我的终端获得完全磁盘访问权限吗？

如果终端拥有它，会的。从终端运行的工具是以终端为准接受检查的；Apple的eslogger手册页说，从“Terminal.app or a third-party terminal emulator”（Terminal.app或第三方终端模拟器）中运行它，需要该App已获授权，而Apple的支持工程师在论坛帖子中写道：“The tool’s responsible code is Terminal.”（该工具的责任代码是Terminal）在我的Mac上，一次需要完全磁盘访问权限的读取从Ghostty中的Claude Code shell发起时成功，在其外部启动时失败。²³⁵

Claude Code或Codex的沙盒能阻止智能体读取我的Messages吗？

默认情况下不能。两者的沙盒都使用Seatbelt，而Seatbelt与完全磁盘访问权限是相互独立的。Claude Code的沙盒默认关闭，开启后也会读取“Most of the machine”（机器的大部分）。Codex的沙盒默认开启，但它的read-only模式在我的Mac上读取了一个受完全磁盘访问权限保护的文件。请明确拒绝这些读取：在Claude Code中用permissions.blockReadsOutsideWorkingDirectories，在Codex中用权限配置文件里的"deny"规则。¹⁵²¹⁵

如何查看哪些App拥有完全磁盘访问权限？

打开“系统设置”>“隐私与安全性”>“完全磁盘访问权限”。⁴ tccutil无法列出它；它唯一的命令是reset。³⁴ 从一个已经拥有完全磁盘访问权限的终端中，读取系统TCC数据库即可列出客户端，如第5节所示；以“authorization denied”失败，意味着你的shell没有该访问权限，或者某条沙盒规则拒绝了读取。¹⁹⁵

我应该从Terminal上移除完全磁盘访问权限吗？

如果你在其中运行智能体，应该。为tmutil之类的备份或管理命令另备一个持有该授权的终端，并且绝不在那里启动智能体。在移除了该权限的终端里，可以预期会出现“文件与文件夹”提示和“Operation not permitted”错误。⁴³¹⁰⁵¹

Apple新的完全磁盘访问权限控制何时推出？

Apple没有说。10月2日的新闻说的是“Going forward”（今后），macOS 27.2 beta 3的发行说明没有提到它，而我在10月11日的发布信息源和发行说明索引中都没有找到macOS 27.1的条目：信息源列出的是macOS 27.0.1（9月28日），它发布时没有开发者发行说明，随后是macOS 27.2 beta 3；27.2的测试版本身始于9月16日。¹⁶⁷⁸⁹

来源