macOS 完整磁碟取用權限與 AI 代理：Apple 說了什麼

Apple 對完整磁碟取用權限說了什麼？這對 AI 代理又代表什麼？ 2026年10月2日，Apple 發布一則簡短的開發者新聞「Updates to Full Disk Access in macOS」（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 的沙盒執行環境內也再次成功，只有在沙盒規則明確拒絕那個資料夾，或我在終端機之外啟動同一個讀取時，才遭到拒絕。⁵

重點摘要

• Apple 說了什麼。 2026年10月2日，Apple 告訴開發者，它「will introduce additional controls」（將推出額外的控制），讓授予完整磁碟取用權限需要「very explicit user action」（非常明確的使用者操作），並點名 AI 代理是風險「will grow substantially」（將大幅增加）的原因。這則新聞沒有給出版本、日期或機制。macOS 27.2 beta 3 的版本說明中沒有任何相關條目。我在10月11日的版本發布 RSS 動態與版本說明索引中都找不到 macOS 27.1 的項目：動態列出 macOS 27.0.1（9月28日），該版本發布時沒有開發者版本說明，接著是 macOS 27.2 beta 3；27.2 的 beta 本身則從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」是它特別點出、會傷及他人的類別。 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 的項目；動態列出日期為9月28日的 macOS 27.0.1（26A434），接著是 27.2 beta 3。27.0.1 更新沒有開發者版本說明頁面；我嘗試這類頁面會使用的網址時，回傳 HTTP 404，27.1 與 27.1 beta 的網址也一樣。⁸⁷ 27.2 beta 3 的說明（這個 beta 的組建編號為 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）>「隱私權與安全性」中的一列。Apple 的 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），並說 App 可以「To direct the user to the Full Disk Access section in System Settings」（為了把使用者導向「系統設定」中的完整磁碟取用權限區段），在 macOS 13 及更新版本上開啟 x-apple.systempreferences:com.apple.settings.PrivacySecurity.extension?Privacy_AllFiles。²⁵ Apple 在 WWDC19 描述過同樣的模式：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」（一個能提示已登入使用者授予 App 完整磁碟取用權限的 API 呼叫，因為目前無法觸發這種提示，而這正是備份 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 的「隱私偏好設定原則控制」承載資料及其服務字典鍵值 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 論壇上指出這是早期 beta 中的名稱：³⁵「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.」（除非 App 被加入「系統偏好設定」>「安全性與隱私」的「隱私」標籤頁中的 Application Data 類別，否則無法存取受保護的儲存空間。）⁴¹ 裝置管理承載資料及其 SystemPolicyAllFiles 鍵值都標示為在 macOS 10.14 推出，而 Apple 支援工程師的貼文也列出「Full Disk Access (macOS 10.14 and later)」。³⁶²⁰

有一個 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 在存取使用者文件前先取得許可），而 Apple 在 WWDC19 把「桌面」、「文件」與「下載項目」資料夾、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 在 System Preferences > Security & Privacy > Privacy > Full Disk Access 中獲得完整磁碟取用權限授權。）²
• 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 的 Terminal 應用程式。）⁴³
• 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 Developer Technical Support 的工程師 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 擁有完整磁碟取用權限，而此程式在 Terminal.app 中建置並執行時，檔案能順利開啟。反之，當從 Terminal 撤銷完整磁碟取用權限、改授予該程式時，就會因權限不足而發生錯誤。）³ 這是開發者的報告，不是 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 腳本，而這些腳本執行時用的不是開啟它的 App 的權限，而是 Terminal 的權限，也就是完整磁碟取用權限。）他也指出，這項技巧「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），Cursor 就是 TCC 為這些命令看到的 App。這是我的推論；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 自動化權限）。¹³ 這是廠商的指示，要把完整磁碟取用權限給終端機，也就給了在其中執行的一切。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」（必須停用系統完整性保護），而基本的收發不需要這樣做。¹⁴ 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，且授予在更新後仍然保留。）⁵¹ 對於電腦操作功能，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 中執行的命令能控制其他 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.」（命令 hook、本機 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 上，執行 2（read-only）與執行 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。 Seatbelt 涵蓋「the full subprocess tree」（整個子行程樹）；網路「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 hook。）⁶⁸ 針對 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 上：誰擁有完整磁碟取用權限，以及我如何得知

本節所有內容都是我在自己的 Mac 上所做的量測，於2026年10月11日從一個 Claude Code 工作階段進行：macOS 27.0，組建編號 26A428，系統完整性保護已啟用。除了兩項之外，所有命令都是唯讀的：一項測試提交了一個 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年，有人問 Apple 支援工程師，為何某個工具自己的授予只在 Xcode 執行它時才生效，他回答「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（執行 2b），所以沙盒確實在運作；它只是不會在那裡阻擋讀取。使用我自己的 Codex 設定（未設定沙盒模式並開啟網路存取）時，讀取同樣回傳該列（執行 2c）。
3. 在 Anthropic 的 sandbox-runtime 0.0.79 內，也就是 Claude Code 沙盒所依據的套件，沒有讀取拒絕（執行 3a）：讀取回傳該列，而在允許資料夾之外的寫入遭到拒絕，一個網路請求也失敗了（curl 結束代碼 56；紀錄沒有顯示原因）。把 denyRead 設在 TCC 資料夾上（執行 3b）時，讀取以「authorization denied」失敗。
4. 對照組。 同樣的 sqlite3 讀取，以 launchd 工作提交，使 Ghostty 與 Claude Code 都不在其啟動鏈中的任何位置：「authorization denied」。⁵

