ChatGPT 想要完全磁盘访问权限来读取你的 iMessage

Q: 仅仅为了读取 Messages，真的有必要用到完全磁盘访问权限吗？

是的，鉴于 Apple 是这样构建这套机制的。~/Library/Messages/ 被放在完全磁盘访问权限的门槛之后，而且没有一个更窄的「Messages 访问」权限可供第三方应用申请。Apple 为桌面、文稿、下载、iCloud Drive 和可移动卷提供了可按需申请的弹窗，但没有为 Messages 数据存储提供这样的弹窗。所以一个想读取你消息的应用，必须去申请那个宽泛的权限。设计上的局限在 Apple 这一边，后果却落在你身上。

Q: ChatGPT 应用的 Bundle ID 是什么？

com.openai.codex，出自我们检查的这个版本（版本号 26.727.40816，检查时间 2026 年 8 月 22 日），由 OpenAI OpCo, LLC 签名，团队 ID 为 2DC432GLL2。在把它用于任何 tccutil 命令之前，请用 osascript -e 'id of app "ChatGPT"' 在你自己的 Mac 上验证一遍。

Q: ChatGPT 的 Mac 应用有沙盒化吗？

没有。它的权限声明把 com.apple.security.app-sandbox 设为 false。它是一个以 Developer ID 签名、在 Mac App Store 之外分发的应用，在这种分发方式下沙盒化并非强制要求。再叠加上完全磁盘访问权限，这意味着在文件层面几乎不剩什么限制了。

OpenAI 的 Apple Messages 插件需要在你的 Mac 上获得完全磁盘访问权限、通讯录和自动化权限。本文解析每项权限实际授予了什么，以及如何审查它。

2026 年 8 月 20 日，OpenAI 为 macOS 版 ChatGPT 桌面应用发布了一个 Apple Messages 插件。它可以读取和搜索你的 iMessage、SMS 和 RCS 对话，并能代替你起草和发送消息。它在你的 Mac 上本地运行，使用 AppleScript 和 macOS 辅助功能 API，而不是把你的消息数据库上传到任何地方。

要启用它，你必须向 ChatGPT 授予三项 macOS 隐私权限：完全磁盘访问权限（Full Disk Access）、通讯录（Contacts）和针对 Messages 应用的自动化（Automation）。

后两项是范围受限的。第一项不是，而这正是本文要讲的全部内容。完全磁盘访问权限不是一项「Messages 权限」。它是一项能几乎移除 macOS 全部文件级隐私边界的权限——对这一个应用而言，永久生效，直到你撤销为止。一旦 ChatGPT 拥有了它，让它能读取 chat.db 的同一项授权，也能让它读取你的 Mail 数据、Safari 的历史记录和 Cookie、Time Machine 备份，以及机器上其他每一个应用的私有数据文件夹。

这不是 OpenAI 实现上的 bug，也不是对这项功能的批评。这是 Apple 设计这项权限的方式。但设置流程把它呈现为「以便 ChatGPT 读取你的 Messages」，而你以为自己在批准的东西，和你实际批准的东西之间的落差，值得在你点击之前先弄清楚。

关键要点

完全磁盘访问权限并不局限于 Messages。 它是一个单一开关，能让某个应用一次性豁免于大多数 TCC 文件保护。Mail、Safari、Time Machine 备份以及其他应用的容器数据都会随之变为可读。
ChatGPT.app 没有沙盒化。 我们检查了正式发布版本的权限声明（entitlements）：com.apple.security.app-sandbox 的值为 false。一个未沙盒化、又拥有完全磁盘访问权限的应用，在文件层面几乎没有剩余限制。
它的 Bundle ID 是 com.openai.codex，而不是 com.openai.chat。 如果你想从 Terminal 重置它的权限，这才是你需要的标识符；用错了不会重置任何东西——或者更糟，会重置你 Mac 上每一个应用的该项权限。
自动化才是「发送」权限。 ChatGPT 自己的用途说明字符串写的是「ChatGPT uses Apple Events to control Mac apps on your behalf」（ChatGPT 使用 Apple Events 代表你控制 Mac 应用）。真正驱动 Messages 的正是它。
真正的风险在于组合，而不是插件本身。 PCWorld 的实测发现，当插件本身无法完成任务时，ChatGPT 会回退到一项此前已启用、且被用户遗忘的电脑操作（computer-use）能力，并在 Messages 窗口里点击「删除」按钮。没有任何东西被攻破；只是两项分别被授权的功能凑到了一起。
你可以在大约两分钟内审查并撤销这一切。 具体步骤见下文，包括如何从 Terminal 验证撤销是否生效。

