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

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.

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

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

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