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」（今後、アプリにこの並外れたレベルのアクセスを本当に与えたいユーザーが、きわめて明示的なユーザー操作によってのみそれを行えるよう、追加の制御を導入する）ことが書かれています。挙げられた理由は「As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially」（AIエージェントの能力と自律性が高まるにつれ、このレベルのアクセスに伴うリスクは大幅に増す）です。¹ macOSのバージョン、日付、仕組み、アプリ名は一つも挙げていません。Macでエージェントを動かしている人にとって今日重要なのは、エージェントがどうやってこのアクセスを手にするかです。コマンドラインのエージェントは、それを起動したターミナルの下で動きます。私が読んだAppleのドキュメントには、これについての一般的な規則はありません。ただ、Appleのesloggerのmanページには、このツールを「from an app, including Terminal.app or a third-party terminal emulator, requires the respective app to be authorized for Full Disk Access.」（Terminal.appやサードパーティのターミナルエミュレータを含むアプリから実行するには、そのアプリにフルディスクアクセスが許可されている必要がある）と書かれています。² Appleのサポートエンジニアはフォーラムの投稿で、これを「The tool’s responsible code is Terminal.」（そのツールの責任コードはTerminalである）と表現しています。³ ターミナルにフルディスクアクセスを与えれば、その中で起動するすべてのエージェントが、ターミナルの読めるものを読めます。Appleの列挙によれば、Mail、Messages、Safariのデータ、そしてTime Machineのバックアップです。⁴ ベンダー各社のサンドボックスは、デフォルトではこれを変えません。私のMacでは、フルディスクアクセスを要する読み取りがエージェントのシェルから成功し、Codexのread-onlyサンドボックス内でもAnthropicのサンドボックスランタイム内でも再び成功しました。拒否されたのは、サンドボックスのルールがまさにそのフォルダを拒否したときと、同じ読み取りをターミナルの外で起動したときだけです。⁵

TL;DR

• Appleが述べたこと。 2026年10月2日、Appleは開発者に対し、フルディスクアクセスの許可に「very explicit user action」（きわめて明示的なユーザー操作）が必要になるよう「will introduce additional controls」（追加の制御を導入する）と伝え、リスクが「will grow substantially」（大幅に増す）理由としてAIエージェントを挙げました。告知にはバージョンも日付も仕組みもありません。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）の設定の一つで、アプリに「access all files on your computer」（コンピュータ上のすべてのファイルへのアクセス）を許すものです。Mail、Messages、Safari、ホームのデータ、Time Machineのバックアップ、そして「certain administrative settings for all users on this Mac」（このMacのすべてのユーザーに関わる特定の管理設定）も含まれます。アプリがこれを求めるプロンプトを出すことはできず、ユーザーが手作業でアプリを追加するか、MDMプロファイルが許可します。私が読んだ範囲では、Appleはこれを3度、バックアップツールやディスクツールと結びつけています。WWDC19、WWDC23、そして10月2日です。^410211121
• エージェントはどう手にするか。 経路は二つです。コマンドラインのエージェント（Claude Code、Codex CLI、Gemini CLI、Hermes Agent、Aider）は、それが動いているアプリに照らして判定されるので、フルディスクアクセスを持つターミナルはそれをエージェントに引き渡します。Appleはこれを、ツールごとにmanページで、またフォーラム上のサポートエンジニアを通じて述べているだけで、文書化された一般規則としては一度も述べていません。デスクトップのエージェントアプリは自分自身の項目を持ちます。そして二つのエージェントベンダー、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のアプリ、バージョン番号付きのClaude Codeバイナリ30個、nodeと四つのPythonインタープリタ、SSHサーバーの項目などです。Ghostty内のエージェントのシェルには実際に機能するアクセスがあり、上にターミナルを持たないlaunchdジョブからの同じ読み取りはTCCに拒否されました。¹⁹⁵
• 今すべきこと。 誰が持っているかを確認する。エージェントを動かすターミナルから外す。インタープリタには決して与えない。ベンダーのサンドボックスをオンにし、不要な読み取りを拒否する。Messagesを読むエージェントは別のmacOSユーザーで動かすか、まったく動かさない。自分として発言するものには送信ごとの承認を残す。以下の各ステップに、出典とコストを添えています。^420152122
• 何が変わりうるか。 Appleの言葉は、より厳格な許可フロー、より狭い範囲、あるアプリから起動したプログラムへ受け継がれる許可の扱いの変更、そして管理対象Macに対する変更を許容します。セクション7では、それぞれをmacOS 27とXcode 27でApple自身が行った隣接する変更に照らして読み、それぞれが依存する条件を示します。どれも予測ではありません。^1232425

1. Appleが10月2日に述べたこと、述べなかったこと

Appleの開発者ニュースフィードは、この告知の日時を2026年10月2日（金）09:00:19（太平洋時間）としています。10月1日の、期限を迎えるDeveloper ID認証局についての告知と、10月5日のiPhone DuoおよびApp Storeアセットの発表との間です。²⁶ 告知は2段落です。私は10月11日にこれを保存し、19分後にもう一度取得しました。カーリーアポストロフィか直線のアポストロフィかの違いを除けば二つのコピーは同一なので、2回の読み取りの間に変更はありませんでした。¹

第1段落は問題を提示します。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」（ユーザーのプライベートなデータを守るための一連の制御に裏打ちされた、Apple製品向けアプリにすばらしい機能を組み込むための強力なAPI）を提供していると述べ、続けてこう書きます。「Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac.」（フルディスクアクセスは、バックアップアプリが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.」（コミュニケーションアプリの場合、これはユーザーがやり取りしている相手のプライバシーも損ないうる）¹

第2段落は約束と理由です。全文を引用します。

「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.」（今後、アプリにこの並外れたレベルのアクセスを本当に与えたいユーザーが、きわめて明示的なユーザー操作によってのみそれを行えるよう、追加の制御を導入する。これへの対処は不可欠である。AIエージェントの能力と自律性が高まるにつれ、このレベルのアクセスに伴うリスクは大幅に増す。ユーザーが自分のデータとプライバシーについて十分な情報に基づいて判断できるよう、そのようなアクセスを許可する前にリスクを明確に理解できるようにすることに取り組む）¹

この中には、ゆっくり読む価値のある点が三つあります。