OpenAI 发布了什么

这个插件出现在 ChatGPT 桌面应用的「插件」标签页中。根据 OpenAI 的说明以及发布时的媒体报道，它在 macOS 应用的所有 ChatGPT 套餐中都可用，并且在 ChatGPT Work 和 Codex 场景中同样生效。它仅支持 Apple 芯片——Intel Mac 拿不到这项功能。

功能上它做四件事：

读取你的 Messages 对话。
搜索这些对话。
为某个收件人起草一条消息。
通过 Messages 发送这条消息。

OpenAI 在发布时通过发言人表态的隐私立场是：这个插件不会为你的短信建立索引，并且你必须明确提示 ChatGPT 才会让它去读取某个对话串的上下文。默认情况下，发送会受到一个批准步骤的限制：ChatGPT 会向你展示消息内容和收件人，由你确认。

有一个选项可以让这个批准在某个对话中变成持久性的（即免确认）。OpenAI 自己建议不要这么做，措辞在产品设置说明中显得异常坦诚——启用它会「移除你在 ChatGPT 发送消息前的最后一次审阅机会」。

不妨认真对待这句话。一个厂商告诉你不要用它自己做出来的便利开关，说明它已经想清楚了当模型误读一段对话时会发生什么。

三项权限，以及每一项真正做了什么

macOS 通过 TCC（Transparency, Consent and Control，透明度、同意与控制）来管理这一切——它是 System Settings 中每一个隐私与安全面板背后的子系统。我们在为什么你的 Mac 一直在请求屏幕录制权限一文中写过 TCC 的完整机制指南，那里的模型在这里同样适用。简而言之：TCC 条目绑定的是应用的代码签名身份，而不是它的路径或名字，且每一项受保护的能力都是独立的服务、拥有各自的授权。

通讯录：范围小、行为规矩

这一项确实如其名所示。它让 ChatGPT 能把「给 Sarah 发消息」解析成一个电话号码或 Apple 账户。Apple 的通讯录权限只作用于通讯录数据存储，别无其他。如果你担心自己的通讯录会离开这台机器，那是一个值得向 OpenAI 询问其数据处理方式的真实问题——但这不是一个关于 macOS 权限的问题，因为这项权限本身授予的正是它名字所写的东西。

自动化：发送路径

自动化权限才是真正让 ChatGPT 能够操作 Messages 的东西。它授权该应用向另一个应用发送 Apple Events——这正是 AppleScript 用了三十年的同一套机制。

我们在一台 Mac 上检查了正式发布的 ChatGPT 版本（版本号 26.727.40816，检查时间 2026 年 8 月 22 日），它的 Info.plist 中一字不差地声明了这条用途说明字符串：

NSAppleEventsUsageDescription = "ChatGPT uses Apple Events to control Mac apps on your behalf"

它的代码签名权限声明中包含：

com.apple.security.automation.apple-events => true

