[FEATURE] Ship a FreeBSD native binary — Bun no longer a blocker

The deprecated-npm-path-plus-auto-updater problem you describe is exactly the fragility worth acting on — a supported install shouldn't hinge on a path that can silently break underneath you.

The one link worth making is #30640, the canonical FreeBSD thread. It was closed as COMPLETED specifically on the premise that Bun-on-FreeBSD (oven-sh/bun#1524) was the hard blocker. Your issue documents that that premise no longer holds — Bun 1.3.14 shipped FreeBSD builds and Claude Code already bundles 1.4.0 — so this reads less like a fresh request and more like grounds to revisit that closure. Worth cross-linking so maintainers see the technical basis for the original decision has changed.

(Not tagging the telemetry issue here — that one's about platform-string mislabeling, which is unrelated to the native-build question you're raising.)

The deprecated-npm-path-plus-auto-updater problem you describe is exactly the fragility worth acting on — a supported install shouldn't hinge on a path that can silently break underneath you. The one link worth making is #30640, the canonical FreeBSD thread. It was closed as COMPLETED specifically on the premise that Bun-on-FreeBSD (oven-sh/bun#1524) was the hard blocker. Your issue documents that that premise no longer holds — Bun 1.3.14 shipped FreeBSD builds and Claude Code already bundles 1.4.0 — so this reads less like a fresh request and more like grounds to revisit that closure. Worth cross-linking so maintainers see the technical basis for the original decision has changed. (Not tagging the telemetry issue here — that one's about platform-string mislabeling, which is unrelated to the native-build question you're raising.)

Yes, that issue is closed and locked and so I cannot comment on it. It is referenced in this issue. Thank you for bringing it up again so it's more visible.

This is a continuation of that issue chain, and I hope it retains the momentum.

Getting native FreeBSD support would be great.

In the meantime, the node-npm version has stopped updating, so if you don't use the linuxulator on FreeBSD you're stuck on Opus 4.6 and no auto-mode features.

In the meantime, the node-npm version has stopped updating, so if you don't use the linuxulator on FreeBSD you're stuck on Opus 4.6 and no auto-mode features.

Can confirm, and worth adding a data point in the other direction: we've been running Claude Code under Linuxulator on FreeBSD for months without a single issue. Primary dev host is FreeBSD 15.0-RELEASE-p9 with linux_base-rl9, currently on 2.1.219, and we've tracked releases from 2.1.154 → 2.1.204 → 2.1.219 that way. I'm typing this comment in a session running exactly that setup. Interactive TUI, headless -p, and nested subagents several levels deep all work — it hasn't been a degraded experience, just a manually-upgraded one.

The path that keeps you on the latest release is to skip the npm wrapper entirely and pull the linux-x64 native binary directly. The wrapper is the part that's broken for us — it resolves a per-platform optional dependency, and @anthropic-ai/claude-code-freebsd-x64 is still unpublished (404 as of today), so npm i -g lays down a stub that dies with "native binary not installed." The linux-x64 package underneath it is current (2.1.220 today) and is a Bun single-file executable that runs unmodified under Linuxulator.

Setup (once):

sysrc linux_enable=YES
service linux start          # loads linux64.ko + linux_common.ko
pkg install linux_base-rl9   # provides /lib64/ld-linux-x86-64.so.2 and glibc

Install / upgrade (repeat per release):

VER=$(npm view @anthropic-ai/claude-code version)
npm pack @anthropic-ai/claude-code-linux-x64@$VER
tar xf anthropic-ai-claude-code-linux-x64-$VER.tgz
./package/claude --version    # sanity check under Linuxulator BEFORE installing

sudo install -m 755 package/claude /usr/local/libexec/claude-code/claude-$VER

Then point a one-line shim at it:

# /usr/local/bin/claude
#!/bin/sh
exec /usr/local/libexec/claude-code/claude-2.1.219 "$@"

Two things worth flagging against the workaround costs listed in the issue body:

BUN_JSC_useBBQJIT=0 is no longer needed. That was necessary when ant-kurt posted it in #30640, but current binaries run with no JIT flags at all. We dropped it around 2.1.154 and nothing has regressed across the three upgrades since.

The auto-updater conflict in #51833 goes away structurally with this layout. The binary lives at a versioned path under libexec and /usr/local/bin/claude is a shim you own, so there's nothing for the updater or a ports install to overwrite mid-session — you're not sharing a filename with either of them. The previous version stays on disk, so rollback is one sudo cp of the old shim. No DISABLE_AUTOUPDATER=1, no fighting misc/claude-code over the same inode.

The honest tradeoff is the one you're already arguing: the upgrade step is manual, because claude update and install.sh still have no FreeBSD path. That's exactly why the native target matters — this is a stable workaround, not a substitute. But it does mean nobody has to sit on an old release while waiting for it.

One more item for your timeline table, since it strengthens the "npm side is already half-wired for this" angle: freebsd-x64 and freebsd-arm64 have been present in the PLATFORMS map in both install.cjs and cli-wrapper.cjs for months. What's missing is a published package for them to resolve to.

bumping this to keep it from going necro