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)

▲ coderbants 9 hours ago | parent | next [-]

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).

	▲	jshier 6 hours ago \| parent \| next [-]
		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.
	▲	ashishb 6 hours ago \| parent \| prev \| next [-]
		> 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
	▲	7 hours ago \| parent \| prev [-]
		[deleted]

▲ king_geedorah 3 hours ago | parent | prev | next [-]

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.

▲ 0c3ca83 5 hours ago | parent | prev | next [-]

- 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 (pledge("stdio rpath wpath cpath fattr flock getpw proc "
      "exec tty id", NULL) == -1) {

▲

rolosa 5 hours ago | parent | next [-]

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.

▲

0c3ca83 3 hours ago | parent [-]

Why would ghostty try to access your disk when you run 'ls /'? ghostty isn't opening any files -- ls is.

	▲	dcrazy 3 hours ago \| parent [-]
		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.

▲

saagarjha 5 hours ago | parent | prev [-]

macOS attributes shell commands to their parent app bundle.

▲

0c3ca83 3 hours ago | parent | next [-]

That seems like a massive hole in the model that would make it very hard to lock down multi-process/privsep programs like sshd.

▲

saagarjha 3 hours ago | parent [-]

Sandboxing something like that is challenging, yes. But probably not for this reason you can always disclaim responsibility for your process.

▲

0c3ca83 3 hours ago | parent [-]

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.

▲

dcrazy 3 hours ago | parent | next [-]

That “just” is doing a LOT of work.

▲

0c3ca83 2 hours ago | parent [-]

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.

	▲	dcrazy 2 hours ago \| parent [-]
		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.

▲

saagarjha 3 hours ago | parent | prev [-]

This is really hard to do in general

	▲	eviks an hour ago \| parent \| next [-]
		Indeed, is only the OS mastermind had billions and years to fix the foundation...
	▲	0c3ca83 2 hours ago \| parent \| prev [-]
		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.

▲

joshspankit 5 hours ago | parent | prev [-]

Indeed. It’s very inconvenient to ‘cd` and have to do the whole permission dance to read a file

▲ musicale 2 hours ago | parent | prev | next [-]

But how is Gemini going to repair your filesystem and restore lost or deleted data?

▲ smcleod 5 hours ago | parent | prev [-]

I wouldn't allow your terminal full disk access, that's quite a risk vector.