GeezerVison

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Global mode asked `bun pm bin -g` for Bun's global bin dir and assumed
the packages sit at `<bin>/../install/global/node_modules`. Bun moves
its bin dir (BUN_INSTALL_BIN, bunfig globalBinDir) and its global dir
(BUN_INSTALL_GLOBAL_DIR) independently, so with either one set the
guessed dir did not exist, get_global_node_modules_paths dropped it
silently, and `scan -g` reported a clean, empty result while every Bun
global package stayed unpatched.

Ask Bun where the packages are instead: the first line of
`bun pm ls -g` is `<globalDir> node_modules (N[ installed])` on every
Bun from 1.0 to 1.4. When bun can't be asked (not on PATH, timed out,
unreadable answer), follow Bun's own openGlobalDir resolution from the
environment: BUN_INSTALL_GLOBAL_DIR, then $BUN_INSTALL/install/global,
then .bun/install/global under XDG_CACHE_HOME or the home dir.

Verified against real Bun 1.1.45, 1.2.23, 1.3.14 and 1.4.2 on macOS
with BUN_INSTALL_BIN and BUN_INSTALL_GLOBAL_DIR set: `scan -g` now
sends the globally installed package to the patch API in every cell.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Seven call sites each asked "is bun.lock the live lock?" with their own
presence check. The lock inventory, the vendored GC probe, the wired
integrity probe and VEX lockfile discovery used lstat, so a dangling
bun.lock symlink counted as present; hosted and vendored routing used
Path::exists, which follows links. Bun opens bun.lock through symlinks
and falls back to bun.lockb only when the open finds nothing: with Bun
1.2.23 and 1.3.14, `bun install --frozen-lockfile` installs from
bun.lockb beside a dangling bun.lock link. On that tree the inventory
returned no packages and no diagnostic, the GC probe never decided, and
VEX discovery saw no refs, while vendored and hosted mode wired
bun.lockb.

Add lock_inventory::bun_text_lock_drives (stat through links, over a
ProjectView) and bun_binary_lock_drives, and route the inventory, the
live-sibling fallback, wired_vendor_integrity, vendored_entry_in_use,
vendored routing and revert, bun_workspace, the hosted engine, CLI
repair's reference scan and VEX discovery through them. Remove
bun_text_lock_present{,_in} and hosted::engine::bun_lock_present.

A bun.lock directory is not treated like a dangling link: Bun opens it,
fails to read it and ignores both locks ("warn: Ignoring lockfile"), so
bun.lockb is not live. The text lock keeps winning there and its guarded
read refuses, which is what every path already did.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

bun_text_lock_drives counted any stat error on bun.lock as "absent",
so bun.lockb was picked as the live lock. Bun's loadFromDir falls back
to bun.lockb only when opening bun.lock fails with ENOENT. Any other
open error (ELOOP from a self-referencing link, ENOTDIR from a link
through a regular file, EACCES from a link into an unreadable
directory) makes Bun print "Ignoring lockfile" and install from
neither lock. Verified with Bun 1.3.14 in a scratch project: a
bun.lock -> bun.lock self-link plus bun.lockb gives "ELOOP: failed to
open lockfile" and a frozen-lockfile refusal, with nothing installed.
The inventory, the GC probe and VEX discovery therefore read refs
from a bun.lockb Bun would not install from. Before #735 these sites
used lstat, which chose the text lock here.

Only io::ErrorKind::NotFound now means absent. Every other error keeps
the text lock shadowing, and its guarded read then refuses or
diagnoses. A unix control test covers an ELOOP self-link and an
ENOTDIR link through a file. It fails on the previous predicate.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Hosted rollback, remove and the hosted -> vendored takeover rebuild a
bun.lock registry 4-tuple with an empty registry slot. Bun writes "" only
for a package from registry.npmjs.org and the full tarball URL for any
other registry, and Bun 1.1.39 through 1.3.6 read "" as npmjs whatever
bunfig.toml says. So on a project with a private registry or mirror the
restored lock fetched from npmjs on a cold frozen install: a 404 for a
private package, a silent bypass of the mirror for a public one. The
bun.lockb takeover restore had the same gap: it wrote the default
registry's dist.tarball into the record, which Bun fetches from as is.

