Safeguard
Supply Chain Security•

How to Install Homebrew on Mac and Linux Safely (What the Script Does)

Install Homebrew from brew.sh with its script, or the signed .pkg on Apple silicon. Read the script first, add brew shellenv to PATH, and keep it patched.

Safeguard Security Team
33 min read

To install Homebrew, go to brew.sh and run the one line installer in Terminal: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)". On an Apple silicon Mac you can instead use the signed Homebrew.pkg from Homebrew's latest GitHub release. On Linux and WSL 2, the same script installs to /home/linuxbrew/.linuxbrew.

The rest of this guide covers what the script actually does (we read all 1,243 lines), how to check the .pkg signature, the PATH step people miss, how Homebrew verifies packages, patching with the new brew vulns command, and clean removal. Every command comes from Homebrew, GitHub or Apple documentation, linked under Sources.

Key takeaways

  • The only official installers are the script linked from brew.sh and the .pkg on the Homebrew/brew GitHub releases page.
  • Since Homebrew 7.0 (September 2026) the installer refuses Intel Macs. Apple silicon on macOS Sequoia 15 or later is the supported setup.
  • The script prints every change and waits for RETURN, refuses to run as root, and checks out the latest tagged release, not the development branch.
  • The 7.0.10 .pkg we checked on 23 October 2026 was Developer ID signed and notarized; verify yours with pkgutil --check-signature.
  • After installing, run the brew shellenv lines the installer prints, or brew will not be found in new shells.
  • Patch weekly: brew update, brew outdated, brew upgrade, and now brew vulns to check installed formulae against OSV.dev.

What is Homebrew, and where does it install?

Homebrew is a package manager for macOS and Linux, including WSL. It installs command line tools and libraries (called formulae) and, on macOS, applications, fonts and plugins (called casks). Each package goes into its own folder, a keg, inside the Cellar, and Homebrew symlinks the files into its prefix. brew.sh says Homebrew does not install files outside its prefix, with exceptions for some casks and system services that need elevated privileges.

Where that prefix lives depends on the platform:

PlatformDefault prefixSupport status (Homebrew Support Tiers, September 2026)
macOS on Apple silicon/opt/homebrewTier 1 on Sequoia 15, Tahoe 26 and Golden Gate 27
macOS on Intel/usr/localTier 3 (legacy); no new bottles; removal in or after September 2027
Linux and WSL 2/home/linuxbrew/.linuxbrewTier 1 with glibc 2.39 or newer on x86_64 (with SSSE3) or ARM64
WSL 1/home/linuxbrew/.linuxbrewTier 3; Homebrew recommends WSL 2
Native WindowsNot supportedThe script aborts on anything but macOS and Linux

Stick to the default prefix. Prebuilt packages, called bottles, target it, and a custom prefix only gets bottles if it is no longer in bytes than the default. The FAQ adds that /opt/homebrew was chosen so it can coexist with a Rosetta 2 install in /usr/local, the root of most "wrong architecture" problems.

What do you need before installing?

macOS requirements

From the Homebrew Installation page and the install script's own checks:

  1. An Apple silicon Mac. On any other CPU the current script stops.
  2. macOS Sequoia 15 or later. Outside the range 15.0 to below 28.0 the script warns that the install may not succeed, then continues. Catalina 10.15 and earlier will not run Homebrew at all.
  3. /bin/bash for the installer. Homebrew's docs note zsh, fish, tcsh and csh will not run it, though Homebrew works from zsh afterwards.
  4. Git 2.7.0 or newer and curl 7.41.0 or newer. The script aborts without a usable Git. On a fresh Mac, Git comes from Apple's Command Line Tools, which the script installs if they are missing and you have sudo.
  5. An administrator account, or a writable prefix provisioned for a non admin account, as covered under Mac fleets below.

Linux requirements

Homebrew on Linux expects a working system C compiler and standard development tools. The Homebrew on Linux page lists these commands:

# Debian or Ubuntu
sudo apt-get install build-essential procps curl file git

# Fedora
sudo dnf group install development-tools
sudo dnf install procps-ng curl file

# CentOS Stream or RHEL
sudo dnf group install 'Development Tools'
sudo dnf install procps-ng curl file

# Arch Linux
sudo pacman -S base-devel procps-ng curl file git

Homebrew uses only your system's glibc and gcc, and installs its own on older distributions. Tier 1 needs glibc 2.39 or newer; 2.13 to 2.38 is Tier 2. 32 bit x86 is not supported, and 32 bit ARM is Tier 3 without bottles.

Script or .pkg: which installer should you use?

Homebrew offers two official installers. brew.sh recommends the script for most people and the .pkg "for interactive or unattended MDM installs."

QuestionShell script (install.sh)macOS .pkg installer
Where it comes fromraw.githubusercontent.com/Homebrew/install/HEAD/install.sh, linked from brew.shRelease assets of github.com/Homebrew/brew/releases/latest
PlatformsmacOS on Apple silicon, Linux, WSLmacOS on Apple silicon, Sequoia 15 or later only
Needs Git already installedYes, or it installs Apple's Command Line Tools firstNo; Homebrew's Mac admin guide recommends it for hosts without Git
How you check itRead the script before running it; it is plain BashDeveloper ID signature and Apple notarization, checked with pkgutil and spctl, plus the SHA-256 digest GitHub shows for the asset
Best fitIndividual developers, Linux servers, WSLMDM rollouts, login window installs, Macs without sudo for the user
Custom ownerRun as that account, or provision the prefixHOMEBREW_PKG_USER setting

Both end with Homebrew in the default prefix, owned by a normal account, so formula installs never need sudo.

What does the Homebrew install script actually do?

brew.sh describes the script in one line: "The script explains what it will do and then pauses before it does it." That is accurate, and the details matter when you run a Bash program with your password at hand. Here is what the 1,243 line version served on 23 October 2026 does, in order.

1. Safety checks before anything changes

  • It requires Bash, not in POSIX mode.
  • If /etc/homebrew/brew.no_install exists, it aborts and prints the file's contents as the reason, a simple block for managed machines.
  • If CI is set or standard input is not a terminal, it runs non interactively without prompts, as NONINTERACTIVE=1 does.
  • It checks the OS (Linux or Darwin), the CPU (Apple silicon on macOS; x86_64 or aarch64 on Linux) and that any --path prefix is absolute, no longer than the default, and not / or /usr.
  • It refuses to run as root ("Don't run this as root!") unless it detects a container or CI job.

2. A sudo check

The script checks whether your account can use sudo, which may prompt for your password once. It uses sudo only for specific steps: creating and setting ownership on the prefix, installing the Command Line Tools, and writing a PATH entry. Every privileged command goes through one helper that prints the command before it runs.

3. A printed plan, then a pause

Before changing anything, it prints "This script will install:" with brew, its man page, completions, the repository directory and, on macOS, /etc/paths.d/homebrew. It then lists directories to be made writable, re-owned or created, whether it will install the Command Line Tools, and any non default Git remote. Then it waits: "Press RETURN/ENTER to continue or any other key to abort." If the list changes ownership of directories you did not expect, press any other key.

4. Directory setup

It creates the prefix owned by your user (and, for macOS administrators, the admin group). For non admin accounts in the staff group it removes group and other write permissions, since every standard macOS account is in staff. It also creates the cache directory in your home folder.

5. Command Line Tools, Git and curl

On macOS, if the Command Line Tools are missing and you have sudo, the script installs them through Apple's softwareupdate tool, falling back to the xcode-select --install dialog. It then searches PATH for Git 2.7.0 or newer and curl 7.41.0 or newer, and prints which ones it found.

6. Downloading Homebrew itself

This is the core step, and it is plain Git:

  1. git init inside the repository directory.
  2. Set the remote to https://github.com/Homebrew/brew, unless you overrode HOMEBREW_BREW_GIT_REMOTE.
  3. Fetch branches and tags, retrying up to five times.
  4. Find the highest version tag and check it out as a local branch called stable.

So you get the latest tagged release, not whatever was merged to the main branch five minutes ago. What the script does not do is verify a cryptographic signature on that tag; it relies on HTTPS to GitHub and Git's object integrity.

7. PATH entry and first update

On macOS with the default prefix and sudo available, the script writes a file at /etc/paths.d/homebrew containing /opt/homebrew/bin, owned by root with mode 0644. It then runs brew update --force --quiet, which downloads Homebrew's package metadata.

8. Analytics notice and next steps

It prints an analytics notice with the opt out link, stating no analytics were sent during the install, then "Next steps" with the shell configuration lines for your shell and, on Linux, a reminder to install build tools.

Why bash -c "$(curl ...)" and not curl | bash

The official command wraps curl in command substitution. Bash cannot start until curl has finished downloading the whole script, so a dropped connection cannot leave you running half a script. The -f flag makes curl fail on an HTTP error instead of handing an error page to Bash. That is a better pattern than piping straight into a shell, but it still runs whatever the server returns, which is why reading the script first is worth five minutes.

How to read the script before you run it

Homebrew's install README documents downloading the uninstall script to a file with curl -fsSLO and running it with /bin/bash. The same pattern works for the installer, and Homebrew's Mac admin guide also runs a saved copy of install.sh:

curl -fsSLO https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh
less install.sh
/bin/bash install.sh

What to look for while reading:

  • The default remotes near the top: https://github.com/Homebrew/brew and https://github.com/Homebrew/homebrew-core.
  • Every use of execute_sudo, the only path to root.
  • No other download hosts: Homebrew itself comes from GitHub over Git.

The file and its full change history are in the Homebrew/install repository on GitHub.

How to install Homebrew on a Mac, step by step

Step 1: check your Mac

Open Terminal and confirm the CPU architecture and macOS version:

arch
sw_vers -productVersion

arch should print arm64 on Apple silicon. If it prints anything else on an Apple silicon Mac, your terminal is running under Rosetta; fix that first (see Common errors). The version should be 15 or higher.

Step 2 (optional): install the Command Line Tools yourself

The script installs them if they are missing, but installing them first means the Homebrew run is shorter and you see Apple's own prompt directly:

xcode-select --install

Homebrew's Common Issues page notes that installing Xcode alone is not enough; the Command Line Tools are a separate package.

Step 3: get the command from brew.sh

Type brew.sh into the address bar yourself rather than clicking a search result, and copy the command from the page. It should be exactly:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

If you prefer to read first, use the three line download, read and run sequence above.

Step 4: read the plan, then press RETURN

Enter your password when asked for sudo. Read the "This script will install" list and the directory changes. On a clean Apple silicon Mac you should see /opt/homebrew paths and /etc/paths.d/homebrew, nothing in your home folder except the cache. Press RETURN to continue.

Step 5: run the PATH commands it prints

This is the step people skip. When the install finishes, the "Next steps" section prints commands for your shell. For the default zsh on macOS, they look like this:

echo >> ~/.zprofile
echo 'eval "$(/opt/homebrew/bin/brew shellenv zsh)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv zsh)"

Copy the lines from your own terminal rather than from this page, because they depend on your shell and prefix. For bash on macOS the file is ~/.bash_profile; for fish it is ~/.config/fish/config.fish. Homebrew's Installation page is blunt about it: if you do not follow those directions, Homebrew will not work.

What brew shellenv does: according to the brew manual, it prints export statements that add Homebrew to your PATH, MANPATH and INFOPATH, and set HOMEBREW_PREFIX, HOMEBREW_CELLAR and HOMEBREW_REPOSITORY. It prints nothing if Homebrew's directories are already in PATH, so running it twice is harmless. The /etc/paths.d/homebrew file the installer wrote also puts /opt/homebrew/bin on the PATH for login shells, but shellenv sets the full environment and is the documented step.

