Homebrew keeps complaining about my Command Line Tools after every macOS update — why does this keep coming back? Homebrew

Question 2: full Xcode contains everything the Command Line Tools do, plus the IDE, simulators and platform SDKs. You do not need both, and having both is a common source of confusion because xcode-select decides which one everything uses.

xcode-select -p

If it prints a path inside Xcode.app, your builds are using Xcode's toolchain. If it prints /Library/Developer/CommandLineTools, they are using the standalone package. Either works for Homebrew; what breaks things is pointing at one that is not there any more, which happens when somebody deletes Xcode and the setting still refers to it.

Unless you build iOS or Mac apps, the standalone tools are all you need and they are a fraction of the size. If you have Xcode for something else, keep it and skip the standalone package rather than maintaining two.

The Command Line Tools are a separate package with its own version, tied to the SDK it shipped with. A macOS update does not update them, because they are not part of the OS — they sit alongside it. So after a major update you have new system headers and an old toolchain that was built against the previous ones, and Homebrew, which compiles things, is the first thing to notice.

It keeps coming back because that is the shape of the problem, not a bug you can fix once.

The reliable repair is a clean reinstall rather than an update:

sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install

Removing first matters. Running the install over the top of a mismatched copy frequently reports success and leaves the old headers in place, which is why the fix sometimes appears not to work.

After that:

xcode-select -p
brew doctor

Practical suggestion once you have sorted the above: after any major macOS update, run the toolchain reinstall before you need it rather than discovering it mid-task.

It takes five minutes and it removes the entire category of "why has my build broken today". I keep it in the same note as the other post-update chores.

And brew doctor is genuinely worth running after an update even when nothing looks wrong — it flags the mismatched-header case explicitly, in advance, instead of letting a compile fail with something unrelated-looking three days later.

The two Homebrews are almost certainly one per architecture, and this is the thing to fix first because it explains the PATH mystery.

• /opt/homebrew — the native ARM installation
• /usr/local — the Intel one

They are separate installs with separate package trees. Having both is not an accident so much as an inevitability: install Homebrew from a terminal running under Rosetta and you get the Intel one; install it from a native terminal and you get the ARM one. Do both at different times and you have two.

Find out what you have:

which -a brew
file /opt/homebrew/bin/brew /usr/local/bin/brew 2>/dev/null

Keep /opt/homebrew and remove the other unless you specifically need an Intel package with no ARM build. Whichever appears first in your PATH is the one brew means, and that ordering is set in your shell profile — which is where the tool that "was not on my PATH" went.