Live data from Hacker News

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

igorstechnoclub.com

51–60 of 96 posts

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#51

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)

I've been collecting a list of sandboxing related projects as well, some lower level than others. I wish I had time to evaluate them all:

- https://github.com/jingkaihe/matchlock

- https://github.com/mishushakov/libkrun-go

- https://github.com/earendil-works/gondolin

- https://github.com/butter-dot-dev/bvisor

- https://github.com/amlalabs/amla-sandbox

- https://github.com/eryx-org/eryx

- https://github.com/containers/bubblewrap (not new)

- https://github.com/coplane/localsandbox

- https://github.com/sd2k/conch

- https://github.com/Gerharddc/litterbox

- https://github.com/finbarr/yolobox

- https://github.com/coventry/sandbox-codex

- https://github.com/osks/ctenv

- https://github.com/tianon/gosu

- https://github.com/colony-2/shai

- https://github.com/rcarmo/agentbox

- https://github.com/coder/httpjail

- https://github.com/bytecodealliance/componentize-py

- https://github.com/tursodatabase/agentfs

- https://github.com/always-further/nono

- (another list on HN Deno Sandbox: https://news.ycombinator.com/item?id=46876022)

- Did not check if any/all of these are here: https://github.com/arjan/awesome-agent-sandboxes

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#52

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.

[dead]

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#53
post #49

Earlier quoted context omitted.

There’s not that much detail. A few comments in 2019 from a DTS person indicated that Apple didn’t really anticipate people shipping on this in volume. My guess is they want to dissuade people from using it. They can’t immediately just do away with it because a bunch of their first party apps use it (entitlements don’t cut it). It’s a weird space.

> a DTS person Quinn the Eskimo, no doubt. I'm convinced he or she is the only actual human being providing developer technical support at Apple. Certainly the only one I've ever successfully communicated with. Support tickets go to robots who are incapable of providing relevant answers. Maybe Quinn is an alias with a team of humans behind it, but I don't think so. I've had him or her take forum posts to private e-ma…

Yeah, it was Quinn. I didn’t want to name them and seem too knowing haha.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#54
post #51

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)

I've been collecting a list of sandboxing related projects as well, some lower level than others. I wish I had time to evaluate them all: - https://github.com/jingkaihe/matchlock - https://github.com/mishushakov/libkrun-go - https://github.com/earendil-works/gondolin - https://github.com/butter-dot-dev/bvisor - https://github.com/amlalabs/amla-sandbox - https://github.com/eryx-org/eryx - https://github.com/containers…

Got a weird one https://github.com/Protonk/PAWL

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

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

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#56

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…

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

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

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

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#58
post #7

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.

Meh, cron on OS X/macOS has been deprecated for over 20 years.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#59

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…

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 ideal…

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

Curious, if this is cross-platform, is your design based on overriding the libc procedures, or otherwise injecting libraries into the process?

Also obligatory https://xkcd.com/2044/

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#60
post #32

Earlier quoted context omitted.

Does anyone have any details regarding the deprecation? I wonder why Apple made this decision.

I don’t know if there are problems with this tool, but the App Sandbox is very configurable and every app store app is in one. It doesn’t make sense to maintain two different complex sandboxing solutions.

App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.

By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.

The downside is that the App Sandbox policy is limiting and inflexible.

Post reply on HN