Step 6: confirm and diagnose

Open a new Terminal window and run:

brew --version
brew --prefix
brew doctor

brew --prefix should print /opt/homebrew. brew doctor exits non zero if it finds potential problems; the manual says its warnings are mainly for debugging.

Step 7: decide on analytics

Homebrew's Analytics page says events include package names, install options, CPU architecture, OS and Homebrew version, with no user identifier or IP address field, kept for 365 days. To opt out before installing anything, run the first command below, or set the variable in your shell profile:

brew analytics off
export HOMEBREW_NO_ANALYTICS=1

Installing with the .pkg instead

  1. Go to github.com/Homebrew/brew/releases/latest. On 23 October 2026 that was 7.0.10, published 19 October, with one asset, Homebrew.pkg.
  2. Download it and verify it as described in the verification section below.
  3. Open it and follow the macOS Installer, which installs to /opt/homebrew.
  4. Add the brew shellenv line from Step 5 to your shell profile yourself.

Mac fleets, non admin accounts and MDM

From Homebrew's Mac admin guide and Installation page:

  • Homebrew is designed for one owning account. It "provides no security guarantees" when users with write access to the prefix are untrusted, including .pkg installs through MDM.
  • For MDM, use the .pkg with HOMEBREW_PKG_USER to name an existing, non root owner. The settings file must be owned by root, mode 0600, with no access control list, or the installer falls back to the console user.
  • export HOMEBREW_NO_SUDO=1 stops Homebrew calling sudo; casks that need it are rejected.
  • Agents running as root should use brew as-brew-user install wget or brew as-console-user install wget, never plain brew as root.
  • The brew manual's HOMEBREW_FORBIDDEN_FORMULAE, HOMEBREW_FORBIDDEN_CASKS, HOMEBREW_FORBIDDEN_TAPS and HOMEBREW_FORBIDDEN_LICENSES variables make Homebrew refuse matching installs, and the installer refuses to run if /etc/homebrew/brew.no_install exists.

The HOMEBREW_PKG_USER settings file, from Homebrew's Installation page (replace penny with the account):

sudo defaults write /var/tmp/.homebrew_pkg_user HOMEBREW_PKG_USER penny
sudo chown root:wheel /var/tmp/.homebrew_pkg_user.plist
sudo chmod 600 /var/tmp/.homebrew_pkg_user.plist
sudo chmod -N /var/tmp/.homebrew_pkg_user.plist

What about Intel Macs?

Homebrew 7.0.0 (September 2026) moved Intel Macs to Tier 3, citing macOS Tahoe 26 as the last macOS for Intel and GitHub retiring Intel macOS runners in autumn 2027. Existing Intel installs keep working without routine bottle builds until Homebrew removes Intel support in or after September 2027. The current installer and the .pkg will not start a new Intel install; Homebrew's docs point Intel users to MacPorts. If you already run Homebrew in /usr/local, keep it patched while you plan a move.

How to install Homebrew on Linux

  1. Install the build tools for your distribution, from the list in the prerequisites section.
  2. Run the same command as on macOS, as your normal user, not root:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
  1. Read the plan and press RETURN. The script creates /home/linuxbrew/.linuxbrew, using sudo only if your account cannot write there.
  2. Add Homebrew to your shell, as the Homebrew on Linux page documents for Bash. Use ~/.zshrc instead if zsh is your login shell.
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bashrc
  1. Test it:
brew install hello
brew doctor

Homebrew's FAQ says this prefix avoids writing to system owned directories after installation while still allowing most bottles. It does not replace apt, dnf or pacman. Keep the operating system and anything that runs as root on your distribution's packages, which get security backports, and use Homebrew for user level tools your distribution ships old or not at all.

Homebrew on Windows: WSL only

