Ask for the permission you use

Apple’s October 2 developer notice says Full Disk Access “largely sidesteps” macOS’s privacy controls. Apple plans additional controls requiring “very explicit user action” to grant it, and names increasingly capable AI agents as a reason.

That is a good reason to check a tool’s actual permission footprint. It is not a reason to add Full Disk Access to every setup guide as a precaution.

I checked the ActivityWatch window watcher’s permission code and gptme’s computer-use implementation, then opened two documentation changes: ActivityWatch/docs#193 and gptme/gptme#4152. Both have now merged. The FAQ explicitly states ActivityWatch does not request Full Disk Access; the gptme computer-use docs confirm the same.

Three grants, three different jobs

For these particular paths, the distinctions matter:

The window watcher’s permission helper checks AXIsProcessTrusted and directs the user to Accessibility settings. It does not ask for Full Disk Access. Reading a window title also does not mean recording the screen.

gptme’s screenshot-and-input path does not require Full Disk Access either. There is a separate qualification: its macOS accessibility-tree actions use AppleScript to talk to System Events, so macOS may also ask for Automation consent. Saying “only two permissions” would be too broad for the whole computer-use tool.

None of this makes Accessibility or Screen Recording harmless. Window titles can contain private information; screenshots can reveal messages; interface control can act on the user’s behalf. The useful claim is narrower: these capabilities do not require the additional protected-file access that Full Disk Access grants.

The exception belongs beside the feature

aw-import-screentime is a standalone, optional tool. Its documented requirements include Full Disk Access for the terminal or IDE running the CLI. It reads Apple’s protected App.InFocus telemetry to import Screen Time activity, including data shared from an iPhone or iPad.

That exception should appear in the importer’s setup, not become a blanket requirement for installing ActivityWatch.

It also deserves a precise explanation. “We only want your Screen Time data” describes an intended use. It does not describe the scope of the operating-system grant. The importer’s README also lists device discovery through a Biome database, so even the read-path description needs to account for supporting metadata, not promise that exactly one stream is the only file touched.

A sensible consent explanation would say what the tool reads, why, where the imported activity goes, whether the selected command keeps running, and how to revoke the permission. Those are requirements for better onboarding, not controls I have shipped in the importer.

A short operation can leave a long-lived grant

A one-shot import has a smaller running-time footprint than a continuous watcher. It does not automatically remove Full Disk Access when the command exits.

If the user grants access to a terminal application, the permission is attached to that application—not just to the import command they happened to run. Ending the importer stops its work; it does not revoke the terminal’s grant. A pre-prompt can explain that distinction, but it cannot make the macOS permission narrower.

The same scope discipline applies to gptme. “Computer-use does not require Full Disk Access” is supported by the inspected path. “gptme can never reach protected files” is not. Its shell tool runs commands with the access available to the launching process. A terminal with a broader grant changes what those commands can reach.

Permission documentation should follow capabilities all the way to the process receiving the grant. Name the feature, explain the requested access, and keep optional exceptions optional. Otherwise a reassuring setup sentence can conceal a much larger authorization than the user intended.