Homebrew 6.0.0 Bets on Trust, Sandboxing, and a Faster Default API

Homebrew, the package manager that quietly underpins development setups on millions of Macs and a growing number of Linux machines, shipped version 6.0.0 on June 11. Maintainer Mike McQuaid framed the release around a handful of structural changes rather than a single headline feature, and the through-line is clear: after a year of supply chain incidents across the broader package ecosystem, Homebrew is hardening the path between a remote repository and code executing on your machine.

The problem Homebrew is solving

A package manager is a trust relationship dressed up as a convenience. When you run brew install, you are downloading and often executing code written by someone you have never met, pulled from a repository you have never audited. Homebrew's official taps go through human review and are maintained by the same people who maintain Homebrew itself. Third-party taps are a different story. A tap can contain arbitrary, unsandboxed Ruby that runs with your user's privileges, and historically Homebrew would evaluate that code as soon as you referenced it.

Version 6.0.0 closes that gap with a feature called tap trust. Taps, and tap-qualified formulae and casks, must now be explicitly trusted before their code is evaluated or run. Official Homebrew taps stay trusted by default, so the typical user notices nothing. But untrusted taps are flagged before any of their code executes, auto-tapping of untrusted sources stops, and the allow, forbid, and trust lists are pinned to specific remotes rather than names that could be hijacked. The brew tap command picks up subcommands for managing trust, brew trust gains a --json=v1 flag, and brew bundle dump records which entries are trusted so the setting survives a machine migration.

Sandboxing comes to Linux

The second pillar is sandboxing. On macOS, Homebrew already runs build, test, and postinstall phases inside a sandbox. Version 6.0.0 brings the same protection to Linux using Bubblewrap, the same low-level sandboxing tool that backs Flatpak. Homebrew refactored its macOS sandbox logic so both platforms share code, hardened the install phases, and extended the sandbox to cover cask executable hooks. For now it is on by default for developers, with the homebrew-core CI setting the sandbox environment during builds. The practical effect is that a malicious postinstall script has far less room to read sensitive files or reach out to the network than it did before.

These two changes sit alongside a longer list of supply chain mitigations that Homebrew has documented in a new Supply Chain Security page: environment secrets are deferred to download time, sensitive variables are filtered during Ruby evaluation, and riskier upstream ecosystems like npm and PyPI now have download cooldowns that delay pulling in a freshly published version. The reasoning is that a compromised package is often caught within hours, so waiting before adopting the newest release reduces exposure.

A smaller, faster API by default

The change most users will feel day to day is the internal JSON API becoming the default. Instead of Homebrew talking to the network repeatedly to assemble metadata, it now downloads all of that information as a single, smaller bundle. That means faster brew update runs and fewer network round trips. The feature shipped as opt-in behind HOMEBREW_USE_INTERNAL_API back in 5.0.0; that variable is now deprecated because the behavior it enabled is simply how Homebrew works.

Performance gains show up elsewhere too. brew leaves is roughly 30 percent faster, bottle tab fetching during upgrades runs in parallel, and startup loads fewer Ruby libraries. Notably, Homebrew also wound down its brew-rs experiment, which tested rewriting parts of the Ruby frontend in Rust. The honest conclusion, published in a new FAQ entry, was that Rust only won on narrow, already-cached bottle fetches and not on representative full installs once you account for pouring bottles, linking, writing metadata, and health checks. The performance work has moved back to Ruby and to starting disk and network I/O sooner. It is a refreshingly candid result to publish given how much marketing energy the industry spends on rewrite-in-Rust narratives.

brew bundle grows up

brew bundle, the declarative way to describe an entire machine's packages in a Brewfile, got substantial attention. Parallel formula installation now runs automatically by default, cleanup support extended to the npm, cargo, go, and uv extensions, and on Windows the bundle can now manage winget packages. There are smaller touches throughout: a --describe flag for brew bundle add, support for krew and npm extensions, and a confirmation prompt before cleanup removes anything.

That Windows support is part of a broader positioning. Homebrew increasingly presents itself as a package manager for everywhere, recommended in Microsoft's Windows Developer Config for WSL setups, working on Bazzite, and now reaching into winget. The ask-before-acting default also arrives in this release, so brew install and brew upgrade show a dependency summary and a confirmation prompt for developers before changing anything, a decision the team attributes directly to its user survey.

The Intel sunset begins

Version 6.0.0 adds initial support for macOS 27, codenamed Golden Gate, and with it the clearest signal yet that Intel Macs are leaving the building. Golden Gate drops Intel support, and Homebrew's support tiers follow: in September 2026, macOS Intel x86_64 moves to Tier 3 with no CI and no new bottles built, and in September 2027 it becomes unsupported entirely with the related code deleted. Anyone still running a pre-Apple-Silicon Mac as a daily development machine now has a concrete deprecation timeline to plan against.

There is also a cluster of new commands worth knowing. brew exec works like npx, running a command inside a formula's environment without a permanent install. brew as-console-user handles running Homebrew correctly under MDM and root environments. A separate brew vulns tap and subcommand checks installed packages against known vulnerabilities, which complements the three security advisories Homebrew published with this release covering a redirect bypass in the POST download strategy, a root code execution path through git hooks in the macOS installer, and a plist trust issue in the same installer.

Why it matters

Homebrew is a non-profit run by volunteers, not a venture-backed company, and that shapes what this release prioritizes. There is no growth metric being chased here. The work is defensive, infrastructural, and largely invisible when it succeeds, which is exactly the kind of unglamorous engineering that package management depends on. For developers, the upgrade is low-drama: most of the security tightening applies first to maintainers and developer mode, and the API change just makes updates quicker. The longer-term story is that the tools sitting underneath everyone's development environment are starting to treat the supply chain as a hostile place by default, and Homebrew is doing it in the open with documentation and honest benchmarks rather than press releases. The project funds this work through GitHub Sponsors, OpenCollective, and Patreon, which is worth remembering the next time brew install saves you an afternoon.