Zsh Illegal Hardware Instruction C

Why zsh Crashes with an Illegal Instruction Error

You're typing a command in zsh and suddenly the shell dies with "illegal hardware instruction: c" or just "illegal hardware instruction." No stack trace, no error message, just gone. This happens more often than you'd think, especially if you're on Apple Silicon or have mixed architectures in your toolchain. The short version: zsh tried to execute a CPU instruction that your processor doesn't recognize. Usually this means you're running a binary compiled for a different architecture than what you're actually using, or you've got a corrupted installation where the executable bits don't match your OS build.

What Causes Zsh Illegal Hardware Instruction C

This is the most common version people search for. The "c" at the end of the error message is often the command that was running when zsh died — it could be any command, not literally the C programming language. The shell prints the offending executable name as part of the crash output, which is why you see it there. But it can also literally refer to a C program or C extension causing the crash. The actual triggers break down into a few categories: First, the Apple Silicon Rosetta problem. If you installed zsh through Homebrew on an Intel Mac and then switched to an M-series Mac without reinstalling, or vice versa, you can end up with a binary compiled for x86_64 running on arm64 hardware through Rosetta 2, and something in that translation layer misfires. The same thing happens if you compiled zsh from source against the wrong SDK target.

Second, a corrupted Homebrew install. I've seen this multiple times after a failed upgrade where some formulae updated and others didn't. zsh itself stays on the old version while its dependencies shift, and you get a binary that's partially incompatible with the runtime libraries it expects. Third, and this one is trickier — plugins or third-party binaries in your PATH that were compiled for a different CPU flag set. A C extension, an outdated npm global, a Python binary built with AVX instructions on a machine that doesn't support them. zsh loads your startup files, hits that binary, and the kernel kills the process with SIGILL.

How to Fix It Step by Step

Start by figuring out what architecture you're actually running. Run uname -m. If it says arm64 and you're on an M-series Mac, that's your baseline. If it says x86_64, you're either on an Intel Mac or running through Rosetta translation, which changes the diagnostic path entirely. Next, check which zsh you're actually executing. Run which zsh and then file $(which zsh). You want the output to say "Mach-O 64-bit executable arm64" on Apple Silicon or "Mach-O 64-bit executable x86_64" on Intel. If those don't match your uname output, that's your problem right there. If you're on Homebrew, the fix is usually straightforward but requires doing it in the right order. On Apple Silicon, Homebrew installs to /opt/homebrew. On Intel, it's /usr/local. If you've somehow mixed these — which happens if you migrated a setup — run brew uninstall zsh, make sure your PATH is clean, then brew install zsh. This rebuilds zsh for your actual architecture. The whole process takes maybe three minutes.

Here's the part people miss. After reinstalling zsh, you need to rebuild your shell configuration. Your .zshrc might be sourcing plugins or binaries that are still compiled for the wrong architecture. Run zsh -d to start zsh without loading any config, then source ~/.zshrc line by line. When it crashes, you've found the offending line. This is how I tracked down a crash last year that turned out to be an old version of starship that had been compiled for x86_64 and wasn't working under Rosetta translation after I switched machines. For the starship case specifically, I ran brew uninstall starship and reinstalled it, which pulled the arm64 build. If you're dealing with a non-Homebrew binary, you can check it with file /path/to/binary and reinstall or rebuild it for the correct architecture. Sometimes the binary is fine but was compiled with CPU flags your chip doesn't support — in that case you need to rebuild from source with appropriate flags like -march=native or the specific target for your chip. If you're not on a Mac and you're seeing this on Linux, the causes are different but the diagnostics overlap. A commonly miscompiled library, a kernel module that doesn't match your CPU, or running a Docker container with the wrong emulation layer. Check dmesg after a crash — the kernel usually logs the exact instruction that triggered the SIGILL, which can point you directly at the problematic binary.

Edge Cases and What to Do When the Standard Fix Doesn't Work

Sometimes you reinstall everything and it still crashes. This happened to me with a custom-compiled Oh My Zsh setup where a plugin was pulling in a C extension that had been cached from a previous architecture. The plugin manager thought it was up to date because the git commit hash hadn't changed, but the compiled artifact was stale. The workaround was deleting the plugin's build cache directory entirely and letting it recompile from scratch on the new system. Another scenario: you're using asdf or pyenv and those runtime managers have binaries compiled for the wrong architecture. Check with file ~/.asdf/shims/zsh or whatever shim you're using. If the shim points to the wrong binary, rerun the install for that plugin or runtime version. There's also the case where zsh itself is fine but your terminal emulator is the problem. Some older terminal apps send malformed escape sequences that trigger a bug in certain zsh versions when combined with specific locale settings. Switch to a different terminal or update it, and the crashes stop. I'd recommend staying on zsh 5.9 or later if you're on Apple Silicon — earlier versions had known issues with certain ARM-specific code paths.

If none of this works and you need a temporary workaround to keep working while you debug, you can start zsh with zsh -f to skip your config entirely, then figure out which part of your setup is causing the crash. It's not a fix, but it lets you get a working shell back while you investigate.