Distinguish hardware and process architecture

An Apple silicon Mac can run native arm64 processes and, through the Rosetta translation environment, some x86_64 processes built for Intel. That flexibility hides a trap: the hardware architecture and the current process architecture are related, but they are not always identical.

Your Mac can be arm64 while your terminal, and every tool it launches, runs translated as x86_64. Everything you install from that terminal inherits the wrong architecture.

Inspect both views

Run these three checks:

uname -m
sysctl -in sysctl.proc_translated 2>/dev/null || true
file "$(command -v node)"

In a native shell on Apple silicon you get:

arm64
0
/opt/homebrew/bin/node: Mach-O 64-bit executable arm64

uname -m reports the architecture the current process sees. sysctl.proc_translated is the real tell: 0 means native, 1 means the shell is running under Rosetta. On an Intel Mac the key does not exist, which is why we silence the error and continue.

file inspects a specific binary. A universal binary lists both architectures; a single-architecture build lists one. This is how you check whether a tool someone shipped you is Intel-only.

How a shell ends up translated

The classic cause is the Open using Rosetta checkbox on Terminal or iTerm in the Finder’s Get Info panel. Someone enables it to work around one stubborn dependency, forgets it, and from then on uname -m reports x86_64 on an arm64 Mac.

You can also enter a translated shell on purpose:

arch -x86_64 zsh
uname -m   # x86_64

That is useful for testing, and dangerous as a default.

Why the mismatch hurts

A translated shell can install tools into a different prefix and build native dependencies for the wrong architecture. The failure shows up later and far away: an npm module compiles fine, then Node refuses to load it with mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64').

When you see that error, don’t reinstall packages first. Check sysctl.proc_translated in the shell that did the install. My advice is to open a native terminal unless one project explicitly requires translation, and to keep any Rosetta work in a clearly labeled separate terminal profile.