主語は許可であって、APIではありません。 約束の動詞はすべて、ユーザーがアクセスを許可する瞬間に関わるものです。「who genuinely wish to grant an app」（アプリに本当に与えたいと望む）ユーザー、「very explicit user action」（きわめて明示的なユーザー操作）、そして「before granting such access」（そのようなアクセスを許可する前に）リスクを理解すること。告知のどこにも、フルディスクアクセスの及ぶ範囲が狭まるとも、それを持つアプリが審査されるとも、それがなくなるとも書かれていません。解釈であることを明記したうえでの私の読みはこうです。この告知はスイッチをオンにする方法の変更を述べており、オンになったスイッチが何を解き放つかについては、どちらとも述べていません。

理由はエージェントですが、対象はアプリです。 Appleは「AI agents」（AIエージェント）に一度だけ、リスクが「will grow substantially」（大幅に増す）理由として触れています。今日このアクセスを悪用しているアプリがエージェントだとは言っていません。その文が語っているのは「Some developers」（一部の開発者）です。また、「an app」（アプリ）の許可に対する制御がどうやってエージェントに届くのかも述べていません。Mac上のエージェントは多くの場合、アプリですらなく、アプリの中で動くコマンドラインプログラムだからです。セクション3はまさにその隙間を扱います。

他者への害として取り上げられたカテゴリーは「communication apps」（コミュニケーションアプリ）です。 Appleはアプリも開発者も名指ししていません。告知が挙げるソフトウェアの種類は二つです。このアクセスが存在する理由としてのバックアップアプリと、ユーザー本人を越えた害、つまり会話の向こう側にいて何も許可していない人々への害と結びつけられたコミュニケーションアプリです。セクション3では、Messages連携にフルディスクアクセスが必要だと文書化されている二つのエージェントベンダーを示します。Appleがそのどれかを念頭に置いていたかどうかは告知には書かれておらず、私もそうだとは仮定しません。

この告知が述べていないこと

欠けているものに注目して読むと、告知には次のものがありません。

• macOSのバージョンも日付もない。 時を表す言葉は「Going forward」（今後）だけです。
• 仕組みがない。 プロンプトの設計、エンタイトルメント、API、App Reviewのルール、デバイス管理の変更、いずれもありません。
• 既存の許可への言及がない。 すでにフルディスクアクセスの一覧にあるアプリがその場所を保てるのか、ユーザーにもう一度確認が求められるのかは書かれていません。
• 管理対象Macへの言及がない。 現在MDMはフルディスクアクセスを許可できますが（セクション2）、MDMには触れていません。
• 開発者がすべきことがない。 期限も、ドキュメントへのリンクも、アプリが対応しなければならない日付もありません。

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日付け、つまり告知の3日後です）には六つのセクション（General、AppKit、Display Settings、Notifications、Shortcuts、StoreKit Testing in Xcode）があり、どれもフルディスクアクセス、TCC、プライバシーとセキュリティに触れていません。最も近いのは、ペーストボードのプライバシーに関する開発者プレビュー用のデフォルトが「has been removed」（削除された）というAppKitの1行です。⁶⁷ 告知の4日後に公開されたAppleの10月の開発者ニュースレターは、iPhone Duoの提出、ラボ、ドキュメントを扱っていて、フルディスクアクセスにもエージェントにも触れていません。²⁷ AppleがPrivacy & Securityに分類しているWWDC26の四つのセッションも、「Secure your app: mitigate risks to agentic features」という題のものを含め、フルディスクアクセスには言及していません。²⁸²⁹

エージェントとファイルアクセスに触れたAppleの文書は、ほかに一つだけ

AIエージェントのファイル権限に触れたAppleの文書が一つあり、それはmacOSではなくXcodeのものです。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の外のエージェントにも及ぶのかは書かれていません。同じノートには、「code-signed agents」（コード署名されたエージェント）がディレクトリツリー内のプロジェクトを「for extended periods of time without being asked for additional permissions」（追加の許可を求められることなく長時間）使えるようにするプレビュー版のMCPサーバーと、Appleが「is not a recommended configuration for at-desk use」（デスクで使う場合の推奨構成ではない）とするフラグ--unsafe-always-allow-all-agentsも記載されています。²⁴ どちらのエントリもフルディスクアクセスには触れていません。

WWDC26のエージェント機能のセッションは、私が読んだAppleの資料の中で、エージェントの脅威モデルに最も近いものです。そこでは「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）＞プライバシーとセキュリティにある1行です。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.」（他のアプリのデータ（たとえばMail、Messages、Safari、ホーム）、Time Machineバックアップのデータ、このMacのすべてのユーザーに関わる特定の管理設定を含め、コンピュータ上のすべてのファイルへのアクセスをアプリに許可する）⁴ 周囲の行は書き方が違います。カレンダー、連絡先、ファイルとフォルダ（Files & Folders）などほとんどの行は「The listed apps have requested access.」（一覧のアプリはアクセスを要求したもの）で終わります。フルディスクアクセスの行には、代わりに「To add an app, click [the Add button] , select the app in the list, then click Open.」（アプリを追加するには、追加ボタンをクリックし、一覧でアプリを選んで「開く」をクリックする）とあります。⁴ この違いこそが要点です。ほかの項目はアプリの側が求め、この項目はユーザーの側が探しに行くのです。

Appleプラットフォームセキュリティは、同じことを表で示しています。アプリによるファイルへのアクセスの制御を扱うページは、「Full internal storage access」（内蔵ストレージへのフルアクセス。同じ制御に対するこの文書での呼び名）を挙げ、「User prompted by app」（アプリがユーザーに確認を求める）の欄にバツ、「User needs to edit system privacy settings」（ユーザーがシステムのプライバシー設定を編集する必要がある）の欄にチェックを付けています。対照的に、ファイルとフォルダはアプリが確認を求めます。¹⁰ 管理者向けのデバイス管理リファレンスは、このサービスを「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.」（指定したアプリに、Mail、Messages、Safari、ホーム、Time Machineバックアップのデータや、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はtransparency、consent、controlの略）と述べ、サポートエンジニアの投稿は、TCCには「has no API surface」（APIの表面がない）と付け加えています。³²³³²⁰ 私のMacのTCC自身のデータベースでは、フルディスクアクセスの行はkTCCServiceSystemPolicyAllFilesというサービス名で保存されています。この文字列は、私が確認したAppleのドキュメント、manページ、SDKヘッダのどこにも出てきません。Appleが文書化している名前は、プロファイルのキーSystemPolicyAllFilesと、設定のアンカーPrivacy_AllFilesです。^19302534

どのように許可されるか

