Reading view
Unspecified Full Disk Access Screw Tightening
Apple (Hacker News, MacRumors, Lobsters, TidBITS Talk):
Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.
[…]
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.
It was pretty obvious something like this would happen after the Muse accessing Messages news.
What we have is just one noisy, confused journalist, Jason Aten. He granted FDA to Muse but refuses to admit it, to the public or even to himself.
I see several issues with the current Full Disk Access system:
Backup apps need FDA, but so do many other types of apps. Often, they don’t need full disk access but rather they need to work around a missing or broken API. All of my apps except ToothFairy use FDA, not because I want to or because it’s easier to code, but because without it the user experience would be much worse or key features wouldn’t work at all.
There is no API for apps to see whether they have FDA or to request it from the user. It’s not like, say, accessing the user’s Contacts where macOS pops up a standard dialog and the app supplies a “reason” string to specify why it wants access. Instead, each app presents its own set of instructions for how to enable it deep in System Settings. It requires the confusing maneuver of first adding the app to the list; it doesn’t automatically show up with a slider switch next to it, like with other privacy settings. This adds an obstacle for users to get up and running with an app but doesn’t really provide additional security, just obscurity.
FDA is not granular. There’s no way for apps to request only the permissions they actually need. For example, SpamSieve wants to be able to access the user’s mail, but it doesn’t need or want to see their iMessages or browser history. This is bad for users because they may be exposing more information than they want to and bad for developers because some users will think your app isn’t worth the risks.
There is no way for the user to see what the app actually did. If it tells me that it wants FDA to access my mail but actually it mucked around with my Time Machine backup, how would I know?
Apple’s wording in System Settings is not very clear. I don’t think most users really understand what FDA is doing.
The previous items combine to create opportunities for malfeasance. It’s normalized that many apps that seem like they wouldn’t need full disk access do need FDA, so this makes it easier for apps to trick the user into granting it under false pretenses. Apple requires that apps coach the user through the process, so it’s normal that users mostly see text from the app (which might not be trustworthy) rather than standard text from Apple, as with other permissions prompts.
But the problem in the Muse case was not malfeasance. Rather, it seems that Muse asked Aten to enable FDA, but he doesn’t remember doing so or didn’t understand what he was doing. It sounds like Apple wants to make this consent more clear, which is good, but other issues would remain. As with the recent keychain story, this feels like a bandaid rather than a thoughtful solution to the real problem. The issues with FDA were clear when it was introduced 8 years ago, and many Radars were filed, but it’s been virtually unchanged since.
Apple seems to think that by making a scarier warning they can convince more users not to grant FDA—or at least perhaps deflect blame from Apple to the user if they later regret it. Maybe that solves Apple’s problem, but it doesn’t really solve the user’s problem. The user is installing Muse because it’s more capable than Siri. They probably do want it to access some protected data, e.g. so it can find information in their mail or messages. So they actually do need to give it FDA. Aside from deterrence, Apple is not actually protecting the user. And the deterrence is kind of sketchy. Rather than providing a safe way for users to choose what to share with a competing product, Apple is saying the only option is to share everything, and then discouraging that. Meanwhile, there’s no switch to turn off Apple Intelligence. It’s like they expect you to stay on eWorld and not download Netscape. I actually really liked eWorld, and the broad Internet wasn’t totally safe (though neither was eWorld), but that doesn’t seem like much of a strategy.
Below I’ve embedded […] a screen recording of a macOS Virtual Machine showing the first run experience of the Meta Muse app.
[…]
It’s important to note that macOS has no API for an app to request or acquire Full Disk Access. The only way for an app to receive Full Disk Access is via the Full Disk Access pane of System Settings, as shown in the video. Thus, the only thing an app can do is open the System Settings pane for the user, as also shown in the video. Once the user is in System Settings, it’s up to the user to manually grant Full Disk Access.
Without Full Disk Access, Muse cannot access the user’s Messages database. If it could, that would be a macOS zero day vulnerability.
[…]
Aten oddly writes as if the “if you give it Full Disk Access” earlier in the article were counterfactual, merely hypothetical, still insisting that he did not give Full Disk Access to Muse.
I really worry about just how much Apple is going to lock Full Disk Access down. I use it with several apps that couldn’t function properly without it, and would be severely hampered if I needed to authorize it manually every time they do something.
However, what Apple absolutely must not do is to make the mistake it made with macOS Sequoia over screen recording. Sure, this is also incredibly dangerous and very strong warnings are appropriate, but what Apple did then was to force us all to confirm these permissions on a weekly basis, as well as after every restart.
Well, this is certainly ominous news for backup programs.
Like it’s not hard enough to turn this stuff on…
Is Apple suggesting this capability could be limited in the future to backup applications alone? I do not like that.
[…]
Because of the lack of information available at present, I do not want to get too far ahead of myself, but I am concerned that it could be a significant curtailing of application permissions. It has the potential for further self-preferencing, as Apple will surely exempt Siri from the kinds of permissions requests it requires of third-party apps, even as it is updated with additional capabilities.
[…]
Call me a naïve little baby if you want, but I do not think preserving Siri’s dominance on Apple’s devices is the company’s reason for locking down Full Disk Access. But Apple’s existing restrictions are part of the reason Siri was awful for a decade. If it had the opportunity to compete with third-party replacements, I doubt it would have languished in a miserable state for as long as it did.
[Only] a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom, launchers like Alfred, the wonderful selection utility PopClip, Apple’s own Pixelmator Pro, Setapp, TestFlight, Supercharge, Madden NFL 27 Arcade Edition, Hazel, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.
[…]
On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.
But there are plenty of legit uses for Full Disk Access. Just looking at my MacBook Air this morning, I’ve given that permission to three apps: Terminal, BBEdit, and SuperDuper. All apps that I trust with that level of power because of their long history and because in order to do what they do best (or at all), they need that access. (Interestingly, on my Mac mini, that list also includes SpamSieve, KnockKnock, and Shortcuts—though not BBEdit, for whatever reason.)
[…]
I think there is a good argument for protecting Full Disk Access further, but there’s also only so much you can do to protect a user from themselves. Ultimately, this is a cat-and-mouse game, and while I don’t want my data purloined or misused, I also don’t want my computer locked down to the point that I can’t use it for all the things I want to do.
To say that I’m nervous about what Apple’s solution will entail is a massive understatement. There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use. Then there is the fact that macOS is a certified Unix system; this means that agents — which are perfectly suited to the command line — have access to the entire universe of tooling built for Unix systems. And, of course, Mac hardware is amazing.
The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile. The biggest issue is GUI-only permission prompts that are invisible to software running on said computer, including agents.
[…]
This system is annoying but manageable on your primary Mac; it’s a disaster on a headless Mac running agents, for two reasons. First, agents write new programs all of the time, and in my case, those programs need access to devices on my network (SMB shares, for example, trigger a TCC warning). What I need is a permission layer for agents, not the programs they create; TCC is operating at the wrong level of abstraction.
Second, the TCC subsystem exposes its prompt in a protected space that no program can see; that means that programs silently fail and the agents don’t know why; what I have to do is remember that there is probably a permissions prompt on screen, log into the Mac Mini with screen-sharing software, and click OK.
Apple’d get a long way by just renaming the privilege. How many laypeople understand what a “disk” even is? Regular people just talk vaguely about how much “memory” their computer has - if they think about it at all other than when they run out of disk space - at which point, how many just think that means they have to buy a new computer? So, how about just “Full Access to All Your Data”? Call it what it basically is.
If Apple has time (or is especially motivated), it might also add more granular options to control what data apps can access. For example, instead of today’s single toggle that grants an app access to the broadly defined “data like Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings,” it might instead allow you to enable access to specific data on a per-app basis. This would allow, for example, Muse to access Mail and Safari, but not Messages or Time Machine.
With all the levels of entitlements and crap they added, I find it ironic that SIP is “only” implemented as “open up every damned thing to everyone” without more refined levels.
John:
I was frankly surprised when I learned FDA was for a machine, across user accounts, rather than for a single user. It seems like granting root, something the *nix community has tried to reduce and lock down for decades.
I certainly don’t trust anyone’s AI with root, and creating a weak, non-admin, user for AI experiments should be a safe path.
While [Gruber sees] this as a “why we can’t have nice things” moment, I see it as another case of Apple using privacy to limit competition in areas it currently lag behind.
I’d prefer to decouple trust in how my personal data is handled from trust in a particular platform or software vendor. That’s what I personally value about EU’s approach: give people rights over their information, make mishandling it a legal liability, and severely punish companies that break those rules.
Apple getting unique privileges to access sensitive data simply because they own the platform, and thus there is an implicit trust in their handling of it, feels like a brittle long-term strategy. If this works without causing anti-trust issues, it only makes Apple more dominant while locking out potentially useful software.
Previously:
- I Said No and Apple Said Yes
- Locked Down Passkey and Keychain Backups
- Meta AI for Mac and Muse
- Mandatory Apple Intelligence
- Reporting a Full Disk Access Bug to Apple
- Terminal and Full Disk Access
- macOS 11.4 Breaks Full Disk Access for Helper Tools
- The Alert Hammer
- Mojave’s New Security and Privacy Protections Face Usability Challenges
Update (2026-10-06): See also: TidBITS Talk and Vitor.
Whether or not you would ever want to unleash AI agents on your Mac, Apple does need to refine Full Disk Access as a matter of urgency. But its design and engineering cannot be rushed. Merely adding to the complexity of current Privacy settings wouldn’t help users, many of whom already find privacy protection confusing and opaque.
it’s clear there’s consumer demand for automated access to iMessages, and instead of offering a proper API with audit trails and fine-grained controls Apple would rather force users to FDA then cry fowl when they grant FDA.
Previously:
Update (2026-10-14): Adam Engst:
63% of the more than 200 people who voted said they had granted Full Disk Access to 6 or more apps, with over half of those people saying they had given 11 or more apps that level of access. In short, Full Disk Access is essential to how many of us use our Macs.
At the same time, Full Disk Access feels a bit like a Band-Aid, partly because Apple hasn’t put enough thought into more granular permissions, forcing many apps to rely on Full Disk Access even when they don’t need all its capabilities.
[…]
Given that Apple’s statement about Full Disk Access seems to have been prompted by the release of Meta’s Muse AI agent, I would suggest Apple think more carefully about how such agents should be handled. They may legitimately need Full Disk Access, along with numerous other permissions, but beyond what would appear in an App Privacy Report, I would like to see them maintain complete logs of every permission-enabled action they take on your computer. Preferably in human-readable form.
EagleFiler 1.9.22
EagleFiler 1.9.22 is a maintenance release of my Mac file/note organizer and e-mail archiving app. This version works around various bugs in macOS 27, adds capture support for the Thorium Web browser, and improves importing from Mariner Paperless.
macOS 27 broke several things with drag and drop out of Apple Mail. Simply trying to read a URL from the pasteboard will cause a hang while it waits forever for the pasteboard server (FB24803817). The same thing happens when using
PasteboardSetPasteLocation()and readingkPasteboardTypeFileURLPromisedirectly, which I was doing (instead of using newer API) to work around bugs in older versions of macOS. EagleFiler now usesNSFilePromiseReceiverfor drags from Mail on macOS 27, which works better, but I also had to work around a bug where Mail would promise superfluous files for which thereadercallback was never invoked at all.macOS 27 also seems to include various regressions when reading PDF and Word files, producing invalid strings containing
NULcharacters. Also, displaying certain PDF files worked fine on macOS 26 but now crashes.I also ran into (and worked around) a bug where macOS 27’s
NSTextViewwould get into an infinite layout loop when displaying an attributed string that included images.Drag and drop from Airmail is still an issue. When using the newer drag APIs, it will often hang Airmail or not produce a file, and this also happens with other apps like Finder as the destination. EagleFiler works around this using older APIs with Airmail and tries to report a helpful error when there’s trouble. Single-message drags work best.
I’ve also been investigating a problem where saving a file with a colored tag in iCloud Drive will, a few seconds later, change the color to gray, but I don’t have a solution for this.
Previously:
Airmail 26.037
Today, Apple sent me an e-mail about the Airmail Mac e-mail client:
Thank you for subscribing to Airmail Pro Yearly. We wanted to let you know about an upcoming change to this subscription.
The developer, Bloop S.R.L, is raising the price of this subscription from $9.99 per year to $49.99 per year.
This is a big increase in percentage terms, but the new price is actually not out of line with subscriptions for other e-mail clients these days. There remains a free version that supports a single mail account.
They recently added an MCP:
Airmail now connects to AI assistants like Claude, Codex, and other compatible chatbots — so you can manage your email just by asking, in plain language.
Ask your assistant to find messages, summarize long threads, draft replies, tidy up your inbox, and organize folders. Airmail stays in control: everything runs on your Mac, and you decide what the assistant is allowed to do.
Most relevant to recent discussions here: does Airmail access Exchange accounts via the moribund EWS or the newer Graph API? They told me that it does not currently support Graph but that they will add that in a future update.
Previously:
SpamSieve 3.3.2
SpamSieve 3.3.2 is an update of my Mac e-mail spam filter that improves remote training, can export more rule information, and improves uninstallation, help, and more. The most significant news is that Microsoft has changed plans again. They will no longer be preventing users from continuing to use Legacy Outlook and in fact will keep it available for download as part of the combined Outlook app. This gives more time to adapt to their change in plans for AppleScript. Exchange (EWS) support remains an issue. Microsoft is still planning to cut off Legacy Outlook users, and Apple has yet to announce when Mail will support Graph. So far, I’ve not heard that it’s enabled in the macOS 27.2 beta.
We’re participating in a seasonal festival of artisanal software called SummerFest. For a limited time, you can get a 25% discount on new purchases of SpamSieve, EagleFiler, and other top Mac apps from our indie developer friends.
Some interesting engineering issues were:
Updating
NSWorkspaceAPIs introduced a problem because with the oldlaunchApplication(at:options:), the.withErrorPresentationoption is off by default, whereas with the neweropenApplication(at:configuration:completionHandler:), thepromptsUserIfNeededoption is on by default.Previously, Core Data would strip leading BOMs from
NSStrings when saving to a SQLite database. With macOS 27, this happens for SwiftStrings, too.I have lots of unit tests that check for memory leaks. These caught a change where
addPersistentStore(type:configuration:at:options:)now seems to return an autoreleased store. Without adding a pool, it looked like there was a leak.Also, the tests were finding lots of “leaks” because KVO was retaining
NSTabView, which retains a controller. Previously,XCTestCase.waitForExpectations(timeout:)would spin the run loop, and everything would get cleaned up. With Xcode 27 and macOS 27, I need to manually spin the run loop before waiting for the expectations.During a software update, macOS may decide to reload the Dock icon. The application package no longer exists because it’s been replaced with a new version. This wasn’t a problem before because SpamSieve had been drawing to an image in memory and setting that as the Dock icon. Now, with the Liquid Glass–imposed removal of custom Dock icons, macOS tries to load the icon from disk, and rather than handling errors gracefully it will crash. I fixed this by setting an image with a memory representation before starting a software update.
-
SpamSieve 3.3.1 introduced a crash affecting a small but significant number of users when doing a Core Data fetch of a large number of objects. The private
[_PFManagedObjectReferenceQueue _processReferenceQueue:]method was seemingly releasing an object that had already been released. What’s odd is that, as far as I can tell, none of the related app code had changed since the previous version, yet suddenly crashes started happening all the way from macOS 12 through macOS 27. If I had to guess, this was triggered by upgrading from Xcode 26.2 to Xcode 26.6. Maybe Swift’s ARC optimizations are doing something subtly different?The crash was triggered by an autorelease pool that I had inserted to promptly clean up any temporary objects after a fetch. (The actual fetched objects were returned and used outside of the pool.) Interestingly, both Gemini and ChatGPT were convinced that this is a well-known exception to standard memory management rules. They said it’s never safe to use managed objects outside of a pool they were fetched in because they depend on internal Core Data objects that the pool will have released. I was not able to find any basis for this “belief,” but it was easy enough to test. As expected, removing the pools (during the beta cycle) just made the same crashes happen slightly later.
I think there’s probably something wrong in Core Data’s internal bookkeeping, but this does not seem to be a popular crash (and I’ve never seen it on any of my Macs), so my code must be doing something uncommon to trigger it. My current best guess is that it was related to calling
refreshAllObjects()after saving. (I bet there’s some fancy bookkeeping to make that efficient.) I was doing this throughout the app to break retain cycles so that unused objects could be deallocated. But it wasn’t necessary in this particular case because the entity being fetched has no relationships. So far, removing the refresh seems to have stopped the crashes, but I won’t know for sure until more people have been using this version for a while.
Previously: