The sandbox is called the App Sandbox, and that’s for a reason. As far as public API is concerned, you can only sandbox apps (and app-like things, like app extensions, system extensions, and XPC Services). Things that aren’t apps always inherit the sandbox from the parent process.
If you bundle such a program in your product, you must set:
However, this just marks the program as inheriting its sandbox, it doesn’t actually trigger the inheritance; that’s something that happens by default.
In contrast, if you run an app, it switches to its own sandbox.
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
You aren't actually doing the same things in those two examples. In the first example, you are running bash with the given script. That runs in your app's sandbox. In the second example, you are running the "open" tool and giving it the path to an app. That is an Apple tool that essentially does the same thing as NSWorkspace. It launches the app as if the user had double-clicked on it. In this situation, it isn't a child process of your app. That means you can't control it like you would a child process. Technically speaking, I think the "open" tool is running under your app's sandbox, but it can call NSWorkspace just like your app can, which gets out of the sandbox.