Homebrew 6.0.0 introduces several changes that developers and system administrators should review before rolling it out across development workstations, CI runners, and managed environments. The release adds explicit trust controls for third-party taps, a smaller internal JSON API, Bubblewrap-based sandboxing on Linux, and major improvements to brew bundle. It also sets a clear timeline for Intel Macs: macOS on x86_64 will move to Tier 3 support in September 2026 and lose Homebrew support entirely in September 2027.

Homebrew 6.0 for sysadmins in 20 seconds

Third-party taps now require explicit trust before Homebrew evaluates or executes their Ruby code.
brew bundle can install formulae in parallel and record trusted taps in a Brewfile.
Linux gains Bubblewrap sandboxing, while the baseline moves to glibc 2.39.
A smaller internal JSON API becomes the default, reducing metadata downloads and network requests.
Intel macOS loses CI and new bottles in September 2026, followed by full removal in September 2027.

Homebrew remains best known as the package manager many Mac users install before tools such as Git, Python, Node.js, PostgreSQL, or wget. Its role is broader in technical environments, however. Brewfiles can define developer workstations, Homebrew can be incorporated into provisioning scripts, and private taps are often used to distribute internal software.

That makes a major Homebrew release relevant beyond individual laptops. Homebrew 6.0 changes some assumptions around third-party repositories, automated deployments, Linux compatibility, and the remaining lifetime of Intel-based Mac environments.

Tap Trust Changes How Third-Party Repositories Should Be Managed

One of the most important changes in Homebrew 6.0 is Tap Trust.

A Homebrew tap is more than a static package catalogue. Third-party taps can contain arbitrary, unsandboxed Ruby code that may be evaluated or executed on the local machine.

Homebrew 6.0 adds an explicit trust mechanism to reduce the risks associated with that model.

Third-party taps, as well as tap-qualified formulae and casks, must now be trusted before their code is evaluated or run. Official Homebrew taps remain trusted by default.

This is particularly relevant for organizations using private repositories or taps maintained by external vendors. Provisioning scripts that previously assumed Homebrew would automatically add and evaluate a tap may need to be reviewed.

Homebrew has expanded brew tap and introduced brew trust functionality for managing these decisions. brew tap-info can also expose the trusted status of a repository.

The trust model extends to configuration-as-code workflows.

brew bundle now understands a trusted: option, while brew bundle dump can record trusted entries in the Brewfile. As a result, trust decisions can become part of the reproducible definition of a development environment instead of remaining an undocumented manual step.

This does not make a trusted third-party repository inherently safe. Once trusted, its code can still execute. The important difference is that Homebrew no longer assumes that trust automatically.

The release includes other supply-chain protections as well. Homebrew filters sensitive environment variables during Ruby evaluation, can require checksums for casks with HOMEBREW_CASK_OPTS_REQUIRE_SHA, and performs some forbidden checks before downloads begin.

The project has also published dedicated documentation covering its approach to software supply-chain security.

Three Security Advisories Add Context to the Changes

Homebrew 6.0 arrives alongside fixes for three security issues.

The first, GHSA-7699-qf8c-q47m, affected the POST download strategy. Under certain conditions, documented HTTPS-to-HTTP redirect protection could be bypassed because the resolved URL was discarded. Homebrew changed the implementation to enforce secure redirects correctly.

A second issue, GHSA-6689-q779-c33m, had potentially more serious consequences.

Git hooks could enable root code execution during the macOS .pkg post-installation process. Homebrew addressed the problem by cleaning the Homebrew Git state and replacing the installer Git directory.

The third advisory, GHSA-59v8-x8q4-px5c, concerned a plist under /var/tmp that could be controlled by a local user. In certain circumstances, the installer could use that information when assigning Homebrew ownership, creating an opportunity for a local attacker.

Homebrew 6.0 also introduces an interesting tool for operational security: brew vulns. Distributed through a new Homebrew tap, the subcommand checks installed packages against known vulnerabilities.

For administrators already using Homebrew as part of workstation management, that provides another mechanism for examining the software installed outside the operating system’s native package-management tools.

Linux Gets Bubblewrap Sandboxing and a New glibc Baseline

Homebrew’s Linux users face two notable changes.

The first is a Bubblewrap-based sandbox.

Homebrew already uses sandboxing on macOS for build, test, and post-installation phases. The project has now worked to bring Linux closer to that model while sharing more of the implementation between the two operating systems.

The work includes sandboxing for cask executable hooks, hardened installation phases, improvements to logging from sandboxed processes, and integration with Homebrew’s CI environment.

The second change concerns compatibility.

Homebrew has migrated its continuous integration baseline to Ubuntu 24.04, raising the Linux reference environment to glibc 2.39.

Systems running an older system glibc move to Tier 2. Homebrew specifically cites Ubuntu 22.04 with glibc 2.35 as an example.

Tier 2 does not mean Homebrew immediately stops working. It does mean new bottles will no longer be built for those configurations, and brew doctor will warn users about the unsupported baseline.

