Fix vendored npm/Bun revert treating an upgrade as drift (#1155) by mikolalysenko · Pull Request #1187 · SocketDev/socket-patch

Mikola Lysenko (mikolalysenko) · 2026-10-08T22:37:17Z

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

Summary

Upgrading or downgrading a vendored package (npm install left-pad@1.3.1, bun update, a Dependabot bump) now reverts cleanly in a plain project. Before, scan --prune, vendor --revert, remove and rollback kept the vendored artifact and ledger entry as "drift". vendor --check then stayed red, and every remedy it named looped. The only way out was deleting .socket/vendor/npm/<uuid>/ and editing state.json by hand.

Root cause

After vendoring, an upgrade keeps the same lock key but locks a new version from the registry. The npm revert (npm_lock.rs revert_one_record) and the Bun text-lock revert (bun_lock.rs) decided whether a record was still ours only by asking whether resolved points into our uuid dir. Any other resolution warned vendor_lock_entry_drifted, and RevertOutcome::drift_skipped() then keeps the artifact and the ledger entry. "Undo the drift" would mean downgrading back to the vulnerable version.

Fix

A live entry that is a same-package version move on the same registry means the vendored version left the lock graph, which is the same situation as npm uninstall. Both backends now emit vendor_lock_entry_removed for it, with the new version in the detail. The existing #665 gate (keep_artifact_while_lock_references_it) then deletes the artifact only once no lock still names the uuid, and keeps it otherwise.

Because this path deletes the only patched copy, it trusts a version move only when nothing visible could make the install come from somewhere else. In every other case the revert drift-keeps exactly as before #1155.

Project gate (both backends, npm_common::project_may_redirect_registry). The project must have:

no overrides in package.json (npm);
no setting at all in the project .npmrc or bunfig.toml. Blank and comment lines are fine; an unreadable file counts as a setting.
no NPM_CONFIG_REGISTRY, npm_config_registry or BUN_CONFIG_REGISTRY in the environment.

Entry check, npm. All of the following must hold:

version differs from both rec.new and rec.original.
The live resolved is exactly <registry>/<name>/-/<basename>-<version>.tgz, using the pre-vendor tarball's directory and file stem. That leaves no room for \, .., extra segments, a query or a fragment.
<version> is a plain [A-Za-z0-9.+-] token. A legacy v1 alias row's npm:left-pad@1.3.1 is read as 1.3.1.
The scheme matches, or moves from http to https (npm does this to old npm 6 locks).
The key is not in npm_non_registry_entries, so no git / URL / file: spec edge qualifies.

Entry check, Bun. The same package name and the same registry field as the pre-vendor tuple, with a different plain version.

The provenance rules were tightened across 8294b94, d1428a3, 4b1630c, 264b6ff, f379b2d, 5c52a32, c5c0736 and 949593f in response to Bugbot.

Open questions for a maintainer. Two Bugbot threads are left open on purpose:

Bun default registry: a Bun empty registry field can't be tied to the registry used at vendor time, because existing records don't store it.
Machine-level config: user and global config (~/.npmrc, the global npmrc, ~/.bunfig.toml) can also redirect fetches. Reading those would make the revert depend on who runs it. ~/.npmrc auth lines would also disable the fix almost everywhere.

The decision is whether to record the registry at vendor time and/or read machine config. Both are follow-ups.

Scope

Covered: npm package-lock.json / npm-shrinkwrap.json (legacy v1 and v2/v3 entries) and Bun bun.lock, in projects with no install-source config.
Not covered: bun.lockb, which Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147 is reworking (it's in the merge queue). A follow-up can apply the same rule there once that lands.
pnpm and yarn classic have the same "re-resolved since vendoring" arm, and their existing tests pin a version change as drift. Changing them deserves its own reviewed change, so I left them alone.
No wrapper changes: npm/, pypi/ and gem/ only dispatch to the binary.

One existing test changed. bun_lock::tests::revert_leaves_drifted_entries_alone_with_warning used bun update to 1.3.1 as its drift example, which is exactly the #1155 behavior. It now drifts the entry to a same-version fork URL, so its drift and keep-gate-liveness coverage stays. The 1.3.1 case moved to a new test that expects the revert.

Tests

Leg of #1155	Test	Red on `main`
npm revert, upgrade of every instance	`vendor::npm_lock::tests::revert_after_version_change_drops_the_unreferenced_artifact`	panics at `!drift_skipped()`
npm revert, downgrade of one instance	`vendor::npm_lock::tests::revert_after_partial_downgrade_restores_the_rest_and_drops_artifact`	panics at `!drift_skipped()`
npm revert, old `http://` lock upgraded to `https://`	`vendor::npm_lock::tests::revert_after_version_change_accepts_http_to_https_upgrade_only`	drift-kept
npm revert with a comment-only `.npmrc`	`vendor::npm_lock::tests::revert_after_version_change_ignores_a_comment_only_npmrc`	drift-kept
npm legacy alias row upgrade	`vendor::npm_lock::tests::version_moved_off_reads_legacy_alias_versions`	n/a (new helper)
Bun text lock, `bun update`	`vendor::bun_lock::tests::revert_after_version_change_drops_the_unreferenced_artifact`	panics at `!drift_skipped()`
`rollback` and `vendor --check`	`in_process_vendor::rollback_after_version_upgrade_cleans_up_and_converges`	rollback exit 1
`remove`	`in_process_vendor::remove_after_version_upgrade_reverts_vendoring`	remove exit 1 ("drift-kept")
`scan --prune`	`scan_vendor_e2e::scan_prune_reverts_vendored_entry_after_version_upgrade`	`keptVendoredEntries: [pkg:npm/left-pad@1.3.0]`

Guards (negative cases; the artifact is kept):

npm:
- revert_keeps_artifact_when_version_changed_but_uuid_still_referenced
- revert_keeps_version_change_resolved_off_the_recorded_registry_as_drift
- revert_keeps_version_change_behind_a_non_registry_spec_as_drift
- revert_keeps_version_change_as_drift_while_any_override_is_declared
- revert_keeps_version_change_as_drift_while_a_project_npmrc_sets_anything (registry, scoped registry, replace-registry-host, proxy + strict-ssl, cafile)
- legacy_pointer_maps_to_its_packages_key
- the https → http half of the scheme test, and the off-tarball half of the alias test
Bun:
- revert_keeps_version_change_from_another_registry_as_drift
- revert_keeps_default_registry_upgrade_as_drift_when_the_registry_is_configured

Local runs (on `949593f`)

cargo clippy --workspace --all-features -- -D warnings: clean.
rustfmt --check on every changed file: clean. main itself isn't cargo fmt --all-clean, so I didn't reformat unrelated files.
cargo test -p socket-patch-core --all-features --lib -- vendor::npm_lock vendor::bun_lock vendor::npm_origin vendor::npm_common: 258/258 passed.
- The whole vendor:: module on c5c0736: 2,415 passed, 2 failed. Both failures also fail on main here: they're chmod tests, and the container runs as uid 0.
in_process_vendor: 124/124 passed. scan_vendor_e2e: 38/38 passed.

CI

949593f: CI green (run 37868096762). Bugbot reviewed 949593f with no new findings, and the PR is mergeable.
c5c0736 was also fully green.
4b1630c's test (windows-latest, 1) failed once on lock_inventory::view::tests::a_read_set_notices_a_changed_file, a test that arrived with Decide whether a hosted patch is pinned through lockfile discovery alone #1058 on main. The same leg passed on every later head.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mo7HM9gyRkUAMxWqi62Dxz

Generated by Claude Code

Note

Medium Risk
Changes vendored revert/rollback semantics and can delete .socket/vendor artifacts when locks show a trusted registry upgrade; misclassification could drop a still-needed patch, though guards limit that to “plain” upgrades with no redirecting config.

Overview
Fixes #1155: when a vendored npm/Bun package is bumped to another registry version (e.g. npm install left-pad@1.3.1 or Dependabot), rollback, remove, scan --prune, and lock revert no longer treat that as permanent drift that keeps the artifact and leaves vendor --check stuck.

npm (npm_lock) and Bun text lock (bun_lock) now detect a same package, same registry, different version move and emit vendor_lock_entry_removed instead of vendor_lock_entry_drifted, so cleanup matches an uninstall once nothing in the lock still resolves through the vendor uuid. The user’s upgraded lockfile is left unchanged.

That “plain upgrade” path is only taken when install provenance looks trustworthy: no package.json overrides, no meaningful project .npmrc / bunfig.toml or registry env vars (project_may_redirect_registry), plus strict checks on resolved / tarball shape (npm) or registry tuple fields (Bun). Other cases (git/URL/file specs, wrong host, overrides, configured default registry for Bun, uuid still referenced) still drift-keep as before.

Adds CLI e2e coverage for rollback/remove/scan prune and a large set of unit tests for positive reverts and negative guards. bun.lockb and pnpm/yarn are out of scope; one Bun drift test now uses a same-version fork URL instead of a version bump.

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

Moving a vendored package to another version (`npm install pkg@x`, `bun update`, a Dependabot bump) left the vendored copy and its ledger entry stuck. `scan --prune`, `vendor --revert`, `remove` and `rollback` called the moved lock entry "drift" and kept everything, so `vendor --check` stayed red and every remedy it named looped. A lock entry that now locks a different version than the one vendored means the vendored version left the lock graph, the same as after `npm uninstall`. The npm and Bun text-lock reverts now report it as `vendor_lock_entry_removed`, leave the user's lock untouched, and delete the artifact once no lock resolves through it. A re-resolution at the same version is still drift and still keeps the artifact. Fixes #1155 Assisted-by: Claude Code:claude-opus-5-5

Covers the `scan --prune` leg of #1155 end to end: after `npm install left-pad@1.3.1` over a vendored 1.3.0, one prune run reverts the entry, removes the artifact and leaves the user's lock byte-identical. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T22:49:44Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

A lock entry that kept the vendored key but changed its version was reverted as an upgrade no matter where it resolved. An edited lock could point that entry at any tarball, and `scan --prune`, `remove` or `rollback` would then delete the vendored copy and turn `vendor --check` green. An upgrade now has to be the same package from the registry the pre-vendor entry used: for npm the new `resolved` must share the original's `<registry>/<name>/-/` tarball directory, and for Bun the spec's package name and the tuple's registry field must match. Anything else stays drift, keeps the artifact and leaves `vendor --check` red. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:02:57Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

Older npm locks record `http://` registry tarball URLs, and the next `npm install` rewrites them to `https://`. An upgrade made that way was still called drift, so the vendored copy stayed stuck as in #1155. A move from `http` to `https` on the same registry now counts as an upgrade; a move from `https` down to `http` stays drift. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:13:34Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

An upgraded npm entry was accepted when its `resolved` sat under the recorded registry directory and ended in `.tgz`. A URL written with backslashes or `..` passed that check, but npm normalizes it before fetching, so it could point at another package's tarball while the vendored copy was deleted. The tarball file must now be exactly `<name>-<version>.tgz`, with the name taken from the pre-vendor tarball and a plain version; anything else stays drift. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:19:03Z

BugBot review

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:22:57Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

Lockfile v1 alias rows store their version as `npm:left-pad@1.3.0`, so the new exact tarball-name check never matched them and a real alias upgrade was still kept as drift. The tarball version is now read from after the last `@` of an `npm:` spec before the same strict check runs. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:33:45Z

BugBot review

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:35:10Z

[agent] test (windows-latest, 1) failed on 4b1630c (job), and I don't think it's this PR's.

The failure: one test, vendor::lock_inventory::view::tests::a_read_set_notices_a_changed_file, panicked at view.rs:1182 with "a replacement". The other 5,497 core lib tests passed.

Why it isn't this PR's:

The test and the ReadSet code it checks came from Decide whether a hosted patch is pinned through lockfile discovery alone #1058, which merged to main at 23:17 (4d06019). CI tested this PR merged onto that base.
This PR doesn't touch lock_inventory, ProjectView or DiskSnapshot.
The failing step renames a same-bytes file over a.lock inside the 2-second "racily current" window, then expects the read set to notice. Decide whether a hosted patch is pinned through lockfile discovery alone #1058's last commit ("Compare racily-current files by content in the read set") was itself fixing this same Windows leg.
main's own push run for 4d06019 has its Windows test jobs still in progress, so I can't yet say whether main is red too.

Fix: none exists yet. I haven't re-run the job: the head has moved to 264b6ff, whose CI run includes the same Windows leg, so I'll use that result. If it fails the same way on 264b6ff (or on main), it needs a fix to #1058's racy-file check on Windows, which belongs in its own PR.

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

An entry npm installs from a git, URL or `file:` spec could still be read as a registry upgrade when its lock `resolved` was written in the registry tarball shape. npm ci installs such an edge from the spec, so the revert deleted the vendored copy while something else got installed. The revert now reads the same non-registry edge set the vendor scan uses (including a registry override's rescue, #490) and keeps any such entry as drift. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-08T23:53:58Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

Two more ways an edited project could make the revert delete a vendored copy while something else gets installed: - npm: a package.json override can swap a registry edge for a git, URL or file: spec, which npm ci installs instead of the lock's resolved tarball. While any override names the vendored package, a version change now stays drift. - Bun: an empty registry field means the default registry, which a committed bunfig.toml or .npmrc can rebind. When either file names a registry, an upgrade from the default registry now stays drift. Both fall back to the pre-#1155 behavior, which keeps the vendored copy, whenever the project's own config could change the install source. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-09T01:05:59Z

BugBot review

Generated by Claude Code

cursor

Stale Bugbot comment from a previous run.

Mikola Lysenko (mikolalysenko) · 2026-10-09T01:52:02Z

[final reviewer] Tanmay Singla (@Tanmay182003) Four non-merge commits landed after your approval on 264b6ff1, so I'm not sending this to the merge queue until you take another look. Together they narrow when the revert treats a version move as an upgrade instead of drift (4 files, +317/−6):

f379b2d3 Keep non-registry installs out of upgrades: entries npm installs from a git, URL or file: spec stay drift, even when the lock's resolved looks like a registry tarball (vendor/npm_lock.rs).
5c52a322 Distrust upgrades a project config can redirect: an npm overrides entry naming the package, or a Bun bunfig.toml/.npmrc registry, keeps the move as drift.
c5c0736a Trust upgrades only without redirecting config: replaces the per-spelling checks with one rule: the upgrade shortcut applies only when there are no overrides in package.json and no .npmrc/bunfig.toml mentioning a registry or scope.
949593fd Fail closed on any project or env registry config: any setting in the project .npmrc/bunfig.toml (proxy, strict-ssl, CA), or NPM_CONFIG_REGISTRY/npm_config_registry/BUN_CONFIG_REGISTRY in the environment, now keeps drift (vendor/npm_common.rs, vendor/npm_lock.rs).

All four make the revert more conservative: when in doubt it keeps the vendored copy, which is how it behaved before #1155. CI is green and the PR is mergeable at 949593fd. Re-approving sends it to the merge queue on my next pass.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-09T02:15:43Z

[burn-down agent] Labeled Ready for review at 949593fd6.

CI: every check on the head is success/skipped (ci-ok green).
Bugbot: Cursor Bugbot check passed on 949593f; no unresolved review threads remain.
Mergeable, no CHANGELOG.md change. The final reviewer noted four non-merge commits after the earlier approval (non-registry installs stay drift; config-redirectable upgrades distrusted), so it needs a fresh human approval.

Generated by Claude Code

…resolved-version-drift

#1147 landed a bun.lockb revert that calls bun_lock::revert_one_record for a migrated text record, and main moved npm_lock's npm_origin import. Both broke against this branch in the merge queue (clippy: E0061, E0425). Pass `false` for the new default-registry argument from the bun.lockb path, which keeps a moved default-registry tuple there as drift: bun.lockb stays outside the #1155 upgrade path. Import legacy_packages_key again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mo7HM9gyRkUAMxWqi62Dxz

Mikola Lysenko (mikolalysenko) · 2026-10-09T15:31:52Z

[agent] The merge queue dropped this PR because clippy failed in merge group 37950597945. It was a semantic conflict with main, not a flake:

E0061: Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147's new bun.lockb revert calls bun_lock::revert_one_record for a migrated text record. This PR added a default_registry_pinned argument to that function.
E0425: main rewrote npm_lock.rs's npm_origin import, which dropped legacy_packages_key.

Fixed in 0c50224, on top of a merge of main (f65a517):

The bun.lockb path passes false, so a moved default-registry tuple there stays drift. bun.lockb remains outside the After npm install <pkg>@<other version> moves a vendored npm package off its patched version, scan --prune, vendor --revert, remove and rollback all drift-keep it, so vendor --check stays red and every remedy it names loops #1155 upgrade path, as this PR's scope says.
The import is restored.

Checked locally on the merged tree:

clippy (-D warnings): clean.
vendor:: lib tests: 2,507 passed. The 2 failures are the known uid-0 chmod tests, which fail identically on main here.
in_process_vendor: 132/132. scan_vendor_e2e: 38/38.

The push dismisses earlier approvals if branch protection is set to, so this needs a re-approval before it can be queued again.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-09T15:40:48Z

[agent] Bun patch compatibility (every native (…) leg, Linux and Windows) and hosted-e2e fail on 0c50224. The cause is external: production no longer publishes the free minimist@1.2.2 patch that both suites are pinned to. This PR doesn't cause it.

Root cause. hosted-e2e's preflight states it directly (job):

preflight_required_patches_are_published: required production patches are no longer available:

pkg:npm/minimist@1.2.2: production publishes NO free patches for this package anymore. This suite is pinned to it — pick a replacement and update both the catalog constants in this file and docs/testing/hosted-production-e2e.md.

canary_patches_name_advisories_so_merge_state_is_inferable reports the same thing ("production publishes no patches").

How the other failures follow from it:

Every Bun native cell scans that same patch, gets "packagesWithPatches": 0, and fails with "Expected one applied patch" (run 37952422797).
PR Fix Bun restore ignoring user registry config (#1276) #1283, which is unrelated, fails the identical Bun legs on the same main (run 37952898642).
This PR only changes the revert of an already-vendored entry. It passed the same workflows on 949593f, before the patch was withdrawn.

What it needs: a fix outside this PR that moves the live-service suites (e2e_hosted_production.rs, scripts/backtest-bun.py and their docs) to a patch production still publishes. None exists yet. I'll re-run the failed checks here once that lands or the patch is republished.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-09T16:23:00Z

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

Port of #1301 (fixes #1293). Production withdrew the free minimist@1.2.2 patch 80630680 and republished the fix as 642d7f02, which turned hosted-e2e, e2e_safety_pnpm and every Bun native leg red here as on main. The vlt harness also now reads the republished patch's unprefixed file keys. Test-only; a no-op once main carries #1301. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mo7HM9gyRkUAMxWqi62Dxz

Mikola Lysenko (mikolalysenko) · 2026-10-09T18:03:03Z

[agent] Production republished the minimist fix as patch 642d7f02. #1301 repins the live suites to it but isn't on main yet, so I ported it here in 7dd9ed1 (test-only, #1293). #1290 and #1274 did the same, and their Bun runs went green.

The port changes:

e2e_hosted_production, e2e_vendored_production, e2e_npm and e2e_safety_pnpm: pinned to the new patch.
backtest-bun.py and its doc: pinned to the new patch.
backtest-vlt.py: reads the republished patch's unprefixed file keys.
The harness unittests, which pass locally (82). The changed e2e suites compile.

This is a no-op once #1301 lands. CI now re-runs hosted-e2e, e2e_safety_pnpm and the Bun native legs.

Generated by Claude Code

Mikola Lysenko (mikolalysenko) · 2026-10-09T18:51:37Z

[final reviewer] I disarmed auto-merge (it was re-armed at 18:23Z). Non-merge commits since your approval at 264b6ff1, head now 3f9b3c77:

f379b2d, 5c52a32, c5c0736, 949593f: narrow when a revert treats a version move as an upgrade. Non-registry installs and installs whose project or env registry config could redirect them fail closed. These are covered in my 01:52Z comment.
0c50224: build fix after merging main's bun.lockb rework (E0061 from the merge-group clippy failure).
7dd9ed1: test-only port of Repin live minimist@1.2.2 suites to republished patch 642d7f02 (#1293) #1301 (minimist repin), which is now on main, so it's a no-op once merged.

Tanmay Singla (@Tanmay182003), please take another look; re-approving lets it go to the queue.

Generated by Claude Code

cursor · 2026-10-09T21:41:13Z

+/// registry" trusts that move only when this is false (#1155). User- and
+/// machine-level config files (`~/.npmrc`, `~/.bunfig.toml`, the global
+/// npmrc) are not read.
+pub(super) async fn project_may_redirect_registry(project_root: &Path) -> bool {


🔒 Agentic Security Review

Severity: HIGH

Description: Version-move cleanup trusts a lock URL prefix as the same registry and deletes the vendored patch, but project_may_redirect_registry ignores the npm/Bun layers that rewrite that URL at fetch time. With registry set only in ~/.npmrc, the global npmrc, or a builtin npmrc, npm's default replace-registry-host=npmjs still fetches a https://registry.npmjs.org//-/-.tgz lock URL from that other registry. Bun does the same for an empty registry field when only ~/.bunfig.toml or $XDG_CONFIG_HOME/.bunfig.toml sets install.registry. Env keys other than NPM_CONFIG_REGISTRY, npm_config_registry, and BUN_CONFIG_REGISTRY are also unread: npm_config_@scope:registry redirects scoped packages, and npm_config_strict_ssl / npm_config_cafile change the TLS identity. npm_config_replace_registry_host matters when a registry is set in one of those unread layers; it does not by itself retarget a registry.npmjs.org URL whose effective registry is still registry.npmjs.org. A normal https-proxy does not substitute the tarball body. version_moved_off never checks the lock integrity against the recorded host; npm/bun only check the bytes they download against the integrity the lock editor wrote.

Impact: A lockfile edit that keeps the pre-vendor registry tarball prefix (or Bun's empty registry field) and changes the version is classified as a clean removal. rollback, remove, and scan --prune then delete .socket/vendor/npm/ and leave vendor --check green, while npm ci or bun install still fetches from a registry or TLS context the recorded URL does not name. If that origin serves bytes matching the lock integrity, those bytes are what gets installed. Before this change the same edit stayed drift, so the patched tarball was kept and the check stayed red.

Remediation: Do not take the version-move cleanup path unless every fetch-affecting npm/Bun layer is known not to rewrite the host or TLS identity. Reuse the existing outer-layer resolution (env, project, user, global, builtin, and ~/.bunfig.toml / $XDG_CONFIG_HOME/.bunfig.toml) for registry, scope registry, replace-registry-host, cafile, and strict-ssl. If any of those is set or unreadable, keep the pre-change drift verdict and the artifact. A proxy setting alone need not fail the check.

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review October 8, 2026 22:49

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs Outdated

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs Outdated

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs Outdated

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs Outdated

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Tanmay Singla (Tanmay182003) approved these changes Oct 8, 2026

View reviewed changes

cursor Bot reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs Outdated

cursor Bot reviewed Oct 9, 2026

View reviewed changes

Comment thread crates/socket-patch-core/src/vendor/bun_lock.rs Outdated

Comment thread crates/socket-patch-core/src/vendor/npm_lock.rs

cursor Bot reviewed Oct 9, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label Oct 9, 2026

This was referenced Oct 9, 2026

Fix Windows flake in read-set replacement test #1237

Merged

Fix macOS Composer legs red on main via setup-php 2.40.0 #1215

Merged

Finish vendored reverts through one shared step with a keep policy (#989) #1245

Merged

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue Oct 9, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 9, 2026

Claude (claude) added 2 commits October 9, 2026 15:24

Merge remote-tracking branch 'origin/main' into agent/fix-vendored-re…

f65a517

…resolved-version-drift

cursor Bot reviewed Oct 9, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 9, 2026

CI performance dashboard #1182

Open

Merge branch 'main' into agent/fix-vendored-reresolved-version-drift

3f9b3c7

Mikola Lysenko (mikolalysenko) enabled auto-merge October 9, 2026 18:23

Mikola Lysenko (mikolalysenko) disabled auto-merge October 9, 2026 18:51

Tanmay Singla (Tanmay182003) approved these changes Oct 9, 2026

View reviewed changes

Merge branch 'main' into agent/fix-vendored-reresolved-version-drift

c2508df

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue Oct 9, 2026

Merged via the queue into main with commit dfa7f42 Oct 9, 2026
45 of 53 checks passed

Mikola Lysenko (mikolalysenko) deleted the agent/fix-vendored-reresolved-version-drift branch October 9, 2026 21:39

cursor Bot reviewed Oct 9, 2026

View reviewed changes

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

Summary

Root cause

Fix

Scope

Tests

Local runs (on 949593f)

CI

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Mikola Lysenko (mikolalysenko) commented Oct 8, 2026 •

edited by cursor Bot

Loading

Local runs (on `949593f`)

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

Mikola Lysenko (mikolalysenko) commented Oct 9, 2026 •

edited

Loading