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.