“Bad CPU Type in Executable” on a Mac: What It Means and How to Fix It

A binary that runs fine on someone else’s Mac stops on yours with a single line: Bad CPU type in executable. It is not corruption and not a permissions problem. The file contains machine code for a processor architecture your Mac cannot execute, and the kernel refuses before the program starts. Almost always that means an Intel binary on an Apple silicon Mac with no translation layer available — but there is a second cause that catches people out, and telling them apart takes one command. The commands below were run on an Apple silicon Mac.

Find out what the file actually is

Before installing anything, look at the binary. Two built-in tools answer the question, and neither needs sudo:

$ file t_x86 t_arm
t_x86: Mach-O 64-bit executable x86_64
t_arm: Mach-O 64-bit executable arm64
$ lipo -archs t_x86
x86_64

lipo -archs is the one to remember: it prints only the architecture list, space-separated, which is exactly what a script wants. Then compare it against what your Mac is:

$ arch
arm64

If the binary says x86_64 and arch says arm64, you have found the mismatch. If they agree and you still get the error, skip ahead to the forced-architecture section — something in between is overriding the choice.

For an app bundle rather than a bare executable, point the same tools at the binary inside it: lipo -archs /Applications/Something.app/Contents/MacOS/Something.

The usual cause: no Rosetta

Apple silicon Macs cannot run Intel code natively. Rosetta 2 translates it, and when it is installed an x86_64 binary just runs — on this machine, with Rosetta present, the Intel build above executes normally. Without it, the kernel has nothing to hand the file to, and that is the error.

Rosetta is not installed by default. macOS normally offers it the first time you open an Intel app from the Finder, which is why the error tends to hit command-line tools instead — a binary launched from the Terminal gets no such prompt. Install it explicitly:

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

man softwareupdate describes the pair exactly that way — “Install Rosetta. Only applies to Apple silicon Macs. Pass –agree-to-license to agree to the software license agreement without any user interaction.” The flag matters in a script or over SSH, where there is nothing to click. Afterwards the same binary runs with no other change — you do not invoke Rosetta, and nothing about the command you type is different. To check whether it is already present, look for the support directory rather than for a command, since Rosetta ships no user-facing binary:

ls /Library/Apple/usr/share/rosetta

Worth knowing before you rely on it. Rosetta was built as transition technology, and the previous one of the same name — the PowerPC translator from the Intel switch — was removed a few releases after that transition finished. Rosetta 2 also never covered everything: kernel extensions, virtual machines running x86 operating systems, and binaries using AVX instructions fall outside what it translates. For a tool you depend on, an arm64 build is the durable answer and Rosetta is the stopgap.

The other cause: something forced the wrong architecture

This is the case that survives installing Rosetta, and it is easy to reproduce. arch can demand a specific architecture, and when the binary does not contain it the launch fails immediately:

$ arch -arm64 ./t_x86
arch: posix_spawnp: ./t_x86: Bad CPU type in executable
$ arch -x86_64 ./t_arm
arch: posix_spawnp: ./t_arm: Bad CPU type in executable

Both directions produce the identical message, and note the posix_spawnp: prefix — when you see that, the request came from a wrapper rather than from you double-clicking something. Both commands exit 1.

In real life the wrapper is rarely typed by hand. It comes from an arch -x86_64 prefix inside a build script or shell alias left over from a Rosetta workaround, from an environment set up under a translated shell, or from a package manager configured for the wrong prefix. The tell is that the architecture you demanded appears nowhere in lipo -archs output — the file is fine, the request was wrong. Grep your shell startup files for arch -x86_64 before assuming the binary is at fault.

arch also reads an ARCHPREFERENCE environment variable when no architecture is given on the command line, so an exported preference from an old session can produce the same effect with no visible flag anywhere.

Universal binaries and why they never hit this

A universal binary carries machine code for more than one architecture in a single file, and macOS picks the native one at launch. file reports the contents in full:

$ file t_uni
t_uni: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
$ lipo -archs t_uni
x86_64 arm64

Because both slices are present, forcing either one works — arch -x86_64 ./t_uni runs through Rosetta, and the default run uses arm64. This is what a well-built Mac app ships as, and it is why the error almost never appears with software distributed through the App Store. When you do meet it, you are usually dealing with a single-architecture build: a tool compiled on a colleague’s Intel machine, an old download, or something a package manager fetched for the wrong platform.

If you build software yourself, lipo -create intel_build arm_build -output universal merges two single-architecture binaries into one, and lipo -archs on the result confirms both are in there.

When there is no fix

One case has no workaround at all. Rosetta 2 translates 64-bit Intel code only, and macOS dropped 32-bit support entirely in Catalina, so a 32-bit i386 binary cannot run on any current Mac regardless of architecture. Even the compiler refuses to produce one — building for i386 on this machine fails at the link stage with The i386 architecture is deprecated for macOS and a missing-architecture error from the SDK.

If lipo -archs reports i386 or ppc, the answer is a newer build of the software, or a virtual machine running an old macOS release. Nothing you install on the host will make that file execute.

Quick reference

Step	Command	What to look for
What is in the file	lipo -archs ./binary	x86_64, arm64, or both
What your Mac is	arch	arm64 on Apple silicon
Is Rosetta installed	ls /Library/Apple/usr/share/rosetta	Directory exists
Install Rosetta	softwareupdate --install-rosetta --agree-to-license	Fixes Intel binaries
Rule out a forced architecture	grep -r "arch -x86_64" ~/.zshrc ~/.zprofile	Leftover workarounds
Merge two builds	lipo -create a b -output universal	Both slices present

The two-command diagnosis: lipo -archs on the file, arch on the machine. If the file lacks what the machine runs, install Rosetta. If the file has it and you still get the error, something is forcing an architecture the file does not contain, and the fix is upstream of the binary.