Both restores now read the registry Bun resolves each package against
(a scope's .npmrc @scope:registry or bunfig [install.scopes] entry, else
BUN_CONFIG_REGISTRY / NPM_CONFIG_REGISTRY, the .npmrc registry, then
bunfig [install] registry, in Bun's order), fetch the version document
from it through fetch_dists_on as the berry and vlt restores do (#918),
and record its dist.tarball. When that registry can't be read, the
default registry's conventional URL is re-based on it (with the existing
upstream_registry_fallback warning). The text slot stays "" for npmjs,
matching Bun's own prefix test, so projects without a custom registry
restore byte for byte as before.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Review follow-ups to the Bun registry-slot restore:

- An npmjs alias as the project registry (registry.yarnpkg.com, or
  http://registry.npmjs.org) had the default document's conventional
  URL re-based onto the alias, so the bun.lock slot carried the alias
  URL where Bun writes "" (its writer prefix-tests the manifest's
  dist.tarball, which those registries advertise on npmjs). Only a
  fallback from a non-default registry (non_default_registry is Some)
  is re-based now, and the slot short-circuits on any npmjs host.
- The env registry lookup took the first non-empty of
  BUN_CONFIG_REGISTRY / NPM_CONFIG_REGISTRY / npm_config_registry and
  then dropped it if it was not a URL; Bun skips a non-http(s) key and
  reads the next one. bun_env_registry now filters inside the search.
- A bunfig [install.scopes] entry with no url (token only) takes the
  configured default registry (.npmrc / bunfig), not the environment,
  matching Bun's `registry.url = base.url`.
- Unit tests no longer read the ambient env registry, and the CLI
  subprocess harnesses strip it, so a shell where npm exports
  npm_config_registry no longer turns the Bun restore tests red.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Bun 1.3.14 added a machine-wide store for the isolated linker
(`[install] globalStore = true` or BUN_INSTALL_GLOBAL_STORE=1). Each
node_modules/.bun/<entry> is then a symlink into
<cache>/links/<entry>-<hash>, and every project using that cache links
to the same directory.

socket-patch did not know this layout. patch/shared_store.rs only
recognized pnpm's global virtual store and PDM's cache, so agent apply
wrote through the link into the shared directory and patched every other
project, and a rollback in one project silently unpatched them all. And
the .bun store walk kept only entries that are real directories, so
every globalStore entry was skipped: agent mode reported transitive
dependencies as package_not_installed, and hosted vex attested a pinned
transitive package as not_affected without reading the unpatched copy
that is actually installed.

Add a BunGlobalStore shared-store kind, recognized on the real path
<cache>/links/<name>@<...>-<hex>/node_modules/<name>, so agent apply and
rollback refuse it like the pnpm and PDM stores (#361), naming the store
and how to get a private copy. Have the .bun walk also follow entries
that link into a Bun global store entry, so scan, apply's resolver, the
peer-copy fan-out and vex see this project's copies there. Other links
in .bun are still skipped.

Tested with real Bun 1.3.14: two projects sharing a cache, agent apply
in one now refuses both the direct and the transitive package and the
other project's bytes stay untouched.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Human-mode apply printed "bun layout detected. Copy-on-write will keep
~/.bun/install/cache/ untouched." for every Bun project. With Bun's global
store (install.globalStore / BUN_INSTALL_GLOBAL_STORE, Bun >= 1.3.14) the
installed package dirs are the cache's shared <cache>/links entries, and
apply now refuses them, so the note said the opposite of what happens.

Add crawlers::bun_uses_global_store, which reads the installed tree (a
node_modules/.bun entry linking into <cache>/links/<entry>-<hash>) rather
than bunfig or the env, and print a note naming the shared store and the
globalStore = false remedy in that case. Other Bun projects keep the old
note.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Vendored mode records bun.lockb wiring as binary package snapshots. Bun's
own `bun install --save-text-lockfile` deletes bun.lockb and carries the
vendored tuples into bun.lock, but every unwind path still treated the
entry as binary-only:

- bun_binary::revert failed hard on the missing bun.lockb, so
  `vendor --revert`, `rollback` and the hosted takeover could not unwind
  the vendored wiring.
- carry_forward_wiring only carried an original across a matching
  surface, so a superseding re-vendor on the migrated lock (which records
  no original for our own stale tuple) lost the registry original, and
  revert then left the project patched while reporting success.

When bun.lockb is gone but bun.lock exists, revert now restores each
recorded binary package in bun.lock: every tuple still pointing into the
entry's vendor artifact is rewritten to the registry 4-tuple Bun writes
for the pristine binary record (key, indent, dependency object and comma
kept verbatim; an empty registry slot under https://registry.npmjs.org
and the tarball URL otherwise, as Bun's text writer does). Records whose
originals disagree are left alone as drift. A re-vendor's bun.lock record
whose predecessor only has bun.lockb records gets that registry tuple as
its pre-vendor original.

Real-Bun fixtures (1.2.23 lockb migrated by 1.2.23 and 1.4.2, pristine
and vendored) pin the exact restored bytes; a Bun-gated e2e covers
vendor --revert, rollback and the hosted takeover, and joins the 1.4.2
CI leg.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The migrated-lock revert tests compare restored bun.lock bytes against
real Bun output; a CRLF checkout on Windows would break that comparison.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

A vendored re-run on a bun.lock that Bun migrated from bun.lockb re-pins
our own tuple at the same uuid whenever the committed artifact is missing
(fresh clone, `repair` rebuild) or the tuple's digest differs. The new
entry carries a `bun_lock_package` record (its original rebuilt from the
binary snapshot), and the same-uuid wiring union in carry_forward_wiring
also keeps the predecessor's `bun_lockb_package` records, since no surface
matches across kinds. revert_bun_opts routes any entry with binary records
to bun_binary::revert, which rejected the text record as "unexpected
binary wiring file or kind": that counted as drift, so revert exited 0
with bun.lock still vendored and the artifact kept.

In the migrated mode, bun_binary::revert now restores `bun_lock_package`
records in bun.lock through the text revert's own per-record restore
(which also converges silently when a binary record already restored the
line). The binary and workspace-mirror records stay in the entry so mirror
tarballs are still cleaned up. A regression test re-pins the same uuid on
both migrated fixtures (1.2.23 digest-less, 1.4.2 with a changed digest)
and checks the revert restores the pristine bun.lock with no warnings.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

After a workspace bun.lockb is vendored, a new dependent of the patched
name@version (a member added later, or `bun add` in a member) makes Bun
write a second, nested registry record of it, because the hoisted record
is now a local tarball. The vendored re-run rewired every matching record
to the same .socket/vendor tarball, leaving two package records with one
resolution - a shape Bun's own writer never produces. On the isolated
linker both map to one node_modules/.bun store directory, so cold frozen
installs failed intermittently with EEXIST (reproduced on Bun 1.3.9 and
1.4.2: 3/8 fresh installs on 1.4.2), while scan/vendor reported success.

The re-run now folds such duplicates into one kept record (the one at
the target tarball, else ours, else the first), the way Bun's re-save
would: their dependency edges resolve to the kept record, the duplicate
rows leave every package column with later IDs (resolution buffer and
meta.id) renumbered, and the hoisting trees are rewritten as Bun
re-hoists them - an edge whose nearest same-name ancestor now holds the
same package is deduplicated and an emptied tree dropped. Bun 1.3.x
re-hoists a frozen binary lock and refuses one whose trees differ
(Lockfile.eql), so merely re-pointing edges, or leaving an orphan record
(which 1.4.2 refuses), is not enough. The buffers are re-laid with Bun's
eight-byte data alignment and the metadata hash updated; the same
workspace normalization as any record edit is applied.

The tree rewrite is exact only where hoisting is predictable, so the
merge is limited to records without dependencies of their own, no peer
edge to them and no bundled edge in the lock; otherwise the records are
rewired as before with a new vendor_bun_lockb_duplicate_records warning.

Tests: real-Bun e2e (new member and `bun add` triggers, 6 cold frozen
installs each, idempotent re-run, revert) on 1.3.9/1.3.14/1.4.2, run in
CI on the 1.3.14 and 1.4.2 legs; hermetic codec and vendor tests over
locks captured from Bun 1.3.9 and 1.4.2.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The bun-lockb/late-dependent fixture added for the duplicate-record fix
is walked by the vex discovery golden corpus, but bun-lockb.json had no
entry for it, so committed_fixture_corpus_matches_golden failed.
Regenerated with SOCKET_PATCH_UPDATE_GOLDEN=1; the only change is the
new empty entry for that fixture.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The vex discovery golden corpus walks every bun-lockb fixture directory.
#861 added the golden entry for its late-dependent fixture, but the
bun-lockb/1.2.23-migrated fixture added by the #784 fix had no entry in
bun-lockb.json, so committed_fixture_corpus_matches_golden still failed
on the combined branch. Regenerated with SOCKET_PATCH_UPDATE_GOLDEN=1;
the only change is the new empty entry for that fixture.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

revert_bun_wiring returned success on a dry run before reading
bun.lock, so revert_bun_opts never saw vendor_lockfile_missing or
vendor_lock_entry_removed and a preview advised `bun install --force`
for a revert that restores nothing (the lock gone, or the entry
removed by `bun remove`).

The dry run now replays the lock in memory like the wet run, skipping
only the write and the artifact deletion, so its warnings and the
reinstall advisory match the wet run's.

Found by Bugbot on #1009.

Assisted-by: Claude Code:claude-opus-5-5

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01TSx4W4Qfb8hsBhw4NEvkv9

The bench gate flagged bun-isolated/hosted and /rescan (+12-13% wall
in CI, +15% instructions under callgrind against main). Cut the
per-entry costs this branch added:

- user_tarball_version (#497): run the cheap leaf checks before the
  vendor-path parse, and reject an entry of another package by length
  and '@' before any string work; the hosted rewriter asks this of
  every lock entry per patch.
- loses_default_trust (#371): look the name up in a set built once
  instead of scanning the default trusted list per call (22k calls in
  the bench).
- live_bun_store_entries_sync (#599): look a guessed link target up
  before building its path, and only clone a target that is newly
  reached.

callgrind on the bun-isolated/hosted fixture: 768.7M -> 728.4M
instructions (main: 669.5M).

Assisted-by: Claude Code:claude-opus-5-5

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01TSx4W4Qfb8hsBhw4NEvkv9

The scan-performance gate failed on bun-isolated/rescan (+10.2% wall
in CI) and bun-isolated/hosted (+8.4%). The cause was the #599
orphan walk over node_modules/.bun, not its reads: the syscall
counts match main. Two things cost the time:

- The walk tracked entries by name. It hashed and cloned an OsString
  for each of the 3000 entries, several times over. It now tracks
  them by index into the store's entry list.
- It read one parallel batch per link-graph frontier, plus another
  batch for the scan. Each batch wakes and parks the walk pool for
  little work, which cost about 12 ms of user and system time. The
  quick walk now reads every entry's listing in one parallel pass,
  the same reads the scan always made, and follows the links in
  memory. The scan reuses those listings without another pass.

What counts as live is unchanged. The full re-walk that runs after
a quick walk leaves entries unreached is still read as before.

bun-isolated/rescan on the bench fixture, against the PR base:
instructions 579M -> 556M (base 524M); paired local compare now
+6.3% hosted and +8.7% rescan wall, +5% CPU (was +11-14%).

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment

Resolve conflicts with #1008, which moved npm-family vendoring into a shared flow: re-apply this PR's bun additions (default-trust warning #371, non-registry tarball warnings and not-rewritable refusal #497, and bun.lockb duplicate-record folding #861) on top of the new backend structure.

Co-Authored-By: Claude <[email protected]>

A Bun hosted restore reads the project's bunfig.toml and .npmrc and
sends the registry credentials they configure. It expanded any
$VAR / ${VAR} in them, so a project could name its own registry host
and have socket-patch send it an unrelated secret such as
$GITHUB_TOKEN. Bun itself would send the same on `bun install`, but
socket-patch also runs where Bun does not, so it is an extra layer of
defense: only NPM_TOKEN, NODE_AUTH_TOKEN and BUN_AUTH_TOKEN expand now,
and any other variable expands to nothing (the read falls back to the
anonymous read, as on main).

The maintainer chose the allowlist on the review thread.

Assisted-by: Claude Code:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01TSx4W4Qfb8hsBhw4NEvkv9

The env allowlist still let an allowed token reach a registry URL's
host, path or query (`https://h/${NPM_TOKEN}/`). That part of the URL
is requested, printed in upstream_registry_fallback and written into
the restored bun.lock / bun.lockb, so the token leaked into all three
(security review on 55cf5b3). A registry URL from bunfig.toml or
.npmrc now expands variables only inside its `user:password@`, which
split_userinfo moves onto the request's Authorization header; a
reference anywhere else expands to nothing, and such a registry falls
back like any other unreadable one.

Assisted-by: Claude Code:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01TSx4W4Qfb8hsBhw4NEvkv9

…sues

# Conflicts:
#	crates/socket-patch-cli/CLI_CONTRACT.md
#	crates/socket-patch-core/src/hosted/governing_root.rs
#	crates/socket-patch-core/src/patch/redirect/upstream/npm.rs
#	crates/socket-patch-core/src/patch/shared_store.rs