What version of Bun is running?

1.3.13 (bf2e2ce) on macOS (Darwin 25.4.0)

What is the problem?

minimumReleaseAge in bunfig.toml is only checked during dependency resolution. If a version is already pinned in bun.lock, both bun install and bun install --frozen-lockfile install it without enforcing the cooldown, even when that locked version was published well within the configured window.

This means the cooldown does not protect against the very scenario it's marketed for: a poisoned version that has already landed in the lockfile (e.g., committed by a developer whose local bunfig was less strict, or pulled in before the cooldown was added).

Reproduction

mkdir bun-minage-bypass && cd bun-minage-bypass

cat > package.json <<'JSON'
{ "name": "minage-bypass", "private": true, "dependencies": { "is-odd": "3.0.1" } }
JSON

# 1. Install with no cooldown to populate bun.lock
bun install

# 2. Add a cooldown that the locked version should violate.
#    is-odd@3.0.1 was published in 2017; a 10-year cooldown means
#    "only install versions >= 10 years old" — 3.0.1 is younger than that.
cat > bunfig.toml <<'TOML'
[install]
minimumReleaseAge = 315360000
TOML

# 3. Reinstall — cooldown should reject is-odd@3.0.1
rm -rf node_modules
bun install                      # → installs 3.0.1, exit 0
bun install --frozen-lockfile    # → installs 3.0.1, exit 0

Expected behavior

bun install (and especially bun install --frozen-lockfile) should fail or warn when a version in the lockfile violates minimumReleaseAge. Otherwise the setting is only a barrier at the moment a new dependency is added — not a durable guarantee about what gets installed in CI.

Actual behavior

The cooldown is silently ignored. The package installs with exit 0 in both modes.

Why this matters

This is the same flaw class as pnpm/pnpm#10438, filed in the wake of the May 2026 Mini Shai-Hulud TanStack compromise. The cooldown is widely understood as supply-chain protection — defenders adding it after the fact (e.g., in response to a published advisory) reasonably expect it to gate every `bun install`, not just net-new resolutions.

The current behavior also asymmetrically penalizes the disciplined case: a team that adds `minimumReleaseAge` after an incident is no safer than one that doesn't, because any already-resolved bad version remains installable.

Possible fixes

• Enforce the cooldown at install-from-lockfile time, not only during resolution.
• Or add a `--resolution-only`-style mode (like pnpm has) that forces re-resolution so the cooldown actually runs.
• Or at minimum emit a warning when a locked version violates the configured cooldown.