[BUG] install.sh serves Linux ARM64 (ELF) binary on macOS ARM64, causing "exec format error"

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?

Running the official install script on macOS Apple Silicon installs a Linux ARM64 ELF binary instead of a macOS Mach-O binary, making Claude Code completely unusable after installation.

The install process has two phases, and the bug is in phase 2:

• Phase 1 (install.sh): Downloads a binary from GCS to ~/.claude/downloads/claude-2.1.63-darwin-arm64. This is now a correct Mach-O binary.
• Phase 2 (claude install subcommand): The downloaded Mach-O binary runs its own install logic, makes a second independent download from GCS, and installs the result to ~/.local/share/claude/versions/2.1.63 with a symlink at ~/.local/bin/claude. This second download fetches the Linux ARM64 binary instead of the macOS one.

The checksums confirm the mismatch:

• Before fix: ~/.local/share/claude/versions/2.1.63 had checksum 1fec8c..., which matches linux-arm64 in the manifest
• After fix: checksum 2e8667..., which matches darwin-arm64 in the manifest

What Should Happen?

Both phases should install a macOS Mach-O arm64 binary, and claude --version should run successfully.

Error Messages/Logs

zsh: exec format error: claude


$ file ~/.local/bin/claude
/Users/ericalt/.local/bin/claude: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped


Phase 2 network trace (captured via `DEBUG='*'` follow-redirects logs) shows the `claude install` subcommand fetching:

https://storage.googleapis.com/.../claude-code-releases/latest
https://storage.googleapis.com/.../claude-code-releases/2.1.63/manifest.json
https://storage.googleapis.com/.../claude-code-releases/2.1.63/darwin-arm64/claude


The URL path is correct (`darwin-arm64`) but the binary served at that path is the Linux ARM64 ELF.

Steps to Reproduce

Prerequisites: confirm you are on Apple Silicon before proceeding:

uname -m   # must return arm64
uname -s   # must return Darwin

1. On a macOS Apple Silicon machine, run:

   curl -fsSL https://claude.ai/install.sh | bash

1. Run claude
2. Observe zsh: exec format error: claude
3. Run file ~/.local/bin/claude to confirm ELF binary was installed

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause: this is a server-side publishing bug. The claude install subcommand correctly
detects darwin-arm64 and fetches the right GCS path both in the broken and fixed runs.
The difference was that on initial install, the GCS bucket was serving the Linux ARM64 ELF
at the darwin-arm64 path. By the time the workaround was run, the correct Mach-O binary
had been published to that path.

Confirmed via checksums:

• Broken install: ~/.local/share/claude/versions/2.1.63 checksum 1fec8c... matches linux-arm64 in manifest
• Fixed install: ~/.local/share/claude/versions/2.1.63 checksum 2e8667... matches darwin-arm64 in manifest

Suggested fix for the publishing pipeline:

1. Add a post-publish validation step that downloads each platform binary from GCS after release

and runs file to assert the correct format (Mach-O for darwin, ELF for linux)

1. Add a checksum cross-check to assert that the checksum in manifest.json for each platform

matches the binary actually served at that path, and not a binary from another platform

Workaround (if still affected) — re-run phase 2 using the correct Mach-O binary that phase 1 downloaded:

Then verify:

file ~/.local/bin/claude        # should show Mach-O 64-bit executable arm64
claude --version                # should show 2.1.63 (Claude Code)