SIGILL on AVX2-less Intel Macs still present in 2.1.181 (regression from #50466 persists)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Why a fresh report
This bug class has a documented history: #50466 isolated the exact regression window (2.1.112 to 2.1.113) with a clean reproduction, was labeled bug, has repro, and regression, and was closed as "not planned." Two subsequent reports, #62244 and #62809, were auto-closed as duplicates pointing back to it.
Filing fresh rather than commenting on a closed thread, for a few reasons. First, the bug is still present in the current build (2.1.181); this isn't historical, it's reproducing today. Second, the original report's proposed fix (a -march=x86-64-v2 baseline, or RUSTFLAGS="-C target-cpu=x86-64" for Rust deps) doesn't appear to have been evaluated in the thread. Third, it's not clear from the closed issue whether "not planned" reflects a deliberate hardware-support boundary or simply fell off the queue; happy to be pointed to that context if it exists.
Adding independent confirmation data here: different machine (iMac13,2 vs. the Mac Pro / iMac in the linked reports, though notably identical CPU model), different version (2.1.181 vs. 2.1.113/2.1.149), same failure signature.
Summary
The Claude Code / Cowork engine bundled with Claude Desktop crashes with EXC_BAD_INSTRUCTION / SIGILL immediately on launch on any Intel Mac whose CPU predates Haswell (lacks AVX2/BMI2/FMA, i.e. Ivy Bridge and earlier). The crash occurs during dyld static initializer execution, before any application code runs, and before the engine can fail gracefully or print a version string.
Environment
Mac model: iMac13,2 (21.5" Late 2012). CPU: Intel Core i5-3470S at 2.90GHz (Ivy Bridge), identical CPU model to #50466's reporter on a different physical machine. macOS: 15.7.7 (24G720). Claude Desktop shell version: 1.14271.0. Embedded Claude Code engine version: 2.1.181, confirming the bug persists across at least 68 point releases since the 2.1.113 regression first reported. Architecture: x86_64, non-fat/single-architecture binary, confirmed via lipo -info, with no AVX2-baseline fallback slice shipped.
CPU feature confirmation (AVX2/BMI2/FMA absent)
$ sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: Intel(R) Core(TM) i5-3470S CPU @ 2.90GHz
$ sysctl -a | grep machdep.cpu.features
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C
$ sysctl -a | grep machdep.cpu.leaf7_features
machdep.cpu.leaf7_features: RDWRFSGS SMEP ERMS MDCLEAR IBRS STIBP L1DF SSBD
AVX1.0 is present; AVX2, BMI2, and FMA (leaf7 feature set) are absent, consistent with Ivy Bridge, one generation before Haswell introduced AVX2 in 2013.
What Should Happen?
Either ship a non-AVX2 baseline build for the embedded Code/Cowork engine, or explicitly document the minimum CPU requirement and fail gracefully with an actionable error instead of an unexplained SIGILL crash-loop.
Happy to provide the full .ips crash log, system_profiler SPHardwareDataType output, or test any proposed baseline build on this hardware.
Error Messages/Logs
{"app_name":"claude","app_version":"2.1.181","bundleID":"com.anthropic.claude-code"}
{
"modelCode": "iMac13,2",
"cpuType": "X86-64",
"exception": {"type": "EXC_BAD_INSTRUCTION", "signal": "SIGILL"},
"termination": {"code": 4, "indicator": "Illegal instruction: 4"},
"procLaunch": "2026-06-19 02:21:33.8943 -0400",
"elapsed": "~324ms after launch",
"coalitionName": "com.anthropic.claudefordesktop"
}
Faulting thread backtrace shows the crash inside dyld4::Loader::findAndRunAllInitializers, i.e. during static initializer execution within the claude binary itself, before any application logic runs. This matches the timing and signature reported in #62809 (~474ms after launch, before any work is done) and the opcode-level diagnosis in #62244 (VEX-encoded BMI2 instruction c4 e2 f9 f7 d1, which Ivy Bridge lacks).
Binary inspection:
$ file claude.app/Contents/MacOS/claude
claude.app/Contents/MacOS/claude: Mach-O 64-bit executable x86_64
$ lipo -info claude.app/Contents/MacOS/claude
Non-fat file: ... is architecture: x86_64
Single-architecture binary, no AVX2-baseline slice. The build assumes AVX2/BMI2 availability unconditionally on x86_64.
Steps to Reproduce
- On an Intel Mac with a pre-Haswell CPU (no AVX2/BMI2; confirm via sysctl -a | grep machdep.cpu.leaf7_features), install/run current Claude Desktop.
- Open Cowork, or otherwise trigger the embedded Claude Code engine (it is spawned automatically by certain Claude Desktop actions, not only via direct CLI invocation).
- The process crashes with SIGILL within ~300ms, before reaching a ready state. Confirm via Console.app or ~/Library/Logs/DiagnosticReports/claude-*.ips.
- Reproducible 100% of the time on this hardware; every launch attempt produces the same crash.
Note on invocation context: this crash is triggered via Claude Desktop/Cowork spawning the bundled engine, not a direct Terminal.app CLI session; the crash log's coalitionName: com.anthropic.claudefordesktop confirms the parent process. This is also why claude --version cannot be run to verify the exact version per the standard preflight check: the version-check command itself hits the same crash path. The version cited in this report is sourced from the cached install directory name (~/Library/Application Support/Claude/claude-code/2.1.181/), not command output.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.112 (per #50466's report; not independently verified on this hardware, see Steps to Reproduce note)
Claude Code Version
2.1.181 (sourced from install directory name, not claude --version output -- see Steps to Reproduce)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Note: this report selects Terminal.app for the required Terminal/Shell field, but the actual crash is not invoked via Terminal at all; it occurs when Claude Desktop/Cowork spawns the embedded engine directly (confirmed by coalitionName: com.anthropic.claudefordesktop in the crash log). There is no Claude Desktop / Cowork option in the Terminal/Shell dropdown.
New finding not present in prior reports: version pinning does not work around this. The embedded Code engine lives in a version-pinned cache directory (~/Library/Application Support/Claude/claude-code/<version>/) that updates independently of the Claude Desktop shell version. Installing an older Claude Desktop build does not pin the Code engine; it still fetches the current (broken) build. This closes off the one user-side workaround (downgrading) that worked for CLI/npm installs per #50466, meaning Claude Desktop / Cowork users on affected hardware have no available workaround at all, unlike npm-install users who could at least pin @anthropic-ai/claude-code@2.1.112.
Additional context that may be useful for triage:
This is not a fringe edge case: Ivy Bridge and earlier Intel Macs (2012-2013 iMacs, Mac Pros, MacBook Pros) remain in active use, including for users running current macOS via OpenCore Legacy Patcher, as in this case. The regression is precisely bisected (2.1.112 to 2.1.113) in the original report and has had no forward progress across 68+ releases. The cost of a fix is plausibly low: a baseline/non-AVX2 build target, matching the precedent set by tools like Bun itself, which ships -baseline builds for exactly this CPU population. At minimum, replacing a silent SIGILL crash-loop with an explicit "your CPU doesn't meet the minimum instruction set" message (mirroring the existing Apple Silicon requirement gate referenced in #18235) would be a low-cost improvement even if a full fix isn't prioritized.
Related: #50466, #62244, #62809, #5864, #10408, #19967, #21018, #41575, #51433, #50904
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