How to Fix the 'zsh: killed' Error on M1, M2, and M3 Macs

intermediate🍎 macOS2026-05-28| macOS (Apple Silicon M1, M2, M3), Terminal, zsh

Error Message

zsh: killed [command_name]
#apple-silicon#codesign#security#terminal#macos

The Error Scenario

You just finished compiling a new tool or downloaded a utility from GitHub. But when you try to run it on your M-series Mac, the terminal shuts you down immediately. Instead of the expected output, you get one cryptic line:

zsh: killed [command_name]

The kernel kills the process before a single line of code can run. You won't find logs, stack traces, or any explanation in the console. It simply stops.

Why This Happens on Apple Silicon

Apple Silicon isn't just about speed; it's about security. Older Intel Macs were fairly relaxed about unsigned code. ARM64 Macs changed the game by enforcing a strict hardware-level rule: every executable memory page must have a valid cryptographic signature.

This protection is managed by Apple Mobile File Integrity (AMFI). If the system detects a binary that doesn't meet security standards, it pulls the plug. This usually happens because:

  • The binary was compiled locally without a signing step.
  • You moved a tool from an Intel Mac (x86_64) to an Apple Silicon (arm64) machine.
  • The file was modified after it was signed.
  • Gatekeeper flagged the file as "quarantined" because it came from a browser download.

Step 1: The Fast Fix - Ad-Hoc Codesigning

You don't need a paid Apple Developer account to fix this. You can apply an "ad-hoc" signature, which tells macOS that you trust the binary to run locally on your machine.

Run the following command in your terminal:

codesign -s - --deep --force ./path/to/your/binary

What these flags do:

  • -s -: Applies a "null identity" (ad-hoc) signature.
  • --deep: Recursively signs any nested libraries or frameworks inside the binary.
  • --force: Overwrites any existing, invalid signatures that might be causing the conflict.

Step 2: Stripping the Quarantine Flag

If you downloaded the tool via Chrome, Safari, or curl, macOS attaches a metadata attribute called com.apple.quarantine. Even with a signature, Gatekeeper might block the execution.

First, check if the attribute exists:

xattr ./path/to/your/binary

If com.apple.quarantine appears in the list, strip it away with this command:

xattr -d com.apple.quarantine ./path/to/your/binary

Step 3: Advanced Entitlements (For Debuggers & JIT)

Complex applications—like custom debuggers or tools using Just-In-Time (JIT) compilation—require specific permissions to interact with system memory. If a basic signature doesn't work, you may need an entitlements file.

  • Create a file named entitlements.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>
</plist>
  • Sign the binary using this plist:
codesign -s - --deep --force --entitlements entitlements.plist ./path/to/your/binary

Verification: Confirming the Fix

To make sure the system now accepts your binary, use the codesign utility to inspect it:

codesign -vvv ./path/to/your/binary

Look for valid on disk and satisfies its Designated Requirement in the output. If you see those, your program should now launch without hitting the zsh: killed wall.

Summary of Commands

If you just want it to work right now, run these two commands in order:

# Clear download restrictions
xattr -cr ./path/to/your/binary

# Apply the local signature
codesign -s - --deep --force ./path/to/your/binary

Related Error Notes