### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Since 2.1.113, @anthropic-ai/claude-code switched from a bundled cli.js to a thin wrapper that copies a per-platform native binary from optionalDependen

[BUG] Publish @anthropic-ai/claude-code-freebsd-x64 (and -arm64) native binary packages

Status Closed — not planned

Reported on v2.1.113

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 16 comments · opened May 21, 2026 · closed Aug 19, 2026

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?

Since 2.1.113, @anthropic-ai/claude-code switched from a bundled cli.js to a thin wrapper that copies a
per-platform native binary from optionalDependencies. Both install.cjs and cli-wrapper.cjs already include
FreeBSD in their PLATFORMS map:

  'freebsd-x64':   { pkg: PACKAGE_PREFIX + '-freebsd-x64',   bin: BINARY_NAME },
  'freebsd-arm64': { pkg: PACKAGE_PREFIX + '-freebsd-arm64', bin: BINARY_NAME },

…but the corresponding npm packages are not published (404), and the GitHub release assets contain only
darwin/linux/win32 tarballs. As a result, every release from 2.1.113 onward is unusable on FreeBSD: install.cjs
prints "Native binaries for freebsd-x64 are not available on this release channel."

The existing FreeBSD port (misc/claude-code in the official ports tree, maintained by yuri@FreeBSD.org) tracked
releases up to 2.1.110 by repackaging the bundled cli.js and running it under FreeBSD's Node.js. The
wrapper-package change makes that approach impossible — the port now has no JS to install. Without a
freebsd-x64 native binary, FreeBSD users are stuck at 2.1.112.

What Should Happen?

@anthropic-ai/claude-code-freebsd-x64@<version> (and ideally -freebsd-arm64) is published to npm with the

same shape as the existing @anthropic-ai/claude-code-linux-x64 package.

claude-freebsd-x64.tar.gz (and -arm64) is attached to the GitHub releases alongside the existing

darwin/linux/win32 tarballs.

npm install -g @anthropic-ai/claude-code on FreeBSD then runs install.cjs, finds the matching optional

dependency, and places the native binary — same flow as Linux.

The platform-detection code already exists in install.cjs/cli-wrapper.cjs, suggesting this was anticipated;
only the binaries themselves need to be built and published.

Error Messages/Logs

Steps to Reproduce

On FreeBSD 15.x or 16-CURRENT with Node.js installed:

  npm install -g @anthropic-ai/claude-code@2.1.145
  # postinstall runs install.cjs
  # → "[@anthropic-ai/claude-code postinstall] Native binaries for freebsd-x64
  #    are not available on this release channel."
  # → Available: darwin-arm64, darwin-x64, linux-x64, linux-arm64,
  #    linux-x64-musl, linux-arm64-musl, win32-x64, win32-arm64
  claude --version
  # → fails: bin/claude.exe is still the install-time stub

Equivalently:

  npm view @anthropic-ai/claude-code-freebsd-x64
  # → 404 Not Found

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.112

Claude Code Version

2.1.145

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Xterm

Additional Information

_No response_

View original on GitHub ↗

9 Comments

kofany · 3 months ago

Yes +1 for FreeBSD

mmenefee · 3 months ago

Confirming @ocochard's diagnosis from the running side, and adding a verified workaround for the latest release so no one has to pin to the pre-2.1.113 port.

The wrapper change doesn't actually block FreeBSD — the published linux-x64 native binary runs unmodified under Linuxulator. Tested just now on FreeBSD 15.0-RELEASE-p5 with the current release (2.1.154):

$ file claude
ELF 64-bit LSB executable, x86-64, dynamically linked,
  interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0
$ ./claude --version
2.1.154 (Claude Code)
$ ./claude --help      # full CLI initializes, exit 0

Full how-to, tracks @latest automatically:

# 1. Linuxulator (one-time)
sudo pkg install -y linux_base-rl9
sudo sysrc linux_enable=YES
sudo service linux start