There is no native Windows Homebrew. Install a Linux distribution under WSL 2, open its shell, install its build tools and follow the Linux steps exactly. Homebrew's Linux page recommends WSL 2 because WSL 1 has known issues running Homebrew executables. Homebrew in WSL manages only that Linux environment, so Windows applications still need their own update routine.

How do you verify the installer and what Homebrew installs?

Verification works at three layers: the installer, Homebrew itself, and each package you install afterwards.

The install script

The script has no signature or published checksum. Its trust comes from where it is served, its public history on GitHub, and you reading it. For automation, keep a reviewed copy of install.sh in your own configuration repository and run that, as Homebrew's Mac admin guide does for MDM agents.

The .pkg installer

The .pkg gives you three independent checks. We ran all three on 23 October 2026 against Homebrew.pkg from release 7.0.10.

1. Compare the SHA-256 with the digest on the release page:

shasum -a 256 Homebrew.pkg

Ours matched the digest GitHub listed for 7.0.10: ae13b8b0ac910730d3e982a9e7518288d17fd0ad272e42f412027e8ab4555575. Homebrew says it enables immutable GitHub releases, and GitHub documents a CLI check that a local file matches an immutable release asset, run with Homebrew/brew as the repository:

gh release verify-asset RELEASE-TAG ARTIFACT-PATH

2. Check the installer signature (from man pkgutil on macOS):

pkgutil --check-signature Homebrew.pkg

Ours reported a package signed with a Developer ID Installer certificate, Team ID 927JGANW46, in the name of a maintainer credited in the release notes, chaining to Apple Root CA, notarized, with a trusted timestamp of 19 October 2026. Homebrew's docs do not publish an expected Team ID, so record the one you see and treat a change as a reason to stop.

3. Ask Gatekeeper (from man spctl):

spctl -a -vvv -t install Homebrew.pkg

Ours returned accepted with source=Notarized Developer ID. Notarization is Apple's automated scan for malicious content and signing problems; Homebrew's security guide notes it is "not a source review." The ticket was not stapled, so this check needs network access.

Bottles: checksums, signed metadata and attestations

Homebrew's security guide describes these protections for what it installs:

  • Pinned checksums. Each formula pins its download to a SHA-256; a mismatch fails the install, and changing a checksum needs a maintainer reviewed pull request.
  • Bottles built by Homebrew from the reviewed formula on ephemeral CI runners, with their checksums also in the formula.
  • Signed JSON API. Package metadata from formulae.brew.sh is JWS signed and verified before use.
  • Build provenance attestations, published by Homebrew CI and backed by Sigstore's public transparency log. Verification is opt in and needs the GitHub CLI:
brew install gh
export HOMEBREW_VERIFY_ATTESTATIONS=1

With this set, Homebrew verifies build provenance for bottles from homebrew/core and supported third party taps before installing. Homebrew hopes to make this the default once it works in pure Ruby.

Casks: a different trust model

Casks install vendor built apps. Their SHA-256 proves the download matches the metadata, not who built it, so Homebrew applies macOS quarantine and lets Gatekeeper check signing and notarization, and it removes official casks that fail. Our post on Homebrew cask security verification goes deeper.

Taps: trust only what you need

Third party repositories, called taps, contain Ruby code that runs with your privileges when Homebrew loads it. Since Homebrew 6.0.0, non official taps need explicit trust. The Tap Trust page recommends trusting a single item rather than a whole tap:

brew tap user/repository
brew trust --formula user/repository/formula
brew install formula

brew trust alone lists what you have trusted. See also Homebrew formula security incidents, Homebrew formula security for engineering teams and checksum vs signature: which to trust for a download.

How to avoid lookalike "brew install" pages