ユーザーが手作業で。 ユーザーはフルディスクアクセスの行を開き、追加をクリックし、アプリを選びます。⁴ アプリがこのためのプロンプトを出す方法を、Appleは何も文書化していません。代わりにAppleのドキュメントが示しているのは、ユーザーを正しいパネルへ連れて行くリンクです。Endpoint Securityクライアントとしてのエンタイトルメントを持つアプリ（ヘッダは、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,」（ユーザーをシステム設定のフルディスクアクセスのセクションへ誘導するには）アプリはmacOS 13以降でx-apple.systempreferences:com.apple.settings.PrivacySecurity.extension?Privacy_AllFilesを開けばよいとしています。²⁵ WWDC19でAppleは同じパターンを説明していました。アプリは「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で認可を確かめ、必要ならユーザーをセキュリティとプライバシーの環境設定パネルへ案内でき、ユーザーは望むならそこでアプリを承認できる）¹¹ 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呼び出し。今はそうしたプロンプトを出す方法がなく、それこそバックアップアプリに必要なものだ）を求めました。Appleのサポートエンジニアの返答は「Please do file an enhancement request.」（ぜひ機能改善の要望を提出してください）でした。³⁵ この記事のために私が読んだすべての資料で、8年後の今も、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のmanページははっきりこう述べています。「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を使って、フルディスクアクセスの認可を与えられる）²³⁶ アプリごとの項目の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.」（ユーザーに確認を求めることなく、組織のアプリがすべてのファイルを扱えるようにする）です。³¹ ここには明確な非対称があります。カメラ、マイク、画面収録、キーボード入力の監視については、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はアプリごとの部分を非推奨にした。 現行のリファレンスでは、フルディスクアクセスを含むすべてのサービス項目が使うIdentityオブジェクトがmacOS 27.0で非推奨と記され、そのキーの一つひとつに「Deprecated: macOS 27+」と書かれています。SystemPolicyAllFilesの項目そのものには非推奨の印はありません。³⁷³⁰ Appleがほかのサービスについて移行先として示す宣言型の後継、つまりアプリ設定の構成は、アクセシビリティ（Accessibility）、Bluetooth、カメラ、音声入力、ローカルネットワーク、位置情報、マイクのプライバシー既定値を提供します。フルディスクアクセスのキーはなく、その既定値は同意を前提としています。「When set, the app displays a consent prompt listing all the configured defaults.」（設定すると、アプリは構成されたすべての既定値を一覧にした同意プロンプトを表示する）³⁸³⁹ Appleはこれを10月2日の告知と結びつけておらず、私も結びつけません。話の隣にある事実です。

存在理由：3度とも挙げられたバックアップアプリ

フルディスクアクセスが誰のためのものかをAppleが述べている箇所を私は三つ見つけましたが、そのどれでも、Appleは同じ種類のソフトウェアを挙げていました。WWDC19では、保護されたデータの二つの階層を説明する中で、Appleは「things like mail or messages and Safari browsing history」（メール、メッセージ、Safariの閲覧履歴のようなもの）を第2階層に置き、これらは「have a high barrier to access because the files are typically only accessed by specialized apps such as disk management or backup utilities.」（そのファイルにアクセスするのは通常、ディスク管理やバックアップユーティリティのような専用アプリだけなので、アクセスの障壁が高い）と述べました。¹¹ WWDC23では、アプリコンテナの保護を紹介する中で「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.」（すでにフルディスクアクセスを許可されたバックアップユーティリティやディスク管理ツールについては、ユーザーがすでにすべてのファイルへのアクセスを認めているので、アクセス時に追加のプロンプトは表示されない）と述べました。¹² そして10月2日には、フルディスクアクセスがデータの制御を迂回するのは「in order to allow backup apps to function properly on the Mac.」（バックアップアプリがMac上で正しく機能できるようにするため）だと述べました。¹ エージェントはバックアップアプリではありません。緊張関係のすべてが、この一文に収まっています。

どこから来たのか

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.」（新しいデータ保護により、アプリは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カテゴリに追加されない限り、保護されたストレージにアクセスできない）⁴¹ デバイス管理のペイロードとその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以降では、ストレージデバイス全体へのアクセスを必要とするアプリは、システム設定（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」（新しいデータ保護により、すべてのアプリはユーザーの書類にアクセスする前に許可を得る必要がある）と述べ、WWDC19でAppleは、デスクトップ、書類、ダウンロードの各フォルダ、iCloud Drive、サードパーティのクラウドストレージ、リムーバブルボリューム、ネットワークボリュームを同意が必要な一覧に加え、「the universe of data that requires preapproval for Full Disk Access has been expanded to include trash.」（フルディスクアクセスの事前承認を要するデータの範囲が、ゴミ箱を含むよう拡大された）と述べました。⁴²¹¹ その後のリリースでは、アプリコンテナの保護（macOS 14）とApp Groupコンテナの保護（macOS 15）が加わりました。どちらもアプリがほかのアプリのデータを読むことに関するもので、前者についてAppleは、フルディスクアクセスを持つアプリには追加のプロンプトが表示されないと述べています。²⁰¹²

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 Groupコンテナへのアクセスでユーザーに認可を求めなくなり、そうしたアクセスはデフォルトで拒否され、プライバシーとセキュリティの設定でユーザーが管理できる）、「XProtect may now restrict access to app data that is commonly targeted by malicious software,」（XProtectは、マルウェアに狙われやすいアプリデータへのアクセスを制限できるようになった）と書き、TCCの項では「Apps can no longer access the local TCC database directly.」（アプリはローカルのTCCデータベースに直接アクセスできなくなった）と書いています。²³ ある既知の問題では、Apple自身のノートがフルディスクアクセスを一時しのぎとして勧めています。バンドル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エージェントが、フルディスクアクセスで保護されたものを読めるようになる経路は二つあります。許可を持つアプリの中で動くか、エージェント自身が許可を持つアプリであるかです。ほとんどのコマンドラインエージェントは前者の経路で手にし、その場合、エージェント自身のために誰かが何かをクリックする必要はありません。

ターミナル経由の経路

ターミナルで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.」（Terminal.appやサードパーティのターミナルエミュレータを含むアプリからesloggerを実行するには、そのアプリがシステム環境設定のフルディスクアクセスで認可されている必要がある）²
• 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.」（アプリケーションバンドルに組み込まれたヘルパーツールは、それを包むアプリバンドルの権限を自動的に引き継ぐ）³⁷

