Fix open bun issues (#992, #861, #784, #764, #735, #635, #599, #578, #497, #443, #371)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

This fixes all 11 open pm:bun issues. None of them had a fix PR before this one. For each issue a regression test was written that fails on main, and real Bun releases (1.1.x–1.4.2, as each issue names) were used to check behavior. Every fix went through two independent reviews, and a completeness pass afterwards found gaps that the later commits close.

Per issue

#992: hosted revert writes "" into the registry slot. restore_bun_locks always wrote "". Bun releases before 1.3.7 read that as npmjs and ignore bunfig, so custom-registry projects broke. Restores now write the project registry's tarball URL, resolved in Bun's own order:

• scope, then bunfig [install] registry, then .npmrc, then env, skipping keys that aren't http(s) URLs;
• "" stays only for npmjs and its aliases;
• the registry's credentials (token or basic auth) are sent, so private scoped registries work;
• userinfo in a registry URL (e.g. https://u:${TOKEN}@host/) is moved onto the request's Authorization header and stripped from the base, so it never reaches bun.lock/bun.lockb or warnings (security review finding on aa03736, fixed in 1305ecb; test bun_registry_userinfo_goes_on_the_request_not_the_base).

Covered end to end for rollback, remove, takeover followed by vendor --revert, and scoped registries.

#861: duplicate bun.lockb records point at one vendored tarball, causing EEXIST. On a vendored re-run, a late nested registry duplicate is now folded into the vendored record the way Bun's own hoister places it. The hoister port follows Bun's Tree.zig/Tree.rs, including unresolved optional peers like ws's bufferutil. Where the fold can't be modeled safely, the run warns with vendor_bun_lockb_duplicate_records. Covered by 16 real-Bun 1.3.9/1.4.2 fixtures and a Bun-gated e2e test.

#784: vendored bun.lockb migrated to bun.lock. Revert and rollback now restore the migrated text lock. A superseding re-vendor keeps the pre-vendor original. A same-uuid re-pin, which leaves an entry with both binary- and text-lock records, reverts cleanly. Covered by a real-Bun e2e test for migrate, then re-run/repair, then supersede, then revert.

#764: the hoisted linker keeps patched bytes after a revert. Bun doesn't re-extract a package when its lock entry moves back to the registry copy of the same name@version. Rollback and vendor --revert now emit vendor_bun_reinstall_required / redirect_bun_reinstall_required, which name bun install --force. The advisory is emitted only when an entry was actually restored, and is deduplicated across legs. The GC path forwards only the two reinstall advisories. A --dry-run preview gives the same advisory, so its reinstall note names bun install --force too (Bugbot finding on 5f75908, fixed in 8ddcb3f).

#735: a dangling bun.lock symlink. One stat-based predicate decides which lock is live. Only ENOENT falls back to bun.lockb, matching Bun; ELOOP, ENOTDIR and EACCES keep the text lock shadowing. Since main's #1050 moved the vendored in-use check into discovery, the GC's in-use verdict reaches this predicate through Bun discovery (bun_text_lock_drives). The #735 GC regression test now runs through Discovery::vendor_entry_in_use.

#635: Bun's global store (install.globalStore). Agent apply and rollback now refuse copies in the global store, because those are shared with other projects. The crawl follows the store's links, and vex judges the store copy. Apply's note says why.

#599: isolated linker with orphaned node_modules/.bun entries. Liveness is now judged by what is actually linked: importers, .bun/node_modules, workspace members from bun.lock and package.json, and links through the global store. This filter applies only to the scan and to vex. Apply, rollback and remove can still reach a patched orphan.

#578: perf regression on bun/hosted. The cheap spec match now runs before is_bundled_entry's JSON parse, in rewrite_bun_lock, classify_rewritable and bundled_matches. Bench, same machine, paired, 25 pairs:

scenario	main	this PR	Δ
bun/hosted	165.5 ms	119.1 ms	−28.2% [−30.0, −26.2]
bun/rescan	164.5 ms	116.4 ms	−28.3% [−31.2, −27.1]

That is within about 5% of cbf1f748, the commit before #472. Requests are unchanged at 127.

#497: URL, file:, git and folder copies. Hosted and vendored runs warn (redirect_bun_non_registry_entry_skipped / vendor_non_registry_entry_skipped), and vex no longer attests while such a copy of the package is in the lock. That covers bun.lock and bun.lockb, including copies whose version the lock doesn't record (pkg.tgz, codeload, git), which vex withholds with patched_ref_unattributable.

#443: relocated Bun global dirs. The global dir now comes from bun pm ls -g, not <bin>/... If that fails, it falls back to Bun's own env order (BUN_INSTALL_GLOBAL_DIR, BUN_INSTALL, XDG_CACHE_HOME, HOME). When the dir can't be determined, the run warns instead of dropping it silently. bunfig globalDir is deliberately not honored, because real Bun 1.4.2 ignores it.

#371: default trust is dropped after a rewire. Hosted and vendored rewires of a package on Bun's built-in default-trusted list now warn (*_default_trust_lost). Adding the package to trustedDependencies automatically would grant trust the user never gave. The warning isn't gated on the Bun version, because nothing in a project reliably pins the Bun that installs it: 1.3.9 and 1.4.2 ignore packageManager, engines.bun and .bun-version.

Merge with main (e647108)

main's #1050 (one discovery verdict for vendored liveness) and #1045 (PurlKey) conflicted with this branch. The branch's npm_flavor::vendored_entry_in_use was dropped in favor of main's Discovery::vendor_entry_in_use. The #735 test was kept and pointed at the new API, using a purl-matched minimist entry. The Bun reinstall dedupe in vendor.rs now keys on PurlKey. Local results on e647108:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: 237 test binaries pass. 13 tests fail only because of the sandbox. 12 of them need a read-only directory to block writes, and the sandbox runs as root, which bypasses that (e.g. covgap_commands_vendor::*_state_write_failure_*, copy_tree::relax_loop_must_not_traverse_symlinked_root). The other one, pipenv_hosted_to_vendored_names_the_unpatched_requirements, needs live pypi.org. None of them touch Bun or the merged code.
• cargo fmt --check reports diffs only in files this branch and the merge don't touch. Those come from main, and CI has no fmt gate.

Known limits / follow-ups

• Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992 follow-up: Bugbot found on 1305ecb that a bunfig token-only scope ([install.scopes] x = { token = ... }) with no default registry configured dropped its token on the npmjs read. The fix is f956e6e on agent/fix-bun-scope-token-npmjs; it could not be pushed here because this PR's branch is locked in the merge queue. It lands as a follow-up PR after this merges.
• Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497: for an unversioned copy (no version recorded), scan still rewires the registry copy without a warning. Only vex withholds the attestation.
• Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992: only the Bun restorers send registry credentials. Project-registry reads for npm, pnpm, yarn berry and vlt are still anonymous, as they are on main.
• Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861: when the patched record's optional peer is also resolved under the same name elsewhere, the hoister port declines the fold and only warns.
• Bun compat harness: rollback cells now follow the After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 advice (plain bun install, then --force) and check the original bytes come back. On Bun 1.3.0 only (1.3.1 fixed it), Bun leaves its hidden hoist link node_modules/.bun/node_modules/minimist on the superseded patched store entry even after --force. When that link is the only patched copy left, the cell records it under upstreamLimitations. A connection reset on the harness's own fetches now gets a fresh-cell retry.
• With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635: bun_global_store_transitive_dep_apply_is_refused skips itself without Bun, and no CI job that runs it installs Bun. The same gap exists on main.
• CI: Audit GitHub Actions began failing on every PR at ~07:59Z after upstream setup-php moved its v2 tag. The one-line fix is Label the setup-php pin in ci.yml with its real tag #1118, ported here as 98f7e5e (it no-ops once main has it).
• CI: composer 2.10.3 / php 8.5 / macos-latest fails on main too: setup-php can't install PHP 8.5 on the runner. It isn't a required check.
• CI: sbt 1.3.13 / jdk 8 / agent failed on e647108's first attempt in agent_sbt_versions_patch_in_place. That test also fails intermittently on main (e2d9633, sbt 1.13.0 / jdk 17 / agent), and this branch changes no sbt or JVM files. The one re-run passed.

Fixes #992
Fixes #861
Fixes #784
Fixes #764
Fixes #735
Fixes #635
Fixes #599
Fixes #578
Fixes #497
Fixes #443
Fixes #371

Scan performance (fd75f30)

scan performance failed on 3a45799: bun-isolated/rescan +10.2% wall (bun-isolated/hosted +8.4%). The cost was the #599 orphan walk over node_modules/.bun. strace -c shows the same syscalls as the base, so the reads were not the problem. The time went to two other things:

• The walk tracked entries by name, hashing and cloning an OsString per entry several times. It now tracks them by index into the store's entry list.
• It ran one parallel pass per link-graph frontier, plus one more for the scan. Each pass wakes and parks the walk pool for little work (about +12 ms user+sys). The quick walk now reads every entry's listing in one pass, the same reads the scan always made, and follows links in memory. The scan reuses those listings without another pass.

What counts as live is unchanged, and the full re-walk is unchanged. Measured locally against the PR base on the bench fixture: 579M -> 556M instructions (base 524M). The paired socket-patch-bench compare -f '^bun' now gives bun-isolated/hosted +6.3% and /rescan +8.7% wall, +5% CPU (it was +11-14%). Tests: cargo clippy --workspace --all-features -D warnings is clean. cargo test -p socket-patch-core --lib gives 5885 passed and 4 failed; the 4 are permission tests that fail the same way without this change when run as root. The CLI bun suites (e2e_bun_lockb, mode_migration_bun, in_process_vendor_bun_takeover, vendor_eject_bun_lockb) give 100 passed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NfrapG9DFf76Fy96mocdRS

---

Note

High Risk
Changes Bun lockfile rewrite/restore, registry credential handling, and post-revert install behavior across many Bun versions—mistakes can break installs or leave unpatched copies in node_modules.

Overview
This PR closes a batch of Bun edge cases around hosted/vendored lock rewrites, upstream restore, and what still runs in node_modules after unwind.

Lock restore & registry semantics (#992, #784): Restoring bun.lock / bun.lockb to upstream no longer always writes "" in the registry slot—it follows Bun’s configured registry and tarball URL (with credential handling kept off the lock bytes). Contract and failure text now tell users to run bun install --force after revert when the hoisted linker would keep patched bytes (#764).

bun.lockb vendoring (#861, #784): Duplicate binary records for the same name@version can be folded via Bun’s hoister when safe; otherwise vendor_bun_lockb_duplicate_records. Migrated text locks participate in revert/rollback paths.

Discovery, apply, and attest (#497, #371, #635, #599, #735, #443): User URL/file:/git copies are skipped or warned and withheld from VEX; default-trusted packages warn after rewire; global-store layouts are refused on agent apply with a clearer note; isolated-linker liveness and dangling bun.lock symlinks are handled; global install dir resolution uses bun pm ls -g with fallbacks.

CLI polish: Rollback/GC/hosted unwind emit redirect_bun_reinstall_required / vendor_bun_reinstall_required and qualify generic reinstall notes; hosted “missing entry” hints ignore redirect_bun_default_trust_lost. CI adds Bun 1.3.14 / 1.4.2 e2e filters; fixtures get .gitattributes for byte-exact Bun locks.

^{Reviewed by Cursor Bugbot for commit fd75f30. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

On 111b849, scan performance is red: bun-isolated/hosted came in at +12.0% wall and bun-isolated/rescan at +13.4%, with CPU up about 10%. Every other scenario, including plain bun, is within noise. This is this PR's own regression. The benchmark passed on 46a0dd1 and is red against the current main.

I reproduced it locally and profiled it with callgrind on the bun-isolated/hosted fixture:

build	instructions
main	669.5M
111b849	768.7M (+15%)
3a45799	728.4M (+8.8%)

The extra cost came from three places:

• With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 store-liveness walk (live_bun_store_entries_sync): about 47M instructions.
• Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 user-tarball check: called about 180k times, once per patch × lock entry.
• On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371 loses_default_trust: called 22k times, scanning the whole default trusted list on each call.

3a45799 trims all three: cheap checks run first, the trusted list is built once as a set, and the walk now looks up guessed targets without allocating or cloning. That cuts about 40M instructions. Locally the gate is still red on wall time, at +11–15%. The rest is the #599 walk's frontier-by-frontier .bun traversal: the scan's store listing now waits on several parallel rounds instead of one.

Getting under +10% needs a design call on #599, so I've asked the owner. The options are: skip the walk when every .bun entry is listed in bun.lock (orphans are by definition absent from the lock), restructure the walk into a single parallel pass, or apply performance-regression-accepted.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit fd75f30. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Needs a maintainer decision (burn-down agent, head fd75f30d). CI is green (453 success, 15 skipped) and every other review thread is resolved. One thing blocks the label: the open Bugbot security thread on crates/socket-patch-core/src/patch/redirect/upstream/npm.rs:1156.

Question: when the Bun hosted restore (rollback / remove / vendor, dry runs included) reads bunfig.toml / .npmrc, which $VAR references may it expand into the registry credentials it sends?

1. None: send only literal tokens. Safest; private registries configured with $NPM_TOKEN fall back to the anonymous read main does today, with an upstream_registry_fallback warning.
2. An allowlist of conventional token variables (NPM_TOKEN, NODE_AUTH_TOKEN, BUN_AUTH_TOKEN). This blocks $GITHUB_TOKEN and other arbitrary secrets and keeps the common setups working.
3. Full Bun parity, as the PR does now, documented.

Whichever you pick, an expanded value that ends up in the registry URL's path or query still has to be stripped from the upstream_registry_fallback warning and from the tarball URL written to the lock. The next agent run will do that together with the option you choose. Reply with 1, 2 or 3 on this PR.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[burn-down] Merged main (f3c6313) into this branch as 274c478 to clear the conflicts with #1008. #1008 moved npm-family vendoring into vendor_npm_family, so this PR's Bun additions now sit in the backends:

• the default-trust warning (On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371) and the vendor_non_registry_entry_skipped warnings (Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497) in BunTextBackend::preflight and BunBinaryBackend::preflight;
• the bun.lockb duplicate-record folding (Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861) in BunBinaryBackend::wire.

CLI_CONTRACT.md keeps both sides' rows. Main's #920 rerun test moved back into rebuild_tests, where its fixtures live.

Checked locally: cargo check (core + cli, all targets) is clean. Core lib tests: vendor::bun 140/140, and 5939 of 5943 overall. The 4 failures are chmod-based tests that can't pass when run as root, outside the Bun code. CLI Bun suites are all green: e2e_bun_lockb, in_process_vendor, in_process_vendor_bun_takeover, mode_migration_bun and vendor_eject_bun_lockb.

agent:needs-human stays on: the security thread at npm.rs:1156 still needs option 1, 2 or 3.

bugbot run

---

Generated by Claude Code