共有:

Rust Runtime, Pre-GA

Claude Code was already running on
a Bun v1.4.0 that doesn't officially exist yet

The Rust-rewritten next-gen Bun runtime was quietly embedded in Claude Code v2.1.181 before it ever got a tagged GitHub release. The runtime generation shift reached real machines before it reached the release notes.

AI Navigate Editorial2026.07.247 min read

2026.05.13 v1.3.14 tagged on GitHub (last Zig build) ~2026.05.17 Version bumped to 1.4.0 (still canary) Shipped ahead of the tag 2026.06.17 Claude Code v2.1.181 bundles Bun 1.4 2026.07.24 Still no official v1.4.0 tag
01
The Discovery

One changelog line quietly
swapped out the runtime

Barely anyone noticed. But it was a quiet generational shift.

The official CHANGELOG.md for Claude Code v2.1.181, shipped on June 17, 2026, buries a single line among other feature additions: "Upgraded the bundled Bun runtime to 1.4." Claude Code runs its internal JavaScript on Bun, and until this release it had stayed on the older, Zig-written generation of the runtime.

Yet checking Bun's own GitHub Releases page shows the latest tagged release is still v1.3.14 (published May 13, 2026), and the npm registry's `latest` tag also still points to v1.3.14. As of this writing (July 24, 2026), no v1.4.0 tag exists on GitHub at all. In other words, Claude Code shipped a pre-release Bun that developers themselves couldn't even fetch with `bun upgrade`, distributing it to millions of developer machines as part of a routine app update.

Bun v1.3.14 (old, Zig)Bun v1.4.0 (new, Rust)
Implemented in ZigImplementation rewritten entirely in Rust
Officially tagged and public on GitHubNo public tag yet — distributed only via Claude Code
Memory usage climbs with every repeated buildMemory usage levels off; leak pattern resolved
Relatively larger binary size~20% smaller on Linux/Windows
02
Under the Hood

535,000 lines of Zig,
ported to Rust in 11 days

What the Bun team's own blog post reveals about the scale of the rewrite and how it was checked.

BEFORE (v1.3.14) 535,496 lines Entire Zig codebase 64 Claudes run in a loop Ported in 11 days AFTER (v1.4.0) ~780,000 lines Entire Rust codebase Verify RISK ~4% of Rust code is unsafe Post-merge: 11 rounds of security review + 24/7 fuzzing
FIG. 535,496 lines of Zig were ported to Rust, then run through multiple layers of post-merge verification
128
bugs fixed that reproduced in v1.3.14
2–5%
faster in Bun's own benchmarks
~20%
smaller binary on Linux/Windows

The Bun team detailed the rewrite in its official blog post, "Rewriting Bun in Rust." Porting 535,496 lines of Zig to Rust was done by a single Anthropic engineer running "roughly 64 Claudes in a loop," finishing in just 11 days. The ported code passed 99.8% of Bun's own test suite, while roughly 4% of the resulting Rust codebase still sits inside `unsafe` blocks.

After merging, the code went through 11 rounds of security review from "Claude Code Security," the same vulnerability-scanning plugin that just landed in Claude Code as a beta feature, with findings addressed along the way. The team also added 24/7 coverage-guided fuzzing across its major parsers — JavaScript, TypeScript, CSS, YAML, and more — where Claude automatically opens a PR for bugs the fuzzer finds, and a human reviews it before merge.

03
Why It Matters

Why this matters right now

JS runtimes went C++ (Node.js) → Rust (Deno), and now Bun has joined the "fast runtimes are written in Rust" camp too.

Bun had built its identity around being fast because it was written in Zig. The fact that its own maintainers rewrote it in Rust isn't a minor internal refactor. Given that Node.js runs on C++/libuv and Deno was Rust from the start, Bun's move means every major JS runtime is now converging on Rust — memory safety enforced at the language level, without giving up speed, is becoming the default rather than the exception.

The other angle is who did the work. This wasn't a human team grinding through a migration — it was AI agents running in massive parallel, finishing in a fraction of the usual time. The pursuit of runtime speed was itself achieved through the speed of an AI-driven mass rewrite — a doubly symbolic moment.

Everyday Claude Code users

No action needed. With the internal Bun switched to the Rust build, builds and startup may feel a little snappier. On Linux, startup has reportedly gotten about 10% faster.

Engineers who run Bun directly

You've effectively been trying the Rust build indirectly through Claude Code before it ever got a tag. For production use, it's safer to wait until a v1.4.0 tag actually lands on GitHub.

CI / build-pipeline owners

If you run Claude Code on self-hosted CI, the internal runtime swap could shift build-time patterns. Taking a quick before/after benchmark makes any change easier to track down later.

This isn't a story that ends at "it's faster."
Code that's roughly 4% unsafe Rust
is already running on your machine.


04
What's Next

What happens next,
and what to watch for

In the short term, the next milestone is Bun actually tagging v1.4.0 on GitHub and npm. Once that happens, developers will finally be able to try the Rust build directly in their own projects, instead of only encountering it inside Claude Code. Three recommended actions: (1) casual users don't need to do anything — just take the Claude Code update as it comes. (2) if you run Bun in your own project, hold off on production adoption until the official tag lands. (3) if you care about build time or startup speed, take a quick before/after measurement around the update.

That said, this isn't a story for unqualified optimism. The port was finished in just 11 days by AI agents working in massive parallel, and roughly 4% of the resulting Rust code still sits inside `unsafe` blocks. Even with 11 rounds of security review and round-the-clock fuzzing layered on top, it remains unusual for pre-release code to already be running on developer machines worldwide. Teams that are sensitive to stability would be reasonable to wait and watch until an official GitHub tag appears.