back
89 comments
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.

I wonder how many major applications and tools depend on sandbox-exec today despite that depreciation, IIRC I can think of the Codex CLI and Swift Package Manager.
Does anyone have any details regarding the deprecation? I wonder why Apple made this decision.
Meh, cron on OS X/macOS has been deprecated for over 20 years.

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

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.

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.

> clone repos into ~/projects

Cloning them there means leaving access to your SSH keys, right?

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

It weirds me out a bit that Claude is able to reach outside the sandbox during a session. According to the docs this is with user consent. I would feed better with a more rigid safety net, which is why I've been explicitly invoking claude with sandbox-exec.
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.
I made a UI for this to run terminal apps, like claude and codex: https://multitui.com
I’m impressed really neat work! Why did you opt for closed source?

edit: I don’t have a problem with closed source, but when software is expected to be accountable for my security I get a little paranoid, so was curious about the safety and guarantees here. The UX and everything else looks great

I like this! I built something similar for sandboxing CLI agents, and in the repo have a collection of minimal profiles for sandbox-exec to use - https://agent-safehouse.dev/
Codex already uses sandbox-exec on macOS :)
Which terminal do you embed?
Wow, this looks very nice.
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.

> not much to do with "App Sandboxes" which is a distinct macOS feature

The App Sandbox is literally Seatbelt + Cocoa "containers". secinitd translates App Sandbox entitlements into a Seatbelt profile and that is then transferred back to your process via XPC and applied by an libsystem_secinit initializer early in the process initialization, shortly before main(). This is why App Sandbox programs will crash with `forbidden-sandbox-reinit` in libsystem_secinit if you run them under sandbox-exec. macOS does no OS-level virtualization.

What you're describing is a resource virtualization with transactional reconciliation instead of program isolation in the mediation sense (MAC/seccomp-style denial).

To let a program act as it wishes, ideally every security-relevant mutable resource must be virtualized instead of filtered. Plus, FS is only one of the things that should be sandboxed. You should also ideally virtualize network state at least, but ideally also process/IPC namespaces and other such systems to prevent leaks.

You need to offer a promotion step after the sandbox is over (or even during running if it's a long-running program) exposing all sandbox's state delta for you to decide selective reconciliation with the host. And you also must account for host-side drift and TOCTOU hazards during validation and application

I'm experimenting with implementing such a sandbox that works cross-system (so no kernel-level namespace primitives) and the amount necessary for late-bound policy injection, if you want user comfort, on top of policy design and synthetic environment presented to the program is hair-pulling.

Sandbox-exec covers everything I personally expect from a sandbox:

- controls which files the process can read and write

- controls what network access the process is allowed

> 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.

You'll want to look into Homebrew (or Macports) for access to the larger world

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>.

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.
Why is not spending resources to develop infrequently-used features that aren't revenue streams "stifling"? Granted, I too would love to have nice UIs for those out of the box, but > 99.9% of Mac users don't care, and 3rd-party developers can pick up the slack and maybe make some money filling the gap.
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)?
Homebrew uses sandbox-exec during builds and installs, yeah. To my memory we’ve used it for at least 6 or 7 years, probably longer.
I’ve written a personal system in Common Lisp for building third-party software on macOS (coincidentally somewhat similar to GUIX), and I use sandbox-exec to isolate execution so that only intended requisites affect the build process and so that installation is strictly confined to the configured destination directory, no scribbling outside the lines.

I think Bazel uses sandbox-exec on macOS.

Nix uses the underlying libsandbox function for builds: https://github.com/NixOS/nix/blob/614072adcb56202f0a09532971...
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

I am not sure using sandbox-exec is a good security architecture for AI agents. It sure is convenient and available to everyone right now. I've made another comment elsewhere in this discussion about what I think "deprecated" means - it is a sharp tool that could break if not tracking everything that changes, including every change in a SW update. It is also easy to get wrong if there is not a "(default deny)" in the profile. An agent could escape if they can find a mach service or some other system call coordinated proxy service. Java, Silverlight and Flash had backdoor communication mechanisms with other instances of themselves that could be abused.
"If" indeed. Apple has a trillion-dollar AI market staring themselves in the face, and they can't even find it in them to sign CUDA drivers for their own good.

The features you're describing would not buy them credibility in the AI field anyhow. They would certainly plaster over some of macOS and iOS' more embarrassing limitations, but professional AI deployments are not hamstrung by those limits. It's just the commodity homelabbers who want to brag about buying a 120gb GPU with anemic compute performance. Apple doesn't need to curry favor with those people, they'd buy the hardware for the luls regardless of what the software experience is like.

Apple is going to Apple. They're as likely to remove the deprecation as they are to restrict it to first party apps only. They don't care about devs.
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.

> Sandbox profiles use a Scheme-like syntax (a LISP dialect) with parentheses grouping expressions.

Wow this is cool

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

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

Are sandbox-exec and seatbelt no longer deprecated? I genuinely don’t know. I am asking
Linux equivalent? Anything for Ubuntu? How different is it than a .venv?
Interesting config used a Scheme-like format. Any ideas on how that came to be?
If there is a gui i can deploy custom browsers for classroom for labbing !
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."?

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.