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:
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.
moecables · · focus · HN ↗
- 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)
0c3ca83 · · focus · HN ↗
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:
rolosa · · focus · HN ↗
0c3ca83 · · focus · HN ↗
kmeisthax · · focus · HN ↗
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.