chore: bump embedded Bun to 1.4.2

[AlexanderWillner]

Issue for this PR

Closes #44945

Type of change

• Refactor / code improvement

What does this PR do?

Bumps the pinned packageManager from bun@1.3.14 to bun@1.4.1 (2026-09-04 follow-up to the 1.4 Rust rewrite). That field drives CI via .github/actions/setup-bun, and bun build --compile embeds the running runtime into release binaries — so this one line is the whole runtime upgrade.

Rebased onto current dev: the Bun 1.4 prerequisite fixes are already merged via #44944, so this PR is now a single one-line commit with no code changes.

How did you verify your code works?

Measured on darwin-arm64, same tree and build flags (--single --skip-embed-web-ui --skip-install), one binary compiled per runtime, isolated data dirs for serve:

Metric	1.3.14	1.4.0	1.4.1
--version peak RSS (median, n=5)	177.5 MB	147.4 MB (-17 %)	137.3 MB (-23 %)
serve cold+idle RSS	~404–412 MB	~352–357 MB	~323–333 MB, very stable
serve cold start until listening	~0.6–0.8 s	~0.7 s	~0.5–0.8 s (no real difference)
packages/opencode suite (3573 tests)	296.8 s, 0 fail	249.4 s, 0 fail (-16 %)	239.1 s, 0 fail (-19 %)
packages/core suite (1097 tests)	29.4 s, 0 fail	26.6 s, 0 fail	25.7 s, 0 fail
Binary size (no embedded web UI)	107.7 MB	112.2 MB	110.5 MB

Notes:

• typecheck clean in both packages under 1.4.1.
• One PTY test (applies plugin shell environment) hangs in this sandbox under both 1.4.1 and 1.3.14, so it is a pre-existing environmental issue, not a 1.4 regression signal.
• TUI boot stopwatch numbers from [FEATURE]: Upgrade bundled Bun from 1.3.14 to 1.4.2 #44945 were not re-measured: the TUI stalls without TTY interaction, so there is no reliable headless measuring point.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[ataidecarlos]

Independent confirmation for this change: I rebuilt the official source with Bun 1.4.0 on Windows 11 ARM64 (native bun-windows-arm64 single-file build) and the Failed to initialize OpenTUI render library: bun:ffi dlopen() is not available in this build (TinyCC is disabled) error is gone — the TUI runs natively on ARM64. This PR is the right fix; the pin alone is what every native ARM64 build is missing.

[Riven-Spell]

Can confirm, works on arm64 windows now

[kvyb]

I measured the default TUI as an independent check of the runtime bump.

Environment: current dev at 10765ff2a, macOS 26.5.2 / M3 / 16 GB, empty Git repo, isolated HOME/XDG dirs, --pure, updates/model fetch disabled, 120x40 tmux, 20-second settle. I compiled the same source/dependency tree once with Bun 1.3.14 and once with 1.4.0. The binaries reported the expected embedded runtimes and returned byte-identical 5,747,400-byte /provider payloads. The TUI was a single OS process with no children, so footprint covered the full app.

Embedded Bun	Physical footprint, MB (5 runs)	Median
1.3.14	593, 707, 751, 713, 575	707 MB
1.4.0	525, 564, 550, 570, 553	553 MB

Launch order was counterbalanced AB/BA. Every pair favored 1.4.0; the median reduction was 154 MB / 21.8%.

I also checked this PR's head (f9c80c048) with Bun 1.4.0: packages/opencode 3,339 tests with 0 failures, packages/tui 194 tests with 0 failures, and opencode/core/tui typechecks passed.

Scope caveat: this measures one clean macOS idle point, not peak memory, long-session growth, active workloads, or other platforms.

[cmoralesc]

+1 on this PR — and one more reason to prioritize it: it fixes the TUI on native Windows ARM64.

The opencode-windows-arm64.zip releases don't work on that platform because they embed Bun 1.3.x, which disables bun:ffi, so OpenTUI fails to start with:

Failed to initialize OpenTUI render library: bun:ffi dlopen() is not available in this build (TinyCC is disabled)