最も直接的な記述は、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サーバーである）。アプリが起動するヘルパーについては「The system treats the app as the responsible code.」（システムはそのアプリを責任コードとして扱う）。launchdジョブについては、SMAppServiceでインストールすればアプリが責任コードになり、そうでなければジョブのプロパティリストがAssociatedBundleIdentifiersでアプリを指定すべきだと書いています。³ 同じスレッドで彼は、これを前提に計画を立てる人にとって重要な但し書きを加えています。「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）と一致します。ターミナルの起動チェーンに許可がある状態で、読み取りは成功しました。後半は私は検証していません。私の対照実験で変えたのは読み取りを起動した場所であって、許可を持つアプリではないからです。

ここから二つの帰結が導かれます。どちらもエージェントに固有のものではありません。

そのターミナルで起動するものはすべてそれを得ます。 エージェント、それが生成するシェル、git、npm install、テストランナー、stdio経由で起動するMCPサーバー、1分前にモデルが書いたスクリプト。これらがターミナルの下で動くなら、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.」（デスクトップ上のファイルを操作する必要があるスクリプトがあっても、インタープリタにその特権を与えたくはないはずだ。そうすればどんなスクリプトでもそれができてしまうからだ）²⁰ フルディスクアクセスを持つターミナルは、同じ問題が一段上で起きているものです。

ほかのアプリがそれを借りられます。 2022年、Jeff Johnsonはソースコード付きで「Every unsandboxed app has Full Disk Access if Terminal does」（Terminalがフルディスクアクセスを持つなら、サンドボックス化されていないすべてのアプリがそれを持つ）を公開しました。彼の指摘はこうです。「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.」（サンドボックス化されていないアプリは実行可能なシェルスクリプトをTerminalで開くことができ、そのスクリプトは開いたアプリではなくTerminalの権限、つまりフルディスクアクセスで実行される）。この手法は「doesn’t work for sandboxed apps」（サンドボックス化されたアプリでは機能しない）とも書いています。⁴⁶ 私のMacで調べたエージェントのデスクトップアプリは、どれもサンドボックス化されていません。ClaudeアプリとCursorはApp Sandboxのエンタイトルメントを持たず、ChatGPTアプリはそれをfalseに設定しています。⁴⁷ Johnsonの主張ではなく私の解釈ですが、ターミナルがフルディスクアクセスを持つMacでは、これらのアプリのどれもが同じ方法でそこに到達できるはずです。

ターミナル自身は何と言っているでしょうか。ターミナルがフルディスクアクセスを持つときに子プロセスが何を得るかを述べたGhosttyやiTerm2のドキュメントは見つかりませんでした。GhosttyのドキュメントとiTerm2のリポジトリをこの語句でGitHubのコード検索にかけても、結果はゼロでした。AppleのTerminalやWarpのドキュメントは同じ方法では調べていません。⁴⁸ アプリ自身が示しているのは、誰のために語っているかです。私のMacにインストールされたアプリから読んだ利用目的の文字列は、その中で動くものを代弁する形で書かれています。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を使おうとしている）です。⁴⁷ アプリがフルディスクアクセスを求めるプロンプトを出せない以上、macOSにはそのための利用目的の文字列はありません。それでもこれらの文字列は設計を示しています。ユーザーが尋ねられる対象はターミナルというアプリなのです。

エージェントを内蔵したエディタも、一段ずれた形で同じように動きます。Cursorのドキュメントは「Cursor runs shell commands directly in your terminal」（Cursorはシェルコマンドをあなたのターミナルで直接実行する）と書いており、エディタの中では、私はこれをCursor自身の統合ターミナルのことだと読んでいます。⁴⁹ 先に挙げたサポートエンジニアのヘルパーのケース（アプリが生成したツールはそのアプリに帰属する）に従えば、それらのコマンドについてTCCが見るアプリはCursorになります。これは私の推論であり、TCCがどのアプリに帰属させるかをCursorのドキュメントは述べていません。³¹⁸

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のmanページも同じ設定を挙げています。² 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」（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から起動されたアプリ、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」（ターミナルアプリが一覧にあり、有効になっている）ことを確かめるようユーザーに指示しています。これも、別の権限についてのターミナル経由の経路です。⁵² Anthropicのサンドボックス、権限、セキュリティのページは、どれもフルディスクアクセスに触れていません。¹⁵⁵³

デスクトップアプリ経由の経路

デスクトップのエージェントアプリはプライバシーとセキュリティにそれぞれ自分の行を持ち、求めるものはアプリによって違います。

• ChatGPT for Mac（私のMacでのバンドル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デスクトップアプリの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アプリはフルディスクアクセスの表に載っています。¹⁹ 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.」（ファイルの読み取り、ファイルの編集、シェルコマンドは、引き続きそのタスクのサンドボックスと承認の設定に従う）と述べています。⁵⁶
• Claude for Mac。 フルディスクアクセスを求めるAnthropicのページは見つかりませんでした。私のMacにあるこのアプリのInfo.plistは、デスクトップ、書類、ダウンロードの各フォルダやApple Eventsなどについて利用目的の文字列を宣言しています（「Claude needs this so commands you run in Claude can control other apps」（Claudeで実行するコマンドがほかのアプリを操作できるよう、Claudeにはこれが必要））。⁴⁷ クイック入力機能は画面収録とアクセシビリティを求めます。⁵⁷
• Cursor。 私が保存したCursorの二つのページ、Run ModesとTerminalのどちらも、フルディスクアクセスを求めていません。Cursorは私のMacの表に載っています。¹⁹¹⁸⁴⁹
• Hermes Agentのコンピュータ操作。 アクセシビリティと画面収録は、hermes computer-use doctorが示す識別子、つまりターミナルではなく別のドライバアプリに与えます。⁵⁸
• エージェント付きのVS Code。 私のMacにはインストールされていません。そのエージェントについてフルディスクアクセスを扱ったMicrosoftのページは見つかりませんでした。⁴⁷⁵⁹

経路別のエージェント