正是這個對照組讓其餘結果有了意義。資料庫檔案的擁有者是 root，依其權限模式人人可讀（-rw-r--r--），因此拒絕執行 4 的不是檔案權限，而是 TCC。¹⁹⁵ 同一個二進位檔、同一個檔案、同一個使用者，從代理的 shell 成功，在它之外失敗。代理的 shell 所擁有的，是從其啟動鏈得來的。支援工程師的規則把終端機指為這條鏈的負責程式碼。³ 有一項但書是我無法用這些資料排除的：這條鏈中也有一個 claude 行程，而 Claude Code 二進位檔也被列出；在執行 3a 與 3b 中，執行沙盒執行環境的是一個 node 行程，而 Homebrew 的 node 也被列出，只是 npx 用的是哪個 node 並未記錄。我的量測顯示存取來自這條鏈，支援工程師的規則說是終端機；它並沒有另外證明 TCC 使用的是 Ghostty 那一列，而不是 Claude Code 或 node 的某一列。Apple 的支援工程師說，這個演算法沒有文件記載。³

執行 3b 與執行 4 印出完全相同的錯誤，儘管拒絕它們的是不同的層。在代理輸出中看到「authorization denied」的操作者，無法從訊息判斷是沙盒還是 TCC 說了不。⁵

在您自己的 Mac 上試試

從您的代理所用的 shell 執行以下命令，當該 shell 的啟動鏈擁有完整磁碟取用權限時，它會印出完整磁碟取用權限清單。當啟動鏈沒有這項權限，或沙盒規則拒絕該資料夾時（如執行 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 執行第5節的查詢，若該 shell 已有此存取權，就會印出清單，這同時也測試了您代理的 shell 是否擁有它；失敗也可能來自拒絕該資料夾的沙盒規則，如執行 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 可用來追蹤的獨立程式。）²⁰ 直譯器自己的列，在直譯器是負責程式碼的任何地方都會生效，例如以 launchd 工作執行、且沒有關聯 App 的腳本；這時以這種方式透過該直譯器啟動的每個 Python 或 Node 腳本，包括 MCP 伺服器，都會得到完整的授予。³² 代價：對真正需要這項存取的腳本，他的「easiest solution」（最簡單的解法）是把它封裝成 MAC 能追蹤的獨立程式，他說用 AppleScript 很容易做到，用 shell 腳本則不然。²⁰

5. 開啟廠商的沙盒，並拒絕不需要的讀取。 預設值的讀取範圍很廣，所以開啟沙盒是必要的，但並不充分。

• Claude Code：sandbox.enabled，接著設定 permissions.blockReadsOutsideWorkingDirectories（或 sandbox.filesystem.denyRead 規則），以及 "allowUnsandboxedCommands": false 來移除沙盒外重試。¹⁵ 請記得 Read 工具、hook 與 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 後端使用 bind mount，即「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 帳號與 macOS 使用者，讓機器人的流量與您個人的 Messages 設定檔隔離。）⁷¹ 把這個使用者設為標準帳號：Apple 說標準使用者「can install apps and change their own settings, but can’t add other users or change other users’ settings.」（可以安裝 App 並更改自己的設定，但無法加入其他使用者或更改其他使用者的設定。）⁷² 在我的 Mac 上，依檔案權限模式，我的使用者「資源庫」以及 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 自己的範例就是在「without prompting the user」（不提示使用者）的情況下，授予組織的 App 存取權。³¹

迴圈工程指南說明如何在無人看管下執行代理；當沒有人坐在鍵盤前閱讀提示時，上述每一步都更加重要。

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」（可能改變）的負責程式碼歸屬，或把新控制綁定到類似後代用戶端的機制。兩段文字都沒有說它會這麼做。

受管理的 Mac。 MDM 如今可以在不提示使用者的情況下授予完整磁碟取用權限。³⁷ 在 macOS 27 中，這個承載資料以 App 為單位的部分已被棄用，而其宣告式替代方案沒有完整磁碟取用權限的鍵值。³⁷³⁸ 條件：如果「very explicit user action」（非常明確的使用者操作）也適用於 MDM 授予，透過描述檔靜默授予就不再可能；如果不適用，受管理的 Mac 就保有靜默途徑。Apple 對這兩點都沒有表態，也沒有把 macOS 27 的棄用與10月2日的消息連結起來。

何時。 這則消息說「Going forward」（今後）。macOS 27.2 beta 3 的說明，對一個日期在它之後三天的 beta 而言，完全沒有提及，而我在10月11日的版本發布動態與版本說明索引中都找不到 macOS 27.1 的項目：動態列出 27.0.1（9月28日），接著是 27.2 beta 3，而 27.2 的 beta 是從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 beta 的說明，尋找相關條目。但 macOS 27.0.1 已經在完全沒有開發者版本說明的情況下推出，所以改變也可能出現在某個小版本更新中，而任何說明頁面上都沒有一行字。⁷⁸ 如果它們隨 macOS 28 推出，WWDC 講座或某個 beta 的版本說明，就是 Apple 以往描述這類改變的地方：WWDC19 說明了 Catalina 的保護措施，macOS 27 的說明則記載了今年的 TCC 棄用。¹¹²³ 無論答案為何，第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，它與完整磁碟取用權限是分開的。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 的 beta 本身則從9月16日開始。¹⁶⁷⁸⁹

資料來源