> We give developers powerful APIs to build incredible capabilities
> Full Disk Access largely sidesteps these controls
That's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk"
For example, if you care about "mail, messages, and even browsing history", why isn't there a subset of "full disk access except for reading mail/messages/browsing history"? Or if vibe code have some basic disk sizing functionality to ask questions about your files, why can't it have a more granular "full disk read only access for file sizes only" so that your vibe coded disk visualization app can't destroy your data or your privacy
> can only do so with very explicit user action.
Which is in the same vein and is mostly useless, just another inconvenient bump
I have a file search app that does its own indexing similar to Everything on Windows (https://lowtechguys.com/cling) and I only index paths.
I don't need file contents, I can skip showing file sizes and date modified on protected paths. Hell I can skip indexing Mail and Messages files altogether since they're pretty useless anyway. But how am I supposed to know beforehand which path will trigger a scary Cling wants to see your <private folder> when doing a simple traversal.
Similarly, window switchers like my rcmd app (https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
This goes on and on.
Want to register a more interesting hotkey like fn-letter? You have to act like a keylogger and ask for Input Monitoring.
Want to focus a specific window instead of activating the app and letting the OS decide which window comes forward? You need Accessibility permissions and full access to control the whole computer.
Want to paste some text into a text field? Accessibility Permissions.
Too granular permissions is hell. But there are these decade-old common use cases for macOS utilities that would make it much easier to keep permissions locked if they became their own permissions.
I have a disk monitoring app that also gives quick access or the ability to eject external drives. Without Full Disk Access, you can’t open a Finder window to the root of the external drive. You can open the parent and select the disk mount point.
I burned a support request on this years ago, and was told that it seemed like a good idea for a future update… a API to open a Finder window at a known path.
macOS used to be one of the most power tool friendly operating systems. Apple Events and AppleScript dictionaries made automation like this so easy. Now everything requires a special permission or specialized Kit to do things that were simple two decades ago.
Personally I’m switching to Omarchy the minute they’ve got an Apple silicon image. Been on macOS since the 90s. I just want to be able to tell the papercuts to go away. Not confident in Apple’s ability to scratch that itch anymore.
I'm not sure I will migrate to Omarchy, but seeing the hype around the system gave me incentive to create TUIs for most of my apps. I'm making my day to day DX as OS-neutral as possible until I finally move to Linux.
> Similarly, window switchers like my rcmd app (https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
Window titles can and often do contain very personal information. A window titled "Planned Parenthood | Official Site" in the hands of a bad actor or some relative-monitoring spyware could have disastrous consequences.
> Want to paste some text into a text field? Accessibility Permissions.
Only if you aren't relying on user-initiated pasting like right click ' cmd+v.
I fully support you on your's previous comment but here I need to remind you what it is you who understand the implication of that query. Regular Joe isn't. And even more importantly is what the vendor is not on R.J. side, it is on the advertising side[0] where the excessive knowledge about a user is the thing.
Like just 15 minuts ago I opened Untappd likr a bazillion times before and were present with 15 screens of toggles and like 250 entities at least. There were at least 10 permissions to give the consent to track the things I do outside the app.
So not only a detailed reason for the permission wouldn't work, it wouldn't be implemented in the first place,
Having had the (dis)pleasure of working with SELinux, it's clear that there are systems out there that can work to solve these problems. On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
> On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
SELinux was originally designed by the NSA to serve their needs, which are probably a bit more intense than "normal" users, and that was over 25 years ago. I'm not convinced a fresh effort couldn't do better, though I'm more skeptical that anyone is willing to invest the resources.
How would you design such a system to be granular enough to solve for arbitrary application needs without being so complex as to be impossible to tune without false positives and false negatives all over the place?
It's not like people have tried to improve core security models, but in my opinion it's not really compatible with the core filesystem abstraction that programmers and power users of desktop computers demand. I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
So what? No one is disagreeing with you about that. The thread was about adding fine grain security controls to traditional OS filesystem access. I was just using iOS as an example, I could just have easily talked about containerization, as a security solution. Of course all those solutions are more limited than a local filesystem—the entire paradigm is designed around full control, you can't bolt on granular security. Heck, even basic UNIX permissions are pretty janky and unmanageable, but at least they more or less work everywhere since they've been around forever. Inventing something now is guaranteed to be annoying and useless.
Terminal is a significant risk though and I’d still really like to see macOS improve the APIs around filesystem access.
Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.
Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).
This is why I use Terminal as my primary terminal, and iTerm as my AI terminal. iTerm gets no permissions, I move specific things to Terminal to do it. Plus I can then style them to optimize for the different usages. And iTerm has better harness hooks anyway.
I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.
But your terminal shouldn't be accessing any files; you just need to be able to launch /bin/zsh or whatever you use as your shell. The shell needs to be able to access files, but its container doesn't.
Of course, you could go farther. For example, on OpenBSD, even /bin/ksh has been somewhat sandboxed; it can see most of the file system, but the things it can do have been limited:
The TCC system attributes the access to Ghostty because that’s the thing the user understands as the app they are interacting with. Otherwise every `posix_spawn()` and `system()` call would result in a new TCC prompt attributed to an inscrutable name.
ls does not live in an .app bundle and it is not managed by launchd. The TCC framework (which implements sandboxing on macOS) and the rest of the UI only respects .app bundles since that's the thing the user sees. The fact that ghostty is fork/execing another process to to the disk access is immaterial to it - hell, if Apple had their way only launchd and Safari would be able to spawn processes at all (like on iOS).
I mean, think about it: what would it mean if ls had a separate sandbox identity from the shell that spawned it? It would mean that any process on the system not entitled to read files from disk could get that entitlement by just fork/execing ls and parsing its stdout. That's not a security boundary that makes sense. ls doesn't read files - ghostty reads files, and ls is just its deputy.
It really isn't; the program just needs to be able to declare what it expects it should be able to do, and what it expects its children should be able to do. The latter doesn't need to be a subset of the former.
The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
But yes, it's unfortunate that macOS sandboxes cannot be nested.
This position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
Yes, and macOS entitlements work similarly, as you know. I was interpreting “what it expects its children should be able to do” as a single rule for all child processes, like in OpenBSD pledge() which the parent seems to be referring to. Sure, such a rule could securely be greater than the parent’s own permissions if you strictly limit what processes can be executed with what arguments.
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.
>The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
That assumes you're only defending against malicious code. Spawning children with limited functionality is a useful defense against non-malicious code being exploited by malicious data, even if those children have privileges the parent lacks.
It's already done on OpenBSD, and linux has the pieces to do it, though it's far more fragile and complicated. I'm not speaking hypothetically here, I've implemented code that works this way.
You are minimizing the difference in scope between the audience and applications of OpenBSD and those of macOS.
macOS has had a capabilities model for over a decade called App Sandboxing. It would be entirely impractical to expect app authors to correctly declare their permissions up front and for users to audit them. Hence the permissions granted to sandboxed apps are pre-determined by the OS, and can be extended through explicit user interaction.
you mean "isn't"? Though there is no indication that a lot was invested, so doesn't give you the measure (my comment was about the availability of resources, not of their actual use)
It's done on the majority of the OpenBSD base system, as well as important ports like Chrome and Firefox. Linux also has the parts to do this, though it's more fragile and complicated.
To be clear I have a much higher standard for what is acceptable than that, you really need to consider software that a hundred million people are going to use
ghostty is the .app, perhaps it makes more sense if you imagine some other app, Spotify.app say, imagine for whatever reason it shells out to ls for listing files, it will show as Spotify requesting access not ls.
Spotify has (had? I no longer use it) a feature that would allow you to make local media available as part of your library anywhere so long as your machine was on and connected to the internet. I would imagine that feature requires disk access under these sandbox / permission models.
Edit: I should say, the model it was created with (select a folder, all media in that folder is mirrored) requires such permissions. One could imagine designs that don’t.
I haven't tested Apple's access model, but is there something that's stopping Gemini from launching `ghostty -e /bin/sh malware.sh`?
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
I have to have my machine further crippled in order protect people who don't know what they're doing on a computer.
I don't think there's anything wrong with people not knowing how to use a computer properly. In fact, I wouldn't expect a normal person to, why should they? So what I would love to see is normies be given iPads, and my computer left the hell alone.
It's like if we over-simplified all the controls in a cockpit because someone who likes playing flying games finds it too difficult to fly a real plane.
We've had a solution to this for a long time in various programs - let the user tell the application how much they know. By default, settings are extremely limited, but you can change settings to "advanced" or "expert", and more options/settings become available.
There is no reason this couldn't work for permissions as well; beginners get the system locked down pretty well, whereas advanced users get a more open system they can do more with, at the expense of potential foot-guns)
(As a side note, we could probably make a plane that had this principle applied as well. With autopilot where it is today, we could easily make a commercial plane that grandma could fly under most circumstances - you just need that real pilot and extra controls for when things go wrong.)
The reason this doesn't work for the OS is that applications invariably ask the user to set settings to "expert" and toggle this and that in order to take full advantage of features.
So I still think the solution is something like iOS or Android. I can not think of anything a non-CS person needs to do that can't be done on those platforms.
Install an app. For apple you need to try test flight to find out too many people use the app so you need to be able to install in developer mode.
I can understand the argument that you should have some technical competency to evaluate that these programs are safe to install, but neither accounts for a technically competent friend/family member suggesting/helping you install an app. Apple requires expertise to even keep an app that doesn't pay to be on the app store installed longer than a week.
I would like the ability to see which specific folders I have granted access to on an app by app basis. And edit. It’s not clear to me how you revoke an app’s individual folder access after you have granted it.
For those who haven’t heard of this, sandboxed apps can request access to a file or folder and persist such access using a security-scoped bookmark. The user however does not know whether the app chooses to persist this bookmark or not; in other words the user does not know whether in each case they are granting a one-time access or persistent access.
There are already folder-specific permissions for every app, including non-sandboxed apps: Desktop, Documents, Downloads. FDA is "everything else". The user has to specifically grant each of those permissions via a system dialog.
With sandboxed apps, you grant access to a file outside the sandbox via a system dialog, open or save. But with non-sandboxed apps, if there were separate permissions for each specific folder, there would have to be separate permission dialogs for each of those folders, and then macOS would become even more of a permissions dialog hell than it already is.
Reminds me of iOS's terrible treatment of PWA local storage. A PWA's offline availability can be revoke at any time the OS decides it knows better than you what your storage should be used for.
For the folders that prompt the access control requests, that should all be in System Settings -> Privacy & Security -> Files & Folders. Each app that's been granted permissions should appear there, and if you click the disclosure triangle, it will list the individual folders with toggles for each.
You could say that about anything, in any OS. Windows is one update away from insulting the user whenever they login. MacOS is one update away from mining crypto for Apple. Android is one update away from sending spam to all your contacts.
The point is about trajectory. Apple continually removes rights from developers, and then users, but grants all those rights to themselves. This has been going on for a while. I left the Apple ecosystem in 2011 because I was concerned about the direction, and in the intervening 15 years, I have not regretted it. The amount of random breakage I get on Mac is annoying enough that I'm happy to get back on Linux.
Please do. Too many applications have too much access. Why do people not realize they installed literal Trojan horses that visit websites and execute commands found on them (prompt injection)?
Good example because all that code is indeed run sandboxed, which is exactly what we need in native apps as well. "Any website" cannot access anything on my computer without explicit and often temporary permission.
Because that's how computers have worked and should work forever? Without a corporate unerlord randomly restricting access to useful functionality and without inane permission popups for every action?
Edit yes, you'd want proper sandboxes for software. Yet Apple's approach is "pay us 100 dollars a year for software signing and sandboxing" which is not what we want
I don’t quite understand why people complains this is bad for AI agents. Local Code (https://releases.drawthings.ai/p/public-beta-of-local-code-b...) doesn’t require full disk access, when you ask the agent to deal with some files it doesn’t have access to, the built-in ‘permit’ tool will trigger the OS folder grant interface and that information will be recorded both by Apple and by the app so it can be revoked later if you want. That allows you to not give full disk access to the app to be useful.
If anything in a world with agents, these TCC dialogs just need to have an "allow once", just like Location Services has on iOS, and just like most harnesses have, a la "Do you want to allow $AGENT to run the following command?" A. Yes. B. Yes and don't ask for $command, C. No but instead just asking "Do you want to allow Claude Desktop access to files and folders on your Desktop?" A. Once. B. Always C. No
I think the issue comes in with terminal emulators and CLI harnesses. TCC permissions are inherited from the "responsible" process, so if you grant Terminal.app or ghostty.app FDA, you've granted zsh or bash or python or any goddamned thing you can run in a shell FDA.
It is! The directory grant is once and the sandboxed app can save the bookmark for the future access. As a agent program, you can display this so users can revoke / temporarily disable access for a period of time: https://developer.apple.com/documentation/foundation/nsurl/s...
Agree, I think for CLI harness, there is no good alternative, you either have access permit per terminal app (which is not ideal), or I guess that is what Apple means they will "address" it?
Because it's deeply annoying/unenjoyable to have to click "Allow" in the middle of a flow, especially if you're not at the time actually _at_ your computer?
Just add to system prompt: “ask permissions for files and folders you might need upfront. Don’t annoy users with permission request in the middle of the flow.”
In fact, my pet peeve is why can't 1Password build in the ability to "remotely" approve something via the 1Password app? I'd get a push message, hit allow, and it does the negotiation in an e2e encrypted way.
Then I could approve something my agent needs when I'm not at the computer. Service Accounts are a crappy solution to be honest.
Some of the restrictions have already been implemented in macOS 27 by restricting access to (at least some ?) containers even with Full Disk Access on.
One niche issue resulting from this : it broke the ability to access my own screensaver settings and files from it's settings app, because those settings live inside a container for a system extension that belongs to Apple (because Apple still hasn't publicly released it's "modern" screensaver api, it's still old style plugins run by a legacy extension).
Several screensaver developers I know got bitten by this and there's no proper workaround, you just have to use "/Users/Shared" and hope that doesn't go away any time soon.
In my case it silently broke migration for Aerial from 3.X to 4.X in Golden Gate (where I moved away from the legacyScreenSaver extension to the new undocumented wallpaperextension format). I did move to "/Users/Shared" earlier this year but some people will inevitably get caught by this if they didn't update, and there's no recourse, FDA doesn't work, you can't even ask for access, nothing works. And since it's a silent fail, I didn't even notice before this week.
I don't know where this "ownership" debate came from. My ownership of my machine depends on strict, broad + fine grained control over what third-party devs (who are not me) get to do with my machine. Our interests are incompatible and hostile, in an era where most "native apps" ship analytics and marketing SDKs, or are videcoded. If macOS didn't offer these controls I would run every apps in a browser where it's sandboxed. This isn't the 90s.
This change is a reaction to a viral story from a tech reporter who shipped all his texts to Meta without meaning to, which tells you there's a consent and transparency issue for nontechnical users. I don't think anyone in the industry has figured out a proper solution. Unless you never interact with nontechnical people, it impacts your privacy indirectly no matter what you do. Though as technical user I hope we can get more fine-grained control and auditing.
Exactly. Third party software must be to some degree treated adversarially. Yes, even FLOSS software, as that can become subject to things like supply chain attacks. Giving any random program one downloads carte blanche access is as insane as leaving one's doors unlocked and open 24/7. It's inviting serious trouble.
> My ownership of my machine depends on strict, broad + fine grained control over what third-party devs (who are not me) get to do with my machine. Our interests are incompatible and hostile, in an era where most "native apps" ship analytics and marketing SDKs, or are videcoded. If macOS didn't offer these controls I would run every apps in a browser where it's sandboxed. This isn't the 90s.
There are benefits to sandboxing F/OSS too, but most of what you describe there are problems with proprietary software published by for-profit corporations and have dramatically less applicability to anything else.
This isn't 1980 anymore. The internet is super hostile and everyone wants to extract data. You're still free to allow every app on your computer full access, I won't. I am very glad that none of the hundreds of apps installed across my phone and Mac can access my photos and cameras without permission.
My concern is that eventually Apple will require all apps (including non-App Store) to be specially approved by Apple in order to get full-disk-access, even if the end-user wants to allow it; like how there are no third-party iPhone/iPad backup apps.
>You're still free to allow every app on your computer full access, I won't.
Sure. Do I have to reboot the machine and put in special commands in the UEFI? Will the next OS update then revert that on me anyway? Will they silo all the data on a per-app database, then make the machine unjailbreakable?
I have little confidence that I am still free to do this much longer.
That's a reasonable concern and I do hope that there's an escape hatch, but it can't be as easy as "click here for full remote control" or else most people would just do that and fall victim. This already happens regularly and it's what privileged dialogs aim to prevent.
I am old, too, old enough to remember sending personal data over plain http with no encryption and needing to do a full wipe of Windows 98/XP machines on a periodic schedule just to keep viruses and malware off of them.
The idea that application A can just have full blown disk access and slurp up your tax returns or something was always a pretty crazy security posture. It just so happened that an honor system kind of almost sort of worked for a while.
You can’t really do an honor system when people are running artificial intelligence systems that have no concept of morality with full disk access.
Realistically we’re never going to be free of rowhammer and meltdown type attacks. Trying to prevent programs running on a computer from having full control of it just promotes a false sense of security.
If we read the article Apple isn’t planning to prevent programs from having full control, they’re just going to have better separation and user controls for “full disk access” versus “access to a limited subset of folders.”
This will allow programs like Spotify to only specify limited folder access while it’ll allow programs like Backblaze Backup
To specify full disk access.
I think its crazier that every app installed by default gets Cellular Data and on WiFi, its even worse because theres not even an option to granularly decide which apps should or shouldnt have that.
Things that have no conceivable need to phone home just get it for the hell of it. Its basically Full Disk Access but for Network Access which is arguably equally problematic
> 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.
If you think an app from (say) Facebook can be trusted with unrestricted access to your whole machine, you're at least a bit naive.
When I hopped onto the Linux bandwagon in the 1990's, the community was touting its amazing security because any damage done was compartmentalized to a particular account. (Of course, that ignores root escalations. Of course, few Linux users cared about that back then because it was an obscure operating system.) In contrast, Macintosh and Windows (non-NT) security was non-existent.
These days, I find increasing security measures both burdensome and restrictive. That said, it is also necessary. We have long left the era when one could trust supposedly reputable software vendors -- never mind random developers.
being a nerd here, sudo - yes, but indeed I thought the entire UNIX design of everything is files and there are permissions, groups, etc, should be sufficient.
But I think the "new world" is, we are over stimulated (eg. agents ask us 'permissions' for a long command) so we might give a sudo not fully aware of it where a big bold UX message box after a 'pseudo' sudo would better catch our eyes.
So it seems this is about adding additional layers over already existing ones in a way?
this is mostly a benefit to the owner. Every security feature , including firewalls, authorization ACLS, etc could potentially be used to reduce the owners rights, but they’ve all been necessary .
I’m with you on ownership, but push against signed code restrictions especially with bootloaders, and closed drivers.
macOS has been revoking access to stuff like this over the past decade. Things like unfettered access to modifying the OS went away with Gatekeeper and System Integrity Protection. "root" access is no longer true root on any Mac, and the user is treated like a prisoner. The UAC-esque prompts that come up in macOS would make Vista-era MS so jealous.
root access is also no longer true root access on a lot of linux distros that are immutable, and container-esque like interfaces such as namespaces + cgroups also limit roots power.
Pointless comment as the same holds true for macOS. Yes, you can load unsigned kext still, and yes, you can modify the userland. Not as easily, but I would argue it is also not harder as on an immutable linux distro.
And despite hyperbole about Apple locking down macOS, ending the era of personal computing, it's hidden behind a toggle in settings. https://www.xkcd.com/1200/ applies, and in the era of downloading random programs off the Internet and cryptocurrency, random programs should have to jump through an extra hoop before getting access to everything. Imo Apple went a bit overboard with granularity, but it's not 1990 and the Windows 98 (lack of) security model doesn't work, and neither does Unix permissions either.
It works just fine for any user with a modicum of sense. I know many people, not technical people at all, who avoid running malicious programs just fine. I don't see a reason why we should lock down everyone all for the sake of a minority who simply refuse to take responsibility or learn.
No, you're not getting old. Tech companies are getting more and more paternalistic, refusing to treat users as adults who can make their own decisions. It's profoundly irritating.
Also, if you are really old, you may remember how unhappy people were when wheel group appeared, and not everyone could "su" to root anymore. Giving everyone root was supposed to be normal!
I'm sure it'll be a permission the user can toggle. So they won't be taking away the ability for apps to see all the files but they'll be adding an extra layer of security so users can choose what an app can see. They're being light on details at the moment though.
But this is what it is currently. At the moment, not only is it a toggle, but unlike almost all other permissions, you can't just request the permission.
You have to send the user to the system settings pane for it and have them manually toggle it on there.
It's hard to imagine how it could be more explicit than it is currently. I imagine they have something draconian planned.
This week, I formatted my entire Mac fleet (an iMac Pro and four MacBooks), and now neither AI agent runs natively. I am using LIMA (https://lima-vm.io) to isolate them in a sandbox, exposing only a repository. I lose some integration, but the peace of mind is worth it.
What we need is true application isolation even in the command line. Treat Terminal as privileged access, not something any app can just command. Sandbox non-app store apps as well.
Whenever I ask Claude to vibecode macOS native apps for me, I always request the apps to be sandboxed. Agents know how to sandbox the apps; just ask. And you can verify it without reading any code.
Call me a paranoid but I'm afraid of the harness itself, not the apps it generates. You can see lots of people being concerned with Deepseek Harness being Chinese, but I share the same sentiment towards all AI-based software that can run unsandboxed on my computer.
This is a fluff piece that has zero technical details. But I find your logic very interesting: if the presence of one CVE in sandboxing makes sandboxing untrustworthy, should we not have long ago discounted the entire security of Linux due to many CVEs for privilege escalation? Or the security of any and all browsers?
Folks like to cite how capability OSes are a great thing, and I certainly appreciate the concept, and, no, MacOS, is not a capability OS.
However, it feels like one to the User. Having to get constantly prompted to grant permissions they don't even necessarily understand to random programs.
There's been chatter about how system like iOS are not "document based", they're app based. Many apps do not present their data as "files", users don't know where their data resides, just that the app knows and that's their window.
I don't know where an application on MacOS can "save their files" if they don't have "Full Disk Access". I don't know if they get some directory "for free" that they can use much like iOS does.
Then, of course, there's the Apple Document model where data auto saves to Somewhere. You have versioned files you can work with. But until you actually "save" the file to "the disk", its living in some unannounced space. My TextEdit app has dozens of "Untitled-XX" files that are...somewhere.
And its great! There's a peace of just having "stacks of stuff" that you can leave "unmanaged". "Where would you like to save your work?" "Oh, great, cognitive load just exploded as need to think about the minutia of data organization, when, mostly I just "don't want to lose this".
But, the constant prompting is exhausting, to me. Again, I have to "think about it". I need to question everything, when I really just want to Get Stuff Done.
And, in time, we become blind to these prompts. "ok, Ok, OK!! GO ALREADY! JUST WORK!!".
Sandboxed Mac apps have access to their own container which includes directories like Documents/ and a temporary directory and more where they can save anything just like on iOS.
That’s not quite how macOS sandboxing works. Users expect to be able to save and open (non-iCloud Drive) files in ~/Documents, not in a containerized silo. If the app uses NSOpenPanel/NSSavePanel, those work with the system to grant the app a sandbox extension to the location the user chooses in the open or save panel.
Yes. Sandboxed apps do get their own home directories (~/Library/Containers/.../Data) and this home directory does contain a Documents directory, but this is just for compatibility's sake – there is no reason to actually use it for anything. Files that an app saves by itself are typically expected to be stored under Library/Application Support or Library/Caches, and this is still true even for a sandboxed home directory. Documents is reserved for files the user saves manually, but as mentioned, manually-saved files should reach the real ~/Documents.
Though, there is also a third type of Documents directory, the kind located at paths such as ~/Library/Mobile Documents/com~apple~TextEdit/Documents. This is part of iCloud Drive and is the same directory that you get in Finder by going to iCloud Drive -> TextEdit. Very confusing.
It's really gotten out of hand. Trying to literally plug something in results in at least one (sometimes multiple) prompts being like "are you SUUUUURE you want this plugged in?"
It's fine if there is a super streamlined flow for access that works with legacy apps and runs in user-mode. Otherwise this might seriously hurt MacOS as a viable development platform.
If it worked as intended, they wouldn't be in this predicament.
That feature was so stupidly nonfunctional before. Some apps got stopped by it, others didn't. Often you'd be able to install an app from homebrew and it had full ride access to the disk, while App Store apps had to request consent for any folder whatsoever. It was completely random.
I think macOS 27 has already shipped a version of this. I remember seeing a prompt for Firefox requesting access to Google Chrome data (presumably to import bookmarks/history?) recently.
If that's the direction things are moving in, I welcome the change. Fine-grained folder access controls (rather than only full iOS-like sandboxing or full disk access) make me much less hesitant to try new apps or have agents access more parts of my system.
But they really need to solve the issue of low-level utilities triggering dozens of permission prompts when walking $HOME. Having to approve or decline Documents, Downloads, Google Drive etc. directory access, all separately, is extremely annoying.
This also affected me (with Firefox specifically). Looking into it, I ran across this blog post. It looks like macOS 27 has specific app data that it’s now preventing unexpected reads from. https://wojciechregula.blog/post/golden-gate-appdata-protect...
I agree that this seems like a good thing. I really don’t need Firefox (or any app!) trying to check another app’s data without explicit permission.
How do you mean? The sandboxes of both iOS and Android have been a resounding success; bugs exist and malware is not impossible, but orders of magnitudes more complex to deploy than on traditional unsandboxed desktop OSes.
The android one isn’t all that great. iOS sandboxing, to a great extent is a 2 step system - the app store and entitlements limit the attack surface long before the sandbox gets tested. That is not necessarily a bad thing. The sandbox on iOS would be forced to be a lot more secure if people were allowed to use the whole ABI of the kernel.
I feel like this isn't going to be a simple permission popup. Probably along the lines of getting an "unapproved" binary to run, where you have to stop what you're doing and wade through settings, trying to find the right toggle 6 nodes deep in the tree.
I am a developer and recently I was troubleshooting an issue with my macOS app where it was working fine on newer macOS but failing on older one only when I archived it (last step before submitting an app for Apple approval). So I'd archive it on my new macOS and airdrop to old macOS and try to run it. Every single time, it'd tell me it was unsafe and ask me whether I'd like to delete it. I'd have to dig through multiple settings screens to "open anyway", enter my password to get it to finally run. What a nightmare not being able to easily run my own app despite having same developer account and Apple ID.
Great, cant wait for the inevitable "Are you sure you want to grant full disk access" prompts every week for eternity until the user is exasperated and revokes access.
Don't be naive, them telling you this in advance and straw man arguments like:
For communication apps, this can also compromise the privacy of the people users are communicating with.
Let me think that they try to sugarcoat a coming change that has the purpose of transforming your computer as an ipad where you have no access to most of it except what is approved by apple.
For the "greater good" as usual.
Just look how deceptive is the Apple post "full disk access" is not even a thing. You have access to your user files and that is all. You need sudo to have more rights.
A normal copilot/Claude/facebook like app shouldn't ask you for such a right except exceptionally for a very good reason.
So when they speak about backup apps, that are the one that could need sudo to backup the whole system, is to tell you that soon only notarized apple approved and app store delivered apps will be allowed to do that, but certainly not you willingly. Maybe not in version 1 but in version 2 for sure.
Then, like for iOS, they could have proprietary apps like Netflix, Facebook and co storing data on your device that you will not have access to.
Apple, as always, seem extremely determined to make sure that they protect things on your computer from being accessed by you.
Apple Intelligence is a great example of this. Everything can funnel up to Siri, but neither you nor any other app on your computer can see what is fed to it by all of the APIs that would provide it data. So anyone who adds support for it is enabling Apple to do their usual slow broken thing with Siri and not enabling any other way you might want to use software or AI with that data.
> protect things on your computer from being accessed by you
This has nothing to do with your access to the disk and everything to do with 3rd party deceiving unhindered access to everything about your life because you installed something like Muse.
Would it really be too much to just allow the user to grant the permission that they want? You already have to jump through special hoops for full-disk access, and there's ALREADY a big warning at the top, explaining that it grants access to things like messages and such.
Above all, we need a true privilege separation API at the application level. Why is the only way to sandbox my code editor to run it in a Linux VM on the Mac? And that’s solely to mitigate supply-chain attacks.
The simple root/user separation has long since ceased to be secure because, on a desktop machine, all sensitive information is, by definition, accessible to the user; having root privileges ultimately offers little advantage when it comes to exfiltrating data.
> 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
"Extraordinary" is a funny word choice. It was completely ordinary for most of the history of personal computing that any app you ran under your normal user account could see everything you had.
(I'm not saying this is a bad thing. As long as they allow informed users to continue to do whatever they please, I'm all for it.)
Now if only any of these controls would let me stop Adobe from creating a “Adobe” folder in my iCloud-synced Documents folder, that would be swell.
I simply do not understand how Adobe manages to bypass every single toggle available there. I can block access to every folder on my computer but the moment I open any Adobe app, they recreate that goddamned folder.
Why? How? Fucking hell Adobe. It’s 2026, you just don’t store cache and setting files in the fucking Documents folder.
I don't understand why this is a problem at all. AFAIK macOS is UNIX, so you can create user accounts and run programs as separate users. This is what I routinely do on Linux to run coding tools or other programs that should not have "full disk access," in particular to the files and mounts of my main user.
Imagine having a personal assistant paid by a sketchy surveillance company. They can't do personal assistant stuff without full access to your email, calendar, etc., but the company paying them wants to harvest your personal data.
Personal assistants are realistic for very rich people because they can be paid an extravagant wage and punished for disloyalty. A personal assistant costing pennies to someone else, with access to data worth more than its salary, makes no sense.
Wasn't there also ongoing confusion within the macOS team about if "Full Disk Access" meant "rw privs to all disks" or "turn off TCC sandboxing but use the current user's privileges"?
I dislike restrictions out of instinct, but to be fair, I've had permissions request popups on my Mac that were the first sign of software, which I had actually written, maybe had some bugs allowing it to work outside of its intended bailiwick.
Is it really that surprising that in a world where we are redefining the meaning of user, that our user based file system security controls will have to change?
Man, I just want Discord to have the ability to do overlays on Mac like it can on PC so I can see who is talking when I’m playing video games. Where is that API update?
My understanding is that Meta Muse simply opens the System Settings Full Disk Access pane, and the user has to enable it themselves using System Settings, which says, "Allow the applications below to access data like Mail, Messages, Safari..." and which requires an administrator password to change.
Thus, I'm not sure what more Apple can do here, but I'm definitely afraid of what they're going to do.
In reality, the "full disk access" restriction system never actually worked right. I'm positive Apple is just trying to save face here and quietly fix it while saying they're "tighting" it
This is a baseless conspiracy theory. Provide proof. No, the confused ramblings of one journalist who is trying to save his own face for granting FDA to Muse does not count as proof.
I totally had pi+qwen3.6-a35b wipe out my entire USB das yesterday migrating it from ntfs drivepool to apfs, 10tb since I'm done with windows. Been joking about qwen wiping out my laptop for a year now and was comfortable enough to just let it look at my storage and it immediately formatted. lmao.
I had 3 duplicate files on each drive and it was impatient and rushing and didn't keep one drive around before formatting them all.
Completely saved me the week of migrating files project I was dreading, thanks. Nothing invaluable but an insane amount of downloading to do and I'm on 5g in the woods.
Sometimes its just draw dropping at how stupid these can be, basically giving a 6yo RHCSE root access.
When I give something a "Full Disk Access" permission, I expect it to have full access to what's on my disk, including "files, mail, messages, and even (gasp) browsing history"! Who are those mysterious people who expect their browsing history to be magically excluded from something called Full fucking Disk Access?
The problem isn't people who intend to provide full disk access. It's the people who unthinkingly grant full disk access to, for instance, Codex, because the AI asked them to.
Those people simply cannot be helped. At the end of the day, you can't stop people from hurting themselves by being too credulous, not without taking away their freedom. Those are the choices: either you accept that some people are foolish and will make bad decisions, or you circumscribe their ability to make decisions. There's no third option, because any halfway measures you take (like what Apple has done with these full disk access permissions) will be mindlessly ignored by someone who is too lazy or foolish to actually think about what they are doing.
Maybe it's just my pet peeve, but it's less about my documents and mail and more about programs, tools and AI harnesses deciding they can fill hidden dotfile folders at root with whatever they want (which they do indiscriminately). I don't just hate that there's tons of untracked caches and temp file data that isn't easily discoverable, but more specifically, I don't want all that crap in my root directory.
Who decided that hidden folders are a good thing anyways? .agent, .agents, .aws, .bun, .cache, .cargo, .claude, .codex , .config, .docker, .gemini, etc. I just end up having to show hidden folders all the time, which defeats the point.
It's gotten truly ridiculous. I want the OS to strictly enforce my root directory. There should be a few global preference files in there for like .zsh, and everything else organized in proper, unhidden folders.
Ironically enough, the UNIX fathers themselves realized that the hidden files idea was terrible and in the 90s kicked them off completely out of Plan 9 and moved user configs to the $home/lib. And yet we still have our home directories being insanely cluttered with dot files.
Oh, I really meant the latest trend of every AI agent having their own dot folder in root. I think Anthropic set off the trend with ~/.claude/ and I really wish everyone would stop now.
Yeah, meant the same thing, polluting user folder with invisible droppings is an ancient (and international, Windows is similar with Documents) pastime. There are some apps that respect XDG env vars instead of ~/.app
> Huh? Seems like a disingenuous statement. I hope they update that sentence with something more accurate.
Right, the classic use case for FDA is Terminal app, not backups. I don't think backup apps even need FDA, because they use the Apple ASR tool that already has special permissions.
Even developing bog standard apps. MacOS without FDA is the death of creativity and productivity.
The permissions/security model should've expanded faster. There's huge benefits to being able to install arbitrary software and not worry about giving it access to everything.
But it would never cover everything to do with a computer.
> TCC permissions don't care if you're root or not.
That wasn't the the point, though. The point is that asr has special private Apple entitlements, allowing it to do things that other processes can't, but it requires root to run asr, so asr can't be triggered willy-nilly by any user process.
> We give developers powerful APIs to build incredible capabilities
> Full Disk Access largely sidesteps these controls
That's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk"
For example, if you care about "mail, messages, and even browsing history", why isn't there a subset of "full disk access except for reading mail/messages/browsing history"? Or if vibe code have some basic disk sizing functionality to ask questions about your files, why can't it have a more granular "full disk read only access for file sizes only" so that your vibe coded disk visualization app can't destroy your data or your privacy
> can only do so with very explicit user action.
Which is in the same vein and is mostly useless, just another inconvenient bump
I have a file search app that does its own indexing similar to Everything on Windows (https://lowtechguys.com/cling) and I only index paths.
I don't need file contents, I can skip showing file sizes and date modified on protected paths. Hell I can skip indexing Mail and Messages files altogether since they're pretty useless anyway. But how am I supposed to know beforehand which path will trigger a scary Cling wants to see your <private folder> when doing a simple traversal.
Similarly, window switchers like my rcmd app (https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
This goes on and on.
Want to register a more interesting hotkey like fn-letter? You have to act like a keylogger and ask for Input Monitoring.
Want to focus a specific window instead of activating the app and letting the OS decide which window comes forward? You need Accessibility permissions and full access to control the whole computer.
Want to paste some text into a text field? Accessibility Permissions.
Too granular permissions is hell. But there are these decade-old common use cases for macOS utilities that would make it much easier to keep permissions locked if they became their own permissions.
I have a disk monitoring app that also gives quick access or the ability to eject external drives. Without Full Disk Access, you can’t open a Finder window to the root of the external drive. You can open the parent and select the disk mount point.
I burned a support request on this years ago, and was told that it seemed like a good idea for a future update… a API to open a Finder window at a known path.
macOS used to be one of the most power tool friendly operating systems. Apple Events and AppleScript dictionaries made automation like this so easy. Now everything requires a special permission or specialized Kit to do things that were simple two decades ago.
Personally I’m switching to Omarchy the minute they’ve got an Apple silicon image. Been on macOS since the 90s. I just want to be able to tell the papercuts to go away. Not confident in Apple’s ability to scratch that itch anymore.
I'm not sure I will migrate to Omarchy, but seeing the hype around the system gave me incentive to create TUIs for most of my apps. I'm making my day to day DX as OS-neutral as possible until I finally move to Linux.
> Similarly, window switchers like my rcmd app (https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
Window titles can and often do contain very personal information. A window titled "Planned Parenthood | Official Site" in the hands of a bad actor or some relative-monitoring spyware could have disastrous consequences.
> Want to paste some text into a text field? Accessibility Permissions.
Only if you aren't relying on user-initiated pasting like right click ' cmd+v.
Of course, not saying those should be allowed by default. But being such often used in utilities, they would benefit from
Instead of the scary and totally unnecessary screen recording permission.I fully support you on your's previous comment but here I need to remind you what it is you who understand the implication of that query. Regular Joe isn't. And even more importantly is what the vendor is not on R.J. side, it is on the advertising side[0] where the excessive knowledge about a user is the thing.
Like just 15 minuts ago I opened Untappd likr a bazillion times before and were present with 15 screens of toggles and like 250 entities at least. There were at least 10 permissions to give the consent to track the things I do outside the app.
So not only a detailed reason for the permission wouldn't work, it wouldn't be implemented in the first place,
I totally agree. It's a shame that the ACL stuff in UNIX-based systems hasn't been changed in the last 20 years (xattr doesn't count).
Having had the (dis)pleasure of working with SELinux, it's clear that there are systems out there that can work to solve these problems. On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
> On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
SELinux was originally designed by the NSA to serve their needs, which are probably a bit more intense than "normal" users, and that was over 25 years ago. I'm not convinced a fresh effort couldn't do better, though I'm more skeptical that anyone is willing to invest the resources.
The Russians did, with Astra Linux. They didn't do better
Has it substantially changed since the 1970s introduction of user / group / others octal permissions?
Yes. The name that you should look up is Trusix.
Trusted Unix Working Group (Trusix) Rationale for Selecting Access Control List Features for the Unix System
https://irp.fas.org/nsa/rainbow/tg020-a.htm
What is the signficance now of this 1989 report?
How would you design such a system to be granular enough to solve for arbitrary application needs without being so complex as to be impossible to tune without false positives and false negatives all over the place?
It's not like people have tried to improve core security models, but in my opinion it's not really compatible with the core filesystem abstraction that programmers and power users of desktop computers demand. I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
> I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
How is moving to iOS's model not nerfing the OS?
Sorry I wasn’t suggesting changing a desktop OS operating system. I’m saying that other paradigms offer a more securable substrate.
That doesn't change the point. Sure, iOS is technically more secure, but it's also increadibly nerfed compared to desktop OSes.
So what? No one is disagreeing with you about that. The thread was about adding fine grain security controls to traditional OS filesystem access. I was just using iOS as an example, I could just have easily talked about containerization, as a security solution. Of course all those solutions are more limited than a local filesystem—the entire paradigm is designed around full control, you can't bolt on granular security. Heck, even basic UNIX permissions are pretty janky and unmanageable, but at least they more or less work everywhere since they've been around forever. Inventing something now is guaranteed to be annoying and useless.
IMHO, it's good to add more specific controls for this. After reading this, I went and checked my list of app with full disk access:
- Ghostty (fine, it's my terminal)
- Alfred (fine, I use it for searching everywhere)
Then I have a few turned off:
- Spotify (why does it need full disk access) ??
- Gemini (nope, don't need it to know everything about my computer)
Terminal is a significant risk though and I’d still really like to see macOS improve the APIs around filesystem access.
Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.
Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).
This is why I use Terminal as my primary terminal, and iTerm as my AI terminal. iTerm gets no permissions, I move specific things to Terminal to do it. Plus I can then style them to optimize for the different usages. And iTerm has better harness hooks anyway.
I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.
> Granting terminal full disk access grants arbitrary scripts full disk access.
Indeed, I run all dev tools including coding agents inside sandbox now
https://github.com/ashishb/amazing-sandbox
I do the same but I rely on devcontainers because editors like vscode, zed, etc… provide native support. It seems easier to use than asb.
If you open a project using a devcontainer it prompts you to build one. As long as you install all the tools you need in it, it just works.
Orbstack is much nicer than Docker to host the containers.
> Granting terminal full disk access grants arbitrary scripts full disk access
No, it grants scripts I run full disk access. Unvetted scripts do not run in my terminal, so there are no secret sub-processes either.
I would want terminal and all its subprocesses to have full disk access - I do tons of stuff from the command line and don't run nonsense stuff.
get out of my way.
- Ghostty (fine, it's my terminal)
But your terminal shouldn't be accessing any files; you just need to be able to launch /bin/zsh or whatever you use as your shell. The shell needs to be able to access files, but its container doesn't.
Of course, you could go farther. For example, on OpenBSD, even /bin/ksh has been somewhat sandboxed; it can see most of the file system, but the things it can do have been limited:
If you try to ls / for example it's going to pop up a request to access your disk, multiple times. It's rather annoying.
Why would ghostty try to access your disk when you run 'ls /'? ghostty isn't opening any files -- ls is.
The TCC system attributes the access to Ghostty because that’s the thing the user understands as the app they are interacting with. Otherwise every `posix_spawn()` and `system()` call would result in a new TCC prompt attributed to an inscrutable name.
ls does not live in an .app bundle and it is not managed by launchd. The TCC framework (which implements sandboxing on macOS) and the rest of the UI only respects .app bundles since that's the thing the user sees. The fact that ghostty is fork/execing another process to to the disk access is immaterial to it - hell, if Apple had their way only launchd and Safari would be able to spawn processes at all (like on iOS).
I mean, think about it: what would it mean if ls had a separate sandbox identity from the shell that spawned it? It would mean that any process on the system not entitled to read files from disk could get that entitlement by just fork/execing ls and parsing its stdout. That's not a security boundary that makes sense. ls doesn't read files - ghostty reads files, and ls is just its deputy.
macOS attributes shell commands to their parent app bundle.
That seems like a massive hole in the model that would make it very hard to lock down multi-process/privsep programs like sshd.
Sandboxing something like that is challenging, yes. But probably not for this reason you can always disclaim responsibility for your process.
It really isn't; the program just needs to be able to declare what it expects it should be able to do, and what it expects its children should be able to do. The latter doesn't need to be a subset of the former.
The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
But yes, it's unfortunate that macOS sandboxes cannot be nested.
This position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
Yes, and macOS entitlements work similarly, as you know. I was interpreting “what it expects its children should be able to do” as a single rule for all child processes, like in OpenBSD pledge() which the parent seems to be referring to. Sure, such a rule could securely be greater than the parent’s own permissions if you strictly limit what processes can be executed with what arguments.
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.
>The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
That assumes you're only defending against malicious code. Spawning children with limited functionality is a useful defense against non-malicious code being exploited by malicious data, even if those children have privileges the parent lacks.
That “just” is doing a LOT of work.
It's already done on OpenBSD, and linux has the pieces to do it, though it's far more fragile and complicated. I'm not speaking hypothetically here, I've implemented code that works this way.
You are minimizing the difference in scope between the audience and applications of OpenBSD and those of macOS.
macOS has had a capabilities model for over a decade called App Sandboxing. It would be entirely impractical to expect app authors to correctly declare their permissions up front and for users to audit them. Hence the permissions granted to sandboxed apps are pre-determined by the OS, and can be extended through explicit user interaction.
If the child could do different things to the parent malicious processes would spawn child processes to do stuff they shouldn’t be able to do, though
This is really hard to do in general
Indeed, is only the OS mastermind had billions and years to fix the foundation...
While looking at resources invested is necessarily a great measure of difficulty, it is somewhat indicative, yes.
you mean "isn't"? Though there is no indication that a lot was invested, so doesn't give you the measure (my comment was about the availability of resources, not of their actual use)
I did yes, sorry
It's done on the majority of the OpenBSD base system, as well as important ports like Chrome and Firefox. Linux also has the parts to do this, though it's more fragile and complicated.
To be clear I have a much higher standard for what is acceptable than that, you really need to consider software that a hundred million people are going to use
Indeed. It’s very inconvenient to ‘cd` and have to do the whole permission dance to read a file
ghostty is the .app, perhaps it makes more sense if you imagine some other app, Spotify.app say, imagine for whatever reason it shells out to ls for listing files, it will show as Spotify requesting access not ls.
Spotify has (had? I no longer use it) a feature that would allow you to make local media available as part of your library anywhere so long as your machine was on and connected to the internet. I would imagine that feature requires disk access under these sandbox / permission models.
Edit: I should say, the model it was created with (select a folder, all media in that folder is mirrored) requires such permissions. One could imagine designs that don’t.
That sounds like something doable with the ordinary select-a-folder permission picker, no full disk access needed.
The gap here in functionality is between 'single manually specified folder/file' and 'entire disk'.
> had?
Still does, at least on Windows. I use it all the time - I have a playlist with a mix of Spotify music, and music from my server.
I haven't tested Apple's access model, but is there something that's stopping Gemini from launching `ghostty -e /bin/sh malware.sh`?
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
So if your terminal has access, your claude in the terminal has access too? that doesn't fix anything
But how is Gemini going to repair your filesystem and restore lost or deleted data?
It won't need to if it can't break my filesystem or lose and delete my data in the first place.
Windows Vista reborn :(
Came across this blast from the past the other day. Funny how the tables have turned.
https://www.youtube.com/watch?v=VuqZ8AqmLPY
I wouldn't allow your terminal full disk access, that's quite a risk vector.
I have to have my machine further crippled in order protect people who don't know what they're doing on a computer.
I don't think there's anything wrong with people not knowing how to use a computer properly. In fact, I wouldn't expect a normal person to, why should they? So what I would love to see is normies be given iPads, and my computer left the hell alone.
It's like if we over-simplified all the controls in a cockpit because someone who likes playing flying games finds it too difficult to fly a real plane.
We've had a solution to this for a long time in various programs - let the user tell the application how much they know. By default, settings are extremely limited, but you can change settings to "advanced" or "expert", and more options/settings become available.
There is no reason this couldn't work for permissions as well; beginners get the system locked down pretty well, whereas advanced users get a more open system they can do more with, at the expense of potential foot-guns)
(As a side note, we could probably make a plane that had this principle applied as well. With autopilot where it is today, we could easily make a commercial plane that grandma could fly under most circumstances - you just need that real pilot and extra controls for when things go wrong.)
The reason this doesn't work for the OS is that applications invariably ask the user to set settings to "expert" and toggle this and that in order to take full advantage of features.
So I still think the solution is something like iOS or Android. I can not think of anything a non-CS person needs to do that can't be done on those platforms.
>> I can not think of anything a non-CS person...
Install an app. For apple you need to try test flight to find out too many people use the app so you need to be able to install in developer mode.
I can understand the argument that you should have some technical competency to evaluate that these programs are safe to install, but neither accounts for a technically competent friend/family member suggesting/helping you install an app. Apple requires expertise to even keep an app that doesn't pay to be on the app store installed longer than a week.
Apple offers that for Macs in many ways. Set your security policy level to Reduced or Permissive:
https://support.apple.com/en-mide/guide/security/sec7d92dc49...
I would like the ability to see which specific folders I have granted access to on an app by app basis. And edit. It’s not clear to me how you revoke an app’s individual folder access after you have granted it.
I have been wanting this for years.
For those who haven’t heard of this, sandboxed apps can request access to a file or folder and persist such access using a security-scoped bookmark. The user however does not know whether the app chooses to persist this bookmark or not; in other words the user does not know whether in each case they are granting a one-time access or persistent access.
This is unrelated to Full Disk Access, though.
There are already folder-specific permissions for every app, including non-sandboxed apps: Desktop, Documents, Downloads. FDA is "everything else". The user has to specifically grant each of those permissions via a system dialog.
With sandboxed apps, you grant access to a file outside the sandbox via a system dialog, open or save. But with non-sandboxed apps, if there were separate permissions for each specific folder, there would have to be separate permission dialogs for each of those folders, and then macOS would become even more of a permissions dialog hell than it already is.
Bitrot by Design.
Reminds me of iOS's terrible treatment of PWA local storage. A PWA's offline availability can be revoke at any time the OS decides it knows better than you what your storage should be used for.
For the folders that prompt the access control requests, that should all be in System Settings -> Privacy & Security -> Files & Folders. Each app that's been granted permissions should appear there, and if you click the disclosure triangle, it will list the individual folders with toggles for each.
One update away to revoking Full Disk Access in the future. This commercial has come full circle: https://www.youtube.com/watch?v=VuqZ8AqmLPY
You could say that about anything, in any OS. Windows is one update away from insulting the user whenever they login. MacOS is one update away from mining crypto for Apple. Android is one update away from sending spam to all your contacts.
The point is about trajectory. Apple continually removes rights from developers, and then users, but grants all those rights to themselves. This has been going on for a while. I left the Apple ecosystem in 2011 because I was concerned about the direction, and in the intervening 15 years, I have not regretted it. The amount of random breakage I get on Mac is annoying enough that I'm happy to get back on Linux.
I think it’s the threshold of them getting-away-with-it without too many people wielding pitchforks.
Please do. Too many applications have too much access. Why do people not realize they installed literal Trojan horses that visit websites and execute commands found on them (prompt injection)?
Accessing any website is basically Remote Code Execution, but for some reason starting up a browser isn't a CVE.
Good example because all that code is indeed run sandboxed, which is exactly what we need in native apps as well. "Any website" cannot access anything on my computer without explicit and often temporary permission.
Because that's how computers have worked and should work forever? Without a corporate unerlord randomly restricting access to useful functionality and without inane permission popups for every action?
Edit yes, you'd want proper sandboxes for software. Yet Apple's approach is "pay us 100 dollars a year for software signing and sandboxing" which is not what we want
I came across this the other day and immediately thought of modern Mac. EVERYTHING is a permission prompt!
I get that it's the safe way to do things, but even as a power user who is concerned with that type of stuff, it's overwhelming!
Hah! I had forgotten this ad. Using a mac nowadays is definitely just like Windows Vista in this ad.
Need some Vaseline for your slope?
Inshallah
I don’t quite understand why people complains this is bad for AI agents. Local Code (https://releases.drawthings.ai/p/public-beta-of-local-code-b...) doesn’t require full disk access, when you ask the agent to deal with some files it doesn’t have access to, the built-in ‘permit’ tool will trigger the OS folder grant interface and that information will be recorded both by Apple and by the app so it can be revoked later if you want. That allows you to not give full disk access to the app to be useful.
If anything in a world with agents, these TCC dialogs just need to have an "allow once", just like Location Services has on iOS, and just like most harnesses have, a la "Do you want to allow $AGENT to run the following command?" A. Yes. B. Yes and don't ask for $command, C. No but instead just asking "Do you want to allow Claude Desktop access to files and folders on your Desktop?" A. Once. B. Always C. No
I think the issue comes in with terminal emulators and CLI harnesses. TCC permissions are inherited from the "responsible" process, so if you grant Terminal.app or ghostty.app FDA, you've granted zsh or bash or python or any goddamned thing you can run in a shell FDA.
It is! The directory grant is once and the sandboxed app can save the bookmark for the future access. As a agent program, you can display this so users can revoke / temporarily disable access for a period of time: https://developer.apple.com/documentation/foundation/nsurl/s...
Agree, I think for CLI harness, there is no good alternative, you either have access permit per terminal app (which is not ideal), or I guess that is what Apple means they will "address" it?
Because it's deeply annoying/unenjoyable to have to click "Allow" in the middle of a flow, especially if you're not at the time actually _at_ your computer?
Just add to system prompt: “ask permissions for files and folders you might need upfront. Don’t annoy users with permission request in the middle of the flow.”
This works alright.
In fact, my pet peeve is why can't 1Password build in the ability to "remotely" approve something via the 1Password app? I'd get a push message, hit allow, and it does the negotiation in an e2e encrypted way.
Then I could approve something my agent needs when I'm not at the computer. Service Accounts are a crappy solution to be honest.
[flagged]
Some of the restrictions have already been implemented in macOS 27 by restricting access to (at least some ?) containers even with Full Disk Access on.
One niche issue resulting from this : it broke the ability to access my own screensaver settings and files from it's settings app, because those settings live inside a container for a system extension that belongs to Apple (because Apple still hasn't publicly released it's "modern" screensaver api, it's still old style plugins run by a legacy extension).
Several screensaver developers I know got bitten by this and there's no proper workaround, you just have to use "/Users/Shared" and hope that doesn't go away any time soon.
In my case it silently broke migration for Aerial from 3.X to 4.X in Golden Gate (where I moved away from the legacyScreenSaver extension to the new undocumented wallpaperextension format). I did move to "/Users/Shared" earlier this year but some people will inevitably get caught by this if they didn't update, and there's no recourse, FDA doesn't work, you can't even ask for access, nothing works. And since it's a silent fail, I didn't even notice before this week.
I didn’t realise screensavers were still a thing… straight to off.
Am I getting old? "full disk access" used to be something that's supposed to be normal; if you're the owner of the machine.
> Am I getting old?
I think so.
I don't know where this "ownership" debate came from. My ownership of my machine depends on strict, broad + fine grained control over what third-party devs (who are not me) get to do with my machine. Our interests are incompatible and hostile, in an era where most "native apps" ship analytics and marketing SDKs, or are videcoded. If macOS didn't offer these controls I would run every apps in a browser where it's sandboxed. This isn't the 90s.
This change is a reaction to a viral story from a tech reporter who shipped all his texts to Meta without meaning to, which tells you there's a consent and transparency issue for nontechnical users. I don't think anyone in the industry has figured out a proper solution. Unless you never interact with nontechnical people, it impacts your privacy indirectly no matter what you do. Though as technical user I hope we can get more fine-grained control and auditing.
Exactly. Third party software must be to some degree treated adversarially. Yes, even FLOSS software, as that can become subject to things like supply chain attacks. Giving any random program one downloads carte blanche access is as insane as leaving one's doors unlocked and open 24/7. It's inviting serious trouble.
> My ownership of my machine depends on strict, broad + fine grained control over what third-party devs (who are not me) get to do with my machine. Our interests are incompatible and hostile, in an era where most "native apps" ship analytics and marketing SDKs, or are videcoded. If macOS didn't offer these controls I would run every apps in a browser where it's sandboxed. This isn't the 90s.
There are benefits to sandboxing F/OSS too, but most of what you describe there are problems with proprietary software published by for-profit corporations and have dramatically less applicability to anything else.
Enough open source stuff gets grabby too. Especially when small devs sell out.
This isn't 1980 anymore. The internet is super hostile and everyone wants to extract data. You're still free to allow every app on your computer full access, I won't. I am very glad that none of the hundreds of apps installed across my phone and Mac can access my photos and cameras without permission.
My concern is that eventually Apple will require all apps (including non-App Store) to be specially approved by Apple in order to get full-disk-access, even if the end-user wants to allow it; like how there are no third-party iPhone/iPad backup apps.
> like how there are no third-party iPhone/iPad backup apps.
I might be missing something but isn't this exactly what iMazing[0] is? I know I use it to backup my iPhone, for example.
[0] https://imazing.com
I think GP was talking about backup apps that run on the iPhone/iPad itself.
It's still possible to back up an iPhone to a jailbroken computer, using roughly the same iTunes sync system that was available on iPods. For now.
>You're still free to allow every app on your computer full access, I won't.
Sure. Do I have to reboot the machine and put in special commands in the UEFI? Will the next OS update then revert that on me anyway? Will they silo all the data on a per-app database, then make the machine unjailbreakable?
I have little confidence that I am still free to do this much longer.
That's a reasonable concern and I do hope that there's an escape hatch, but it can't be as easy as "click here for full remote control" or else most people would just do that and fall victim. This already happens regularly and it's what privileged dialogs aim to prevent.
That's regulatory capture - the only ones who can extract data now are the big corporations and it's sanctioned.
I am old, too, old enough to remember sending personal data over plain http with no encryption and needing to do a full wipe of Windows 98/XP machines on a periodic schedule just to keep viruses and malware off of them.
The idea that application A can just have full blown disk access and slurp up your tax returns or something was always a pretty crazy security posture. It just so happened that an honor system kind of almost sort of worked for a while.
You can’t really do an honor system when people are running artificial intelligence systems that have no concept of morality with full disk access.
> artificial intelligence systems that have no concept of morality
Their problem is not lack of morality. It is simply being unreliable, untrustworthy and unsafe.
Realistically we’re never going to be free of rowhammer and meltdown type attacks. Trying to prevent programs running on a computer from having full control of it just promotes a false sense of security.
If we read the article Apple isn’t planning to prevent programs from having full control, they’re just going to have better separation and user controls for “full disk access” versus “access to a limited subset of folders.”
This will allow programs like Spotify to only specify limited folder access while it’ll allow programs like Backblaze Backup To specify full disk access.
> Trying to prevent programs running on a computer from having full control of it just promotes a false sense of security.
Why would that stop at your computer's network socket?
I’m 50 and I think it’s crazy we ever thought it was acceptable to give every app you run full access to all the files on your computer by default.
I think its crazier that every app installed by default gets Cellular Data and on WiFi, its even worse because theres not even an option to granularly decide which apps should or shouldnt have that.
Things that have no conceivable need to phone home just get it for the hell of it. Its basically Full Disk Access but for Network Access which is arguably equally problematic
On iOS apps can't run in the background without permission.
Only on systems without proper user management, or if the owner is logged in as the administrator.
"the owner is logged in as the administrator"
this is a majority of macos users (including many who are "technical")
TFA:
> 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.
If you think an app from (say) Facebook can be trusted with unrestricted access to your whole machine, you're at least a bit naive.
Remember: it's not your machine, it's Apple's. You just get the privilege of using it.
I don't know what to think about this.
When I hopped onto the Linux bandwagon in the 1990's, the community was touting its amazing security because any damage done was compartmentalized to a particular account. (Of course, that ignores root escalations. Of course, few Linux users cared about that back then because it was an obscure operating system.) In contrast, Macintosh and Windows (non-NT) security was non-existent.
These days, I find increasing security measures both burdensome and restrictive. That said, it is also necessary. We have long left the era when one could trust supposedly reputable software vendors -- never mind random developers.
being a nerd here, sudo - yes, but indeed I thought the entire UNIX design of everything is files and there are permissions, groups, etc, should be sufficient.
But I think the "new world" is, we are over stimulated (eg. agents ask us 'permissions' for a long command) so we might give a sudo not fully aware of it where a big bold UX message box after a 'pseudo' sudo would better catch our eyes.
So it seems this is about adding additional layers over already existing ones in a way?
The UNIX model assumed each human had one user. It did not provide a flexible way to sub-divide that scope for each program running as that user.
It has been extended, but not in a way that non-technical users can really use.
You misunderstand. The software that has full access to disk, and can do anything without you knowing it, is the owner of the machine.
this is mostly a benefit to the owner. Every security feature , including firewalls, authorization ACLS, etc could potentially be used to reduce the owners rights, but they’ve all been necessary .
I’m with you on ownership, but push against signed code restrictions especially with bootloaders, and closed drivers.
macOS has been revoking access to stuff like this over the past decade. Things like unfettered access to modifying the OS went away with Gatekeeper and System Integrity Protection. "root" access is no longer true root on any Mac, and the user is treated like a prisoner. The UAC-esque prompts that come up in macOS would make Vista-era MS so jealous.
root access is also no longer true root access on a lot of linux distros that are immutable, and container-esque like interfaces such as namespaces + cgroups also limit roots power.
Pointless comparison as you the user still have full control over all of that on Linux.
Pointless comment as the same holds true for macOS. Yes, you can load unsigned kext still, and yes, you can modify the userland. Not as easily, but I would argue it is also not harder as on an immutable linux distro.
And despite hyperbole about Apple locking down macOS, ending the era of personal computing, it's hidden behind a toggle in settings. https://www.xkcd.com/1200/ applies, and in the era of downloading random programs off the Internet and cryptocurrency, random programs should have to jump through an extra hoop before getting access to everything. Imo Apple went a bit overboard with granularity, but it's not 1990 and the Windows 98 (lack of) security model doesn't work, and neither does Unix permissions either.
It works just fine for any user with a modicum of sense. I know many people, not technical people at all, who avoid running malicious programs just fine. I don't see a reason why we should lock down everyone all for the sake of a minority who simply refuse to take responsibility or learn.
No, you're not getting old. Tech companies are getting more and more paternalistic, refusing to treat users as adults who can make their own decisions. It's profoundly irritating.
The software running isn't the owner though.
Do you run every process as root?
Basically, the security model has changed:
https://xkcd.com/1200/
Also, if you are really old, you may remember how unhappy people were when wheel group appeared, and not everyone could "su" to root anymore. Giving everyone root was supposed to be normal!
I'm sure it'll be a permission the user can toggle. So they won't be taking away the ability for apps to see all the files but they'll be adding an extra layer of security so users can choose what an app can see. They're being light on details at the moment though.
But this is what it is currently. At the moment, not only is it a toggle, but unlike almost all other permissions, you can't just request the permission.
You have to send the user to the system settings pane for it and have them manually toggle it on there.
It's hard to imagine how it could be more explicit than it is currently. I imagine they have something draconian planned.
This week, I formatted my entire Mac fleet (an iMac Pro and four MacBooks), and now neither AI agent runs natively. I am using LIMA (https://lima-vm.io) to isolate them in a sandbox, exposing only a repository. I lose some integration, but the peace of mind is worth it.
What we need is true application isolation even in the command line. Treat Terminal as privileged access, not something any app can just command. Sandbox non-app store apps as well.
Whenever I ask Claude to vibecode macOS native apps for me, I always request the apps to be sandboxed. Agents know how to sandbox the apps; just ask. And you can verify it without reading any code.
Call me a paranoid but I'm afraid of the harness itself, not the apps it generates. You can see lots of people being concerned with Deepseek Harness being Chinese, but I share the same sentiment towards all AI-based software that can run unsandboxed on my computer.
I'll call you prudent.
> And you can verify it without reading any code
... said that OpenAI security guy, no doubt.
There are several ways using only the GUI to tell whether an app is sandboxed.
You'd think.
https://www.sentinelone.com/vulnerability-database/cve-2026-...
This is a fluff piece that has zero technical details. But I find your logic very interesting: if the presence of one CVE in sandboxing makes sandboxing untrustworthy, should we not have long ago discounted the entire security of Linux due to many CVEs for privilege escalation? Or the security of any and all browsers?
No.
But we probably should not think "There are several ways using only the GUI to tell whether an app is sandboxed.".
Let's not be that OpenAI guy.
Just use an iPad?
Unfortunately the iPad is still not seen as a first-class OS so there's no Claude Code nor VS Code on it.
You can still drive Claude Code from an iPad if it runs on a remote box, I do that from the Claude app with this: https://aicommander.dev
No thanks
Oh no, even more permission prompts on macOS. It's already almost unusable due to the existing ones.
Folks like to cite how capability OSes are a great thing, and I certainly appreciate the concept, and, no, MacOS, is not a capability OS.
However, it feels like one to the User. Having to get constantly prompted to grant permissions they don't even necessarily understand to random programs.
There's been chatter about how system like iOS are not "document based", they're app based. Many apps do not present their data as "files", users don't know where their data resides, just that the app knows and that's their window.
I don't know where an application on MacOS can "save their files" if they don't have "Full Disk Access". I don't know if they get some directory "for free" that they can use much like iOS does.
Then, of course, there's the Apple Document model where data auto saves to Somewhere. You have versioned files you can work with. But until you actually "save" the file to "the disk", its living in some unannounced space. My TextEdit app has dozens of "Untitled-XX" files that are...somewhere.
And its great! There's a peace of just having "stacks of stuff" that you can leave "unmanaged". "Where would you like to save your work?" "Oh, great, cognitive load just exploded as need to think about the minutia of data organization, when, mostly I just "don't want to lose this".
But, the constant prompting is exhausting, to me. Again, I have to "think about it". I need to question everything, when I really just want to Get Stuff Done.
And, in time, we become blind to these prompts. "ok, Ok, OK!! GO ALREADY! JUST WORK!!".
Exhausting.
Sandboxed Mac apps have access to their own container which includes directories like Documents/ and a temporary directory and more where they can save anything just like on iOS.
That’s not quite how macOS sandboxing works. Users expect to be able to save and open (non-iCloud Drive) files in ~/Documents, not in a containerized silo. If the app uses NSOpenPanel/NSSavePanel, those work with the system to grant the app a sandbox extension to the location the user chooses in the open or save panel.
Yes. Sandboxed apps do get their own home directories (~/Library/Containers/.../Data) and this home directory does contain a Documents directory, but this is just for compatibility's sake – there is no reason to actually use it for anything. Files that an app saves by itself are typically expected to be stored under Library/Application Support or Library/Caches, and this is still true even for a sandboxed home directory. Documents is reserved for files the user saves manually, but as mentioned, manually-saved files should reach the real ~/Documents.
Though, there is also a third type of Documents directory, the kind located at paths such as ~/Library/Mobile Documents/com~apple~TextEdit/Documents. This is part of iCloud Drive and is the same directory that you get in Finder by going to iCloud Drive -> TextEdit. Very confusing.
It's really gotten out of hand. Trying to literally plug something in results in at least one (sometimes multiple) prompts being like "are you SUUUUURE you want this plugged in?"
It's fine if there is a super streamlined flow for access that works with legacy apps and runs in user-mode. Otherwise this might seriously hurt MacOS as a viable development platform.
[dead]
If it worked as intended, they wouldn't be in this predicament.
That feature was so stupidly nonfunctional before. Some apps got stopped by it, others didn't. Often you'd be able to install an app from homebrew and it had full ride access to the disk, while App Store apps had to request consent for any folder whatsoever. It was completely random.
I think macOS 27 has already shipped a version of this. I remember seeing a prompt for Firefox requesting access to Google Chrome data (presumably to import bookmarks/history?) recently.
If that's the direction things are moving in, I welcome the change. Fine-grained folder access controls (rather than only full iOS-like sandboxing or full disk access) make me much less hesitant to try new apps or have agents access more parts of my system.
But they really need to solve the issue of low-level utilities triggering dozens of permission prompts when walking $HOME. Having to approve or decline Documents, Downloads, Google Drive etc. directory access, all separately, is extremely annoying.
This also affected me (with Firefox specifically). Looking into it, I ran across this blog post. It looks like macOS 27 has specific app data that it’s now preventing unexpected reads from. https://wojciechregula.blog/post/golden-gate-appdata-protect...
I agree that this seems like a good thing. I really don’t need Firefox (or any app!) trying to check another app’s data without explicit permission.
Oh wow, it's a manually curated list by Apple? Fascinating, thank you!
Sandboxing is great in theory, but, aside from maybe Qubes, they are rarely a security boundary in practice.
How do you mean? The sandboxes of both iOS and Android have been a resounding success; bugs exist and malware is not impossible, but orders of magnitudes more complex to deploy than on traditional unsandboxed desktop OSes.
The android one isn’t all that great. iOS sandboxing, to a great extent is a 2 step system - the app store and entitlements limit the attack surface long before the sandbox gets tested. That is not necessarily a bad thing. The sandbox on iOS would be forced to be a lot more secure if people were allowed to use the whole ABI of the kernel.
I feel like this isn't going to be a simple permission popup. Probably along the lines of getting an "unapproved" binary to run, where you have to stop what you're doing and wade through settings, trying to find the right toggle 6 nodes deep in the tree.
I am a developer and recently I was troubleshooting an issue with my macOS app where it was working fine on newer macOS but failing on older one only when I archived it (last step before submitting an app for Apple approval). So I'd archive it on my new macOS and airdrop to old macOS and try to run it. Every single time, it'd tell me it was unsafe and ask me whether I'd like to delete it. I'd have to dig through multiple settings screens to "open anyway", enter my password to get it to finally run. What a nightmare not being able to easily run my own app despite having same developer account and Apple ID.
Staple and notarize it, and then invoke the xattr -d quarantine command on it.
You don’t need to kill the quarantine bit if you notarize and staple. If you do still get prompted, the dialog will have an Open button on it.
And with a 24 hour timeout!
Great, cant wait for the inevitable "Are you sure you want to grant full disk access" prompts every week for eternity until the user is exasperated and revokes access.
Don't be naive, them telling you this in advance and straw man arguments like:
Let me think that they try to sugarcoat a coming change that has the purpose of transforming your computer as an ipad where you have no access to most of it except what is approved by apple.For the "greater good" as usual.
Just look how deceptive is the Apple post "full disk access" is not even a thing. You have access to your user files and that is all. You need sudo to have more rights.
A normal copilot/Claude/facebook like app shouldn't ask you for such a right except exceptionally for a very good reason.
So when they speak about backup apps, that are the one that could need sudo to backup the whole system, is to tell you that soon only notarized apple approved and app store delivered apps will be allowed to do that, but certainly not you willingly. Maybe not in version 1 but in version 2 for sure.
Then, like for iOS, they could have proprietary apps like Netflix, Facebook and co storing data on your device that you will not have access to.
Apple, as always, seem extremely determined to make sure that they protect things on your computer from being accessed by you.
Apple Intelligence is a great example of this. Everything can funnel up to Siri, but neither you nor any other app on your computer can see what is fed to it by all of the APIs that would provide it data. So anyone who adds support for it is enabling Apple to do their usual slow broken thing with Siri and not enabling any other way you might want to use software or AI with that data.
> protect things on your computer from being accessed by you
This has nothing to do with your access to the disk and everything to do with 3rd party deceiving unhindered access to everything about your life because you installed something like Muse.
Would it really be too much to just allow the user to grant the permission that they want? You already have to jump through special hoops for full-disk access, and there's ALREADY a big warning at the top, explaining that it grants access to things like messages and such.
1) Don't like Apple? Don't buy their products
2) You still have full disk access if you want
You know, surprisingly enough, some of us here on this forum are software developers.
And so it ends up mattering to us what the rest of society gets in terms of software too.
Above all, we need a true privilege separation API at the application level. Why is the only way to sandbox my code editor to run it in a Linux VM on the Mac? And that’s solely to mitigate supply-chain attacks.
The simple root/user separation has long since ceased to be secure because, on a desktop machine, all sensitive information is, by definition, accessible to the user; having root privileges ultimately offers little advantage when it comes to exfiltrating data.
> 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
"Extraordinary" is a funny word choice. It was completely ordinary for most of the history of personal computing that any app you ran under your normal user account could see everything you had.
(I'm not saying this is a bad thing. As long as they allow informed users to continue to do whatever they please, I'm all for it.)
Now if only any of these controls would let me stop Adobe from creating a “Adobe” folder in my iCloud-synced Documents folder, that would be swell.
I simply do not understand how Adobe manages to bypass every single toggle available there. I can block access to every folder on my computer but the moment I open any Adobe app, they recreate that goddamned folder.
Why? How? Fucking hell Adobe. It’s 2026, you just don’t store cache and setting files in the fucking Documents folder.
I don't understand why this is a problem at all. AFAIK macOS is UNIX, so you can create user accounts and run programs as separate users. This is what I routinely do on Linux to run coding tools or other programs that should not have "full disk access," in particular to the files and mounts of my main user.
Imagine having a personal assistant paid by a sketchy surveillance company. They can't do personal assistant stuff without full access to your email, calendar, etc., but the company paying them wants to harvest your personal data.
Personal assistants are realistic for very rich people because they can be paid an extravagant wage and punished for disloyalty. A personal assistant costing pennies to someone else, with access to data worth more than its salary, makes no sense.
Yup. I do this all the time on both Mac and Linux.
https://news.ycombinator.com/item?id=9224
Wasn't there also ongoing confusion within the macOS team about if "Full Disk Access" meant "rw privs to all disks" or "turn off TCC sandboxing but use the current user's privileges"?
Just a reaction to Muse accesing that one guys iMessage history without permission.
I dislike restrictions out of instinct, but to be fair, I've had permissions request popups on my Mac that were the first sign of software, which I had actually written, maybe had some bugs allowing it to work outside of its intended bailiwick.
Is it really that surprising that in a world where we are redefining the meaning of user, that our user based file system security controls will have to change?
Man, I just want Discord to have the ability to do overlays on Mac like it can on PC so I can see who is talking when I’m playing video games. Where is that API update?
Everyday, we get one step closer to the year of the Linux desktop.
Any day now
Give me a shout when they get Bluetooth headphones working!
Any tips on the screenshot utility not getting disk access? Must be related because since macOS 27 it gets a no write permission error.
So this will make building apps from source outside macports/homebrew even more annoying?
My understanding is that Meta Muse simply opens the System Settings Full Disk Access pane, and the user has to enable it themselves using System Settings, which says, "Allow the applications below to access data like Mail, Messages, Safari..." and which requires an administrator password to change.
Thus, I'm not sure what more Apple can do here, but I'm definitely afraid of what they're going to do.
No, that's not what happened.
In reality, the "full disk access" restriction system never actually worked right. I'm positive Apple is just trying to save face here and quietly fix it while saying they're "tighting" it
This is a baseless conspiracy theory. Provide proof. No, the confused ramblings of one journalist who is trying to save his own face for granting FDA to Muse does not count as proof.
"I have a bad feeling about this..."
I totally had pi+qwen3.6-a35b wipe out my entire USB das yesterday migrating it from ntfs drivepool to apfs, 10tb since I'm done with windows. Been joking about qwen wiping out my laptop for a year now and was comfortable enough to just let it look at my storage and it immediately formatted. lmao.
I had 3 duplicate files on each drive and it was impatient and rushing and didn't keep one drive around before formatting them all.
Completely saved me the week of migrating files project I was dreading, thanks. Nothing invaluable but an insane amount of downloading to do and I'm on 5g in the woods.
Sometimes its just draw dropping at how stupid these can be, basically giving a 6yo RHCSE root access.
When I give something a "Full Disk Access" permission, I expect it to have full access to what's on my disk, including "files, mail, messages, and even (gasp) browsing history"! Who are those mysterious people who expect their browsing history to be magically excluded from something called Full fucking Disk Access?
The problem isn't people who intend to provide full disk access. It's the people who unthinkingly grant full disk access to, for instance, Codex, because the AI asked them to.
Those people simply cannot be helped. At the end of the day, you can't stop people from hurting themselves by being too credulous, not without taking away their freedom. Those are the choices: either you accept that some people are foolish and will make bad decisions, or you circumscribe their ability to make decisions. There's no third option, because any halfway measures you take (like what Apple has done with these full disk access permissions) will be mindlessly ignored by someone who is too lazy or foolish to actually think about what they are doing.
Turns out you actually can stop them from hurting themselves. iOS has done this already very successfully.
People want a computer that prevents catastrophic mistakes and Apple has the ability to deliver that.
Most people don’t know what a disk is.
Then tell them to stop trying to use a computer, give them an apple juice and let them go back to eating their favorite color of crayon.
Did you ask the people you communicate with for consent to add their messages to the open ai training set?
Maybe it's just my pet peeve, but it's less about my documents and mail and more about programs, tools and AI harnesses deciding they can fill hidden dotfile folders at root with whatever they want (which they do indiscriminately). I don't just hate that there's tons of untracked caches and temp file data that isn't easily discoverable, but more specifically, I don't want all that crap in my root directory.
Who decided that hidden folders are a good thing anyways? .agent, .agents, .aws, .bun, .cache, .cargo, .claude, .codex , .config, .docker, .gemini, etc. I just end up having to show hidden folders all the time, which defeats the point.
It's gotten truly ridiculous. I want the OS to strictly enforce my root directory. There should be a few global preference files in there for like .zsh, and everything else organized in proper, unhidden folders.
Ironically enough, the UNIX fathers themselves realized that the hidden files idea was terrible and in the 90s kicked them off completely out of Plan 9 and moved user configs to the $home/lib. And yet we still have our home directories being insanely cluttered with dot files.
> Who decided that hidden folders are a good thing
The grey beards who designed the OS decades ago? Though the lore is the hidden fact of ".dot" was just a bug
> There should be a few global preference files in there for like .zsh,
Why, though, this can more cleanly live in your "config/shell" folder
Oh, I really meant the latest trend of every AI agent having their own dot folder in root. I think Anthropic set off the trend with ~/.claude/ and I really wish everyone would stop now.
Yeah, meant the same thing, polluting user folder with invisible droppings is an ancient (and international, Windows is similar with Documents) pastime. There are some apps that respect XDG env vars instead of ~/.app
"Updates to-" instills such a deep-rooted fear in me. I know whatever follows is about to suck.
"Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac"
Huh? Seems like a disingenuous statement. I hope they update that sentence with something more accurate.
However, I've wanted much more granularity and pervasive permissions so I'm glad they're adding them.
> Huh? Seems like a disingenuous statement. I hope they update that sentence with something more accurate.
Right, the classic use case for FDA is Terminal app, not backups. I don't think backup apps even need FDA, because they use the Apple ASR tool that already has special permissions.
Even developing bog standard apps. MacOS without FDA is the death of creativity and productivity.
The permissions/security model should've expanded faster. There's huge benefits to being able to install arbitrary software and not worry about giving it access to everything.
But it would never cover everything to do with a computer.
The backup apps I'm familiar with read files directly; they don't use asr.
If asr can be used to bypass FDA then that is just a security vulnerability.
asr requires root. However, it appears that CCC and SuperDuper do require FDA.
That doesn't really make a difference, as TCC permissions don't care if you're root or not.
> TCC permissions don't care if you're root or not.
That wasn't the the point, though. The point is that asr has special private Apple entitlements, allowing it to do things that other processes can't, but it requires root to run asr, so asr can't be triggered willy-nilly by any user process.
EDR and RMM are two major ones for corporate managed Macs
I got annoyed most by the keychain password and developing a Mac app without the developer ID, which is also a problem I have faced.
[flagged]
[dead]
If there is one thing I absolutely despise with all of my heart, then it's mega corporations patronizing their paying customers.