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
macOS's Little-Known Command-Line Sandboxing Tool (2025)
21–30 of 96 posts
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#22I made a UI for this to run terminal apps, like claude and codex: https://multitui.com
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#23Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#24https://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.
Basically everyone who has to care about security on the Mac.
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#25Are sandbox-exec and seatbelt no longer deprecated? I genuinely don’t know. I am asking
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#26It 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…
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.
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#27Do 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)?
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#28https://github.com/obra/packnplay
https://github.com/strongdm/leash
https://github.com/lynaghk/vibe
(I've been collecting different tools for sandboxing coding agents)
Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)
#29See 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)
https://github.com/eugene1g/agent-safehouse via CGamesPlay
https://multitui.com/ via davidcann