Bun version mismatch (packageManager / bun --version) in CI

The Bun on the runner is a different version than the one that generated your bun.lockb or that your packageManager field pins. Newer or older Bun can rewrite the lockfile, miss a feature, or reject a flag.

What this error means

CI installs a different Bun than local (bun --version differs), the lockfile shows an unexpected diff, or a command fails with "unknown option" that works on your machine.

Terminal

$ bun --version
1.0.25
error: unknown option '--frozen-lockfile'
# locally you run bun 1.1.34 where the flag exists

Common causes

setup-bun installs latest, not your version

Without a pinned bun-version, setup-bun grabs the newest release, which can differ from what your team runs locally and from what wrote the lockfile.

packageManager pins a Bun the runner ignores

A packageManager: "bun@x.y.z" field in package.json states intent, but nothing enforces it unless CI pins the same version explicitly.

How to fix it

Pin the exact Bun version in setup-bun

Read the Bun version from your packageManager field or .bun-version.
Set bun-version in setup-bun to that exact value.
Commit the pin so every job uses the same Bun.

.github/workflows/ci.yml

- uses: oven-sh/setup-bun@v2
  with:
    bun-version-file: .bun-version

Standardize the version everywhere

Keep the packageManager field, .bun-version, and CI pin in sync so local and CI resolve identically.

package.json

{
  "packageManager": "bun@1.1.34"
}

How to prevent it

Pin bun-version (or bun-version-file) in setup-bun, never rely on latest.
Keep packageManager and .bun-version aligned with the CI pin.
Bump the version in one place and let CI follow it.