Fix Bun restore ignoring user registry config (#1276)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1276

Summary

Hosted Bun unwinds (rollback, remove <purl>, and the hosted → vendored takeover for bun.lock and bun.lockb) now look up each package's registry the way Bun does. That includes the user's .npmrc and the global bunfig, not only the files beside the lock.

Before this, a private scope set only in ~/.npmrc or ~/.bunfig.toml (the usual place, since tokens aren't committed) was looked up on the public registry, without credentials, which also leaked the private package name. The restore then either failed with a 404 or exited 0 after writing "" plus a same-name public package's integrity. That lock breaks cold frozen installs on Bun ≥ 1.3.7 and installs the public package on Bun ≤ 1.3.6.

Root cause

BunRegistrySettings::read (crates/socket-patch-core/src/patch/redirect/upstream/npm.rs) read only {lockdir}/.npmrc and {lockdir}/bunfig.toml. It modelled one project-level config, not Bun's layered one.

Measured Bun behaviour

Measured with a request-logging mock registry on Bun 1.1.39, 1.2.23, 1.3.6, 1.3.7, 1.3.9, 1.3.12, 1.4.0 and 1.4.2 (Linux). Every layer below was varied pairwise.

• User .npmrc: $XDG_CONFIG_HOME/.npmrc when that file exists, else ~/.npmrc. NPM_CONFIG_USERCONFIG is ignored.
• Global bunfig: $XDG_CONFIG_HOME/.bunfig.toml when XDG_CONFIG_HOME is set (Bun then never reads ~/.bunfig.toml), else ~/.bunfig.toml.
• Merging: settings merge per key. A key in a project file beats the same key in the user or global file of the same kind, and unrelated keys still come from the user or global file. A scope entry beats any default registry. The env registry beats the configured default registry but not a scope.
• Precedence flip in Bun 1.4.0: Bun ≤ 1.3.x takes any .npmrc key over any bunfig key. Bun ≥ 1.4.0 does the reverse.
• Lock versions: Bun 1.4 is the first to write lockfileVersion: 2, and Bun 1.3 ignores a v2 lock. Bun 1.4 keeps a v1 lock as v1, so a v0/v1 lock (or a bun.lockb) doesn't say which Bun installs it.

The fix

• BunConfigFiles holds the .npmrc layers (project, then user) and the bunfig layers (project, then global). bun_user_config_paths finds the user files as measured above. bun_lookup_layered resolves each key from the highest-precedence file that sets it, in either kind order.
• BunConfigOrder:
  • A v2 bun.lock uses bunfig-first (Bun ≥ 1.4).
  • A v0/v1 bun.lock or a bun.lockb is Unknown. A package is refused, with the existing checkout remedy, only when the two orders give a different registry or credentials. Otherwise the restore proceeds as before.
• Variable expansion: the user's own files expand any ${VAR}, as Bun does (e.g. //npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}). Project files keep the existing NPM_TOKEN / NODE_AUTH_TOKEN / BUN_AUTH_TOKEN allowlist. Credentials are never printed: refusals show only bases, which have their userinfo stripped.
• Both callers (restore_bun_locks, and the bun.lockb takeover restore) go through refuse_ambiguous before fetching.
• CLI_CONTRACT.md and docs/ecosystems.md describe the layering, the version split and the refusal.

Behaviour change for maintainers: a project whose own .npmrc and bunfig.toml name different registries for the same package, on a v0/v1 bun.lock, used to be restored npmrc-first. It is now refused with the checkout remedy, because Bun 1.4 would resolve it bunfig-first. On a v2 lock it now follows Bun 1.4 (bunfig-first) instead of npmrc-first. The flip is real but small in practice: it only matters when both kinds set the same key differently.

Also included: one rustfmt-only line in upstream/mod.rs. Main isn't cargo fmt --check clean on it, and the cargo fmt --all step required before marking ready reformatted it.

Tests (red → green)

Issue case	Test	Without fix	With fix
#1276 scope + token only in ~/.npmrc	registry::bun_remove_reads_registries_set_only_in_the_user_npmrc	exit 1, cannot restore …	pristine lock
#1276 ~/.bunfig.toml [install.scopes]	registry::bun_remove_reads_registries_set_only_in_the_global_bunfig	exit 1	pristine lock
$XDG_CONFIG_HOME/.npmrc / .bunfig.toml beat ~ decoys	registry::bun_remove_reads_the_xdg_config_home_npmrc_and_bunfig	exit 1	pristine lock
v2 lock: global bunfig beats project .npmrc (Bun 1.4)	registry::bun_remove_on_a_v2_lock_takes_bunfig_over_npmrc	upstream_registry_fallback	pristine lock, no fallback
v1 lock, .npmrc vs bunfig disagree	registry::bun_remove_refuses_when_npmrc_and_bunfig_disagree_on_a_v1_lock	exit 0, guessed	refused, pin kept
Real Bun: scope only in $XDG_CONFIG_HOME/.npmrc, scan → rollback → fresh frozen install	e2e_redirect_bun_build::bun_redirect_rollback_reads_a_scope_set_only_in_the_user_npmrc	HTTP 404 Not Found from the default registry (the issue's symptom)	byte-exact lock, original bytes installed

The integration tests are in crates/socket-patch-cli/tests/in_process_vendor_bun_takeover/registry.rs. Core unit tests in npm.rs:

• bun_user_config_paths_follow_bun_s_lookup
• bun_layers_take_each_key_from_the_highest_file_that_sets_it
• bun_user_files_expand_any_variable_project_files_only_token_ones
• bun_refuses_a_registry_the_lock_s_bun_version_would_decide

The existing #992 tests still pass unchanged.

in_process_vendor_bun_takeover's runner now also removes XDG_CONFIG_HOME, so a developer's user config can't steer the fixtures. HOME was already pinned to a stand-in.

Commands run locally

• cargo fmt --all -- --check: ok.
• cargo clippy --locked --workspace --all-features -- -D warnings: ok. --all-targets reports nothing in the changed files; its other findings are in files this PR doesn't touch.
• cargo test -p socket-patch-cli --all-features --test in_process_vendor_bun_takeover: 40/40.
• cargo test -p socket-patch-core --lib redirect::upstream: 119/119.
• SOCKET_PATCH_BUN_E2E_REQUIRED=1 SOCKET_PATCH_BUN_E2E_VERSION=1.4.2 cargo test -p socket-patch-cli --all-features --test e2e_redirect_bun_build -- --include-ignored: 36/36. The 1.1.45 / 1.2.23 / 1.3.14 legs run in CI.
• cargo test --workspace --all-features --no-fail-fast: 13 failures, all environmental and none in Bun or redirect code:
  • 12 are permission-based write-failure tests (covgap_commands_vendor, repair, copy_tree, vlt_heal, vendor::pypi_*, in_process_redirect write-failure cases). The sandbox runs as uid 0, which ignores chmod 0o555.
  • 1 is mode_migration_pypi::pipenv_hosted_to_vendored…, which fails fetching https://pypi.org through the sandbox's TLS-inspecting proxy (the Every HTTPS call fails behind a TLS-inspecting proxy because the clients trust only bundled webpki roots #1107 shape).
• Wrappers under npm/, pypi/ and gem/ only dispatch to the binary, so they need no change.

Follow-ups (not in this PR)

• Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 is the yarn berry twin (berry_lookup_registry ignores ~/.yarnrc.yml, npmScopes registries and YARN_NPM_REGISTRY_SERVER). It's a separate reader, so it's left for its own PR.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes hosted lockfile restoration and private-registry lookup (including credentials), but ambiguity is refused and behavior is heavily tested; v0/v1 locks with conflicting project npmrc/bunfig now fail restore where npmrc-first guessing used to succeed.

Overview
Hosted Bun unwinds (rollback, remove, and hosted → vendored takeover) now resolve each package’s registry the way Bun does, not only from .npmrc / bunfig.toml beside the lock.

The upstream restore loads layered config: project then user .npmrc ($XDG_CONFIG_HOME/.npmrc or ~/.npmrc), project then global bunfig.toml, plus env registry overrides. Keys merge per Bun’s precedence (project beats user/global; Bun ≥ 1.4 prefers bunfig over .npmrc, ≤ 1.3 the opposite). On lockfileVersion 2 restores use bunfig-first; on v0/v1 bun.lock or bun.lockb it refuses pins when the two orders would pick different registries or credentials, instead of guessing.

Credential handling matches Bun: user-owned config may expand any ${VAR}; project files still only expand NPM_TOKEN / NODE_AUTH_TOKEN / BUN_AUTH_TOKEN. Refusal messages expose registry bases only.

Docs (CLI_CONTRACT.md, docs/ecosystems.md) and tests cover user-only scopes, XDG paths, v2 bunfig-over-npmrc, v1 conflicts, and e2e rollback with scope in user .npmrc.

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

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Bun patch compatibility / native (*), e2e (ubuntu-latest, e2e_safety_pnpm) and hosted-e2e are red on f637b68. They all look like the public patch API no longer serving npm patches, not this PR.

• hosted-e2e (e2e_hosted_production, which failed on all 3 attempts): preflight_required_patches_are_published fails. That test only checks that the patches the suite needs are still published. Every npm-ecosystem lane fails too, each with redirect.redirected: 0 and no patches: npm_package_lock, npm_shrinkwrap, pnpm, yarn_classic, yarn_berry, bun, vlt and canary_patches_name_advisories…. The PyPI (uv) and RubyGems (bundler) lanes pass on the same runner.
• native (*): every Bun version, on Linux and Windows, fails at the first scan. It reports packagesWithPatches: 0 for pkg:npm/minimist@1.2.2.
• e2e_safety_pnpm: apply against the public proxy leaves index.js unpatched, with its original hash.

This PR only changes how Bun registry config is read on the hosted restore paths (rollback, remove, and the bun.lockb takeover). It doesn't touch the patch search, apply, or the npm, pnpm, yarn or vlt code.

The Bun workflow passed on main at 0ce8d6c (14:58), and on the fix/gc-report-json-1257 branch at 15:03. main's later runs are cancelled or still queued. I can't reach patches-api.socket.dev from my sandbox to check it directly.

No fix exists in the repo for this. I'll re-run the failed jobs once after these runs finish, and compare against main's pending runs.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Update on the red Bun checks: main fails the same way. Bun patch compatibility on 31383f5 (run 37951436371, 15:24–16:01) has all 23 native jobs failing, with only build and binary passing. So the patch API failure described above is not this PR's.

I've re-run the failed jobs once on both of this PR's runs (37952898642 and 37952898726). The rest of CI on f637b68 is green (169/172 jobs), and the PR has no merge conflict.

---

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 f637b68. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Picked this PR up because its heartbeat was stale. On f637b68 it's green except for three checks, and none of them come from this PR:

• hosted-e2e, e2e (ubuntu-latest, e2e_safety_pnpm) and every Bun native (*) leg fail because of Merge queue blocked: production no longer publishes free minimist@1.2.2 patch #1293. Production withdrew the free minimist@1.2.2 patch 80630680-…. The safety_pnpm log shows index.js with the old afterHash 043f04d1…, which is that withdrawal. main fails these checks the same way.
• A fix now exists in Repin live minimist@1.2.2 suites to republished patch 642d7f02 (#1293) #1301 and Follow the republished minimist canary patch #1302 (repin to 642d7f02-…). Both are open and waiting for review. I'm not porting the repin here because it would only add unrelated test constants that conflict with whichever one lands.
• The one allowed re-run has already been used. Bugbot's review of f637b68 is clean, and both review threads are resolved.

Next: once #1301 or #1302 merges, merge main into this branch and re-check CI.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Ready for review at 8f948e739921.

• CI: required checks ci-ok and clippy green; 8 check suites succeeded. 1 superseded workflow run(s) show as cancelled; the required gates passed on this head.
• Mergeable against main, no CHANGELOG.md change.
• Bugbot reviewed this head; no unresolved review threads.

Labeled Ready for review by the burn-down agent. Slack announcement pending (connector unavailable this run).

---

Generated by Claude Code