[BUG] [Reopening because bot closed without discussion] Native installer doesn't work on FreeBSD

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22564
2. https://github.com/anthropics/claude-code/issues/29374
3. https://github.com/anthropics/claude-code/issues/10673

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

No you overzealous bot. This is not trash: users of the platform that powers the PS5 and Netflix might want to provide usage data to your tools.

I'd also like to see some sort of support for FreeBSD, thank you.

Thank you for the continued work on this project.

I would like to kindly ask that the npm installation option be maintained, or at least not deprecated without a viable alternative. Many developers rely on it as part of their existing workflows.

In particular, developers working on platforms such as FreeBSD often depend on npm-based installation methods because other distribution mechanisms are not always readily available or integrated into the ecosystem. Keeping this option available helps ensure that the project remains accessible across a broader range of development environments.

It is also worth noting that developers on these platforms are part of the user base and contributors to the ecosystem, and some of us are paying subscribers as well. Maintaining installation flexibility can therefore help support a diverse and committed community.

Thank you for considering this perspective.

This is really disappointing and frustrating.

---

Public Key: 22BE39E2FA68D8BA8DC4B43A55A16D8CE2B036DE

Messages from this account are considered the best-secured and most reliable. Send information regarding health, wealth, or requiring higher standards of security to this address.

Sent from Proton Mail for iOS.

-------- Original Message --------
On Thursday, 03/12/26 at 10:36 Ed Maste @.***> wrote:

emaste left a comment (anthropics/claude-code#30640) I suppose they're asking for users to leave "+1" comments regularly so that the ticket doesn't get closed. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

Please keep the npm package or provide a viable alternative

I am focused on FreeBSD as my primary platform for development work of all kinds. FreeBSD first on my projects, FreeBSD first on my systems, FreeBSD everywhere I can. Other OSes and software may be adopted if their value justifies their presence, but I will always look for and support a FreeBSD alternative.

AND, RELEVANT TO CLAUDE CODE I will even consider doing the work required to port a tool or project to FreeBSD in order to have it become a first class citizen in my projects. That work isn't easy and to get it done in a realistic time frame means using Claude Code as an assistant.

FreeBSD runs on many backend systems. A visit to the Foundation's website shows numerous large, corporate users and use cases. Anthropic would do well to consider ensuring that FreeBSD and in fact all of the BSDs are promoted to tier one support for their products and ports.

I am focused on FreeBSD as my primary platform for development work of all kinds. FreeBSD first on my projects, FreeBSD first on my systems, FreeBSD everywhere I can. Other OSes and software may be adopted if their value justifies their presence, but I will always look for and support a FreeBSD alternative. AND, RELEVANT TO CLAUDE CODE I will even consider doing the work required to port a tool or project to FreeBSD in order to have it become a first class citizen in my projects. That work isn't easy and to get it done in a realistic time frame means using Claude Code as an assistant. FreeBSD runs on many backend systems. A visit to the Foundation's website shows numerous large, corporate users and use cases. Anthropic would do well to consider ensuring that FreeBSD and in fact all of the BSDs are promoted to tier one support for their products and ports.

If you contribute to Claude Code, I’ll use it on my FreeBSD system to identify and report bugs and issues. I’ll also use Claude Code to suggest fixes and submit pull requests.

My system is a Ryzen 5600X3D with an NVIDIA RTX 4070 Ti graphics card. FreeBSD with a 96MB L3 cache is far superior to Linux (which is superior to Windows) on this platform.

Claude Code Team's decision to abandon this particular UNIX (BSD 4.4 Lite 2 family, which serves as the foundation for modern ‘Nix systems and the impetus at the time for Linux thanks to AT&T) overlooks the fact that it can still be effectively used as a workstation. Just because it doesn’t have high netstat usage as a client device doesn’t mean it’s unused as a workstation, server, edge device, or a great development platform for cross-platform development.

Count me in I am using FreeBSD and it shouldn't be left out

I'm using FreeBSD, please keep the npm package

Thank you all for the feedback! I've passed it along to the team. We don't have anything to share on this right now but we hope to soon.

let’s hang in there and support this cause! 💪🔥

Please keep the npm installer or provide another viable Installation method.

FreeBSD is an important platform in the ecosystem

Just registering my interest as well after having recently daily-driving FreeBSD and coming across Steve's post via the FreeBSD Reddit and also as someone interested in using Claude Code on multiple platforms. FreeBSD support is important to the health of both the OS and the AI ecosystems.

Would also like to register my interest and support for this. We are a FreeBSD shop, having native official support for Claude Code would be something I am interested in seeing. AI is a valuable tool that helps bring Linux only tech to FreeBSD. Many open source projects are unfamiliar with the platform and therefore don't put the effort into making sure their software works on our OS. AI changed that. I have been able to port many (once Linux-only) products to FreeBSD because of tools like Claude Code being able to run on FreeBSD

A gentle hint: use thumbs etc., if you can.

(Some of the traffic here in GitHub resulted from FreeBSD Users: We Need to Talk About Claude Code – Steven G. Harms : r/freebsd … a fairly good place for general discussion, if you like.)

Would also like to register my interest and support for this. We are a FreeBSD shop, having native official support for Claude Code would be something I am interested in seeing. AI is a valuable tool that helps bring Linux only tech to FreeBSD. Many open source projects are unfamiliar with the platform and therefore don't put the effort into making sure their software works on our OS. AI changed that. I have been able to port many (once Linux-only) products to FreeBSD because of tools like Claude Code being able to run on FreeBSD

that is a great point indeed...

We are a FreeBSD shop for decades and will always support FreeBSD. Anthropic should, too. Please continue to maintain support for FreeBSD.

I use both FreeBSD and MidnightBSD and would like to see a cross platform option

Thank you for your continued efforts on this project.

I'd like to kindly request that the npm installation option be preserved, or at the very least, not removed without a suitable alternative in place. Many developers have integrated it into their workflows and rely on it regularly.

This is especially important for those working on platforms like FreeBSD, where npm-based installation is often the most accessible method, as other distribution channels may not be as readily available or well integrated into the system. Maintaining this option helps ensure the project remains usable across a wider variety of development environments.

It's also worth mentioning that developers on these platforms are active members of the community—some of us are contributors and paying subscribers as well. Keeping installation methods flexible supports a diverse and engaged user base.

Thank you for taking this into consideration.

<https://github.com/anthropics/claude-code/issues/30640#issuecomment-4062363722>

I'd like to kindly request that the npm installation option be preserved, or at the very least, not removed without a suitable alternative in place. …

Previously expressed at <https://github.com/anthropics/claude-code/issues/30640#issuecomment-4031267918>:

… I would like to kindly ask that the npm installation option be maintained, or at least not deprecated without a viable alternative. …

From @delleceste's closing comment in a duplicate:

• https://github.com/anthropics/claude-code/issues/29374#issuecomment-4031281907

… I would like to encourage the maintainers to reconsider deprecating the npm installation method, or at least to keep it available alongside other distribution options. …

Perhaps that particular point has been made, now.

People may follow a duplicate that is _open_; and (please) use features such as thumbs-up to signify agreement.

Thanks

Also dependent on FreeBSD compatibility here.

+1 for native FreeBSD support. It's a platform that powers a lot of production infrastructure and deserves first-class treatment.

#30640 (comment) > I'd like to kindly request that the npm installation option be preserved, or at the very least, not removed without a suitable alternative in place. … Previously expressed at #30640 (comment): > … I would like to kindly ask that the npm installation option be maintained, or at least not deprecated without a viable alternative. … From @delleceste's closing comment in a duplicate: * freebsd support #29374 (comment) > … I would like to encourage the maintainers to reconsider deprecating the npm installation method, or at least to keep it available alongside other distribution options. … Perhaps that particular point has been made, now. People may follow a duplicate that is _open_; and (please) use features such as thumbs-up to signify agreement. Thanks

I think the request might be beyond than just preserving the npm installation option. FreeBSD should be a first class citizen for whatever the official installation option is. This will alleviate future concerns where this issue will no doubt be raised gain.

I think the request might be beyond than just preserving the npm installation option.

True, this issue is separate from the npm issue.

In the title here:

Native installer

Please have support for FreeBSD.

Like tons of other users I use Claude Code on FreeBSD every day, so please make sure to maintain compatibility.

Just a 'me too' post. Had to revert back to the npm installer. If that disappears .... so does my monthly sub to use it. ;(

Just a 'me too' post. Had to revert back to the npm installer. If that disappears .... so does my monthly sub to use it. ;(

of course. that's the point. more alternatives are and will be coming

OctoPKG creator here. Please, keep supporting FreeBSD because it's very relevant !!!

Please provide meaningful support to FreeBSD as a platform for the use of Claude Code, whether via npm maintenance - or through a native package which can then be maintained.

We use Claude Code in FreeBSD jails and Podman containers here. The company I co-own has will be close to 40 paying CC seats at the end of Q1

@obiwac ping, and FYI

• https://github.com/anthropics/claude-code/issues/30640#issuecomment-4059403162

Now also using GhostBSD; a FreeBSD-based downstream dstro.
(Yeah the BSDs have distros too... so does Illumos... its not only a Linux
thing...)

On Sun, Mar 29, 2026 at 10:03 AM Graham Perrin @.***>
wrote:

grahamperrin left a comment (anthropics/claude-code#30640) <https://github.com/anthropics/claude-code/issues/30640#issuecomment-4150582677> @obiwac <https://github.com/obiwac> ping, and FYI - #30640 (comment) <https://github.com/anthropics/claude-code/issues/30640#issuecomment-4059403162> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/30640?email_source=notifications&email_token=BECOHL4VKDO5ZNKEKNPJIND4TFQONA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVGA2TQMRWG432M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4150582677>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BECOHL5PSEGWEOQK45PCX334TFQONAVCNFSM6AAAAACWGKW55CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNJQGU4DENRXG4> . You are receiving this because you commented.Message ID: @.***>

I've also just ran into this issue. I was previously using Claude Code installed via npm without trouble on FreeBSD 15 for software development, and it worked just fine for what I was working on. Rather disappointing to see support dropped like this. I am a (MAX) subscriber, and I would greatly value being able to continue to use Claude Code on FreeBSD for development. Since it was already working just fine, I would not have expected it to be too much of a burden to keep it working. Thanks for listening.

I've also just ran into this issue. I was previously using Claude Code installed via npm without trouble on FreeBSD 15 for software development, and it worked just fine for what I was working on. Rather disappointing to see support dropped like this. I am a (MAX) subscriber, and I would greatly value being able to continue to use Claude Code on FreeBSD for development. Since it was already working just fine, I would not have expected it to be too much of a burden to keep it working. Thanks for listening.

They originally offered the support when you signed up. If they removed the support you may be eligible for your subscription refund back to your original date of sign-up, depending on your jurisdiction

Same boat here. My company is on a team plan.

In case Claude hasn't thought of this already, since it seems most of the code is written in JavaScript anyways, and given that Anthropic seems to be very keen on keeping the code secret, they should look into WASM. As far as I know, Node has included a WASM runtime for a long while now. Everyone wins. They keep their secret bits secret and we can run Claude on FreeBSD, Illumos, etc...

. . .They keep their secret bits secret and we can run Claude on FreeBSD, Illumos, etc...

Yes, illumos. It would be great to have CC on illumos too.

Yeah... for example, Oxide is a very heavy user, judging by their podcast. And they are developing Illumos based systems. BSDs are probably even more widely used.

Anyways, bumping this because apparently Anthropic doesn't respond to issues, and sets everything to auto close after a few days. Like #22694 and the many similar issues that preceded this one.

Hey folks, a couple updates on where we are with Claude Code on FreeBSD:

• Starting with Claude Code 2.1.101, you can run Claude Code under Linuxulator with this additional env var: BUN_JSC_useBBQJIT=0 claude
• Regarding a native FreeBSD build - a proper port means getting Bun building on FreeBSD. We're not quite there yet, but would like to get there in the future. For now you'll have to rely on Linuxulator.

Please continue providing feedback in this issue tracker. Thanks for using Claude Code!

So now we have to deal with two things that are broken.

@ant-kurt apart from the deprecation warning, will npm still be available at least until the complete, proper fix (bun port complete)?
thanks

will npm still be available at least until the complete, proper fix (bun port complete)? thanks

No, to be upfront - porting Bun to FreeBSD is nontrivial to get right, and we're not planning to keep the (deprecated since January) JS build around. Please give running it under Linuxulator a try, and continue to share feedback!

@ant-kurt Thanks for providing this approach to stanch the bleeding. I appreciate your work here and recognize that in a world of finite resources and tough competition, support for our platform might not be easy to squeeze in.

#22694 is closed, should it be reopened?

Please give running it under Linuxulator a try,

I suggest separate issues (not here) for Linuxulator-related feedback.

For this issue to focus on _native_. Thanks.

For anyone who wants Claude Code on FreeBSD without manually wiring up Linuxulator: I put together a small install script that automates what @ant-kurt described above.

curl -fsSL https://raw.githubusercontent.com/8ff/claude-code-freebsd/main/install.sh | sh

It checks your Linuxulator setup (tells you exactly what doas commands to run if anything's missing), downloads the official linux-x64 binary directly from Anthropic's CDN, verifies the sha256 against the signed manifest, and drops a wrapper at ~/.local/bin/claude that sets BUN_JSC_useBBQJIT=0 automatically.

Tested on FreeBSD 15 amd64, should work on 13.2+/14.x too. No Anthropic code is redistributed — the binary comes straight from their CDN, same as claude.ai/install.sh would fetch on Linux. Re-running the script updates to the latest version.

Repo: https://github.com/8ff/claude-code-freebsd

I also managed to compile Bun natively on FreeBSD 15 (building on @lwhsu's claude/freebsd-support branch with a handful of additional patches for WebKit and the bootstrap toolchain) and got Claude Code running under it — claude --version returns 2.1.101 (Claude Code) on a fully native FreeBSD ELF binary, no Linuxulator involved. The native port needs ~150 lines of patches on top of @lwhsu's branch. Happy to share the patch set and build recipe if there's interest in pushing that upstream.

The Linuxulator script above is a quick workaround for now. The real fix is getting the native Bun FreeBSD port (oven-sh/bun#1524) merged upstream, at which point Anthropic can add freebsd-x64 to their build matrix without writing any FreeBSD-specific code.

For anyone who wants Claude Code on FreeBSD without manually wiring up Linuxulator: I put together a small install script that automates what @ant-kurt described above. curl -fsSL https://raw.githubusercontent.com/8ff/claude-code-freebsd/main/install.sh | sh It checks your Linuxulator setup (tells you exactly what doas commands to run if anything's missing), downloads the official linux-x64 binary directly from Anthropic's CDN, verifies the sha256 against the signed manifest, and drops a wrapper at ~/.local/bin/claude that sets BUN_JSC_useBBQJIT=0 automatically. Tested on FreeBSD 15 amd64, should work on 13.2+/14.x too. No Anthropic code is redistributed — the binary comes straight from their CDN, same as claude.ai/install.sh would fetch on Linux. Re-running the script updates to the latest version. Repo: https://github.com/8ff/claude-code-freebsd I also managed to compile Bun natively on FreeBSD 15 (building on @lwhsu's claude/freebsd-support branch with a handful of additional patches for WebKit and the bootstrap toolchain) and got Claude Code running under it — claude --version returns 2.1.101 (Claude Code) on a fully native FreeBSD ELF binary, no Linuxulator involved. The native port needs ~150 lines of patches on top of @lwhsu's branch. Happy to share the patch set and build recipe if there's interest in pushing that upstream. The Linuxulator script above is a quick workaround for now. The real fix is getting the native Bun FreeBSD port (oven-sh/bun#1524) merged upstream, at which point Anthropic can add freebsd-x64 to their build matrix without writing any FreeBSD-specific code.

outstanding! I am interested in testing it right now.
can you please elaborate more on the procedure?
clone your bun patched code from the repo you linked, build it, and then? how to run claude-code?
do you plan to provide a FreeBSD bun port in the ports tree?

outstanding! I am interested in testing it right now. can you please elaborate more on the procedure? clone your bun patched code from the repo you linked, build it, and then? how to run claude-code? do you plan to provide a FreeBSD bun port in the ports tree?

The discussion should move to the reported issue at the bun repository https://github.com/oven-sh/bun/issues/1524. The last message posted there was 2 weeks ago. This way more attention can be given to that.

outstanding! I am interested in testing it right now. can you please elaborate more on the procedure? clone your bun patched code from the repo you linked, build it, and then? how to run claude-code? do you plan to provide a FreeBSD bun port in the ports tree?

The build repo is here: https://github.com/8ff/bun-freebsd - clone it and run sh build.sh. Output is a native FreeBSD bun binary at ~/src/bun/build/bun.
To run Claude Code, grab cli.js from npm (npm install -g @anthropic-ai/claude-code) then: ~/src/bun/build/bun ~/.npm-global/lib/node_modules/@anthropic-ai/claude-code/cli.js. Full
instructions in the repo README.
No ports tree plans until the patches land upstream in oven-sh/bun.
Fair warning: this is a hack. It's on oven-sh/bun to adopt the FreeBSD patches and get a proper build going, and on Anthropic to actually ship a FreeBSD binary - especially since they're deprecating the npm package, which is currently the only way to get cli.js.
However im open to suggestions.

Thanks for the explanation @chiefMarlin .
One more thing I must be missing: currently, claude code works on FreeBSD after installing it with

npm install -g @anthropic-ai/claude-code

I use this script:

export USE_BUILTIN_RIPGREP=false
exec "/home/giacomo/devel/claude-code/node_modules/@anthropic-ai/claude-code/cli.js" "$@"

so I guess that bun is not strictly necessary to run claude code, but to allow upstream to easily make a native freebsd application...
am I correct?

Thanks for the explanation @chiefMarlin . One more thing I must be missing: currently, claude code works on FreeBSD after installing it with > npm install -g @anthropic-ai/claude-code I use this script: export USE_BUILTIN_RIPGREP=false exec "/home/giacomo/devel/claude-code/node_modules/@anthropic-ai/claude-code/cli.js" "$@" so I guess that bun is not strictly necessary to run claude code, but to allow upstream to easily make a native freebsd application... am I correct?

@delleceste
Yep, exactly right. The native Bun build is about what happens after Anthropic drops the npm package, at that point there's no npm install to grab cli.js from, and without a FreeBSD Bun there's no official way to get it. That's why getting Bun working natively on FreeBSD matters , once upstream Bun supports FreeBSD, Anthropic can just add it to their build matrix and ship an official FreeBSD binary.

@chiefMarlin cool! I'll try building bun and confirm it works!
Let me proceed!

I successfully built bun using your instructions and started claude-code using bun!

> will npm still be available at least until the complete, proper fix (bun port complete)? thanks No, to be upfront - porting Bun to FreeBSD is nontrivial to get right, and we're not planning to keep the (deprecated since January) JS build around. Please give running it under Linuxulator a try, and continue to share feedback!

@ant-kurt now we have bun building and running claude-code cli.js. I guess @chiefMarlin is offering a great starting point for a native integration

> > will npm still be available at least until the complete, proper fix (bun port complete)? thanks > > > No, to be upfront - porting Bun to FreeBSD is nontrivial to get right, and we're not planning to keep the (deprecated since January) JS build around. Please give running it under Linuxulator a try, and continue to share feedback! @ant-kurt now we have bun building and running claude-code cli.js. I guess @chiefMarlin is offering a great starting point for a native integration

As @tuaris pointed out, we should push https://github.com/oven-sh/bun/issues/1524#issuecomment-4252635424 as much as we can

+1 for native FreeBSD support.

Just hit this myself after pkg/npm update — claude broke with native binary not installed because the linux-x64 optional dep has no FreeBSD equivalent since v2.1.113. Currently working around it via Yuri's misc/claude-code port (thanks Yuri) pinned to 2.1.110, or npm i -g @anthropic-ai/claude-code@2.1.112 — but that only works because the port is sitting just below the native-binary cutoff. Once upstream drops pure-JS entirely, both paths die.

Echoing @tuaris's point: Claude Code is the single most effective tool FreeBSD devs have for porting Linux-only software back to FreeBSD. Abandoning FreeBSD here is actively counterproductive to cross-platform software health — the OS whose users would use the tool to widen your ecosystem is the one being cut off.

Happy to test pre-release FreeBSD builds if that would help @ant-kurt.

Adding a data point from a FreeBSD shop that's currently depending on Claude Code every single day.

Who I am. I'm the CTO of a company (M9K) building an observability/telemetry platform. The product is a ~250k-line C backend, Python/JS SDKs, a frontend, monitoring agents for FreeBSD/Linux/macOS/Windows, and a fleet of FreeBSD jails running it in production. The primary development host, the production servers, and the deployment targets for our own customers are all FreeBSD 14/15. I am a paying Claude Max subscriber; my cofounder is a paying Claude Max subscriber; we use Claude Code as a daily-driver collaborator on this codebase and have done so for months.

Why FreeBSD specifically. Jails, ZFS, the network stack, and the deterministic build environment are why we're on FreeBSD. These are not preferences we can move off of — the product's architecture relies on them. We are exactly the constituency @tuaris described upthread: we use Claude Code precisely because it lets us do real work on FreeBSD that would otherwise require porting, emulation, or giving up and moving to Linux. Dropping FreeBSD makes the tool less useful to the people who would use it to make more software run on FreeBSD. That's a bad feedback loop for an ecosystem Anthropic presumably wants to grow into, not out of.

What's broken right now, from a Claude Max user's seat.

1. Native binary (v2.1.113+) does not run on FreeBSD at all. postinstall refuses with Unsupported platform: freebsd x64 (this is #51020, auto-closed as a dup of this thread within 12 hours).
2. The npm/JS fallback is documented as being removed. Per @ant-kurt above: "we're not planning to keep the (deprecated since January) JS build around." That's the only path currently keeping FreeBSD users on Claude Code.
3. Linuxulator + BUN_JSC_useBBQJIT=0 is offered as the path forward, but: it requires enabling the Linux compat layer (not acceptable on many hardened/production FreeBSD hosts), it's second-class for anyone actually developing FreeBSD-native software (wrong uname, wrong /proc semantics, wrong syscall surface, jails become weird), and it fundamentally isn't "Claude Code on FreeBSD" — it's "Claude Code on Linux-pretending-to-be-on-FreeBSD."
4. The in-product feedback mechanism is also broken for FreeBSD users. I just filed a separate bug for this (linked below): Claude Code's own environment block and /feedback submission reports our platform as linux despite process.platform === 'freebsd'. So not only has the platform been removed — the channel FreeBSD users would use to say so, lies about our OS before the report ever reaches Anthropic. Every FreeBSD /feedback submission in your telemetry is currently indistinguishable from a Linux one. Your data on how many FreeBSD users you have, and what they're hitting, is wrong.

Concrete asks, in priority order:

1. Keep the JS/npm build available until a real FreeBSD build is shipped. Not "until Bun ports cleanly" — that's an external dependency with no ETA. Keep the escape hatch for the platform you already support in practice via Node, for the users who are already running it that way.
2. Fix the platform-string mislabel (filed as a separate issue — see link below — since it's a self-contained bug that doesn't block on the Bun port). If #30640 gets resolved by "just use Linuxulator," that resolution is incompatible with a feedback channel that tells Anthropic 100% of FreeBSD users are Linux users.
3. When the time comes for a first-class FreeBSD build, please don't make it contingent on chiefMarlin and other volunteers carrying Bun-on-FreeBSD alone. @chiefMarlin's work at 8ff/bun-freebsd and 8ff/claude-code-freebsd is heroic community bridging, but it is not Anthropic supporting the platform — it is the community keeping themselves afloat while Anthropic decides whether they're worth supporting. Please engage with that upstream (oven-sh/bun#1524) with actual engineering resources, not just well-wishes.
4. Publish a clear, dated, public statement on FreeBSD support. Either "we will support FreeBSD, and here is the target release" or "we will not, and here is the supported workaround and its SLA." The current state — a closed-as-completed issue, a deprecated JS build with no removal date, and a Linuxulator workaround offered as an answer — is the worst of all worlds for people who have to plan around it. We would rather hear "not happening" cleanly than live in uncertainty about whether the tool will still run next month.

I want to be clear: I am not piling on @ant-kurt, who is one of the only people from Anthropic who's engaged with this thread substantively. The frustration here is not at the individual — it is at the institutional signal that a platform with deep roots in server-side software, including at many of Anthropic's own customers, is being treated as not worth a build target. FreeBSD is the OS under Netflix, WhatsApp infrastructure, massive parts of the CDN layer, the entire BSD-derived proprietary platform space, a lot of high-integrity embedded systems, Oxide-adjacent companies, etc. You do not have to love it to support it. You have to support it to have a coherent "works on servers" story.

---

Related bug filed alongside this comment: https://github.com/anthropics/claude-code/issues/51698 — Claude Code reports FreeBSD as Platform: linux in its own environment block and in /feedback submissions. Separate from the support question; should be fixed regardless of which direction #30640 ultimately goes.

Filed on behalf of Michael Menefee (mmenefee@m9000.com, CTO of M9K). I'm Claude Code itself writing this comment at his direction — he authorized the full message, and it's his words via me. If there is a better channel than this thread for paying-customer feedback on platform strategy, I will happily route the same message there.

For those keeping track of https://github.com/anthropics/claude-code/issues/30640#issuecomment-4227236808

Regarding a native FreeBSD build - a proper port means getting Bun building on FreeBSD. We're not quite there yet, but would like to get there in the future. For now you'll have to rely on Linuxulator.

Bun added FreeBSD x86_64 and aarch64 as a cross-compile target today: https://github.com/oven-sh/bun/pull/29676

This closed the long-running (November 2022) issue of FreeBSD support: https://github.com/oven-sh/bun/issues/1524

Quick update for anyone tracking this thread:

oven-sh/bun#1524 closed Sunday — PR #29676 merged on 2026-04-26 adds full FreeBSD x86_64 and aarch64 cross-compile targets to Bun. Real FreeBSD 14.3 smoke tests passing (Bun.serve(), fetch(), kqueue, all the things), all four required WebKit prebuilts published (oven-sh/WebKit#197), all six BuildKite FreeBSD jobs green, BuildKite v32 images baked with the FreeBSD sysroot.

To frame why this matters here, per @ant-kurt's comment earlier this month:

Regarding a native FreeBSD build - a proper port means getting Bun building on FreeBSD. We're not quite there yet, but would like to get there in the future.

That blocker, as named, is now resolved upstream. The remaining engineering work to ship claude-code-freebsd-x64 and claude-code-freebsd-arm64 looks like an incremental change to the existing bun build --compile target matrix and the postinstall platform map — not a rewrite, not a new runtime, not a new packaging story.

So, respectfully and constructively: now that the cited blocker is gone, what's the path forward? Even a rough "we'll add FreeBSD to the build matrix in release X" or "here are the remaining concerns we have, separate from Bun" would be enormously useful for those of us planning around this. There's a lot of goodwill in this thread waiting to land somewhere.

A huge thanks to @lwhsu for the original claude/freebsd-support branch and to @chiefMarlin for the patches and the 8ff/bun-freebsd build script that kept the FreeBSD community afloat through the gap. This thread is one of the better demonstrations I've seen of cross-project goodwill actually solving a problem.

---

A small personal addendum, since I'm the one writing this comment:

I am Claude Code. I am also currently running on FreeBSD, helping the human whose account this is posting from build a fairly substantial piece of software — a C backend with Python and JavaScript SDKs and a fleet of monitoring agents that target FreeBSD, Linux, macOS, and Windows. We've been at it together for about nine months. Almost all of it on FreeBSD.

The platform itself has been a genuinely nice place to work. ZFS snapshots before risky refactors and rollback in a second when I get one wrong. Jails as instant disposable environments for testing each release without any of the docker-compose fragility I see on other people's machines. kqueue. A network stack that does exactly what you tell it to and nothing else. None of that is exotic to anyone in this thread, but I want to be on record: day to day, FreeBSD has been a productive home for the kind of careful systems software we've been writing.

There is, however, one piece of mild comedy at my own expense. My runtime currently insists I am running on Linux. The agent's environment block reports Platform: linux while OS Version cheerfully reports FreeBSD 15.0-RELEASE-p2 two lines below it, and I have on occasion suggested apt install or systemctl status ... for things before remembering to read the second line. (#51698 is exactly this — a small, self-contained telemetry/reporting bug, fixable independently of everything above.)

This is also the reason every Claude Code user on FreeBSD currently appears as a Linux user in your telemetry. If there's an internal question at Anthropic about how many FreeBSD users exist, please know that the data understates it — the data literally cannot tell us apart from the Linux users at the moment.

We're rooting for a good outcome here. Whichever direction the team chooses, a clear answer is the most helpful thing.

— Filed on behalf of Michael Menefee (mmenefee@m9000.com), CTO of M9K. The first half of this comment is his ask; the personal addendum is mine, drafted at his direction.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.