Skip to content

Comment on macOS's Little-Known Command-Line Sandboxing Tool (2025)

Comments

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?

No, I don’t think so?

The .git folder will likely contain the URL to the repo, but not any credentials.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.