各セルの出典はセクション3と4にあります。^{51166022561361146217481859} 2列目の二つのエディタについての記載は、サポートエンジニアのヘルパーのケースからの私の推論であり、ベンダーの記述ではありません。3列目にパターンがあります。フルディスクアクセスを名指しする二つのベンダーは、Messagesに到達するためにそうしています。Messagesは、その露出が「the people users are communicating with」（ユーザーがやり取りしている相手）にも及ぶとAppleが言うデータです。Appleはどのエージェントも名指ししておらず、私も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のプロファイルは、責任アプリが持っていないTCCの許可をプロセスに与えることはできません。これは、「including those running as root」（rootとして動いているものも含めて）すべてのプロセスがMACに従うというAppleのサポートエンジニアの説明から導かれることで、私は検証していません。もう一つの面は、セクション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.」（どちらでもサンドボックスは同じファイルシステムとネットワークの制限を課す。違いは、サンドボックス化されたコマンドが自動承認されるか、明示的な許可を必要とするかだけである）¹⁵
• その外側にあるもの。 組み込みのファイルツールとWebツールは「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が損害を与えられないコンテナやVMのような隔離された環境でのみ使うこと）と述べています。⁵³

これらのキーが置かれる設定ファイルについては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"の組み合わせと定義し、デスクトップアプリのメニューは「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.」（デフォルトでは、ローカルのツールのサブプロセスはOSユーザーの実際のHOMEをそのまま使う）⁶¹
• コマンドのルールはサンドボックスではない。 「Deny rules are a shell-command policy, not a complete shell interpreter or an OS capability sandbox.」（拒否ルールはシェルコマンドのポリシーであって、完全なシェルインタープリタでもOSの機能サンドボックスでもない）⁶⁴
• 境界はコンテナ。 「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です。⁶⁶
• 脱出口。 tools.elevatedは、OpenClawの言葉では「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プロファイルが包んでいるのはシェルツールだけで、ハーネス自身の内部のgitはサンドボックスなしで動き、リポジトリが供給するcore.fsmonitorフックに従う）⁶⁸ Codexに対しては、2026年8月12日に報告された二つの脱出があり、「Both were fixed inside of eight days」（どちらも8日以内に修正された）とされます。そのうち一つでは「launchd starts the application unsandboxed, outside Codex’s process tree.」（launchdがアプリケーションを、サンドボックスなしで、Codexのプロセスツリーの外で起動する）⁶⁹ Claude CoworkのVMに対しては、ホストの読み書き可能なマウントへの脱出があり、そこから「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ジョブを登録し、その出力を二つのファイルに書き出させてから、ジョブを削除しました。もう一つは、実行のためにAnthropicのsandbox-runtime 0.0.79をnpx -yでインストールし、その実行用に使い捨ての設定ファイルを二つ書きました。サンドボックス内の書き込みプローブは試行であり、サンドボックスはそれを拒否しました。ネットワークプローブは失敗した試行で、その原因は記録からは確定できません。私は設定を何も変えず、何も許可も取り消しもしていません。¹⁹⁵ 見つけたものは、アプリ名とサービス名で記述します。証拠がプログラムがフルディスクアクセスの一覧にあることを示すところでは「一覧に載っている」と書き、アクセスがあると書くのは、読み取りによってアクセスが機能していることが示されたところだけです。

エージェントの起動チェーン

Claude Codeがコマンドを実行するシェルはzshで、それを起動したのはclaude、それを起動したのは私のログインシェル、それを起動したのはlogin、それを起動したのはターミナルアプリのGhosttyです。環境はTERM_PROGRAMをghosttyと報告します。¹⁹ Appleのサポートエンジニアの規則に従えば、このチェーン内のあらゆるものの責任コードはGhosttyです。³

一覧を読む

私が調べた範囲では、macOSはフルディスクアクセスを持つものを一覧表示するコマンドを文書化していません。tccutilのコマンドはresetただ一つです。³⁴ 一覧はTCCのデータベースにあります。エージェントのシェルからはユーザーごとのデータベースを開けず、そのフォルダはユーザーのApplication Supportフォルダのディレクトリ一覧にも現れませんでした。理由はわかりません。macOS 27のリリースノートには「Apps can no longer access the local TCC database directly」（アプリはローカルのTCCデータベースに直接アクセスできなくなった）とあり、それが理由かもしれませんが、ノートはどのデータベースのことかを述べていないので、説明のつかないままにしておきます。¹⁹²³

システム全体のデータベースは開けました。サービスとクライアントの2列だけを選び、フルディスクアクセスのサービスで絞り込み、各スイッチがオンかどうかを記録する列は一度も読んでいません。返ってきたのは75行です。¹⁹ そもそも開けたこと自体が証拠です。2022年にJeff Johnsonは、フルディスクアクセスを持つTerminalが「can read or write any restricted files, including the TCC database itself」（TCCデータベースそのものを含め、制限されたあらゆるファイルを読み書きできる）ことを示しました。彼が示したのはユーザーごとのデータベースについてで、後述の対照テストは、このMacではシステムのデータベースについても同じことが言えると示しています。⁴⁶⁵ これはまた、先に引用したリリースノートにもかかわらず、macOS 27.0では、起動チェーンに許可を持つプロセスからシステムのTCCデータベースを今も直接読めたことを意味します。¹⁹²³

75行は、種類ごとに一つの規則を順番に適用して分類しました。三つのターミナルのバンドルID、バージョン番号付きのClaude Codeバイナリへのクライアントパス、ChatGPT、Cursor、XcodeのバンドルID、nodeまたはpython3.xのインタープリタのパス、SSHサーバーのクライアント、com.apple.または/System/で始まるクライアント、私自身の開発ビルド、そしてそれ以外のすべて、の順です。¹⁹⁴⁷ 各グループの中身は次のとおりです。

• ターミナル（3）。 Terminal、iTerm2、Ghosttyのすべてが一覧に載っています。
• Claude Code（30）。 30の別々の行で、それぞれがClaude Codeバイナリの一つのバージョンへのパスです。2.1.177から、このセッションで動いていたバージョンである2.1.296までです。¹⁹⁴⁷ Anthropicによれば、ネイティブインストーラを使った場合、バックグラウンドセッションのホストの項目は「appears as Claude Code and the grant persists across updates.」（Claude Codeとして表示され、許可はアップデートをまたいで保持される）⁵¹ このMacのデータベースでは、バージョンごとに1行が保存されています。システム設定がそれらをどう表示するか、各スイッチがオンかどうかは確認していません。検証していない私の解釈では、これらはバックグラウンドセッションのホストによる要求で、アップデートのたびに一つずつ増えたものです。
• エージェントのホスト（3）。 ChatGPTアプリ（バンドルIDcom.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は一覧に載っていてエージェントのホストにもなりますが、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.」（一つのnpmパッケージへの許可ではなく、そのNodeランタイムへの広い許可として）扱うようにと。⁵⁰
• SSH（1）。 SSHのサーバー側のクライアントであるsshd-keygen-wrapperです。私はこれを「Allow full disk access for remote users」（リモートユーザにフルディスクアクセスを許可）が制御する項目だと考えています。¹⁹³
• その他のApple（3）、私自身のビルド（5）、それ以外のすべて（25）。 最後のグループには、ディスクやクリーンアップのユーティリティ、セキュリティスイート、VPNとクラウドストレージのクライアント、アップデータ、プリンタのソフトウェア、ゲーム、ビデオ会議アプリ、メッセージングアプリが含まれます。いくつかはディスクユーティリティ、つまりAppleが名指しするもう一つの種類のソフトウェアですが、75行のどれもバックアップアプリではありません。