Install commands are an attractive target because people paste them into a terminal with an administrator password ready. A fake page only needs to change one URL in the command. Some habits that make that much harder:

  1. Type brew.sh yourself rather than clicking sponsored search results, which can copy the real site's title.
  2. Check the URL in the command before pressing Enter. The only official script URL is https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh. Another domain, a URL shortener, a gist or a different GitHub account is not Homebrew, and neither is a multi line "setup" snippet.
  3. Do not set Git mirror variables you did not choose. HOMEBREW_BREW_GIT_REMOTE and HOMEBREW_CORE_GIT_REMOTE redirect where Homebrew comes from. Homebrew's docs warn that setting them grants those repositories the same trust as Homebrew itself. The installer prints a notice when they are set; if you see it and did not set them, abort.
  4. Get the .pkg only from the Homebrew/brew releases page and check its signature, whatever a file elsewhere is named.
  5. Treat commands from forums and AI chat answers as untrusted until you have compared them with brew.sh and docs.brew.sh.

How to keep Homebrew and your packages patched

Homebrew is a rolling release package manager. The FAQ's update routine is four commands:

brew update
brew outdated
brew upgrade
brew upgrade <formula>

brew update refreshes Homebrew and its metadata, brew outdated lists what is behind, and brew upgrade upgrades everything or one named formula, plus related formulae, since Homebrew only tests the latest combination. More in brew update vs brew upgrade vs brew outdated.

Automatic updates

Per the brew manual, Homebrew runs brew update before commands such as brew install or brew upgrade once every 24 hours by default, adjustable with HOMEBREW_AUTO_UPDATE_SECS or disabled with HOMEBREW_NO_AUTO_UPDATE=1. If you disable it, schedule brew update elsewhere. Auto update never upgrades installed packages; that is still brew upgrade.

Casks that update themselves

A plain brew upgrade skips self updating casks when it cannot reliably compare versions, per the FAQ. To include them:

brew upgrade --greedy

Check installed formulae for known vulnerabilities with brew vulns

Homebrew 7.0.0 added a built in brew vulns command and an advisory database that records vulnerabilities against the formula versions Homebrew ships, including backported fixes. With no arguments, it checks all installed formulae against OSV.dev:

brew vulns
brew vulns --severity=high
brew vulns --fix-available
brew vulns --brewfile
brew vulns --json

--fix-available limits output to vulnerabilities with a released fix, which is your "upgrade now" list. --brewfile checks what a Brewfile would install. The manual is clear about scope: casks and packages installed by other package managers are not scanned, and "a complete scan does not guarantee the absence of vulnerabilities."

Patch Homebrew itself

Homebrew has its own advisories. The 7.0.0 notes list GHSA-rg9r-ppxp-87hm (High, fixed in 6.0.12), where unsigned cask removal metadata could execute commands with sudo, among others. brew update moves you to the latest tagged release; confirm with brew --version.

Fleets and Brewfiles

A Brewfile run with brew bundle gives each machine a reviewable package list, and brew vulns --brewfile checks it. On managed Macs, run updates as the prefix owner with brew as-brew-user update.

How to uninstall Homebrew cleanly

Homebrew's FAQ points to the official uninstall script in the Homebrew/install repository. Run it as the same user who owns Homebrew:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

Better, download it and do a dry run first. The README documents the download, and the script's own help lists a --dry-run option that simulates removal without deleting anything:

curl -fsSLO https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh
/bin/bash uninstall.sh --help
/bin/bash uninstall.sh --dry-run
/bin/bash uninstall.sh

To remove an old Intel install in /usr/local from an Apple silicon Mac, pass the prefix, as the README shows:

/bin/bash uninstall.sh --path /usr/local

What the script removes: Homebrew's repository, the Cellar and Caskroom (so every formula and cask installed through Homebrew), Homebrew's symlinks in the prefix, the /etc/paths.d/homebrew file if it contains the Homebrew bin path, and by default the cache and logs. Use --skip-cache-and-logs to keep those. It then lists any "possible Homebrew files" it did not delete, for you to review by hand. If some steps fail, it says Homebrew was partially uninstalled and suggests running it again with sudo.