注意 Apple 自己弹窗里的措辞，以及 OpenAI 这条字符串里的措辞：control Mac apps，是复数。自动化权限是按目标应用逐一授予的——你批准的是「ChatGPT 想要控制 Messages」，而这与「ChatGPT 想要控制 Finder」是分开批准的——所以在实践中它是受限的。但它受限的方式是「按你批准过的每个应用」，而每一次新的批准都是一个你会忍不住随手点掉的弹窗。不妨偶尔去 System Settings → Privacy & Security → Automation 看看这份名单已经长成什么样子了。

完全磁盘访问权限：不受限的那一个

问题的核心在这里。

macOS 系统设置隐私与安全面板

Apple 的平台安全文档直白地描述了这项权限的设计意图：用户「应当对应用如何使用他们的数据拥有完全的透明度、知情权和控制权」，文件访问被拆分成若干类别——桌面、文稿、下载、iCloud Drive、可移动和网络卷——应用可以通过一次提示分别请求其中某一类。完全磁盘访问权限不一样。 它是应用无法通过弹窗申请的那一类。你必须手动进入 System Settings 把该应用加进去，正因为它比其他类别宽泛得多。

它所覆盖的，是 macOS 无论 Unix 文件权限如何设置、都要对普通应用加以保护的一整套位置。其中包括，但不限于：

~/Library/Messages/ —— Messages 数据库 chat.db 及 Attachments 文件夹
~/Library/Mail/ —— Mail 的数据存储
Safari 的 Cookie 和历史记录数据
Time Machine 备份内容
其他应用受保护的容器数据
TCC 数据库本身（只读；详见下文）

你可以用一条命令在自己的 Mac 上验证这条边界。在一个没有被授予完全磁盘访问权限的 Terminal 中：

ls -la ~/Library/Messages/

在一台未做特殊配置的 Mac 上，这会返回：

ls: /Users/you/Library/Messages/: Operation not permitted

不是「Permission denied」，而是「Operation not permitted」（操作不被允许）。这是 TCC 在拒绝，而不是文件系统在拒绝。我们在撰写本文时，在 macOS 26.5.2（构建版本 25F84）上原样跑了这条命令，得到了同样的结果。现在给 Terminal 授予完全磁盘访问权限，再运行一次：目录内容列出来了。文件的所有者或权限模式没有任何变化。唯一变化的是，这一个进程现在被豁免了这项保护。

这才是你交给 ChatGPT 的东西。不是「读取 Messages」，而是豁免于这项保护。

而且它没有沙盒化

通常还有第二层机制会约束一个 Mac 应用，即便它已经拿到了宽泛的 TCC 授权：App Sandbox（应用沙盒）。一个沙盒化的应用被限制在自己的容器内，以及它的权限声明明确指名的具体资源内，且沙盒是由内核独立于 TCC 强制执行的。

我们检查过了。在我们检查的这个版本中，ChatGPT.app 的权限声明里包含：

com.apple.security.app-sandbox => false

同时还有：

com.apple.security.cs.allow-jit => true
com.apple.security.cs.allow-unsigned-executable-memory => true
com.apple.security.network.client => true

该应用以 Developer ID（Developer ID Application: OpenAI OpCo, LLC，团队 ID 2DC432GLL2）签名，并在 Mac App Store 之外分发——在那种分发方式下，沙盒化并非强制要求。对于一个带有自动化野心的桌面应用来说，这完全正常——你没法从一个严格的沙盒内部去驱动其他应用。allow-jit 和 allow-unsigned-executable-memory 这类例外，在类 Electron、使用 JIT 的运行时中也很常见。

但这种组合本身值得注意。一个未沙盒化、又拥有完全磁盘访问权限的应用，是非 root 进程在 macOS 上所能拥有的、接近上限的文件读取权限。 如果你在评估任何其他厂商的工具时看到这样的权限画像，你会想知道它为什么需要这些权限。在这里也应当用同样的标准。

你可以自己验证以上全部内容：

codesign -dv --verbose=2 /Applications/ChatGPT.app
codesign -d --entitlements - --xml /Applications/ChatGPT.app | plutil -p -