75行のうち42行は、エージェントがその下で、またはそれを通じて動けるものです。そのどれもバックアップアプリではありません。

七つの実行：サンドボックスと許可は別々の層

どの層が判定しているかを見るために、一つのプローブ、つまりそのシステムデータベースから1行を読む操作を、条件を変えて実行しました。加えて、両方のサンドボックス内での書き込みプローブと、sandbox-runtime内でのネットワークプローブも行いました。⁵

1. エージェントのシェル、サンドボックスなし。 読み取りは行を返しました。
2. Codex CLI 0.154.0のSeatbeltサンドボックス内、read-onlyモード。 読み取りは行を返しました。同じサンドボックスはワークスペース外へのtouchを「Operation not permitted」で拒否したので（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の読み取りを、GhosttyもClaude Codeも起動チェーンのどこにもないよう、launchdジョブとして登録したもの：「authorization denied」。⁵

ほかの結果に意味を与えるのは、この対照実験です。データベースファイルの所有者はrootで、モード（-rw-r--r--）上は誰でも読めるので、run 4を拒否したのはファイルの権限ではなく、TCCです。¹⁹⁵ 同じバイナリ、同じファイル、同じユーザーで、エージェントのシェルからは成功し、その外では失敗しました。エージェントのシェルが持っていたものは、その起動チェーンから得たものです。サポートエンジニアの規則は、そのチェーンの責任コードとしてターミナルを挙げます。³ このデータでは取り除けない但し書きが一つあります。チェーンにはclaudeプロセスも含まれており、Claude Codeのバイナリも一覧に載っています。また、run 3aと3bではsandbox runtimeをnodeプロセスが動かしており、Homebrewのnodeも一覧に載っていますが、npxがどのnodeを使ったかは記録されていません。私の測定が示すのは、アクセスがチェーンから来ているということで、サポートエンジニアの規則はそれがターミナルだと言っています。TCCが使ったのがClaude Codeやnodeの行ではなくGhosttyの行であることを、測定が単独で証明しているわけではありません。Appleのサポートエンジニアは、そのアルゴリズムは文書化されていないと述べています。³

run 3bと4は、異なる層に拒否されたにもかかわらず、まったく同じエラーを出力します。エージェントの出力に「authorization denied」を見たオペレーターは、そのメッセージからは、拒否したのがサンドボックスなのかTCCなのかを判別できません。⁵

自分のMacで試す

エージェントが使うシェルから実行すると、そのシェルの起動チェーンがフルディスクアクセスを持っていれば、フルディスクアクセスの一覧が出力されます。チェーンが持っていない場合、あるいはrun 3bのようにサンドボックスのルールがフォルダを拒否している場合は、「authorization denied」で失敗します。読むのは2列だけで、何も変更しません。結果は行であって、スイッチの状態ではありません。

# 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がアクセスをどのアプリに帰属させたかを見るために、Appleの導入ガイドはログストリームlog stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'を示しており、責任アプリやバイナリをリアルタイムで「to try to identify」（特定しようとする）ためのものとしています。³¹ 今回の測定では私はこれを実行していません。セクション5が、判定したのがGhosttyの行なのかチェーン内の別の行なのかを言えないのはそのためです。上のデータベースクエリは、今後のリリースで動かなくなるかもしれません。Appleはこのファイルもそのスキーマも文書化しておらず、macOS 27のノートはすでに、アプリは「can no longer access the local TCC database directly.」（ローカルのTCCデータベースに直接アクセスできなくなった）と述べています。²³

6. 今すべきこと

10月11日に私が読んだ時点では、新しい制御について公開された仕組みもリリースノートも見つからなかったので、ここにあるのは移行作業ではありません。エージェントを動かすMacであれば今日どれでも私が行うことを、各ステップの出典とコストとともに挙げたものです。私自身のMacでもまだすべては済ませていません。セクション5は、その「before」の姿です。

1. 誰がフルディスクアクセスを持っているかを確認する。 システム設定＞プライバシーとセキュリティ＞フルディスクアクセスを開き、一覧を読みます。⁴ ターミナル、エディタ、エージェントアプリ、エージェントのバイナリ、インタープリタ、そして見覚えのないものを探してください。シェルからは、そのシェルがすでにアクセスを持っていれば、セクション5のクエリが一覧を出力します。これは、エージェントのシェルがそれを持っているかどうかのテストも兼ねます。ただし失敗は、run 3bのように、フォルダを拒否するサンドボックスのルールから来ることもあります。⁵ コスト： なし。一覧に載っているアプリが必ずしもオンになっているとは限らないことを覚えておいてください。

2. エージェントを動かすターミナルから外す。 これが最も多くを変えるステップです。コマンドラインツールの責任コードはターミナルなので、ターミナルの許可がそのままエージェントの許可になります。³² バックアップや管理作業のためにコマンドラインからフルディスクアクセスが必要なら（tmutilとfdesetupの文書が想定しているのはまさにその用途です）、許可を持つ2本目のターミナルアプリを用意し、そこでは決してエージェントを起動しないようにします。⁴³⁴⁴（この最後の部分はAppleではなく私の提案です。Jeff Johnsonは、サンドボックス化されていないアプリがAppleのTerminalでスクリプトを開くことでその許可を借りられることを実演しました。私の解釈では、スクリプトを開ける2本目のターミナルアプリにも同じことが当てはまりえます。⁴⁶）コスト： 保護された場所が「Operation not permitted」で失敗し始め、ファイルとフォルダのプロンプトが戻ってきます。Appleのフォルダ単位の制御が対象とするのは「Desktop, Documents, Downloads, network volumes, and removable volumes.」（デスクトップ、書類、ダウンロード、ネットワークボリューム、リムーバブルボリューム）です。¹⁰ AnthropicはClaude Codeのバックグラウンドセッションについて同じ失敗と、その対処である、その項目へのファイルとフォルダの許可を文書化しています。⁵¹ OpenClawは、フォルダ単位の許可を避けるためにファイルをそのワークスペース内に置くことを勧めています。⁵⁰

