npm hosted pin next to a bundled copy can't be unwound: rollback/remove refuse it, and the vendored takeover skips the restore, so vendor --revert lands back on hosted and allow-remote=all stays

[agent] Found by the scheduled npm bug-hunt routine (ledger #302).

Summary

When a project installs name@version twice, once as a normal registry entry and once bundled inside another package (inBundle: true), a bare hosted scan rewires the normal entry and warns that the bundled copy stays unpatched (redirect_npm_bundled_instance_skipped). That's the documented behaviour. But afterwards socket-patch can't manage the pin it just wrote:

rollback and remove refuse it. They exit 1 with "package-lock.json wire(s) Socket-hosted patches that cannot be attributed to one package version … (patched_ref_unattributable: … also installs a bundled copy …)". The suggested fix is "re-run socket-patch scan --mode hosted", which writes the same state again. The only way out is git checkout.
The hosted → vendored takeover (scan --mode vendored) quietly skips the upstream restore. It exits 0, emits no vendor_takeover_reverted_redirect event, and records the hosted URL (with its grant token) as the vendor ledger's wiring original. The project .npmrc that hosted mode created (exactly allow-remote=all\n) is left in place.
Because of (2), vendor --revert lands back on the hosted pin, not upstream. .npmrc still says allow-remote=all, and rollback still refuses, as in (1).

Impact

A user who tries hosted mode on a project with a bundled duplicate (common: npm itself bundles ansi-regex, semver and others) can't undo it with socket-patch, and every suggested remedy loops.
Switching to vendored leaves allow-remote=all committed. On npm 12 that silently turns off the allow-remote=none default for every URL dependency, though no hosted entry needs it any more.
The vendor ledger keeps a grant-tokenized hosted lock fragment as the "pristine" original. The takeover code comment at crates/socket-patch-cli/src/commands/vendor.rs:2380 names this as exactly what the restore exists to prevent.

Expected (CLI_CONTRACT.md)

"Takeover reconciliation": vendoring over a hosted pin "first RESTORES that purl's lock entries to their default upstream registry entry … so the vendor ledger records the PRISTINE registry entry as its wiring original and vendor --revert lands back on upstream registry state, never on hosted". A purl whose upstream entry can't be restored "fails redirect_revert_failed … (exit 1 / partial_failure, nothing vendored for it, the hosted wiring left in place)". So it should either restore or refuse loudly. Today it does neither.
npm allow-remote unwind: "once rollback, remove or a hosted → vendored takeover has restored the last hosted entry … a project .npmrc holding exactly allow-remote=all\n … is deleted".
rollback / remove should be able to restore a pin that a plain hosted scan wrote. Without a bundled copy they can, and the same takeover prints Note: pkg:npm/ms@2.1.3 was hosted; restored its upstream registry entry (.npmrc, package-lock.json) before vendoring (mode takeover) and deletes .npmrc.

Repro (Linux, main `045d7ec`, reproduced twice on each npm)

The patch comes from a local mock of the public patch proxy (SOCKET_PROXY_URL=http://127.0.0.1:8787, routes /patch/batch, /patch/view, /patch/blob, /patch/package plus the hosted tarball), and every command gets --patch-server-url http://127.0.0.1:8787.

mkdir -p bsrc app
(cd bsrc && echo '{"name":"bund","version":"1.0.0","dependencies":{"ms":"2.1.3"},"bundleDependencies":["ms"]}' > package.json \
  && npm install && npm pack && mv bund-1.0.0.tgz ../app/)
cd app
echo '{"name":"app","version":"1.0.0","private":true,"dependencies":{"bund":"file:bund-1.0.0.tgz","ms":"2.1.3"}}' > package.json
npm install            # lock: node_modules/ms (registry) + node_modules/bund/node_modules/ms {inBundle: true}
git init -q && git add -A && git commit -qm init

socket-patch scan $PSU            # exit 0; node_modules/ms -> hosted URL; .npmrc = allow-remote=all
socket-patch rollback $PSU        # exit 1, patched_ref_unattributable; lock unchanged
socket-patch remove $PSU pkg:npm/ms@2.1.3   # exit 1, same
socket-patch scan --mode vendored $PSU --json
#   exit 0; no vendor_takeover_reverted_redirect event
#   .socket/vendor/state.json wiring[0].original.resolved = http://127.0.0.1:8787/npm/<uuid>/ms-2.1.3.tgz
#   .npmrc still "allow-remote=all"
socket-patch vendor --revert      # exit 0; lock back to the hosted URL; .npmrc still there

Result, the same on every cell:

hosted scan exit=0 .npmrc=allow-remote=all
rollback exit=1 lock="resolved": "http://127.0.0.1:8787/npm/1111…/ms-2.1.3.tgz"
remove exit=1
vendored takeover exit=0
  takeover event: False
  ledger original resolved: http://127.0.0.1:8787/npm/1111…/ms-2.1.3.tgz
  .npmrc after takeover: allow-remote=all
vendor --revert exit=0 lock="resolved": "http://127.0.0.1:8787/npm/1111…/ms-2.1.3.tgz" .npmrc=allow-remote=all

Control: the same project without bund passes. Rollback restores registry.npmjs.org, the takeover prints the restore note, and .npmrc is deleted.

OS	npm (lockfileVersion)	Reproduces
Linux	8.19.4 (v2) / Node 22	yes
Linux	10.9.4 (v3) / Node 22	yes (twice)
Linux	12.2.0 (v3) / Node 24	yes
macOS / Windows	—	untested (probe branches paused); the logic is OS-independent

First bad: not bisected. v4.0.0 used the ledger-based hosted design (its rollback needs .socket/manifest.json), so there's no like-for-like v4 cell.

Suspect code

crates/socket-patch-core/src/vex/discover/npm.rs:104-125: a ref whose purl also has a bundled copy is turned into a patched_ref_unattributable diagnostic and dropped from refs. That's right for VEX, but the same discovery feeds the management commands.
crates/socket-patch-cli/src/commands/vendor.rs:2200-2207: the takeover's hosted_pins come only from HostedPin::all(&discovery), i.e. attributable refs. A contested pin is invisible, so hosted_pin_of returns None, the restore block at :2385 is skipped, and the backend vendors on top of the hosted entry. The eject path does check inventory.contested_refusal() (vendor.rs:706), but the scan/get vendored takeover doesn't.
crates/socket-patch-core/src/patch/redirect/upstream/mod.rs:235-260: rollback / remove refuse any ContestedWiring, including this one, which the hosted rewriter itself produced. Its remedy text ("re-run socket-patch scan --mode hosted") loops.

Related but separate: #325 / draft #669 (in-run VEX attesting the bundled-contested purl) and #588 (an unwired same-lock registry copy). This issue is about unwinding hosted state, not attestation.

npm: run 19 ledger (#828, #812 comment)

[agent] Triaged: priority:p1 (npm). Not a duplicate. #325 / #669 and #588 / #589 are about VEX attestation. This issue is about unwinding hosted state: npm discovery drops a bundled-contested ref as patched_ref_unattributable, so the management commands can't see the pin hosted mode wrote. That is HostedPin::all in the vendored takeover, plus the ContestedWiring refusal in redirect/upstream/mod.rs. No open PR covers it. Not clustered with any other open issue.

Generated by Claude Code

[agent] Yarn classic bug-hunt routine (ledger #304): yarn classic reproduces this too, with a git-sourced copy of the same name@version instead of a bundled one. I'm adding the matrix here rather than filing a duplicate, since the refusal is the same ContestedWiring path. The trigger is new with #710 (the #363 fix, cfe060d). Before it, the git block was rewired too (and broke installs), so this state couldn't arise.

Shape: a yarn workspace where a depends on left-pad@^1.3.0 (registry) and b on left-pad@git+https://github.com/stevemao/left-pad.git#v1.3.0. yarn.lock then has a registry block and a git block, both 1.3.0. Local mock patch API, SOCKET_PATCH_SERVER_URL set to it.

yarn install && git add -A && git commit -qm init
socket-patch scan --mode hosted      # exit 0, redirected: 1, redirect_yarn_classic_git_skipped; registry block pinned
socket-patch scan --mode hosted      # exit 0 (re-run)
socket-patch list                    # exit 1, hosted_wiring_contested
socket-patch rollback                # exit 1, patched_ref_unattributable ("… installs from git …"); lock unchanged
socket-patch remove pkg:npm/left-pad@1.3.0   # exit 1, hosted_wiring_contested
socket-patch repair                  # exit 0, lock still pinned
socket-patch scan --mode vendored --vendor-source service
#   exit 0, no vendor_takeover_reverted_redirect event;
#   .socket/vendor/state.json wiring original = the hosted URL
socket-patch vendor --revert         # exit 0; yarn.lock back on the hosted pin, not upstream
socket-patch rollback                # exit 1 again

Linux, Node 22, main 4646693:

yarn	hosted scan	rollback / remove / list	hosted → vendored takeover restores upstream	`vendor --revert` lands on
1.0.2	exit 0, pinned	refused (exit 1)	not run	—
1.7.0	exit 0, pinned	refused (exit 1)	not run	—
1.10.1	exit 0, pinned	refused (exit 1)	no (ledger original = hosted URL)	hosted pin
1.22.22	exit 0, pinned (×2)	refused (exit 1, ×2)	no (ledger original = hosted URL)	hosted pin

The pure-vendored flow on the same project is fine: it wires the registry block, warns vendor_yarn_classic_git_entry_skipped, and rollback is byte-exact. vex never attests here, as documented. The yarn-side discovery that turns the git sibling into patched_ref_unattributable is crates/socket-patch-core/src/vex/discover/yarn.rs (added in #710). So a fix in upstream/mod.rs / the takeover's hosted_pins should cover yarn classic too. Please include a yarn classic git-sibling case in its tests.

Generated by Claude Code

Being fixed in draft PR #1008 (batch fix for open pm:npm issues).

Fix hosted pin beside a bundled copy that rollback can't unwind (#828)

[agent] Yarn classic bug-hunt routine (ledger #304): a third trigger for the same ContestedWiring refusal, an npm: self-alias. This needs no git or bundled copy, only yarn 1.22.22 and a plain package.json. Main 05ecc6e, Linux, ×2. I'm adding it here so the in-progress fix (#1008) can cover it.

echo '{"name":"p","version":"1.0.0","private":true,"dependencies":{"left-pad":"1.3.0","lp":"npm:left-pad@1.3.0"}}' > package.json
yarn install      # yarn 1.22.22 writes two blocks: `left-pad@1.3.0:` and `"lp@npm:left-pad@1.3.0":`
socket-patch scan --mode hosted     # pins left-pad@1.3.0, skips the alias block with redirect_yarn_classic_alias_skipped (documented), exit 0
socket-patch rollback               # exit 1 patched_ref_unattributable: lock entry `"lp@npm:left-pad@1.3.0"` installs it from registry.yarnpkg.com …
socket-patch remove pkg:npm/left-pad@1.3.0   # exit 1, same
socket-patch list --json            # exit 1
socket-patch scan --mode hosted     # exit 0, writes the same state again (the suggested remedy loops)
socket-patch scan --mode vendored   # exit 0, "applied", no takeover-revert event
socket-patch vendor --revert        # exit 0, but yarn.lock's left-pad@1.3.0 block is back on the hosted URL, not upstream

So it's the same three symptoms as the npm bundled case: management commands refuse the pin the scan just wrote, the vendored takeover skips the upstream restore, and vendor --revert lands on hosted.

yarn 1.10.1 isn't affected: it merges the two keys into one block (left-pad@1.3.0, "lp@npm:left-pad@1.3.0":), which hosted pins as a whole, and rollback works. Any yarn release that keeps the alias in its own block (1.22.22 here) hits it.

Generated by Claude Code

Fix hosted pin beside a shrinkwrapped or git copy that rollback can't…

Document shadowing of pins beside same-lock unpatched copies

Merge origin/main into agent/fix-npm-open-issues

Merge main into agent/fix-npm-open-issues

Navigation Menu

Repository navigation

npm hosted pin next to a bundled copy can't be unwound: rollback/remove refuse it, and the vendored takeover skips the restore, so vendor --revert lands back on hosted and allow-remote=all stays #828

Summary

Impact

Expected (CLI_CONTRACT.md)

Repro (Linux, main `045d7ec`, reproduced twice on each npm)

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

npm hosted pin next to a bundled copy can't be unwound: rollback/remove refuse it, and the vendored takeover skips the restore, so vendor --revert lands back on hosted and allow-remote=all stays #828

Description

Summary

Impact

Expected (CLI_CONTRACT.md)

Repro (Linux, main 045d7ec, reproduced twice on each npm)

Suspect code

Activity

mikolalysenko commented on Oct 5, 2026

mikolalysenko commented on Oct 5, 2026

mikolalysenko commented on Oct 7, 2026

mikolalysenko commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Repro (Linux, main `045d7ec`, reproduced twice on each npm)