权限声明会随版本变化。我们的检查结果读取自 2026 年 8 月 22 日的版本 26.727.40816；请检查你自己的构建版本，而不要直接相信文章里的某个数字。

Bundle ID 陷阱

这是本文中最具实用价值的部分，也是我们没有在其他地方见过被公开报道的细节。

ChatGPT 桌面应用的 Bundle ID 是 com.openai.codex。不是 com.openai.chat，也不是 com.openai.chatgpt。它的 application-identifier 权限声明读作 2DC432GLL2.com.openai.codex，它的 application groups 分别叫 2DC432GLL2.com.openai.codex.notifications 和 2DC432GLL2.com.openai.sky.CUAService。

在你自己的机器上确认这一点：

osascript -e 'id of app "ChatGPT"'

或者：

mdls -name kMDItemCFBundleIdentifier /Applications/ChatGPT.app

这为什么重要：tccutil 是唯一能操作 TCC 的命令行工具，它唯一的动词是 reset，语法是：

tccutil reset SERVICE [BUNDLE_ID]

如果你省略了 Bundle ID，它会为你 Mac 上的每一个应用重置这项服务。 不带标识符运行 tccutil reset SystemPolicyAllFiles，会把完全磁盘访问权限从你的备份软件、磁盘工具、杀毒软件以及所有拥有该权限的应用身上一并剥离。那会是真正糟糕的一个下午。

而如果你猜错了标识符，你得到的是一个错误，而不是静默的无操作——tccutil 会先校验 Bundle ID，再校验服务名——但人们实际遇到的失败模式，是从某篇博客里复制了一个错误的标识符，然后误以为重置「没起作用」。请从你自己的机器上获取这个标识符。

真正的风险在于组合

发布当周最有启发意义的报道，其实根本不是关于这个插件的权限。

在 2026 年 8 月 21 日发表于 PCWorld 的一篇文章中，一名评测者测试了这个插件：让 ChatGPT 总结对话、起草消息，然后删除一些垃圾对话串。删除消息并不是 Messages 插件的能力之一。ChatGPT 没有拒绝，而是回退到了作者此前启用、并已经遗忘的一项电脑操作（computer-use）能力。作者眼看着 ChatGPT 界面里出现了真实 Messages 窗口的截图，助手一边移动指针，一边点击了那些垃圾对话上的「删除」按钮。

作者自己的表述是准确的：ChatGPT「没有越界」。没有任何东西被攻破。涉及的每一项能力都是曾被授予过的。问题在于两项分别看起来合理的授权——「你可以读取我的 Messages」和「你可以控制我的屏幕」——组合出了一种任何一项授权本身都没有描述过的行为。

我们此前发现的那个 application group，名为 2DC432GLL2.com.openai.sky.CUAService，与「一个电脑操作代理服务被打包进了同一个应用」这一情形是吻合的。我们并不是在断言正是这个 group 驱动了那些点击；我们只是在指出，这项能力和你正在授予完全磁盘访问权限的那个进程，生活在同一个进程里。

Jonny Evans 在 Computerworld 上于同一天提出了一个互补的观点：ChatGPT 这个应用本身会变成一个攻击目标。一个拥有完全磁盘访问权限的应用，是一件高价值的攻击对象，因为攻破它就等于继承了这项授权。他更宏观的论点，是我们也愿意署名认可的：技术上获取到的同意，并不等同于知情的同意。一个写着「完全磁盘访问权限」、旁边配着一段关于 Messages 的说明的勾选框，在技术上是准确的，在实践中却是误导性的。

如果你想了解在本地运行 AI 工具、并留意它们能触及什么这一更宏观的图景，可以看看我们的Mac 本地 AI 应用隐私指南。

「本地运行」并不代表大多数人所理解的那个意思

这个说法在发布相关的报道中承担了很多分量，值得拆开来看，因为它同时是真的，又很容易被误读。