Afterwards, remove the brew shellenv line from your shell profile, and any brew.env files or ~/.homebrew/trust.json tap trust file you no longer need. Before removing an install you still use, brew bundle dump records its packages in a Brewfile.

Common errors and how to fix them

"brew: command not found" after installing

You skipped Step 5, or added the line to a file your shell does not read. Run the brew shellenv commands the installer printed, then open a new terminal. To fix the current session immediately on Apple silicon:

eval "$(/opt/homebrew/bin/brew shellenv)"

On Linux, use the /home/linuxbrew/.linuxbrew path. Lost the printed commands? Homebrew's docs say the installer can be rerun on an existing installation.

"Homebrew on macOS is only supported on Apple Silicon processors!"

You are on an Intel Mac, or your Terminal is running under Rosetta on Apple silicon. Run arch. If it prints anything other than arm64 on an Apple silicon Mac, your terminal app is running under Rosetta; run it natively and try again. On a real Intel Mac, see the Intel section.

Two Homebrew installs or the wrong architecture

Migration Assistant or an x86_64 terminal can leave both /usr/local and /opt/homebrew installs active. Homebrew's Common Issues page suggests checking:

arch
command -v brew
brew --prefix

An Apple silicon shell should normally report arm64 and use /opt/homebrew. Before removing the old Intel install, record its packages with its own executable:

arch -x86_64 /usr/local/bin/brew bundle dump --file=~/intel-Brewfile

Review the Brewfile, reinstall under /opt/homebrew, and only then uninstall the /usr/local copy with --path /usr/local. brew doctor also warns when another brew shadows the current one in PATH.

Permission errors on /usr/local or the prefix

Homebrew's guidance is not to recursively change ownership or permissions of the whole prefix or Caskroom, including /usr/local on Intel, without first identifying the wrong path and its expected owner. Run brew doctor and include ls -ld output for that path if you ask for help. If the installer reports that the prefix "exists but is not searchable," its own message suggests restoring default permissions:

sudo chmod 775 /opt/homebrew

"Don't run this as root!"

You ran the installer with sudo or as root. Run it as your normal user; it asks for sudo itself when needed. In MDM, use the .pkg with HOMEBREW_PKG_USER or run the script as the target user, as shown in the Mac admin guide.

Xcode Command Line Tools missing or outdated

If brew doctor reports missing or outdated Command Line Tools, install all available macOS updates, then reinstall the tools if needed:

xcode-select --install

After a major macOS upgrade, Common Issues recommends brew update then brew upgrade, and warns against creating symlinks for missing versioned libraries.

Common mistakes

  • Copying the install command from a page other than brew.sh, or from an ad.
  • Running the installer with sudo, or running brew as root from a management agent.
  • Skipping the shellenv step, then hand editing PATH so an old Intel brew wins.
  • Setting HOMEBREW_BREW_GIT_REMOTE from a blog post to "speed up" installs, which hands Homebrew's trust to that mirror.
  • Trusting whole third party taps when you only need one formula.
  • Running brew update but never brew upgrade, so metadata is fresh and software is old.
  • Sharing one Homebrew prefix between several users, which Homebrew calls unsupported and gives no security guarantees for.
  • Recursively chowning /usr/local to make a permission error go away.

Where Safeguard fits, honestly

Safeguard does not install Homebrew, check your .pkg signature, scan Homebrew formulae or update your laptop's packages. Patching those with brew upgrade and brew vulns stays with you or your device management.

Safeguard comes in at what those tools build: the open source dependencies your Homebrew installed Node, Python, Java or Go pull into projects and container images. Safeguard inventories those dependencies, produces SBOMs for repositories, container images and SBOM files (for example safeguard scan --dir . or safeguard scan --image with an image name), matches components against vulnerability databases and uses reachability analysis to rank the findings your code actually calls. When a fixed version exists, autonomous remediation can open a fix pull request in your Git host. Remediation ships switched off by default, so your team decides what runs on its own.

Fix it without waiting for upstream

