Homebrew 6.0 sandbox: what the systemd confinement actually does

Homebrew 6.0 shipped a Linux sandbox. Here's what that actually means in practice.

The short version

The sandbox isn't containers. It's systemd sleep confinement applied per-formula at install/run time. When a formula runs, systemd places it in a cgroup slice with restricted access to filesystem paths, syscall capabilities, and device nodes. If the formula tries to write somewhere it shouldn't, the kernel enforces it at the cgroup level — not at the container boundary.

Why this matters for dev environments

On a dev workstation or shared Linux build box, Homebrew installs run under the same user context as everything else. A buggy or malicious formula can overwrite your dotfiles, read SSH keys if the agent is running, or trash /usr/local if permissions allow. The sandbox doesn't eliminate that risk, but it limits the blast radius.

Specifically, the confinement:

• Denies access to paths outside the Homebrew prefix unless explicitly allowlisted


• Drops capabilities like CAP_SYS_ADMIN that aren't needed for most formula builds


• Restricts device access so the formula can't probe /dev

What doesn't change

This isn't containerisation. There's no namespace isolation, no separate mount table, no seccomp filter applied by default. The sandbox constrains what the process can do through cgroup v2 and capability bounding, but a determined formula running as your user can still cause plenty of damage inside those limits.

Also worth noting: this only applies on Linux. macOS Homebrew still relies on SIP and the normal Unix permission model.

Checking if a formula is sandboxed

You can inspect the cgroup a formula is running in after install:

# Find the PID of a running formula

pgrep -f <formula-name>



# Check its cgroup slice

cat /proc/<PID>/cgroup

If Homebrew's sandbox is active, the process will be under a homebrew.sandbox slice rather than the default user slice.

If you need to opt out

Some formulae legitimately need wider access — building kernel modules, probing hardware, etc. You can bypass the sandbox per-install:

HOMEBREW_NO_SANDBOX=1 brew install <formula>

Just be deliberate about when you do this. The sandbox exists precisely because a formula you didn't write is executing arbitrary code on your system.

The practical takeaway

6.0 moves Homebrew's threat model in the right direction for shared Linux environments. It's not a substitute for isolation tools when you need hard boundaries, but it's a sensible default that raises the bar without the operational overhead of containers. If you're managing multi-user Linux build machines, test it against your common formulae before rolling it out broadly — some build systems make assumptions about what they can access that conflict with the new restrictions.