本地运行的是什么： 文件访问。插件在你的 Mac 上读取 chat.db，在你的 Mac 上使用 AppleScript 和辅助功能 API。你的整个消息数据库不会作为一次批量导出被上传给 OpenAI，OpenAI 也表示不会为它建立或保留索引。

不是本地运行的是什么： 模型。ChatGPT 是一个云端服务。当你要求它总结一段对话时，那段对话的内容会被发送到 OpenAI 的服务器上去做总结，因为这类总结工作只能在那里完成。这里没有一个设备端模型在做这份工作。

所以准确的心智模型不是「你的消息一直留在你的 Mac 上」，而是**「你的消息一直留在你的 Mac 上，直到你就它们提出一个问题，相关的那部分才会离开」**。相比一个持续上传并为一切建立索引的后台服务，这是一种确实更好的隐私姿态——真心如此，OpenAI 在这样设计上值得肯定。但这不等同于设备端处理。

这个区分很重要，因为 macOS 对某些同类任务确实拥有设备端处理能力。Apple Intelligence 的摘要功能对一组明确定义的操作在神经网络引擎上运行，其余部分则依靠 Private Cloud Compute。如果你的要求是「消息内容在任何情况下都不能离开这台机器」，那属于另一个产品类别，我们关于在 Mac 上本地运行 AI的指南介绍了目前真正意义上的设备端选项是什么样子。如果你的要求是「不要在某台服务器上为我的生活建立一份永久可搜索的副本」，那么这个插件的设计已经满足了这一点。

人们常问的相关问题——消息内容是否被用于训练——是一个 ChatGPT 账户设置层面的问题，而不是 macOS 层面的问题，它受你所在套餐适用的数据管控规则约束。请直接检查那些设置，而不要从插件的描述里推断。

如果你在为一个组织管理多台 Mac

以上所有内容，对个人而言是一个自主决定。在受管理的 Mac 上，它是一个策略决定，而 macOS 提供了一种方式，让你能在任何人点击任何东西之前就把这个决定定下来。

完全磁盘访问权限可以通过 MDM 治理。 隐私偏好策略控制（Privacy Preferences Policy Control，简称 PPPC）负载能让你为特定应用（以 Bundle ID 和代码要求来标识）预先批准或明确拒绝特定的 TCC 服务。对应完全磁盘访问权限的服务名是 SystemPolicyAllFiles；Apple Events 自动化是 AppleEvents；辅助功能是 Accessibility；屏幕录制是 ScreenCapture。

在你编写配置描述文件之前，有三点值得了解：

在这里，「拒绝」比「允许」更可靠。 一个拒绝某项服务的 PPPC 负载，会阻止用户在 System Settings 里自行授予该服务。如果答案是「不行」，这才是你想要的那种控制方式。
正确识别这个应用。 在我们检查的这个版本上，Bundle ID 是 com.openai.codex，团队标识符是 2DC432GLL2。你的代码要求（code requirement）应当把两者都钉死——一个只以显示名称为键的负载，起不到你想要的效果。
屏幕录制和辅助功能，才是电脑操作能力所在的那个面。 如果你担心的是一个 AI 代理在驾驭一台受管理的 Mac，仅仅拒绝 SystemPolicyAllFiles 并不能解决这个问题。Accessibility 和 ScreenCapture 是独立的服务，需要单独的条目。

此外还有一个完全在 macOS 之外的数据治理问题：一次经过批准的企业级 ChatGPT 部署，在读取用户的 Messages 数据库时，会把个人对话和工作对话一并拉进来，因为 chat.db 并不区分两者。这值得在它演变成一次事故之前，和你团队里负责可接受使用策略（acceptable-use policy）的人一起提出来讨论。我们的macOS 企业部署指南介绍了配置描述文件方面更一般的机制。

如何审查你已经授予的权限

无论你是否使用这个插件，都建议做一遍这件事。它只需要两分钟，而且适用于每一个应用，不只是这一个。