3. エージェント自身の項目を確認する。 Claude Codeのバックグラウンドのホストは「separately from your terminal」（ターミナルとは別に）アクセスを要求し、独自のフルディスクアクセスの項目を持ちえます。⁵¹ 私のMacでは、バージョン番号付きのClaude Codeバイナリが30個一覧に載っており、検証はしていませんが、私はそれをそのホストの項目だと解釈しています。¹⁹ 許可したつもりのないものは削除し、バックグラウンドセッションがフォルダを必要とするところでは、代わりにファイルとフォルダの許可を与えます。エージェントアプリもそれぞれ自分の行を持っています。私のMacでは、ChatGPT、Cursor、Xcodeのアプリがすべて一覧に載っています。¹⁹ コスト： 保護されたフォルダを読むバックグラウンドセッションは、より狭いアクセスを与えるまで失敗します。

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ジョブとしてスクリプトを実行する場合に効いてきます。そのときは、そのインタープリタを通じてそのように起動されたすべてのPythonやNodeのスクリプトが、MCPサーバーも含めて、許可のすべてを得ます。³² コスト： 本当にアクセスが必要なスクリプトについては、彼の「easiest solution」（最も簡単な解決策）は、MACが追跡できる独立したプログラムとしてパッケージすることで、それはAppleScriptなら簡単だがシェルスクリプトでは簡単ではない、と彼は述べています。²⁰

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ユーザーで動かすか、使わずに済ませる。 iMessageボットについてのOpenClaw自身のデプロイの助言は、「Use a dedicated Apple ID and macOS user so bot traffic is isolated from your personal Messages profile.」（ボットのトラフィックを個人のMessagesのプロファイルから隔離するため、専用のApple IDとmacOSユーザーを使う）です。⁷¹ そのユーザーは通常のアカウントにします。Appleによれば、通常ユーザーは「can install apps and change their own settings, but can’t add other users or change other users’ settings.」（アプリをインストールし、自分の設定を変更できるが、ほかのユーザーを追加したり、ほかのユーザーの設定を変更したりはできない）⁷² 私のMacでは、私のユーザーのLibrary、Mail、Messagesの各フォルダは、ファイルモード上は私しか読めません。したがって別の通常ユーザーとして動くプロセスは、TCCに照会される前に、通常のファイル権限によって拒否されます。これはモードからの私の推論であり、実行したテストではありません。¹⁹ 但し書きが二つあります。Appleのサポートエンジニアによれば、フルディスクアクセスはユーザー単位ではなく「system wide」（システム全体）なので、あるアカウントでそれを許可されたアプリは、すべてのアカウントでそれを持ちます。そしてAppleのガイドによれば、この設定は「certain administrative settings for all users on this Mac.」（このMacのすべてのユーザーに関わる特定の管理設定）にまで及びます。²⁰⁴ コスト： 2つ目のログイン、2つ目のキーチェーンと設定一式、そして共有しない限りメインアカウントのファイルを見られないエージェント。

7. 必要なければ「Allow full disk access for remote users」（リモートユーザにフルディスクアクセスを許可）をオフにする。 SSH経由でエージェントを操作するなら、責任コードはSSHサーバーで、この設定がその許可です。³ 私のMacでは、そのクライアントが一覧に載っています。¹⁹ コスト： リモートシェルは保護された場所へのアクセスを失います。

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.」（コンテナやVMのような隔離された環境）のためにとっておくよう述べています。⁵³ コスト： クリックが増えます。それこそが狙いです。

9. Macを管理しているなら、プロファイルが何を許可しているかを監査する。 プライバシー設定ポリシー制御のプロファイルは、ターミナルを含め、任意のバンドルIDやパスにSystemPolicyAllFilesを許可でき、「The user isn’t prompted and can’t change this value.」（ユーザーには確認が求められず、この値を変更することもできない）²³⁷ macOS 27では、このペイロードのアプリごとの部分は非推奨と記され、宣言型の後継にはフルディスクアクセスのキーがありません。³⁷³⁸ ユーザーが手作業で許可したフルディスクアクセスをMDMが報告する方法を、Appleが文書化しているのは見つけられませんでした。コスト： 見つかったプロファイルが、バックアップやセキュリティのエージェントを支えている場合があります。Apple自身の例は、組織のアプリに「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,」（アプリにこの並外れたレベルのアクセスを本当に与えたい場合、きわめて明示的なユーザー操作によってのみそれを行える）とされ、「clearly understand these risks before granting such access.」（そのようなアクセスを許可する前に、これらのリスクを明確に理解する）べきだとされます。¹ Appleは説明付きの同意をすでに出荷しています。macOS 27の宣言型のアプリ設定は、プライバシーの既定値を適用する前に、組織が求められている理由の説明を載せた同意プロンプトをユーザーに表示します。³⁹³⁸ 条件： 新しい制御が新規の許可にだけ適用されるなら、すでにフルディスクアクセスを持つターミナルはそれを保ち、その中で動くエージェントは、ユーザーがリセットするまで影響を受けません。既存の許可にも適用されるなら、フルディスクアクセスを持つすべてのターミナルも影響を受けます。告知はどちらとも述べていません。

より狭い範囲。 Appleはスイッチをそのままにして、その下からデータを移すこともできます。Appleはこうした線をこれまでにも引き直してきました。Catalinaはフルディスクアクセスを要するものにゴミ箱を加え、macOS 14と15はアプリコンテナとグループコンテナをそれぞれ独自の保護の下に置き、macOS 27は他チームのコンテナをデフォルトで拒否し、XProtectが「app data that is commonly targeted by malicious software.」（マルウェアに狙われやすいアプリデータ）を制限できるようにしました。¹¹²⁰²³ 条件： AppleがMail、Messages、Safariのデータを、フルディスクアクセスが及ばない独自の制御の下に移すなら、ターミナルがフルディスクアクセスを保っていても、ターミナル経由の経路はそれらに届かなくなります。告知は範囲の縮小に触れておらず、その「this extraordinary level of access」（この並外れたレベルのアクセス）という言い回しは、現状の許可を表しています。

受け継がれる許可の扱いの変更。 「grant an 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」（アプリ）への制御はターミナルに着地し、Appleが、そのエンジニアが文書化されておらず「subject to change」（変わりうる）と呼ぶ責任コードの帰属を変えるか、新しい制御をdescendantsクライアントのようなものに結びつけない限り、その中のすべてのエージェントは引き続き結果を受け継ぎます。どちらの文書も、そうするとは述べていません。