(tracked in #19130 and #38520 — both still open)

Bun 1.4 rewrote bun:ffi natively into JavaScriptCore without TinyCC and it works on Windows ARM64 stable. Verified locally on a Windows 11 ARM64 machine: dlopen("kernel32.dll") + calls work with the official bun-windows-aarch64.zip 1.4.0, and running opencode from source (dev branch) with Bun 1.4.0 stable initializes OpenTUI correctly.

So this bump isn't just a performance win — it's what makes the Windows ARM64 build usable at all. 🙏

[kareldonk]

why is this taking so long

[kernel-oops]

Additional Linux evidence for Bun 1.4.2: an earlier controlled comparison on our custom OpenCode baseline measured CPU usage falling from roughly 62–68% to 5–6%. The runtime CPU benefit is attributable to the Bun GC timer fix (oven-sh/bun#35356), not the filesystem-cycle fix below. The operator now reports a few days of normal server and TUI use with excellent CPU usage and no noticed issues; this is user-reported soak on a custom build, not pristine-upstream or cross-platform validation.

We also found a compiled first-prompt failure with Bun 1.4.2. #48397 breaks the filesystem import cycle and includes a clean-upstream Linux compiled regression; it is now ready for review as a companion to this runtime upgrade.

[imarshallwidjaja]

+1 from our side, with a matching crash.

We run 1.18.30 (embedded Bun 1.3.14) on WSL2: opencode serve under a systemd user unit with Restart=on-failure. Three crashes in two days, each one:

panic(main thread): Bus error at address 0x767D80048ABE
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Systemd recorded status=4/ILL, and the kernel reported the trap at ip:2607064. That's the address the core dumps in #40219 were traced to, which points at the ByteStream use-after-free fixed in oven-sh/bun#31963. If the shared address holds up, the runtime bump is what fixes it.

Two things that might help triage. We only see this under serve, and memory looks ordinary at crash time (RSS 0.86GB, peak 3.22GB). There's also about 44s between the panic printing and systemd reaping the process, so the real outage runs longer than RestartSec suggests.

Caveat: our Sep 13 trap lines had rotated out of the journal, so the address match rests on one crash, and we haven't disassembled the binary to confirm the site.

#40812 shows the same pattern on serve with 1.3.14, so it isn't just us.

[boyingliu01]

Adding a Windows x64 (non-ARM) FFI-crash data point to the smoke-test gap called out in #44945 — that request specifically flags "Windows needs a smoke test: the fix referenced from #44513 is not visible in the 1.4.0 release notes." I can help close that.

The crash this bump fixes (evidence)

On 1.18.31 (embedded Bun 1.3.14), Windows 11 x64, I get the exact Zig::JSFFIFunction::trampoline segfault that oven-sh/bun#31941 traced to the TinyCC trampoline — the path removed by oven-sh/bun#35246, which ships in Bun 1.4.0:

Bun v1.3.14 (0d9b296) on windows x86_64_baseline [StandaloneExecutable]
Segmentation fault at address 0x20A3EC55A62
- *1 unknown/js code*
- JSFFIFunction.cpp:166: Zig::JSFFIFunction::trampoline
Features: spawn, standalone_executable, workers_spawned, napi_module_register,
          process_dlopen, fetch, http_server, jsc, shell

Crash report: https://bun.report/1.3.14/ea10d9b296m7Gz/339/D_is33sB_____A20gBkmt144B

Env: Windows 11 x64, CPU sse42 avx avx2 avx512, long TUI session (Elapsed: 1265442ms, Peak: 2.44GB, Faults: 1054253338), heavy spawn/fetch. File as opencode#31144.

What I can do for the smoke test

I have a reliable repro of the pre-fix crash on this machine, which is the piece that makes a before/after comparison meaningful:

• Windows 11 x64, baseline-capable CPU — this is the x64 path, complementing the ARM64 confirmations already in this thread (@ataidecarlos, @Riven-Spell, @cmoralesc)
• Long-session TUI with the win32 console-guard FFI polling active (packages/opencode/src/cli/cmd/tui/win32.ts → setInterval(enforce, 100) on kernel32.dll GetConsoleMode/SetConsoleMode)
• The guard polls ~10×/sec, so a few hours of normal TUI use reliably reaches the trampoline crash → a usable negative control on 1.3.14

If it's useful, I'm happy to:

1. Run a build of this PR's branch on Windows x64 for an extended session and report whether the JSFFIFunction::trampoline crash recurs (it should not, per Shell progress bars spam TUI output and context #35246), plus RSS/Faults over time.
2. Report the same metrics on current dev (Bun 1.3.14) as the baseline for comparison, so the before/after pair is on identical hardware.
3. Include a bun.report link for any crash that does occur, so it can be re-triaged if the signature changes from JSFFIFunction::trampoline to something else.

Just point me at the branch/tag to test (or confirm dev after merge) and I'll run it and post results here.

Independent of the FFI crash, this bump also looks worth it on the measured resource numbers alone (RSS / suite runtime) that @kvyb and @kernel-oops reported.