Why your Python3 crashes with an illegal instruction in zsh
This happens more often than you'd think, and it's almost always an architecture mismatch between the shell environment and the Python binary you're trying to run. You're not doing anything wrong. The system just ended up in a state where it doesn't know which CPU instruction set to use. When you see this in your terminal, the shell hands off execution to Python and the CPU immediately refuses to process whatever instruction it was told to run. There's no Python error message because Python never actually starts. The kernel kills the process before it gets a chance to print anything useful. macOS ships with a few different Python installations depending on how you installed it. Homebrew, pyenv, the official installer, Xcode command line tools — they all leave different binaries in different places. When zsh looks for python3, it walks your $PATH from left to right. If you have an x86_64 Python sitting in front of an arm64 Python, or if a Rosetta-translated binary got mixed into the path, the CPU throws an illegal instruction the moment it encounters an ARM-native instruction it can't translate.
On Intel Macs the problem is usually the opposite — you've somehow grabbed an arm64 build and your CPU doesn't support it at all. Apple Silicon makes this messier because both architectures can coexist, which means your path resolution becomes the primary failure point rather than the hardware itself.
How I fix it — my actual workflow
First thing I do is check what the shell thinks it's going to run: which python3 Then I verify the architecture of that exact binary:
Get the Full Details
file $(which python3) If it says something like "Mach-O 64-bit executable x86_64" on an M-series Mac and you were expecting ARM, that's your problem. If it says "arm64" on an Intel Mac, same thing but reversed. Next step is checking whether Rosetta is even installed, because if you're on Apple Silicon and trying to run any x86 binary without Rosetta, you get this exact error:
softwareupdate --install-rosetta That installs the translation layer. It takes about two minutes and requires accepting a license agreement. I've seen people skip this entirely and then spend an hour wondering why their Python won't start.
The edge case that nearly cost me a day
Last year I hit this on a freshly installed M2 Mac where everything looked correct. `which python3` pointed to /opt/homebrew/bin/python3, `file` confirmed arm64, Rosetta was installed, and yet every Python 3 invocation crashed with an illegal hardware instruction. No traceback, no output, just the shell returning to the prompt like nothing happened. The issue turned out to be that Homebrew had been installed twice — once natively for arm64 and once inside a Rosetta terminal window for x86_64. The x86 Homebrew left a stale python3 stub at /usr/local/bin/python3 that was shadowing the correct one, but it was a symlink pointing to an x86_64 binary that couldn't run natively. The fix was deleting the duplicate installation: sudo rm -rf /usr/local/bin/python3* /usr/local/Cellar /usr/local/Library
Then cleaning up my PATH in ~/.zshrc to remove any /usr/local entries that didn't belong. After that, `python3 --version` worked immediately. That took about 45 seconds once I figured out what was happening. The hour I lost was entirely because I kept assuming the problem was with Python itself rather than the path resolution.
Reinstalling cleanly when nothing else works
When the diagnosis above doesn't surface the issue, a clean reinstall is usually faster than chasing symlinks. With Homebrew on Apple Silicon: brew uninstall --force python@3.12
brew install python@3.12
brew link python@3.12 Make sure you're running those commands in a native arm64 terminal, not a Rosetta terminal. A Rosetta terminal will install the x86_64 version of Homebrew packages even if you think you're on ARM.
If you're using pyenv instead, the same principle applies: pyenv uninstall 3.12.3
pyenv install 3.12.3
pyenv global 3.12.3 Pyenv compiles from source by default, so architecture mismatches are less likely unless you've set conflicting BUILD ENV variables. I've seen people export ARCHFLAGS="-arch x86_64" in their zshrc and then wonder why their ARM Mac can't run what it just compiled.
Check your .zshrc for hidden culprits
Scroll through your zsh configuration file and look for anything that modifies PATH, sets ARCHFLAGS, or runs arch -x86_64 zsh or similar Rosetta launch wrappers. These are easy to miss if you added them months ago and forgot why they were there in the first place. A common one is Homebrew's initialization block at the bottom of the file — make sure it's only pointing to /opt/homebrew on Apple Silicon, not /usr/local. Another thing to check: are you sourcing another config file inside .zshrc that overwrites your PATH? I once found a nested source command in a dotfiles repo that was prepending an old x86_64 Python path after Homebrew's arm64 path. Removed the override and everything worked.
When this approach doesn't help
If you've verified the binary architecture matches your CPU, confirmed Rosetta is installed, cleaned up duplicate installations, and Python still crashes on startup, the problem may be deeper. Corrupted system libraries, a broken OpenSSL dependency, or a macOS beta with known issues can all cause this. In those cases rebuilding from source with every dependency specified explicitly tends to work better than relying on prebuilt binaries. It also takes significantly longer — expect 20 to 40 minutes for a full compile versus the 2 minutes a Homebrew install usually takes. Another scenario where reinstalling won't fix it: you're running this inside a Docker container or a remote environment where the host architecture differs from what the container expects. That's a separate class of problem entirely and needs a different solution. The core takeaway is that this error is rarely about Python being broken. It's about your shell environment pointing at the wrong binary for the CPU you're actually running on. Fix the path, verify the architecture, and move on.
