Rosetta.
one update, and every Intel tool on my Mac died at once.

A macOS update took Rosetta with it, and every Intel tool on my Mac quit at the same time. How to spot it, the one-line fix, and why that fix is on a timer.

Everything broke at once

I updated macOS. Then I sat down to work on the Brasil homelab and my Mac forgot how to run anything.

git remote -v
#    -> -bash: /usr/local/bin/git: Bad CPU type in executable

brew install git
#    -> .../portable-ruby/current/bin/ruby: Bad CPU type in executable

npm run dev
#    -> env: node: Bad CPU type in executable

Three tools, one error.

I spent part of the night fixing them one at a time. New git, new PATH, next problem. It worked. It was also the wrong way to look at it. This was not three problems. It was one.

The translator I did not know I had

My Mac is Apple Silicon. Those tools were Intel, left in /usr/local by an old Homebrew install.

uname -m
#    -> arm64

file /usr/local/bin/git
#    -> /usr/local/bin/git: Mach-O 64-bit executable x86_64

Apple Silicon cannot run Intel programs on its own. Rosetta translates them in the background. It never asks. It never tells you. So as long as Rosetta was there, my Intel tools just worked, and I never knew they were Intel.

”Bad CPU type in executable” means there is nothing left to translate. The update took Rosetta with it, and every Intel tool on the machine went down together.

Check your own Mac

Two questions. Is Rosetta running? And what on this Mac needs it?

# is Rosetta running
/usr/bin/pgrep oahd || echo "Rosetta not running"

# what architecture is this tool
file $(which node)

# every Intel-only binary in the old Homebrew location
for f in /usr/local/bin/*; do file "$f" | grep -q x86_64 && echo "$f"; done

If that loop prints anything, every line is a tool living on borrowed time.

The one-line fix

softwareupdate --install-rosetta --agree-to-license

Then open a new terminal window. This part got me. A window that is already open keeps its old environment. I had one window that worked and one that did not, and I spent longer than I want to admit convinced the fix had failed. The fix was fine. The window was old.

node --version
git --version
#    -> both answer again

Everything came back.

The fix is on a timer

Apple is phasing Rosetta out. macOS 27 is the last release with full support. With macOS 28, expected in 2027, most Intel-only apps stop running on Apple Silicon.

Apple’s own pages cannot quite agree on the exact version. They all agree on the direction. Reinstalling Rosetta buys time. It does not fix anything.

The real fix

Stop needing Rosetta. For command-line tools, that means the Apple Silicon Homebrew in /opt/homebrew, and reinstalling from there.

# put the Apple Silicon Homebrew first, now and in every new shell
eval "$(/opt/homebrew/bin/brew shellenv)"
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.bash_profile

# reinstall what you actually use
brew install git node

which node
#    -> /opt/homebrew/bin/node

Then run the loop again. Anything still in /usr/local/bin that says x86_64 gets reinstalled natively, or deleted if you forgot why you installed it.

Full honesty: I have not done this part yet. Rosetta got me back to work that night. Cleaning out /usr/local is on the list.

Final checklist: after any big macOS update

Run this before you trust your terminal.

# 1. Is Rosetta running (only matters while Intel tools remain)
/usr/bin/pgrep oahd || echo "Rosetta not running"

# 2. Your main tools are native
file $(which git) $(which node) $(which kubectl)
#    -> arm64 or universal, not x86_64 only

# 3. The Apple Silicon Homebrew comes first
which brew
#    -> /opt/homebrew/bin/brew

# 4. Nothing Intel-only left in the old location
for f in /usr/local/bin/*; do file "$f" | grep -q x86_64 && echo "$f"; done
#    -> no output

When that last command prints nothing, Rosetta can leave whenever it wants.