AINEWS
Homebrew 6.0.0 Makes Third-Party Taps Explicitly Trusted
The new tap trust mechanism turns Homebrew's implicit third party tap posture into an explicit one, with migration friction for users of niche or custom remote taps.
The new tap trust mechanism turns Homebrew's implicit third party tap posture into an explicit one, with migration friction for users of niche or custom remote taps.
Before Homebrew 6.0.0, installing a third-party tap meant Homebrew would happily execute whatever unsandboxed Ruby that tap shipped, with no prompt and no audit trail beyond the tap name you typed. That implicit-trust model is exactly what the 6.0.0 release announcement, posted by project lead Mike McQuaid on June 11, 2026, is designed to retire.
The release's headline change is a new tap trust mechanism. Third-party taps can ship arbitrary Ruby that runs unsandboxed on a developer's machine, and the new model treats that as a decision the developer should make consciously rather than something the tool assumes. Taps must now be explicitly trusted before their code is evaluated or run. Official Homebrew taps remain trusted by default. Trust, allow, and forbid lists are pinned to the tap remote, which means a tap cannot quietly widen its own permissions by changing what it claims to be.
For day-to-day users, the practical change shows up the first time you add a tap you have not seen before. Homebrew will flag the tap as untrusted, refuse to auto-tap it on your behalf, and require an explicit trust command before it evaluates formulae, casks, or tap-qualified items. The brew tap interface gains commands to manage trust, including the ability to trust a tap by its remote URL, and brew trust and brew tap-info expose the current trust state, which makes it possible to audit what is on your machine without digging through dotfiles.
If you maintain a long tap list, the migration is the part to plan around. A list of custom-remote taps that you added casually over the years is now a list you have to walk through and trust by name. brew bundle reflects the same shift: the new trusted: option, combined with brew bundle dump recording trusted entries, treats custom-remote taps as something a Brewfile has to mark explicitly rather than absorb by default. That is more friction than the old model, and for users of niche or single-maintainer taps, the friction lands in proportion to how many of those taps are in play.
The other 6.0.0 changes sit underneath that lead. The internal Homebrew JSON API, which Homebrew has been using behind the scenes for some time, becomes the default: it is faster, smaller, and removes a class of shelling-out overhead. The HOMEBREW_USE_INTERNAL_API environment variable, which used to opt into the internal API, is deprecated in favor of the new default. Linux gains sandboxing via Bubblewrap, putting it closer to the sandboxing model Homebrew has long used on macOS. The release also bundles many brew bundle improvements (the announcement lists them in aggregate rather than item by item, so the specifics live in the project's release notes and GitHub tag), a round of general performance work, and a set of default behaviors tuned from the Homebrew user survey. Initial support for macOS 27, codenamed "Golden Gate", is in, which the release hedged as initial rather than a general-availability claim for the new macOS release.
The honest read is that 6.0.0 trades convenience for legibility. A Homebrew install is a supply-chain surface as much as a package manager, and the implicit-trust default was the part most worth tightening. The friction shows up at the moments a developer is least likely to be reading release notes: the first brew install of the morning, on a CI runner that just inherited a tap list, on a junior teammate's laptop where the security boundary is the part they did not choose. What to watch next is how quickly the third-party tap ecosystem settles on a discoverable trust model, and whether Homebrew surfaces trust state more visibly during the moments a developer is most likely to rubber-stamp it.