[derefr]

I think the idea is that there should be an option to have Apple-App-Store-audited capability-manifest-sandboxed CLI apps with auto-updates, as well as untrusted, non-sandboxed CLI apps.

Specifically, I would expect two things:

1. In general, macOS .app bundles should be able to “provide” a bin/ directory that gets added (appended, not prepended!) to your PATH while you have the package available on disk + non-quarantined. Just like .app bundles can “provide” file extension bindings that cause things to open in them. (And probably, just like with file extension bindings, you’d want to give the user the same “this is a program downloaded from the Internet…” Gatekeeper warning the first time a command-line invocation causes the user to end up running an executable from a given .app package, if the .app hasn’t yet been Gatekeeper-blessed.) Kind of surprised this hasn’t always been a thing since NeXTSTEP, actually.

(And, ideally, rather than needing to care about PATH ordering re: these applications’ exposed bin/ executables, instead make a generic system for interactively choosing preference-ordering, like Debian’s update-alternatives(1) but as a per-user runtime-bound preference.)

2. The App Store should allow at least apps that contain both GUI and CLI versions (e.g. gVim packaging its own command-line `vi`; or Sublime Text with its `subl` command) — where all the same capability-manifest sandboxing applies to the command-line executables that applies to the GUI app; and where the CLI version of the executable linker-loader is made slightly smarter re: auto-granting capabilities, such that if you e.g. pass a file or directory path as a command-line argument to a CLI program, then that CLI program should be auto-granted a capability on that file/directory during that run.

[xign]

Most packages that Homebrew install just wouldn't fit nearly into the kind of sandbox model that you suggested. Just think about command-line applications that can take in any file as input and process them, e.g. Git, ffmpeg, etc. Or like a compiler like clang. Even for GUI apps most Mac applications do not use sandbox / App Store because it's actually quite difficult to work within that framework for a lot of types of applications.

macOS also doesn't have a way to tag a command line application to have sandboxing, as sandboxing only works for an "app" bundle, not random executables.

This isn't really a Homebrew problem anyway. If there is this magical sandboxing capability that works, nothing stops a Homebrew package from using it.