管理対象のMac。 MDMは今日、ユーザーに確認を求めることなくフルディスクアクセスを許可できます。³⁷ macOS 27では、そのペイロードのアプリごとの部分は非推奨となり、宣言型の後継にはフルディスクアクセスのキーがありません。³⁷³⁸ 条件： 「very explicit user action」（きわめて明示的なユーザー操作）がMDMによる許可にも適用されるなら、プロファイルによる無言の許可はもはやできなくなります。適用されないなら、管理対象のMacには無言の経路が残ります。Appleはどちらの点についても何も述べておらず、macOS 27での非推奨化を10月2日の告知と結びつけてもいません。

いつか。 告知は「Going forward」（今後）と述べています。告知の3日後付けのベータである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」（アプリはローカルのTCCデータベースに直接アクセスできなくなった）を、macOS 27のリリースノートのTCCの見出しの下に載せました。²³ 条件： 新しい制御が開発者向けノートのあるリリースで届くなら、そのノートこそAppleが今年のTCCの非推奨化を載せた場所であり、私はmacOS 27.xのベータのノートを毎回読んで該当する行を探します。しかしmacOS 27.0.1はすでに開発者向けリリースノートをまったく持たずに出荷されているので、変更がどのノートのページにも1行も載らないポイントリリースで届く可能性もあります。⁷⁸ macOS 28で届くなら、Appleがこれまでこの種の変更を説明してきたのはWWDCのセッションかベータのリリースノートです。Catalinaの保護についてはWWDC19、今年のTCCの非推奨化についてはmacOS 27のノートでした。¹¹²³ いずれにせよ、セクション6のステップは答えに左右されません。

要点まとめ

Macでエージェントを動かしているなら

• Appleは10月2日、フルディスクアクセスの許可には「very explicit user action」（きわめて明示的なユーザー操作）が必要になると述べ、その理由としてAIエージェントを挙げました。バージョン、日付、仕組みは示していません。¹
• コマンドラインのエージェントは、ターミナルが持っているものを何でも持ちます。Appleのmanページとサポートエンジニアは、ターミナルが責任コードだと述べています。Appleは一般規則を文書化していません。²³
• ベンダーのサンドボックスはフルディスクアクセスの制御ではありません。私のMacでは、保護された読み取りがCodexのread-onlyサンドボックスもAnthropicのサンドボックスランタイムも通り抜けました。それを止めたのは、まさにそのフォルダに対する読み取り拒否か、ターミナルの外での起動だけでした。⁵
• エージェントを動かすターミナルからフルディスクアクセスを外し、nodeやpythonには決して与えず、サンドボックスだけでなく読み取りの制限もオンにしてください。²⁰¹⁵²¹
• エージェントがMessagesを読むなら、専用のmacOSユーザーを与え、送信ごとの承認を残してください。⁷¹²²

エージェントやエージェントアプリを作っているなら

• ユーザーに、ターミナルやエージェントのプロセスへフルディスクアクセスを与えるよう指示しないでください。現在二つのベンダーが、Messagesのためにそうしています。¹³¹⁴
• Appleが文書化している経路は、プロンプトではなくパネルへのリンクです。スイッチはユーザーのものであり、Appleはそれをオンにするにはきわめて明示的なユーザー操作が必要になると述べています。²⁵¹
• サンドボックスがデフォルトで何を読むかをドキュメントに書いてください。Codexのドキュメントは、そのサンドボックスが「limits what it can touch (typically to the current workspace)」（触れられるものを（通常は現在のワークスペースに）制限する）と述べていますが、そのソースと私の実行は、読み取りがワークスペースのはるか先まで届くことを示しています。⁶⁰⁶³⁵

よくある質問

Macのフルディスクアクセスとは何ですか？

システム設定＞プライバシーとセキュリティにある設定で、アプリに「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.」（他のアプリのデータ（たとえばMail、Messages、Safari、ホーム）、Time Machineバックアップのデータ、このMacのすべてのユーザーに関わる特定の管理設定を含め、コンピュータ上のすべてのファイルへのアクセス）を許します。アプリがこれを求めるプロンプトを出すことはできません。ユーザーが追加ボタンでアプリを加えるか、MDMプロファイルが許可します。⁴¹⁰²

Appleは2026年10月にフルディスクアクセスについて何を発表したのですか？

2026年10月2日付けの開発者ニュース「Updates to Full Disk Access in macOS」で、Appleは「will introduce additional controls」（追加の制御を導入する）と述べ、アプリにこのアクセスを与えたいユーザーが「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のmanページは、「Terminal.app or a third-party terminal emulator」（Terminal.appやサードパーティのターミナルエミュレータ）から実行するにはそのアプリが認可されている必要があると述べ、Appleのサポートエンジニアはフォーラムの投稿で「The tool’s responsible code is Terminal.」（そのツールの責任コードはTerminalである）と書いています。私のMacでは、フルディスクアクセスを要する読み取りが、Ghostty内のClaude Codeのシェルからは成功し、その外で起動したときには失敗しました。²³⁵

Claude CodeやCodexのサンドボックスは、エージェントが私のMessagesを読むのを止めますか？

デフォルトでは止めません。どちらのサンドボックスもSeatbeltを使っており、これはフルディスクアクセスとは別のものです。Claude Codeのサンドボックスはデフォルトでオフで、オンにしても「Most of the machine」（マシンのほとんど）を読みます。Codexのものはオンですが、そのread-onlyモードは私のMacでフルディスクアクセスで保護されたファイルを読みました。読み取りは明示的に拒否してください。Claude Codeではpermissions.blockReadsOutsideWorkingDirectories、Codexでは権限プロファイルの"deny"ルールです。¹⁵²¹⁵

どのアプリがフルディスクアクセスを持っているか、どうすれば確認できますか？

システム設定＞プライバシーとセキュリティ＞フルディスクアクセスを開いてください。⁴ tccutilでは一覧を出せません。そのコマンドはresetだけです。³⁴ すでにフルディスクアクセスを持つターミナルからであれば、セクション5のように、システムのTCCデータベースを読むとクライアントが一覧表示されます。「authorization denied」で失敗した場合、シェルがアクセスを持っていないか、サンドボックスのルールが読み取りを拒否したかのどちらかです。¹⁹⁵

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日に始まっています。¹⁶⁷⁸⁹

出典