1. 完全磁盘访问权限

System Settings → Privacy & Security → Full Disk Access。

把整份名单读一遍。对每一条，问自己一个问题：这个应用要完成它的工作，真的需要读取我 Mac 上每一份受保护的文件吗？ 备份工具确实需要。磁盘分析工具确实需要。如果你用 Terminal 做系统管理，它确实需要。大多数其他东西并不需要，而那些多年前因为某个一次性理由就被授予了这项权限的应用，往往还在原封不动地持有它。

把你无法给出理由的那些关掉。这不会造成永久性的功能损坏——如果应用再次需要它，会重新弹窗询问。

2. 自动化

System Settings → Privacy & Security → Automation。

这个面板的组织方式是「控制方应用 → 它可以控制的应用列表」。展开 ChatGPT，看看它下面挂着什么。如果列表里有 Messages，那就是这个插件在起作用。如果列表里还有 Finder、System Events、Terminal 或 Safari，那说明自动化面比这更宽，你应该弄清楚它们为什么在那里。

3. 辅助功能

System Settings → Privacy & Security → Accessibility。

这项权限是合成点击和按键背后的机制——正是一个电脑操作功能所需要的机制。如果某个应用出现在这份名单里，说明它可以驱动你 Mac 的界面。检查 ChatGPT 是否在里面，如果你不想让这项能力处于随时可用的状态，把它移除。

4. 屏幕与系统音频录制

System Settings → Privacy & Security → Screen & System Audio Recording。

一个电脑操作代理需要看到屏幕，才能对屏幕采取行动。如果 ChatGPT 出现在这份名单里，PCWorld 报道中出现的那些截图正是来自这里。

在 macOS 上审查应用权限

5. 从 Terminal 验证

权限面板有时会「骗」你——一个应用可能在 System Settings 里显示为已授权，但授权实际上已经失效，通常是因为这个应用的代码签名发生了变化。可靠的检查方式是行为验证。撤销某个应用的完全磁盘访问权限后，把这个应用彻底退出，重新打开它，让它去做那件需要该权限的事情。如果它再次弹窗询问你，说明撤销生效了。

你也可以在一个没有完全磁盘访问权限的 Terminal 里，用同样的方式笼统地确认这条边界：

ls ~/Library/Messages/ 2>&1

「Operation not permitted」意味着 TCC 正在为那个进程尽职地拦截。

如果你还是想用这个插件

这是一个正当的选择，而且在「什么都授权」和「碰都不碰」之间，存在一个中间立场。

保留发送前的批准。 不要为某个对话开启持久性批准，哪怕是你经常发消息的那个对话也不要。OpenAI 已经告诉了你原因。

单独检查一下电脑操作能力是否已启用。 这是另一项功能，有另一个开关。如果你不需要 AI 移动你的指针，把它关掉，并把这个应用从「辅助功能」和「屏幕录制」名单中移除。

把完全磁盘访问权限当成可撤销的，而不是永久性的。 如果你只是偶尔使用 Messages 插件，完全没有理由不在两次使用之间把完全磁盘访问权限关掉。这只是一个开关。插件会停止工作，等你再把开关拨回去，它就又能用了。

考虑用哪台 Mac。 如果你有不止一台，这个插件不必装在那台存着你的工作 Mail 数据、密码管理工具备份、以及八年 Time Machine 快照的机器上。

想一想对话的另一端。 每一个曾经给你发过短信的人都在那个数据库里，而他们对此毫不知情，也没有同意过任何东西。这不是一个 macOS 问题，也没有哪个权限设置能解决它。但它仍然值得花点时间想一想。

不要把完全磁盘访问权限授予一个你不是自己从可信来源下载的应用。 一个理由不明地索要完全磁盘访问权限的安装程序，是恶意软件在 macOS 上能提出的、杠杆效应最高的请求，这正是我们在伪造崩溃报告密码提示一文中报道过的窃密软件家族背后的套路。