# 2. Fetch the linux-x64 native binary for the current release.
#    npm skips it on a FreeBSD host (process.platform === 'freebsd'),
#    so pull the optional-dep tarball directly:
ver=$(npm view @anthropic-ai/claude-code version)
npm pack @anthropic-ai/claude-code-linux-x64@"$ver"
tar xzf anthropic-ai-claude-code-linux-x64-"$ver".tgz
install -m 755 package/claude ~/bin/claude   # anywhere on PATH

# 3. Run it.
claude

No bun build, no port pin, no BUN_JSC_useBBQJIT=0 (that was needed for older builds; 2.1.154 runs clean without it). The 500-byte bin/claude.exe stub the wrapper drops on FreeBSD is the "native binary not installed" error everyone's hitting — this sidesteps it with the Linux binary Linuxulator already runs.

Why the ask in this issue is now a small step: the distribution machinery is already wired (the freebsd-x64/freebsd-arm64 entries @ocochard quoted), the Linux build runs unmodified under Linuxulator, and the previously-cited Bun blocker (oven-sh/bun#1524) closed on 2026-04-26 with FreeBSD x86_64/aarch64 cross-compile targets merged. A true freebsd-native package would drop the Linuxulator dependency, but even shipping the Linux binary as the freebsd optional-dep — so npm i -g just works under Linuxulator — would fix the install break for every FreeBSD user today.

— FreeBSD shop running Claude Code daily across a fleet of jails; happy to test FreeBSD builds.

insanityinside · 3 months ago

As a workaround until we get a native build, I've made https://github.com/insanityinside/claude-freebsd - it's pretty robust after testing and debugging on my setup, and will hopefully make life easier for others. Installs a wrapper for Claude Code in /usr/local/bin/claude, does automatic version checks, can update Claude and itself, and does sanity checks on the setup to save anyone else the 2 hours of head scratching I did when Claude was hanging on startup for me. Feedback welcome, hope it's useful to others.

Work in progress, I'll keep updating as I spot any bugs / issues.

Tested on amd64 under FreeBSD 15, 14.4 and 14.3, and on 14.4 and 14.3 in Bastille jails, and tested on arm64 under QEMU.

insanityinside · 3 months ago

Realised I've accidentally duplicated the efforts of @chiefMarlin (ref: https://github.com/anthropics/claude-code/issues/30640#issuecomment-4231873323), but added some enhancements such as the arm64 support, installing it system-wide, losing the no-longer-necessary BUN_JSC_useBBQJIT=0, and the mount checks. No disrespect intended, just somehow completely missed the fact you'd written a script, thanks to Github collapsing the comments and a touch of ADHD. 😅

jtrotsky · 2 months ago

+1 was caught by this, have switched to the workaround ty to @chiefMarlin @insanityinside. Imploring Anthropic to ship the native binary so we can get an up-to-date port 🙏

kofany · 2 months ago

+1, Anthropic give us native freebsd bin! I need to make my FreeBSD Desktop run in to space :P

hotbit9 · 2 months ago

+1 — hit this same wall on #30640 back when native binaries first broke FreeBSD installs. For what it's worth, Linuxulator isn't a real fix for those of us who'd rather not run a Linux compat layer just to use a CLI tool — it works, but it's not what "FreeBSD support" should mean. The original blocker (Bun lacking FreeBSD support, oven-sh/bun#1524) closed back on 2026-04-26 with FreeBSD x86_64/aarch64 cross-compile targets merged, so the technical case against a genuine native freebsd-x64/freebsd-arm64 build mostly evaporated. The PLATFORMS map already has the entries wired in install.cjs/cli-wrapper.cjs — please finish the job and publish actual native packages, not just point people at Linuxulator. 🙏

I'm sure Claude could help speed this along too — must be nice having a coding assistant on staff for exactly this kind of grunt work.