https://man.freebsd.org/cgi/man.cgi?query=sandbox-exec&aprop...:

“The sandbox-exec command is DEPRECATED. Developers who wish to sandbox an app should instead adopt the App Sandbox feature described in the App Sandbox Design Guide”

That still is the case for MacOS 26.3 (https://man.freebsd.org/cgi/man.cgi?query=sandbox-exec&aprop...)

MacOS 10.13.6 is from 2017, so this has been deprecated for almost 10 years.

See https://bdash.net.nz/posts/sandboxing-on-macos/ for more details on how sandboxing works on macOS. It touches on how the SBPL Scheme source code is interpreted in userspace to build a bytcode representation of the policy, and the kernel MAC hooks that the Sandbox kernel extension uses for enforcing sandbox policies.

Both Claude Code and Codex use sandbox-exec with Seatbelt to sandbox execution:

- https://developers.openai.com/codex/security/#os-level-sandb...

- https://code.claude.com/docs/en/sandboxing

I made a UI for this to run terminal apps, like claude and codex: https://multitui.com

I'd add one warning for folks who haven't used it before: a tiny typo in the profile can turn into confusing runtime failures later, far away from the command that triggered them. The tool is useful, but the feedback loop is rough.

Thanks for putting this together, it's very helpful.

Readers may also be interested in <https://github.com/eugene1g/agent-safehouse> which was open sourced after a recent HN conversation <https://news.ycombinator.com/item?id=46923436>.

    alias sandbox-no-network='sandbox-exec -p "(version 1)(allow default)(deny network*)"'

for sh-compliant shells, including a whitespace at the end of the alias string causes the next token to also go through alias expansion. (maybe it would also be a hint to the shell for tab completion as well). This is a perfect example of when, where, and why you would want to do that.

It drives me nuts that sandbox-exec has "sandbox" in the name, since it's nothing like a real sandbox, and much closer to something like a high-level seccomp, and not much to do with "App Sandboxes" which is a distinct macOS feature.

IMO a real sandbox let's a program act how it wishes without impacting anything outside the sandbox. In reality many of these tools just cause hard failures when attempting to cross the defined boundaries.

It's also poorly documented and IIRC deprecated. I don't know what is supposed to replace it.

If macOS simply had overlay mounts in a sandbox then it would unlock so much. Compared to Linux containers (docker, systemd, bubblewrap, even unshare) macOS is a joke.

See also:

https://github.com/obra/packnplay

https://github.com/strongdm/leash

https://github.com/lynaghk/vibe

(I've been collecting different tools for sandboxing coding agents)

This tool is not just used for safety. ;)

You can spoof or disappear a mashed file. You can trigger vulnerabilities by breaking internal assumptions of a program.

Do any of the third-party package managers (Brew, MacPorts) perhaps use this for things like builds (or even installs, if things are restricted to (e.g.) /opt)?

what is with the ai written articles lately? and ai designed websites?

who looks at it and goes "yes, ill upvote this. more people should see it."?

If Apple wanted to win back some serous credibility in the AI field there are two very low hanging fruit that they could use:

- Announce that they are no longer going to deprecate sandbox-exec and instead publish detailed documentation for it

- Add a reliable "select all" option to the iOS copy/paste menu

Nice write-up! This is one component of a much larger umbrella framework for security on Apple platforms:

https://developer.apple.com/documentation/security

I went down the sandbox-exec rabbit hole recently trying to get a “safe shell” for poking at random GitHub projects. I eventually realized I was solving the wrong problem.

For development you usually don’t need a kernel policy language - you mostly want: 1. builds not trashing your real $HOME 2. no dotfiles/config pollution 3. some basic separation if a project does something dumb

A much simpler (and more reliable) alternative on macOS is just a dedicated throwaway user account. macOS already isolates home directories, keychains, and app state per-user, so you get a practical sandbox without fighting SBPL quirks or mysterious denials.

My workflow now: I have a user called rsh. I clone and build everything there. My real home directory stays clean. If a project goes crazy, it only damages /Users/rsh

It also avoids the “1000 hidden files in your home folder” problem that a lot of language ecosystems cause.

Minimal setup :

sudo sysadminctl -addUser rsh -password $(LC_ALL=C tr -dc A-Za-z0-9 </dev/urandom | head -c 16); sudo dseditgroup -o edit -d rsh -t user admin || true; sudo install -d -m 755 -o rsh -g staff /Users/rsh/projects

Then add this alias to your ~/.zshrc command:

alias rsh='sudo -iu rsh /bin/zsh -l'

After that I just run rsh, clone repos into ~/projects, and build there.

You can tell MacOS was developed by OS nerds but stifled by product managers. There are a lot of gems like Sandboxing and Hyperkit with incredible features and practically no user interface.

Interesting config used a Scheme-like format. Any ideas on how that came to be?

Are sandbox-exec and seatbelt no longer deprecated? I genuinely don’t know. I am asking

Although macOS do provide many little known useful tools (besides this, there’s also dtrace, pf, etc), I still run a Linux VM in my MacBook for daily work. Thing is, the effort I spend on learning these tools is almost wasteful unless I’m doing iOS or macOS development. Skills about Linux tools however, is something people considered valuable because of its wider application. I think apple is missing opportunities by not doing more about macOS Server platform.