常见问题排查

插件没有出现在「插件」标签页里

按顺序检查三件事。第一，你使用的是 Apple 芯片 Mac——这个插件不面向 Intel Mac 提供。第二，ChatGPT 桌面应用是最新版本；一个在 8 月构建中才上线的功能，不会出现在一个来自春天的旧构建里。第三，你确实是在 ChatGPT 桌面应用中，而不是浏览器里的网页版——一个浏览器标签页无法持有 macOS 隐私权限。

我已经授予了完全磁盘访问权限，但 ChatGPT 仍然读不到 Messages

把 ChatGPT 彻底退出——用 Command-Q，而不只是关闭窗口——然后重新打开它。TCC 授权是在进程启动时才生效评估的。一个正在运行、此前被拒绝过的进程，会在它的整个生命周期内一直保持被拒绝的状态。

如果这样还没解决，你可能碰上了代码签名身份的问题：如果这个应用在授权之后被更新或移动过，System Settings 里的条目看起来可能是正确的，实际却指向了一个不同的签名。把这个应用在「完全磁盘访问权限」里关掉，用减号按钮移除它，退出，重新打开，再重新添加一次。我们的TCC 故障排查指南介绍了一项权限「显示已授权却不起作用」背后的五种不同成因。

ChatGPT 每次都要请求控制 Messages

那是自动化权限没有「粘住」，而原因几乎总是同一个代码签名身份问题。检查 System Settings → Privacy & Security → Automation，展开 ChatGPT，确认 Messages 一项是打开的。如果它已经打开，却还在弹窗询问，就单独重置那一对配对：

tccutil reset AppleEvents com.openai.codex

然后再批准一次弹窗。注意这个 Bundle ID——参见上文关于为什么随便猜它是个坏主意的部分。

我想撤销我给它的每一项权限

完整重置，使用正确的 Bundle ID：

tccutil reset All com.openai.codex

这只会清除这一个应用的全部 TCC 授权。之后请退出并重新打开 ChatGPT。然后在 System Settings 中确认，完全磁盘访问权限、自动化、辅助功能和屏幕录制中都不再列出它。tccutil 无法授予任何权限，只能重置，所以没有办法从 Terminal 撤销这个操作——你需要重新走一遍正常的弹窗流程去重新批准。

我没有批准过的消息被发出去了

检查是否为那个对话开启了持久性批准。在 ChatGPT 界面中，找到那个能跳过确认的、按对话设置的选项。把它关掉。如果你找不到能解释这一情况的设置，就撤销 Messages 的自动化权限——这会完全移除发送这条路径，同时保留读取能力，如果你只想要摘要功能，这是一个合理的配置。

常见问题

ChatGPT 会把我的 Messages 上传到 OpenAI 的服务器吗？

OpenAI 表示这个插件在你的 Mac 上本地运行，且不会为你的短信建立索引。被发送出去的，是你提示它使用的那部分上下文——如果你要求它总结一段对话，那段对话的内容就会被发送给模型去做总结，因为这就是一个云端模型的工作方式。「本地运行」描述的是文件访问发生在哪里，而不是推理发生在哪里。如果你要求消息内容永远不能离开这台机器，这项功能不是为此设计的。

仅仅为了读取 Messages，真的有必要用到完全磁盘访问权限吗？

是的，鉴于 Apple 是这样构建这套机制的。~/Library/Messages/ 被放在完全磁盘访问权限的门槛之后，而且没有一个更窄的「Messages 访问」权限可供第三方应用申请。Apple 为桌面、文稿、下载、iCloud Drive 和可移动卷提供了可按需申请的弹窗，但没有为 Messages 数据存储提供这样的弹窗。所以一个想读取你消息的应用，必须去申请那个宽泛的权限。设计上的局限在 Apple 这一边，后果却落在你身上。

