Homebrew 7.0.0: what breaks on Monday and what to adopt

A volunteer project just retired a CPU architecture

Homebrew 7.0.0 went out on 13 September, and the release post summarises itself in one sentence: "The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3."

That last clause is why the Hacker News thread hit 585 points and 234 comments within a day, with lead maintainer Mike McQuaid answering throughout. The plain reading is uncomfortable: a package manager run by volunteers has stopped supporting an entire architecture because the two companies that used to supply the hardware and the CI minutes have walked away. The post puts it bluntly: "Apple and GitHub's retreat from Intel support exceeds what Homebrew's volunteers can replace." Apple "have dropped Intel x86_64 support from macOS 27 Golden Gate" and "GitHub Actions will retire Intel macOS runners in autumn 2027."

This is not a changelog. The GitHub release bundles 127 merged pull requests from 23 contributors, and you can read those yourself. What follows is what actually breaks when you open a laptop or a CI dashboard this week, and the two additions worth adopting before you touch anything else.

The Intel MacBook on your desk

If you are on Intel, the important date is not the one in the release post. Officially, "Homebrew moves macOS Intel x86_64 to Tier 3 in September 2026", with support ending on 2027-09-01. In practice the Intel CI runners were switched off on 31 August, ahead of the deadline, because pre-test setup on those runners had ballooned from seconds to more than two hours and nobody could debug why.

The consequence is already visible: Intel users are hitting "no bottle available!" on install. The documented options are brew install --build-from-source on a configuration Homebrew no longer tests, or moving to MacPorts.

"Tier 3" sounds like a soft landing. It is not. The support-tier docs define it as: "A Tier 3 configuration is not supported. These configurations fall far outside Homebrew's testing infrastructure and may fail to function reliably, even if basic installation is possible." Tier 1 is now Apple Silicon on Sequoia 15, Tahoe 26 and Golden Gate 27. There is no Intel row above Tier 3.

The pushback in the thread was that Apple shipped a major macOS for Intel only a year ago, so the cut feels early. McQuaid's answer, in substance, was that if Apple and GitHub cannot keep supporting Intel macOS, Homebrew cannot either. Whatever you make of that, an Intel Mac is now a machine where brew upgrade can turn into a compile job with no upstream to file against. If that laptop is on your team, budget the replacement now rather than in September 2027.

Two smaller floor changes travel with this: the minimum macOS is now Big Sur (11), so 10.15 is gone entirely, and the macOS installer package is Apple Silicon only.

The CI job and the Brewfile that stop working

The migration guide is short and every line of it will bite someone. Check your repos for these before they fail:

• Homebrew/actions@master. The master branch is frozen and the compatibility bootstrap retires on 2027-03-01. Pin to main, a CalVer release, or a SHA, while the fix is still a one-line diff.
• HOMEBREW_BUNDLE_JOBS. Replaced by HOMEBREW_DOWNLOAD_CONCURRENCY. If your Dockerfile or CI env exports the old name, concurrency silently falls back to the default.
• brew bundle install --cleanup. Gone. Cleanup is now a separate brew bundle cleanup step, so a script that relied on the combined flag leaves stale formulae behind rather than failing loudly.
• HOMEBREW_EVAL_ALL / --eval-all. Removed. Tap maintainers who used it for audits across all formulae need a different approach.
• brew update --merge. Disabled.
• HOMEBREW_NO_SANDBOX_CASK. Disabled with no replacement. A cask that only installed with the sandbox off now needs fixing at the cask.

None of these are dramatic alone. The problem is that they live in .github/workflows, Brewfile and Dockerfile files nobody has opened in a year. A grep -r across your org for the identifiers above is a ten-minute job that saves a confusing Monday.

The Linux image that assumed Bubblewrap

On Linux the sandboxing story flipped. Bubblewrap is out: "Homebrew 7.0.0 replaces it with Landlock, requiring no dependencies or escalated Docker permissions, which caused setup problems with Bubblewrap."

That is good news for anyone who ever added --privileged or extra capabilities to a container just so brew could sandbox a build. Those flags can come out. Watch the other direction too: HOMEBREW_NO_SANDBOX_LINUX is deprecated, with removal on 2027-12-11. If an image sets it to sidestep the Bubblewrap dependency, the reason for the override has already gone. Remove the variable, rebuild, and confirm the build passes under Landlock while you still have a year of fallback.