Homebrew patches the tools on your machine; the next question is the code those tools produce. The projects you build with a freshly installed toolchain carry their own open source dependencies, and those dependencies are where most vulnerabilities live.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

Your situationWhat to use
A fixed version existsAutonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version
You need to know today whether you are affectedGold Open Source lookup and "Am I affected?" checker, free and without login
You want vulnerable versions to stop shippingThe Gold scan GitHub Action in CI, plus Safeguard policies and gates
Upstream has no fix yet, or will not ship oneA custom Gold request; fork and patch (early access)
You want to start clean on new projectsPull hardened components and images from Gold Registry

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

How do I install Homebrew on a Mac?

Open Terminal and paste the command from brew.sh: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)". Enter your password, read the list of changes, press RETURN, then run the brew shellenv commands it prints. On Apple silicon you can use the signed Homebrew.pkg from Homebrew's GitHub releases instead.

Is the Homebrew install script safe to run?

It is the official installer: it prints every change, waits for confirmation, refuses to run as root and installs the latest tagged release. It does not verify signatures, so download it, read it and run your reviewed copy, or use the signed .pkg on Apple silicon.

Why does my Mac say "brew: command not found" after installing?

Homebrew is not in your PATH yet. Run the "Next steps" commands the installer printed, which add eval "$(/opt/homebrew/bin/brew shellenv zsh)" to ~/.zprofile for zsh, then open a new terminal.

Can I install Homebrew on an Intel Mac?

Not with the current installer. Since Homebrew 7.0.0 the script stops on Intel CPUs, the .pkg is Apple silicon only, and Intel Macs are Tier 3 with no new bottles. Homebrew plans to stop running on Intel in or after September 2027 and suggests MacPorts for Intel users. Existing Intel installs still update for now.

How do I install Homebrew on Windows?

Homebrew does not run natively on Windows. Install a Linux distribution under WSL 2, install its build tools, and run the Linux install command inside it. Homebrew there manages Linux software in WSL only.

How do I install Homebrew on Ubuntu?

Run sudo apt-get install build-essential procps curl file git, then the brew.sh command as your normal user. Add eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" to ~/.bashrc and test with brew install hello.

How do I update Homebrew and everything installed with it?

Run brew update, then brew outdated to see what is behind, then brew upgrade. Add brew upgrade --greedy for casks that update themselves, and brew vulns --fix-available to see which installed formulae have known vulnerabilities with a released fix.

How do I completely uninstall Homebrew?

Download the official uninstall script with curl -fsSLO https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh, run /bin/bash uninstall.sh --dry-run to preview, then /bin/bash uninstall.sh. Remove the brew shellenv line from your shell profile afterwards and review any leftover files it lists.

See how Safeguard would help

None of these demos install Homebrew; they pick up once your new tools are building projects. To try the CLI yourself, download it from https://safeguard.sh/download and follow the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It is the flow for the first Node project you open after brew install node.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. On a new workstation, it puts dependency checks next to the toolchain Homebrew just installed.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If an assistant helps you set up projects, this limits what it can reach while it looks up findings and safe versions.

Click through it at your own pace, or open it full screen.

Quick check

Why does the official command use bash -c with curl inside $( ) rather than piping curl into bash?

Command substitution makes Bash wait until curl has downloaded the entire script, so a dropped connection cannot run half of it, and curl -f fails on HTTP errors instead of passing an error page to Bash. It still runs whatever the server sends, which is why reading a downloaded copy first is the safer habit.

Which two macOS commands let you check that Homebrew.pkg is signed and notarized?

pkgutil --check-signature Homebrew.pkg shows the Developer ID Installer certificate chain and notarization status, and spctl -a -vvv -t install Homebrew.pkg asks Gatekeeper to assess it. Compare shasum -a 256 output with the digest on the GitHub release page as a third check.

Sources

Last reviewed: 23 October 2026. Homebrew releases often; check brew.sh, docs.brew.sh and the Homebrew/brew release page for the current version and requirements.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.