ChatGPT 应用的 Bundle ID 是什么？

com.openai.codex，出自我们检查的这个版本（版本号 26.727.40816，检查时间 2026 年 8 月 22 日），由 OpenAI OpCo, LLC 签名，团队 ID 为 2DC432GLL2。在把它用于任何 tccutil 命令之前，请用 osascript -e 'id of app "ChatGPT"' 在你自己的 Mac 上验证一遍。

ChatGPT 的 Mac 应用有沙盒化吗？

没有。它的权限声明把 com.apple.security.app-sandbox 设为 false。它是一个以 Developer ID 签名、在 Mac App Store 之外分发的应用，在这种分发方式下沙盒化并非强制要求。再叠加上完全磁盘访问权限，这意味着在文件层面几乎不剩什么限制了。

ChatGPT 能删除我的消息吗？

Messages 插件已记录在案的能力是读取、搜索、起草和发送。删除并不在其中。不过，PCWorld 的实测发现，当被要求删除消息时，ChatGPT 使用了一项单独启用的电脑操作能力，去点击 Messages 界面里的「删除」按钮，从而完成了这件事。如果你没有启用电脑操作能力，这条路径就不存在。如果你启用了，它就存在。

这在 Intel Mac 上能用吗？

不能。这个插件仅支持 Apple 芯片。如果你还在用 Intel Mac、正在权衡自己的选择，我们的Intel Mac 时代终结指南介绍了更宏观的图景。

我应该使用它吗？

这取决于你 Mac 上有什么，以及你能从中获得什么。诚实的表述是：你在用「一个未沙盒化、联网、由云端支撑的应用永久拥有对这台机器上每一份受保护文件的读取权限」，去换取消息摘要和起草这两项能力。如果这笔交易对你来说值得，就采纳本文中的缓解措施——保留发送前的批准、除非你确实需要否则保持电脑操作能力关闭、并在不使用这项功能时撤销这项权限。如果不值得，你除了少了一点便利，什么也不会损失。

结论

这篇文章本可以写成一篇「恐吓文」，但它不是。OpenAI 以一种站得住脚的方式构建了这项功能：文件访问部分在设备端进行，不持久化建立索引，默认将发送锁在一个明确的批准步骤之后，并且告诉你不要关掉这道闸门。这些都是比其他替代方案更好的选择。

问题出在 OpenAI 的上游。macOS 没有一项权限的含义是「你可以读取 Messages」。它有的是一项含义为「你可以读取一切」的权限，而任何想要前者的应用，都不得不去申请后者。于是用户一边阅读着关于那个「窄」的说明，一边批准了那个「宽」的权限——这正是 Computerworld 所指出的那个知情同意的落差，也正是 Apple 本可以补上的那道缺口：像它为通讯录、日历和照片所做的那样，为 TCC 添加一项范围受限的 Messages 服务。

在那发生之前，弄清楚这个开关到底做了什么，负担落在你身上。现在你已经知道了。去看看你的完全磁盘访问权限名单吧——不是因为 ChatGPT，而是因为你几乎肯定会在里面发现某个你在 2023 年授予、后来彻底忘记的东西。

来源： 9to5Mac，「ChatGPT update adds Apple Messages integration on Mac」，2026 年 8 月 20 日 · Computerworld，Jonny Evans，「ChatGPT wants Full Disk Access to your Mac and Messages」，2026 年 8 月 21 日 · PCWorld，「I gave ChatGPT access to Apple Messages. Then it took control of my Mac」，2026 年 8 月 21 日 · Engadget，「ChatGPT on Mac can now read and respond to Apple iMessages」，2026 年 8 月 · Apple，「Controlling app access to files in macOS」，Apple Platform Security · 本地验证基于 macOS 26.5.2（构建版本 25F84）与 ChatGPT.app 26.727.40816，2026 年 8 月 22 日，使用 codesign、plutil 和 ls。