That distinction matters for administrators deliberately keeping development or server environments on older long-term support distributions.

Homebrew recommends moving to a Tier 1 configuration such as Ubuntu 24.04 or, where appropriate, using its ghcr.io/homebrew/brew container image.

`brew bundle` Becomes More Useful for Workstation Provisioning

Homebrew 6.0 includes a substantial set of improvements to brew bundle.

One of the most practical is parallel formula installation, with jobs now started automatically when possible.

The command can also manage a broader range of tooling. Homebrew has added npm and krew extensions, while winget support is available for Windows-specific bundle configurations.

Cleanup support has expanded to npm, Cargo, Go, and uv packages as well.

For engineering teams that maintain a Brewfile as a declarative description of developer workstations, these additions allow more of the environment to be managed from a single configuration.

There is a security component here too. Homebrew has changed how npm installations are performed through brew bundle, with the project describing the new process as more secure.

Another addition aimed at managed fleets is brew as-console-user.

The command is designed for Mobile Device Management (MDM) and root-initiated environments where Homebrew operations need to execute as the correct console user.

Homebrew 6.0 also introduces brew exec, a command conceptually similar to npx that can execute software within environments provided by Homebrew formulae.

A Smaller JSON API Means Fewer Metadata Requests

The internal JSON API is now Homebrew’s default.

Homebrew had offered this mechanism as an opt-in through HOMEBREW_USE_INTERNAL_API since version 5.0.0. That environment variable is now deprecated because the internal API is enabled by default.

The change affects how Homebrew retrieves package metadata.

Instead of relying on the previous approach, the internal API combines Homebrew metadata into a smaller download. According to the project, this allows brew to update faster while making fewer network requests.

There are performance improvements elsewhere too.

Homebrew reports startup optimizations, less work loading Ruby libraries, parallel bottle-tab fetching during upgrades, and an approximately 30% improvement in brew leaves.

The project also explored a more fundamental performance change through brew-rs, an experiment that moved parts of Homebrew’s Ruby frontend to Rust.

That experiment has now ended.

According to Homebrew, the Rust implementation was faster in narrow scenarios such as already-cached bottle fetches, but it did not deliver a sufficient advantage across representative full installations involving bottle extraction, linking, metadata writes, and health checks.

Development effort has therefore returned to the Ruby implementation, with a greater focus on starting useful network and disk I/O earlier.

For infrastructure tooling, the outcome is a useful reminder that replacing a language does not necessarily reduce end-to-end execution time when much of the workload depends on storage, networking, decompression, and external processes.

Intel Mac Support Is Entering Its Final Phase

Homebrew 6.0 adds initial support for macOS 27 Golden Gate, but Apple’s new operating system no longer supports Intel Macs.

Homebrew has consequently defined its own timeline for retiring macOS x86_64.

The first major change arrives in September 2026.

Intel macOS will move to Tier 3. Homebrew will no longer provide CI coverage for the platform, and new bottles will no longer be built specifically for Intel-based macOS systems.

The final step comes one year later.

In September 2027, Homebrew plans to drop Intel macOS support entirely and remove the related code.

This matters for organizations that still use Intel Macs as developer workstations, lab machines, build systems, or CI runners.

Existing packages will not suddenly stop executing when the Tier 3 transition happens. The operational problem is more gradual: relying on Homebrew to keep those machines current will become increasingly difficult once official testing and new precompiled binaries disappear.

Organizations with remaining Intel Macs therefore have a concrete date to include in hardware lifecycle and CI migration planning.

At the same time, Homebrew 6.0 adds recognition for M5, M5 Pro, and M5 Max, reinforcing the project’s transition toward Apple Silicon.

For system administrators and developers evaluating the upgrade, three areas deserve particular attention: third-party and private taps, Linux systems running older glibc versions, and any automation that still depends on Intel-based Macs.

The familiar brew install workflow remains largely intact. Homebrew 6.0 changes more of what happens behind that command: which repositories are allowed to execute code, how installation processes are isolated, how workstation configurations are reproduced, and which legacy platforms will continue receiving supported packages.

Frequently Asked Questions

Do private taps need changes with Homebrew 6.0?

Possibly. Homebrew 6.0 introduces explicit trust requirements for third-party taps before their code is evaluated. Teams should review provisioning scripts, CI configurations, and Brewfiles that rely on private or external taps.

Does Homebrew 6.0 stop supporting Ubuntu 22.04?

Not immediately. Ubuntu 22.04 falls into a Tier 2 configuration because its system glibc is older than Homebrew’s new baseline. New bottles will not be built for that configuration, and brew doctor will issue a warning.

When will Homebrew stop supporting Intel Macs?

Intel macOS moves to Tier 3 in September 2026, losing CI coverage and new platform-specific bottles. Homebrew plans to remove Intel macOS support entirely in September 2027.

What changes in `brew bundle` with Homebrew 6.0?

Among other improvements, brew bundle gains parallel formula installation, npm and krew extensions, broader cleanup support, and the ability to represent trusted taps in Brewfiles.