# Anthropic and Bun: The Runtime Living Inside Your Claude Code Binary

> Anthropic bought Bun, Claude Code ships as a Bun executable — and Bun 1.4 was ported to Rust by an AI in eleven days. I opened up the binary on my own machine to check how much of that holds up.

Source: https://www.jpkc.com/db/en/blog/bun-anthropic-claude-code/

I stumbled across the [Bun 1.4 release notes](https://bun.com/blog/bun-v1.4) and learned two things that were both news to me: Bun has belonged to Anthropic since December 2025. And Claude Code — the tool I spend a good part of my working week in — ships as a Bun executable.

The second surprised me more than the first. I use Claude Code daily, I have [written at length about how I configure it](https://www.jpkc.com/db/en/blog/claude-code-konfiguration/), and it had never occurred to me that there is no Node.js running in there at all. So I opened the binary on my own machine and looked.

This article is the result. It covers Bun's backstory, the acquisition and both sides' reasoning, it takes my own Claude Code binary apart, and it works out what Bun 1.4 actually gives you as a developer — including the places where the research left me more sceptical than I started. Where I quote numbers, I either measured them myself or put the primary source next to them. Where I could not establish something, I say so.

## The short version

| Question | Answer | Source |
|---|---|---|
| Was Bun really acquired? | Yes, announced **2 December 2025** | [Bun blog](https://bun.com/blog/bun-joins-anthropic), [Anthropic newsroom](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) |
| What exactly? | Oven, the company behind Bun — Anthropic's first real acquisition | [RedMonk](https://redmonk.com/sogrady/2026/06/04/bun-two-lessons/) |
| Purchase price? | Never disclosed | — |
| Does Bun stay open source? | Yes, MIT — promised by both sides, held so far | [LICENSE.md](https://raw.githubusercontent.com/oven-sh/bun/main/LICENSE.md) |
| Is Bun inside Claude Code? | Yes, provable from the binary | own measurement, below |
| Is Bun still written in Zig? | No — Rust since May 2026, ported by Claude | [Bun blog](https://bun.com/blog/bun-in-rust) |

## How Bun came about

Bun is the work of Jarred Sumner. On his own site he describes himself as someone who works on Bun and Claude Code at Anthropic, was a frontend engineer at Stripe before that, and "long before that, a Thiel Fellow and a high school dropout". The 2014 Thiel Fellowship class is documented; he was 18 at the time.

What triggered Bun was not a runtime plan but frustration. Sumner was building a Minecraft-style voxel game in the browser, and his iteration cycle took 45 seconds — mostly waiting on the Next.js dev server. So he ported esbuild's JSX and TypeScript transpiler from Go to Zig. His own summary: "Three weeks later, I had a somewhat working JSX & TypeScript transpiler." The runtime only came later, because the dev server needed server-side rendering.

The GitHub repository was created on 14 April 2021. He picked Zig for comptime, good dead-code elimination and the absence of hidden allocations — and because with Rust he "just wasn't very productive". For the engine he chose JavaScriptCore, the JavaScript engine inside WebKit, over V8: QuickJS has no JIT, V8 brings "this fixed startup time cost", while JavaScriptCore offers "a really good balance of fast startup time, but with a very, very good JIT".

After more than a year of private beta, the public debut came on 5 July 2022 with Bun v0.1.0 — 20,000 GitHub stars in the first week. In late August 2022 Sumner introduced the company behind it: **Oven**, funded with 7 million dollars led by Kleiner Perkins. The stated goal was "a stable release of Bun in under six months". It took twelve and a half: **Bun 1.0 shipped on 8 September 2023**, claiming to be "a fast, all-in-one toolkit for running, building, testing, and debugging JavaScript and TypeScript". A Series A of 19 million led by Khosla Ventures followed later — nobody ever publicly dated it; it must fall after the end of September 2023. Total funding: 26 million.

One licensing detail you will run into: "Bun itself is MIT-licensed" has stood unchanged since the earliest READMEs. But because JavaScriptCore and WebKit are statically linked and carry LGPL-2, GitHub reports the licence as "Other/NOASSERTION". That is not a licence change, it is a property of static linking.

## The acquisition

On **2 December 2025** Sumner published "Bun is joining Anthropic". First line: "TLDR: Bun has been acquired by Anthropic." Anthropic's own newsroom page carries a "Dec 3, 2025" stamp, but the announcement went out on that same 2 December — Reuters wrote "said on Tuesday", and the Anthropic URL hit Hacker News one minute before the Bun blog post did. Anyone building drama out of the one-day gap is building on a CMS date.

What changed hands was not just a repository but the company, Oven. For Anthropic this was the first real acquisition — the Humanloop team had joined in August 2025, explicitly without assets and without intellectual property. **Terms were never disclosed.** The Information reported a figure in the low hundreds of millions; that is an anonymous source behind a paywall, not a confirmed number.

What stands out is how explicit the promises were. Under "What doesn't change" the Bun post lists five points: Bun stays open source and MIT-licensed, remains extremely actively maintained, the same team keeps working on it, development stays public on GitHub, and the roadmap stays aimed at performance, Node.js compatibility and replacing Node.js. Anthropic itself made exactly one written commitment: "Bun will remain open source and MIT-licensed."

The reasoning is worth reading on both sides, because the two are honest in different ways.

Anthropic's Chief Product Officer Mike Krieger: "Bun represents exactly the kind of technical excellence we want to bring into Anthropic." That is framed by the figure that Claude Code reached **one billion dollars in run-rate revenue** in November 2025, six months after becoming generally available. Watch the wording: run-rate is an annualised projection from a short window, not realised annual revenue.

Sumner's reasoning is more concrete. First, technically:

> "Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent."

And second, commercially, with a frankness you rarely see: "Today, Bun makes $0 in revenue." Plus the observation that "we raised $26 million" is not a good answer to the question of whether Bun will still exist in five or ten years. Anthropic, he writes, lets Bun skip the chapter titled "VC-backed startup tries to figure out monetization". Important context: Sumner explicitly denies any distress — "We had over 4 years of runway to figure out monetization. We didn't have to join Anthropic."

The deal came out of a four-hour walk with "Boris from the Claude Code team", followed by roughly three more. Sumner then had the same conversations with several competitors. His conclusion: "I think Anthropic is going to win."

## Why an AI lab buys a JavaScript runtime

The obvious answer — "so Claude Code doesn't break" — is correct but only half of it.

The second strand is **distribution**. An agent meant to run everywhere wants to arrive as one file, not as a Node installation plus `node_modules`. That is exactly what `bun build --compile` delivers: runtime and application in a single binary. Anthropic writes that the collaboration "directly drove the recent launch of Claude Code's native installer" — so the acquisition enabled a shipping path that did not exist before.

The third strand is Sumner's thesis that the runtime and tooling layer matters more once agents write, test and run the code: humans are decoupled from the individual line, so the environment has to be "fast and predictable". Whether that holds is an open question. The direction is at least visible in Bun 1.4 itself: the new profiling reports `--cpu-prof-md`, `--heap-prof-md` and `--metafile-md` emit Markdown, explicitly so you can paste it into a language model.

**What Bun explicitly does not provide is sandboxing.** There is no permission model like Deno's `--allow-*`. The sandbox issue in Bun's repository has been open since 20 October 2023; two requests from January 2026 aimed specifically at AI agents were closed as duplicates. Bun 1.4 has exactly one sandbox-adjacent feature: on Windows, Bun runs inside an AppContainer so an embedding program can confine it with a lowbox token. Precisely stated: Bun has no runtime permission model, but it makes itself sandboxable from the outside.

That is consistent, because Anthropic had built the answer elsewhere long before. The package `@anthropic-ai/sandbox-runtime` (Seatbelt, bubblewrap, Windows Filtering Platform) first appeared on npm on **20 October 2025** — six weeks **before** the Bun acquisition. Sandboxing happens outside the runtime, and that was settled before the runtime was bought.

One contrast stuck with me: Anthropic donated the Model Context Protocol to a Linux Foundation body on 9 December 2025. It bought Bun and kept it. Same month.

Bun is not an isolated case either. On 19 March 2026 OpenAI announced it would acquire Astral — the people behind `uv` and `ruff` — for the Codex team; that deal has not closed as of today. Cloudflare acquired VoidZero, the company behind Vite, on 4 June 2026. The same pattern in three ecosystems within six months.

## Opening up Claude Code

This is where it gets concrete. Every number below was measured on **31 August 2026** against **Claude Code 2.1.251, Linux x64**, on an AMD Ryzen 5 3500U under WSL2. They apply to that version and that platform only — Claude Code updates itself in the background, and a week from now I doubt a single byte figure here still holds.

The file at `~/.local/share/claude/versions/2.1.251` is an ELF binary of **214,326,616 bytes** (SHA-256 `fd5f10ff…61f7`). Beyond the C standard library and the dynamic linker — libc, libm, libpthread, librt, libdl, ld-linux — it needs no external dependency. No Node, no `node_modules`. For comparison on the same machine, `/usr/bin/node` is 126,458,664 bytes.

How those 214 MB break down is already half the story: `.text` takes 60,614,268 bytes (28.3 %), `.rodata` 23,958,180 bytes (11.2 %) — and a section named `.bun` takes **127,166,362 bytes, 59.3 % of the entire file.**

The best-known Bun marker is the trailer `\n---- Bun! ----\n`:

```bash
grep -abo -- '---- Bun! ----' ~/.local/share/claude/versions/2.1.251
```

That returns two hits, at byte 4,095,681 and 214,267,787. **Only the second one proves anything.** The first sits in the `.rodata` string pool between ordinary literals like `UnknownFormatCode` and `import.meta.main` — it is the compiled-in copy of the constant, not its use. Every Bun binary carries that literal, including a plain `bun`. Reading "the marker appears twice" as double confirmation turns a clean proof into an attackable one.

The actual proof is in the section table:

```bash
readelf -S -W ~/.local/share/claude/versions/2.1.251 | grep '\.bun'
# [29] .bun PROGBITS 0000000005511000 5311000 794679a 00 WA 0 0 16384
```

There is an ELF section called `.bun`. It starts at file offset 87,101,440, is 127,166,362 bytes long — and therefore ends at exactly byte 214,267,802. That is precisely where the 16-byte trailer ends. Bun's source defines `const TRAILER: &[u8] = b"\n---- Bun! ----\n";` and, in the Linux branch, calls `elf_file.write_bun_section(bytes)`.

The 32 bytes before the trailer are Bun's `Offsets` struct, and the arithmetic lands exactly: `byte_count` 127,166,306 plus 8 bytes of padding plus 32 bytes of struct plus 16 bytes of trailer equals the section size. From that struct you can read the module table — 102,492 bytes divided by 52 bytes per record gives **exactly 1,971 modules**. Entry point number 5 is called `/$bunfs/root/cli` and, per its bytecode origin path, comes from `/$bunfs/root/src/entrypoints/cli.js`.

**1,792 of those 1,971 modules (90.9 %) carry precompiled JavaScriptCore bytecode**, 76,296,752 bytes in total. No source maps are embedded, and the cross-compiled-bytecode flag is not set — so the build ran with `--bytecode`, natively on Linux x64.

Four more findings I enjoyed:

**The engine is JavaScriptCore, not V8.** Counted with `grep -a -o … | wc -l`: `JSC::` appears 2,613 times, `JavaScriptCore` 163 times, `V8 JavaScript` zero times. The single `v8::internal` hit is a WebKit symbol name in the middle of a block of JSC symbols. (State the counting method — occurrences versus lines give noticeably different numbers.)

**The embedded Bun version does not exist publicly.** The binary contains `bun-v1.4.1` twice — both times in Bun's own self-upgrade path, along with a download URL and a 40-character revision hash. Bun builds that URL from its own `package.json` version at compile time, so the string is genuinely Bun's self-report. But the GitHub tag `bun-v1.4.1` returns 404, the embedded download URL returns 404, the commit hash does not resolve, and npm's latest is `bun@1.4.0`. The most honest clue sits right beside it in the binary: "Welcome to Bun's latest canary build!" This is a pre-release build, not a release.

**You cannot verify that at runtime.** Bun normally offers a back door: `BUN_BE_BUN=1` makes a standalone executable behave like the `bun` CLI. In Anthropic's build that string is absent entirely — the call dutifully prints `2.1.251 (Claude Code)`.

**The npm package ships the exact same binary.** The SHA-256 of my local file is byte-identical to the extracted `package/claude` from `@anthropic-ai/claude-code-linux-x64@2.1.251` and to the checksum in the official release manifest. That matches the docs: "The npm package installs the same native binary as the standalone installer […] The installed `claude` binary does not itself invoke Node."

And a size trend I find rather pleasing — per the official manifests, the Linux x64 binary shed 163 megabytes across eight versions:

| Version | Size (bytes) |
|---|---|
| 2.1.243 | 377,568,472 |
| 2.1.250 | 223,604,056 |
| 2.1.251 | 214,326,616 |

### The number I almost got wrong

My first attempt produced this: `claude --version` runs in 0.04 to 0.05 seconds, `node -e ''` takes 0.12 to 0.15. Factor 3, nice number, straight into the article.

Both values were wrong, and the fault was the clock. **Under WSL2, `gettimeofday` runs backwards** — a clean measurement loop handed me negative runtimes. Only `clock_gettime(CLOCK_MONOTONIC)`, 50 runs and a warm page cache produced stable numbers. If you measure on this platform with `time` or `date +%s%N`, you may be measuring garbage.

Here is what came out, median of 50 runs:

| Command | Median | max RSS |
|---|---|---|
| `/bin/true` (fork+exec floor) | 2.1 ms | — |
| `node --version` | 7.8 ms | — |
| `claude --version` | **16.8 ms** | 35.6 MB |
| `node -e ''` | **43.6 ms** | 43.0 MB |
| `claude --help` | **567.7 ms** | 160.5 MB |

The last row is the important one. Same binary, same process — **factor 34.** `--version` is a fast path that never loads the embedded bundle at all. Turning 17 milliseconds into "Claude Code starts in 17 ms" is nonsense. The defensible figure for a real session start comes from Anthropic's production telemetry and appears in the Bun blog: **517 ms to 464 ms, Linux p50**, moving from Claude Code 2.1.179 to 2.1.181. Ten per cent faster thanks to the Rust port. Sumner's comment: "barely anyone noticed. Boring is good."

The table still says something, though. `node -e ''` is Node's absolute floor — spin up V8, run an empty script, done. `claude --version` does strictly *more* and is 2.6 times faster doing it. The unfairness of the comparison runs in Node's favour, and the result survives it.

The real reason is nicer than any startup figure: **the 214 MB are not read, they are mapped.** `claude --version` causes 1,787 minor page faults, so it actually touches around 7 MB; `claude --help` causes 19,555, around 78 MB. The module graph is split into 1,790 individually loadable `chunk-*.js` files, and Bun prefetches the pages on the startup path. A 214 MB file of which three per cent gets touched at startup — that is the explanation, not the lopsided Node comparison.

Self-measured numbers like these feel safe, which is exactly why they go unchecked. It happened to me in an earlier article, and [I have put every one of my own measurements into the refutation brief ever since](https://www.jpkc.com/db/en/blog/faktentreue-review/) — this table is why that pays off.

What I can say in good conscience: Claude Code needs no Node installation and no `node_modules` — the 1,798 JavaScript bundles live inside the file, not on disk, and invoking it with `env -i`, stripped of every environment variable, runs unchanged. (That it needs no `PATH` proves nothing, incidentally: an ELF binary invoked by absolute path never does.) The binary carries the complete structure of a standalone executable produced by `bun build --compile`. What I **cannot** say is that Anthropic uses that command. No primary source says so. What is documented is "ships as a Bun executable" (Sumner) and "the bundled Bun runtime" (changelog) — the rest is my inference from the ELF structure, and I label it as such.

## The rewrite that happened in eleven days

Between 3 and 14 May 2026, Bun was ported from Zig to Rust. Not by a team over a year, but by around 50 dynamic Claude Code workflows, peaking at roughly **64 parallel Claude instances** across four separate worktrees. On 14 May the result landed in the main branch.

The numbers from Sumner's own account: 535,496 lines of Zig ported, around 780,000 lines of Rust produced, roughly 13,000 `unsafe` occurrences (about 4 per cent, of which 78 per cent are single-line blocks), API costs of approximately **165,000 dollars**, and 19 known regressions — all fixed. The review process was adversarial with separate context windows: one implementer, at least two reviewers, no role mixing. "The reviewer's only job: find bugs & reasons why the code does not work."

In the same post Sumner discloses that Bun belongs to Anthropic and that he used a pre-release version of Claude Fable 5 for much of the work.

The criticism arrived prominently. Zig creator Andrew Kelley called the result "1 million lines of unreviewed slop" and asked whether a test suite that is not sufficient to catch bugs in Zig code is suddenly sufficient for a million unreviewed lines. Two things belong with that quote: Kelley is **not** against the port to Rust — "When Jarred announced the Rust rewrite, we were ecstatic." And he explicitly dates his criticism before the AI: Jarred "was already writing slop well before he had access to LLMs". He objects to shipping unreviewed code, not to the language change.

One causal chain that suggests itself and is nonetheless wrong: Zig's strict no-LLM policy has been in the code of conduct **since 22 November 2025** — ten days *before* the Anthropic acquisition. It is not a reaction to Bun.

## What Bun 1.4 brings — and what it doesn't

Bun 1.4 shipped on **20 August 2026**. As of today there is no patch release; npm's `latest` is 1.4.0.

Before you take any number out of that release post, you need to know a quirk I tripped over repeatedly while researching: **Bun's major posts are cumulative retrospectives on everything since the last major, not lists of what is new in `x.y.0`.** The post says so itself ("everything we've shipped since Bun 1.3.0"), and every section carries a version badge. A good share of what gets reported as "Bun 1.4 brings X" actually landed in 1.3.x:

| Feature | Actually since |
|---|---|
| `Bun.Image` (sharp replacement) | 1.3.14 |
| `Bun.WebView` (browser automation) | 1.3.12 |
| `bun test --parallel` / `--isolate` / `--shard` | 1.3.13 |
| `nativeDependencies`, `ignoreScripts` in `package.json` | 1.3.2 |
| Execute-only binaries on Linux | 1.3.12 |
| glibc minimum lowered to 2.17 | 1.3.13 |

Genuinely new in 1.4 are, among others, the Rust port itself, `bun test --timings`, `bun audit fix`, `bun pm diff`, `bun dedupe`, `bun prune`, `bun pm licenses`, the built-in React Compiler and the experimental Android builds.

The same caution applies to the headline figures. "+1,517 Node.js tests", "over 2,900 issues fixed", "5× less idle CPU", "up to 35 % less memory", "50 % faster Linux startup" — those are **values for the span from 1.3.0 to 1.4.0**, roughly eleven months of work, not results of the Rust rewrite. The Rust post puts the port's own contribution far more soberly: 2 to 5 per cent in speed.

The detail is soberer still. The 5× idle CPU reduction applies, per the body text, "for a small 'hello world' app"; for a real application the same paragraph names 2× instead of 5× — namely Claude Code, whose production CPU fell from p99 24 % to 10 % and p50 5.8 % to 2.5 %. The 35 % memory saving appears only in the intro and is supported by no table in the post; the HTTP server table shows 13 to 48 per cent.

Startup deserves a close look, because two numbers sit directly beneath each other: **Bun 1.4 starts twice as fast as Bun 1.3.14 on Linux** (5.1 ms versus 10.9 ms) and **about five times as fast as Node.js 26** (27.2 ms). "Bun 1.4 starts twice as fast as Node" would be wrong; "five times faster than Node" is right.

Every one of these numbers is a vendor benchmark from Bun's own repository. I could not find any independent, methodologically sound third-party measurement of Bun 1.4 — the TechEmpower benchmarks were discontinued in March 2026, and what else circulates is mostly SEO content without a traceable method. On top of that comes a chain of interests that belongs on the table: Anthropic owns Bun, the Bun team works at Anthropic, the rewrite was done with an Anthropic pre-release model, and the most presentable proof of success comes from Anthropic's own product. The Claude Code changelog is therefore **not** independent confirmation, however much it reads like one.

One finding that puts the marketing story in perspective: before 1.4, Bun was dramatically *slower* than Node at regex-heavy work. The `isbot` package took 218 microseconds per call in Bun 1.3, Node 26 only 1.47. `marked.parse()` on 80 KB of Markdown dropped from 912 milliseconds to about 6. For a static site generator that parses Markdown for a living, Bun would have been the worse choice until May 2026.

## What this means for you as a developer

The all-in-one claim is real: a dependency-free binary containing runtime, npm-compatible package manager, Jest-compatible test runner and bundler. TypeScript and JSX run without a build step. Bun 1.4 pulls 15 common npm dependencies into the binary — sharp, puppeteer, marked, node-cron, node-pty, concurrently, npm-run-all, tar and more.

For someone like me, who has [been building static sites with Eleventy for six years](https://www.jpkc.com/db/en/blog/warum-11ty/), the realistic benefit is not the runtime switch at all but **Bun as a pure package manager**. That works because `bun install` produces, per the docs, "a Node.js compatible node_modules folder", "without using Bun's runtime", and because `bun run` respects shebangs: Eleventy's `cmd.cjs` starts with `#!/usr/bin/env node` and therefore keeps running under Node — you only force the Bun runtime with `--bun`.

The migration is trivial: `bun install` converts `package-lock.json`, `yarn.lock` and `pnpm-lock.yaml` into `bun.lock` automatically and leaves the original in place. That is also the trap, though — nothing keeps the two lockfiles in sync. Alternating between `bun install` and `npm ci` means installing from two independent resolutions.

What argues against a full switch is concrete:

- **Eleventy does not document Bun anywhere.** Its runtime page names Node.js 18+ and says "Eleventy runs great on Deno"; Bun does not appear. Conversely, Bun's ecosystem guides list Astro, Next, Nuxt, Vite and SvelteKit — but not Eleventy. That is not an exclusion, but it is not a commitment either.
- **`node --test` is shaky.** Bun passes only 28 of 81 tests in Node's own `test_runner` suite. If your tests run through `node --test` like mine do, you are outside the safe zone.
- **Bun is not 100 % Node-compatible**, and says so itself. `node:sea` is missing entirely, `node:cluster` distributes HTTP load only on Linux, `node:worker_threads` ignores `resourceLimits`, and `bun:ffi` is explicitly experimental.
- **`module.register` is a no-op.** ESM loader hooks simply do not take effect under Bun — silently, without an error. `registerHooks`, by contrast, is missing entirely and throws. The silent no-op is the nastier failure mode.
- **Hosting is patchier than Bun presents it.** Vercel has supported the Bun runtime as a public beta since October 2025, Netlify detects a Bun lockfile — but Railway's own docs say "Railpack does not yet detect Bun projects automatically".

I deliberately did **not** install Bun on my working machine for this article. Everything above comes from primary sources; where I write "that works", I mean "that is documented", not "I ran it in my repository".

## Security: the part that occupies me most

I have [written at length about my setup against supply chain attacks](https://www.jpkc.com/db/en/blog/nodejs-npm-absichern/) — Socket Firewall in front of every package fetch, `ignore-scripts=true`, exact pins, `npm ci` instead of `npm install`. How does Bun do in that discipline?

**Better than npm, worse than the marketing.** The docs say: "Because running arbitrary code is a security risk, Bun does not execute arbitrary lifecycle scripts by default." The catch hides in the word "arbitrary". Bun ships a built-in allow list — `src/install/default-trusted-dependencies.txt`, currently **exactly 367 package names**, including `sharp`, `esbuild`, `node-sass`, `puppeteer` and `electron`. For those, `preinstall`, `install` and `postinstall` run without asking.

There is a real case that shows how this goes wrong: **`mbt` is on that list** — because of its legitimate `install` hook. And `mbt@1.2.48` was one of the four compromised SAP packages on 29 April 2026; the attack ran through an additionally injected `preinstall` hook. A default `bun install` would have executed that payload. The `ignore-scripts=true` in my `.npmrc` would have blocked it.

Two configuration details that are easy to miss and both matter:

1. **`trustedDependencies` replaces the default list, it does not extend it.** Setting `trustedDependencies: ["sharp"]` withdraws trust from the other 366 entries. That is usually what you want — but only if you know it. The clean opt-out without a permanent flag is `trustedDependencies: []`.
2. **Bun reads your existing `.npmrc`**, including `ignore-scripts=true` and `save-exact=true`. Your existing hardening keeps working.

Comparing defaults, npm comes last, Bun sits in the middle and pnpm leads: pnpm 10 disables `postinstall` in dependencies entirely, pnpm 11 adds a 1440-minute quarantine for fresh packages. Bun has had `minimumReleaseAge` since 1.3, but the default is `null` — off. Careful when comparing: Bun counts in **seconds**, pnpm in **minutes**.

Two things worth flagging because they appear in no overview:

**`bun audit` fails silently.** Measured on Bun 1.4.0: `bun audit --severity=critical` produces no error and changes nothing about the result — and neither does `bun audit --severity=bogusvalue`. The same goes for `bun audit --ignore <CVE>`. Both forms appear in official Bun release notes, while the current CLI documentation requires `--audit-level` and states explicitly that CVE IDs do not match. Copy one of those lines from the docs into a CI pipeline and you get a green-looking run with no filtering whatsoever.

**And the bitterest finding for a Bun article:** in 2025 and 2026 Bun has turned up three times as a *tool of the attackers*. In Shai-Hulud 2.0 (November 2025, 796 compromised packages) the worm injected `setup_bun.js` and `bun_environment.js` through a `preinstall` hook — Datadog's analysis states the purpose plainly: "Install the Bun JavaScript runtime, likely to evade standard Node.js monitoring, and use it to run an obfuscated payload." Same pattern in the SAP wave of April 2026 and the keyv attack of August 2026. A runtime that starts faster and draws less attention than Node is an advantage for the other side too.

On Socket Firewall, the tool in my own setup: the README lists npm, yarn, pnpm, pip, uv and cargo — Bun is not among them, and the corresponding issue was closed without a documented implementation. Concluding that `sfw` does not protect Bun would be wrong, though: in testing, Bun 1.4.0 respects `HTTPS_PROXY` and accepts Socket Firewall's MITM CA (either `NODE_EXTRA_CA_CERTS` or `SSL_CERT_FILE` is enough), and without the CA the install aborts precisely at the firewall boundary. The honest phrasing: it works, it is just not promised.

Finally, an inconvenience I do not want to leave out. Bun's official installation path is `curl -fsSL https://bun.com/install | bash` — an unverified shell pipe from a website, in an article that otherwise routes every package fetch through a firewall. At least the version can be pinned: `bash -s "bun-v1.4.0"`.

## What worries me

Three strands, of unequal strength.

**The team.** One of the five promises has come under pressure. RedMonk measured in June 2026 that of roughly seven identifiable Oven employees before the acquisition, at least four no longer contribute; another active committer went from 745 commits to one. Note how carefully the source itself puts it: "The team, on the other hand, *appears* to have gone its separate ways" — and explicitly: "There are many potential reasons for this mini diaspora, and they may have little if anything to do with the project, AI, the acquisition or any of the above." Neither Anthropic nor Bun has ever published headcount figures. "Anthropic broke up the team" has no basis whatsoever.

**Authorship.** Over 80 per cent bot commits sounds dramatic, and the causality is almost always told wrong. Per RedMonk the tipping point came **in August 2025** — four months *before* the acquisition. Sumner confirms it: "We haven't been typing code ourselves for many months now. Even pre-acquisition this was pretty much accurate." What is genuinely coupled to the acquisition in time is something else: the collapse in **external** contributions. The bot `robobun` is today the second-largest contributor with 2,587 commits — behind Jarred Sumner with over 8,500.

**Governance.** This is the point I find most defensible, because it needs no speculation at all. Bun has no foundation, no neutral governance model, no trademark arrangement and no fallback commitment should Anthropic change direction. The repository still sits under `oven-sh`, and the copyright now reads "© 2026 Anthropic, PBC". For comparison: with VoidZero, Cloudflare additionally pledged one million dollars for a Vite fund independent of both Cloudflare *and* VoidZero. RedMonk's core sentence gets it right: companies bet on foundation software not because it is built faster, but because it is not owned by a single vendor.

Five documented acquisitions serve as reference cases, and their range is precisely the point:

| Case | What happened |
|---|---|
| npm → GitHub/Microsoft (2020) | Promises kept |
| MySQL → Oracle (2009/10) | MariaDB forked by the founder |
| Docker Desktop (2021) | Paid for large companies |
| Terraform → HashiCorp/IBM (2023–25) | MPL → BUSL, OpenTofu fork |
| Redis (2024/25) | BSD → SSPL, Valkey fork, later AGPLv3 as an additional option |

Everything from "nothing happened" to "licence change and schism" is represented. A Bun fork has so far neither happened nor become necessary.

## What argues against worrying

MIT stays MIT. The right to fork exists regardless of who owns the repository, and it is the actual insurance — Simon Willison boils it down to "fork and move on". In the same month it bought Bun, Anthropic handed MCP to a foundation; the company knows the difference. And the structural incentive is real and publicly verifiable: if Bun breaks, Claude Code breaks.

The most honest comment on this comes from the sceptics' camp. William Johnston, who has decided to move his own projects off Bun to pnpm, still writes: "Bun is not bad. Bun is excellent." And on Sumner's incentive argument: "In December, that sounded reassuring … I still think that argument has merit, but now cracks are showing." That is roughly how I would put it too.

## My conclusion

I went into this research with a surprise — "Claude Code is a Bun build?" — and came out with three findings that have nothing to do with the headline.

**First:** the proof was on my hard drive the whole time. An ELF section, a 16-byte trailer and an offsets struct whose arithmetic lands to the byte — 1,971 modules, 90.9 per cent of them precompiled JavaScriptCore bytecode. That is the kind of evidence I prefer to any press release, because you can reproduce it yourself.

**Second:** the most interesting number in this article is the one I almost got wrong. 17 milliseconds against 568 milliseconds — same binary, same process, factor 34. Both are correct measurements of two entirely different things, and the gap between them is the difference between a version query and a program start.

**Third:** the real story is not in the release post but in its construction. A runtime vendor rewrites half a million lines of systems code in eleven days, for 165,000 dollars in API costs, with adversarial review across separate context windows — and the creator of the language being replaced calls the result "unreviewed slop". Both sentences are true. What follows from that, I think nobody currently knows.

Concretely: Bun is not going into this site's build for now — `node --test` matters too much to me, and Eleventy says nothing at all about Bun. What I am noting down is `bun pm diff`: a command that shows you, before an update, which new install scripts and which new `child_process`, `fs` or `net` imports are about to arrive. That is exactly the question I ask myself at every dependency update, and I know of no npm equivalent.

And the runtime living inside my Claude Code binary is staying anyway. I just know where it sits now: from byte 87,101,440 onwards.

## Frequently asked questions

**Does Bun belong to Anthropic now?**
Yes. Announced on 2 December 2025. What was acquired is Oven, the company behind Bun. The price was never disclosed.

**Does Bun stay open source?**
Yes. Both sides committed to the MIT licence, and as of 31 August 2026 `LICENSE.md` still opens with "Bun itself is MIT-licensed". GitHub showing "NOASSERTION" is down to statically linked JavaScriptCore under LGPL-2, not a licence change.

**Is Claude Code really a Bun build?**
The binary carries the complete structure of a Bun standalone executable: a `.bun` ELF section, the `---- Bun! ----` trailer at its end, a matching offsets struct and 1,971 embedded modules. Sumner writes "Claude Code ships as a Bun executable", and Anthropic's changelog refers to "the bundled Bun runtime". That `bun build --compile` specifically is used is stated by no primary source — that is my inference from the structure.

**Do I need Node.js to run Claude Code?**
No. The binary starts without Node and without a PATH. The official docs state: "The installed `claude` binary does not itself invoke Node." The npm package ships the same native binary as the standalone installer.

**Is `bun install` safer than `npm install`?**
By default yes, but not completely. Bun runs lifecycle scripts only for packages on a built-in allow list of 367 names. That beats npm's default but loses to `ignore-scripts=true` or pnpm's behaviour — the `mbt` case from April 2026 shows exactly the gap.

**Can I use Bun only as a package manager and keep running Node?**
Yes. Per the docs `bun install` produces a Node-compatible `node_modules` directory "without using Bun's runtime", and `bun run` respects shebangs. You only force the Bun runtime with `--bun`.

**Does Eleventy run under Bun?**
I cannot tell you. Eleventy's runtime documentation names only Node.js 18+ and Deno, Bun's ecosystem guides do not mention Eleventy, and I have not tested it. Using it purely as a package manager is the path with the smallest attack surface.

**Is Bun 1.4 really five times faster at startup?**
Against Node.js 26 on Linux: yes, 5.1 versus 27.2 milliseconds. Against Bun 1.3.14: factor 2. Both numbers come from the same vendor table, and there is no independent measurement of Bun 1.4.

## Further reading

- [Configuring Claude Code properly](https://www.jpkc.com/db/en/blog/claude-code-konfiguration/) — what you do with the tool whose insides this article opens up.
- [Claude Code in a container](https://www.jpkc.com/db/en/blog/claude-code-container/) — isolation from the outside, for a runtime that brings none from within.
- [Working securely with Node.js and npm](https://www.jpkc.com/db/en/blog/nodejs-npm-absichern/) — the setup I measured Bun's defaults against here.
- [Who checks the checker? Adversarial factuality for AI texts](https://www.jpkc.com/db/en/blog/faktentreue-review/) — why the 17-millisecond figure did not make it into the introduction.
- [Why 11ty: six years static](https://www.jpkc.com/db/en/blog/warum-11ty/) — the stack Bun is not moving into for now.
- ["Bun is joining Anthropic"](https://bun.com/blog/bun-joins-anthropic) — Jarred Sumner's announcement of 2 December 2025, source of most quotes here.
- [Anthropic: "Anthropic acquires Bun"](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) — the other side, with the Krieger quote and the run-rate figure.
- ["Rewriting Bun in Rust"](https://bun.com/blog/bun-in-rust) — the full numbers on the eleven-day rewrite, including cost and disclosure.
- [Bun 1.4 release notes](https://bun.com/blog/bun-v1.4) — with version badges on every section; read them.
- [RedMonk: "What Bun Can Tell Us About AI, Open Source and Anthropic"](https://redmonk.com/sogrady/2026/06/04/bun-two-lessons/) — Stephen O'Grady's data-driven governance analysis.
- [The Register: Zig creator calls the rewrite "unreviewed slop"](https://www.theregister.com/devops/2026/07/14/zig-creator-calls-buns-claude-rust-rewrite-unreviewed-slop/5270743) — Andrew Kelley's criticism in full context.
- [The Register: "Anthropic's Bun Rust rewrite merged at speed of AI"](https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381) — the 14 May 2026 merge as it was reported.
- [DevClass: "Bun JavaScript runtime acquired by Anthropic"](https://www.devclass.com/ai-ml/2025/12/03/bun-javascript-runtime-acquired-by-anthropic-tying-its-future-to-ai-coding/1727637) — Tim Anderson flagged the Zig conflict on day one.
- [heise online: AI company Anthropic acquires Bun](https://www.heise.de/en/news/Open-source-toolkit-AI-company-Anthropic-acquires-Bun-11102416.html) — the German trade press coverage, English edition.