The release also tightens the sandbox on macOS; the notes list items such as "Narrow mkdir_p sandbox write permissions". A formula that was quietly writing outside its prefix during install may start failing. That is the sandbox doing its job, not a regression to work around.

Adopt this first: brew vulns and the CC0 advisory database

Here is the part of the release that should change how you run a Mac fleet. brew vulns is now built in, "checking known vulnerabilities using OSV.dev without another tap or gem". Behind it is a new advisory database that "records vulnerabilities against the formula versions and revisions Homebrew ships, including backported security fixes", published as OSV-format records that are "freely reusable under CC0".

The distinction from brew audit matters. Audit checks whether a formula is well-formed; it has never told you whether the installed version of curl has a known CVE. Generic scanners that match on upstream version numbers get Homebrew wrong in the other direction, flagging a formula as vulnerable when Homebrew already backported the fix at a revision bump. A database keyed on the exact formula version and revision, maintained by the people who do the backporting, closes that gap. Because it is CC0 and in OSV format, a security team can ingest it into whatever they already run without a licence conversation.

The minimum useful setup is a scheduled CI step on any repo that ships a Brewfile:

brew update
brew bundle install
brew vulns

Run it on a schedule, not only on push, because the advisory database changes independently of your code. For laptops, a daily brew vulns catches the machine that has not run brew upgrade since spring.

The second adoption is smaller but changes daily habits: brew install --dry-run now previews both formulae and casks. Before a big upgrade on a machine you depend on, a dry run shows exactly what would move, and on Tier 3 hardware it shows which installs are about to become source builds.

Two more items from the same release: eight security advisories are fixed (one High, two Moderate, five Low), and the macOS installer now ignores prefix-owned Git configuration that could previously have executed as root. If you image machines with the installer package, rebuild your base image.

The Rust rewrite that was slower

One exchange in the Hacker News thread deserves a wider audience than a comment section. Asked about performance, McQuaid said of a Rust rewrite: "I tried it. It ended up being slower on most non-synthetic benchmarks", adding that the lessons from the attempt were used to make the Ruby front end faster.

The 7.0.0 speedups came from that route. brew install, brew reinstall and brew upgrade now "overlap package preparation and downloads", and brew config "gathers independent system details concurrently". Portable Ruby moved to 4.0.6_2. None of it required abandoning the language.

The reflexive advice for any slow tool is to rewrite it in a faster one. This is a data point from someone who did the work: the synthetic benchmarks looked good, the real workload did not, and profiling the existing code paid off instead. Measure what the tool actually does before you pick a language for the rewrite.

The other thread running through the discussion was how much of the release was written with LLM assistance. McQuaid's answer, paraphrased, was that a good deal of his own work was, that he reviews all of it locally before it goes anywhere, and that he built his own agent IDE to do it. The Lobsters thread was quieter, at 45 points and 3 comments.

What to do this week

In order, and the whole list is under an hour for a typical team:

1. Inventory Intel Macs. Any machine still on x86_64 is on an unsupported tier with no CI behind it. Decide whether it builds from source, moves to MacPorts, or gets replaced.
2. Grep for the removed flags. Homebrew/actions@master, HOMEBREW_BUNDLE_JOBS, --cleanup on brew bundle install, HOMEBREW_EVAL_ALL, HOMEBREW_NO_SANDBOX_CASK. Fix each where it lives.
3. Clean up Linux images. Drop the Bubblewrap workarounds and the HOMEBREW_NO_SANDBOX_LINUX override, rebuild, verify under Landlock.
4. Add brew vulns to CI on a schedule, and point your security team at the CC0 advisory database.
5. Use --dry-run before the first big upgrade on any machine you rely on.

The bigger lesson is about free infrastructure. Homebrew did not drop Intel because it wanted to; it dropped Intel because Apple stopped shipping the OS and GitHub is retiring the runners, and volunteers cannot fund the difference. If your own pipeline leans on donated hardware or free CI tiers, those can be withdrawn on someone else's schedule too.