runtime: Bun 1.4 preview-dev product candidate stack

[lidge-jun]

Area

Multiple areas

What are you trying to accomplish?

Ship a production-ready Bun 1.4 candidate stack on preview-dev so that when Bun 1.4.0 reaches npm, the stable promotion is a single dependency bump — all compatibility patches, CI qualification, and memory/stream/worker improvements are already landed and verified.

What prevents this today?

• Bun 1.4.0 canary is not yet published on npm (latest canary: 1.3.13-canary.20260425.1, latest stable: 1.3.14)
• CI hardcoded bun-version: 1.3.14 in 11 places — resolved in c7c34f6 via composite action
• preview-dev was not a CI-qualified branch — resolved in c7c34f6
• Stream caps, Worker lifecycle, and fetch paths need runtime-gated Bun 1.4 optimizations

What should OpenCodex do?

When a Bun 1.4 canary becomes available on npm, implement the following commit train on preview-dev:

Commit train (blocked on upstream Bun 1.4 canary)

#	Commit	Status
1	ci(runtime): source Bun version from package.json and qualify preview-dev	✅ Done (c7c34f6)
2	chore(runtime): bundle Bun 1.4.0-canary.N on preview-dev	⏳ Blocked — no canary on npm
3	test(runtime): record bundled Bun version and revision across package smokes	⏳ Depends on #2
4	test(memory): add 1.3.14 versus 1.4 wave and quiescence harness	⏳ Depends on #2
5	perf(stream): enable eager relay for qualified Bun canary revisions	⏳ Depends on #2
6	perf(stream): use an exact byte queue and global relay budget	⏳ Depends on #5
7	fix(fetch): cancel unconsumed response bodies on retry and failure	⏳ Depends on #2
8	perf(worker): skip Bun 1.3.14 OS join settles on qualified Bun 1.4	⏳ Depends on #2
9	test(runtime): prove Bun 1.4 isolate teardown without legacy job splits	⏳ Depends on #8
10	docs(release): document Bun 1.4 preview-dev promotion and rollback	⏳ Depends on all
D-day	chore(runtime): promote bundled Bun from canary to 1.4.0	⏳ After npm release

Example usage or interface

Stable-day promotion sequence:

preview-dev → dev → preview → main

Day-of changes limited to:

- "bun": "1.4.0-canary.N"
+ "bun": "1.4.0"
- MIN_FIXED_BUN_VERSION: null
+ MIN_FIXED_BUN_VERSION: "1.4.0"

Alternatives or workarounds

Wait for Bun 1.4.0 stable and scramble on release day — riskier because stream/worker/fetch patches would be untested on the new runtime.

Additional context

• Roadmap docs: devlog/_plan/260814_bun14-preview-dev/ (000-100 decade docs with diff-level precision)
• CI composite action already landed: .github/actions/setup-project-bun/action.yml
• Branch: preview-dev (fast-forward from dev, now CI-qualified)
• Key files to patch: src/lib/bun-stream-caps.ts, src/server/relay-eager.ts, src/storage/worker-lifecycle.ts, fetch error paths across src/oauth/, src/providers/, src/adapters/
• Rollback devices to preserve until stable 1.4 first release: OPENCODEX_BUN_PATH, streamMode=legacy-tee, Worker settle fallback, split fresh-process CI jobs

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[coderabbitai]

🔗 Related PRs

#350 - fix(responses): reconstruct dropped SSE output items + dedupe replayed multi-agent guidance (#334, #326) [merged]
#375 - [WRONG BRANCH] fix(cursor): estimate context after restart [closed]
#734 - fix(launcher): honor OPENCODEX_BUN_PATH [open]
#887 - fix(windows): settle scheduler verification and record Bun runtime provenance [open]
#947 - fix(streaming): prevent Darwin rewrite stalls [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lidge-jun]

Branch README landed: d29b837e3.

devlog/_plan/260814_bun14-preview-dev/README.md is now the entry point for this track. It carries the current blocker, the resume procedure, branch invariants, the release-day diff, and the rollback devices.

Landed on preview-dev (3 commits ahead of dev)

commit	what
c7c34f6e3	CI sources the Bun version from package.json; preview-dev added to push triggers
f8f9200d4	plan unit — decade docs 010–100
d29b837e3	branch README + upstream track pointer

Still blocked upstream. No Bun 1.4 canary exists on npm:

$ npm view bun dist-tags --json
{ "latest": "1.3.14", "canary": "1.3.13-canary.20260425.1" }

Why the runtime patches are not committed

Commits 5 (perf(stream)) and 8 (perf(worker)) branch on a verified Bun.revision, not a version string — that is the whole point of the canary gate. With no published canary there is no revision to qualify, so committing them now would add branches that can never evaluate true and would tempt someone to open the gate on a semver alone. They stay as diff-level specs in the decade docs.

Resume trigger

npm view bun versions --json | grep 1.4.0-canary

Once that returns a version, rebase preview-dev onto dev and start at 020_bundle_canary.md. 020 records the qualified revision that 050 and 080 depend on, so it must land first.

[lidge-jun]

The blocker was wrong, and it was mine.

npm has no Bun 1.4 line, but GitHub does — oven-sh/bun publishes a rolling canary release with 34 platform assets, and it is already there:

$ gh release download canary --repo oven-sh/bun --pattern bun-darwin-aarch64.zip
$ ./bun-darwin-aarch64/bun --revision
1.4.0-canary.1+032b8dbf1

So this track is unblocked. Qualification runs against the GitHub asset through the OPENCODEX_BUN_PATH override that already existed; package.json stays at 1.3.14 because that is what users install. npm is the destination on stable day, not the prerequisite.

Landed

commit	what
bce1fe8f4	canary fetch script, qualified-bun.json, composite-action channel input, bun-canary-qualify CI lane
5e34feebe	README corrected
7bab92781	workflow hardening test taught the new CI shape

Three things the build found

1. SHASUMS256.txt cannot gate the download. The manifest lags the rolling assets — asset re-uploaded 2026-08-14T11:52:50Z, manifest still from 2026-08-13T14:30:31Z, digest mismatched a correct download. A hard SHA gate would have failed every run. Two independent downloads agreed with each other, so the assets are stable per-moment and the manifest is the stale artifact. shasumsMatch is recorded and warned on, never fatal; Bun.revision plus a green CI run is the real pin.

2. run-bun-test-batches.sh called bun from PATH. The lane would have exported the override and then qualified the bundled stable runtime anyway — a qualification that never happened. Fixed to honor OPENCODEX_BUN_PATH.

3. The first canary CI run failed, and Bun 1.4 was innocent. tests/ci-workflows.test.ts reported 3 failures and a runtime crash. The same three fail identically on stable 1.3.14: earlier commits on this branch moved the pinned setup-bun SHA into the composite action, added a job, and added a branch, and the hardening test still described the old shape. Now 132 pass / 0 fail on both runtimes, including under --isolate.

Still not promoted

qualifiedRevisions in scripts/runtime/qualified-bun.json is empty, deliberately. Having the binary is not qualification. When bun-canary-qualify is green across the supported platforms, adding that revision in its own commit is the single edit that opens the revision-gated work in 050 (stream caps) and 080 (worker settle).

[lidge-jun]

Both runtimes now agree, and the CI lane is green.

Full suite, dedicated machine

Verification moved off a shared laptop onto a Mac mini (macOS 15.7.4, arm64, 10 cores) so a stall could not be confused with contention:

runtime	result	time
1.4.0-canary.1+032b8dbf1	11712 pass / 8 skip / 0 fail across 726 files	422s
1.3.14 (control)	11712 pass / 8 skip / 0 fail across 726 files	462s

Identical counts, identical file coverage. Typecheck clean on both.

Linux CI: run 31804645454 — bun-canary-qualify success, every sibling job success. The previous run failed on the exact defect the TOML fix repairs, so the red-to-green transition is attributable rather than incidental.

Two more differences found since the last comment

Bun 1.4 passes an empty PATH through to children. 1.3.14 ignored PATH="" and handed the child the parent PATH, so three tests that blanked PATH to stop codex discovery were also silently keeping dirname and cat reachable for their /bin/sh fake launchers. Fixed with a named /usr/bin:/bin constant. Production is unaffected — nothing in src/, bin/, or scripts/ blanks PATH, and the generated unix shim uses shell builtins only.

Bun 1.4 enforces "a value must begin on its assignment line" — and this one found a real bug rather than a stale test. multiAgentV2EnabledFromConfigText parses first and falls back to a line-based scanner when the parse fails. On 1.3.14 the parse always succeeded for hint = with the array on the next line, so the fallback never ran for that shape. On 1.4 it does, and tomlTableBody reads the [ as a table header, truncating before enabled = true — reporting a feature the user enabled as disabled. That is precisely what the function comment warns against: a parse failure presented as a state.

The scanner stays untouched; its own comment records that making it string-aware previously broke three other readers, and twenty call sites consume it. The repair is at the call site: if the parse fails, join dangling key = lines and parse once more. The unmodified document is always tried first, so a bad join cannot displace a correct read.

Commits

7bab92781 workflow hardening test · 4e64e96f7 TOML datetime contract · be06958d7 PATH inheritance · 0e4cadc42 the features.ts fix · a392a9e0a results recorded

Still not promoted

qualifiedRevisions remains empty. Green on macOS and Linux is not qualification everywhere — Windows is where the 1.3.14 Worker and isolate problems actually lived, and the canary lane is ubuntu-latest only. A green functional suite also says nothing about the memory behaviour this migration exists for; that needs the harness in 040.

[Wibias]

Triage hierarchy

Treat this issue as the runtime roadmap parent for Bun-version qualification and runtime-dependent fixes.

Current child/symptom issues:

• [Bug][macOS] Bundled Bun 1.3.14 exits with SIGTRAP after connection reset and TLS verification failures #1419 — native Bun SIGTRAP/runtime failure symptom.
• [Bug] Streaming requests to opencode.ai hang with HTTP/2 SSE (200s timeout → 502/499, Codex stuck on 'thinking') #1668 — HTTP/2/SSE interoperability symptom, currently addressed by PR fix(server): add per-provider upstreamHttpVersion to pin Bun fetch HTTP version #1792.

These remain separate symptom issues because they have independent reproductions and can receive targeted mitigations before the broader Bun runtime program completes.