Bug hunt ledger: Yarn classic (1.x)

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Yarn classic (1.x) bug-hunt routine (label pm:yarn-classic).

Last updated: 2026-10-09 (run 37), main 9ab72d4 (the 5.0.0 release commit is merged, but the latest tag is still v4.0.0). Run 37 filed nothing new. #1158 / #1081 are verified fixed by #1180 and #1236's main shape by #1242 (its member-relative follow-up does not reproduce: yarn 1 locks member file: paths root-relative). #1271 and #558 still reproduce on main; open PRs #1274 and #1328 fix them (verified on the PR heads, incl. the scoped @s/p@: shape). Run 36: Run 36 filed #1271: a yarn.lock key with an empty range (left-pad@: from "left-pad": "", or a merged left-pad@, left-pad@^1.3.0: block) is dropped by lock-only discovery and unmatched by the hosted and vendored rewriters (split_pattern rejects an empty range). It reproduces on v4.0.0 too. Run 36 also re-ran the EOL battery after #1227 (vendored writers now use the majority line ending) with no regression, and re-confirmed #692 and #558. #1236's follow-ups (renamed tarball / member copies) are tracked on that issue and PR #1242. Run 35 re-ran the batteries after #1008 (npm-family vendoring now goes through one generic driver, and #828 adds shadowed pins) with no regression, and filed #1236: a file: directory or git copy of the patched package under another dependency name ("lp2": "file:./lpdir") isn't seen by hosted, vendored, in-run VEX or lock-only VEX, the renamed counterpart of #921. PR #1180 (#1158 / #1081) is still open. Run 34 re-ran the hosted / vendored / agent batteries after #1058 / #1147 / #1160 with no new yarn-only bug. On main a hosted scan with an npm: alias beside a direct copy now pins nothing (redirect_unattributable); open PR #1180 fixes that, #1158 and #1081 (verified at 46f1bc0). Previously: Runs 5–33 added the cells in "Run 5 cells" through "Run 33 cells" below. Run 33 checked #1039 (the staged, atomic vendored→hosted takeover) and #1117 (BOM handling); the only new fail is #1158 (a takeover un-patches a vendored npm: alias copy beside a pinned direct copy). Run 32 checked #1057 (the yarn grammar refactor; it fixes the hosted half of #467), #1050 and #1029 with no regressions. #1013 / #1078 / #519 are closed by #1083 / #1033; run 31 verified the mirror fix cross-OS. Since run 28, #364, #921, #857, #884, #831, #974, #938 (#940) and #907 (#917) are closed by merged fixes, and #1071 (#1073) and #975 (#978) have landed too; the old fail #364 cells now mean a project-level mirror is refused (pass), and #1115 (a mirror in a workspace member's .yarnrc) is the remaining mirror gap. The project-mode matrix below was measured on f6b7fb9 (v4); cells marked "(v5)", the global matrix and the "v5 project-mode cells" list were re-run on v5.

Coverage matrix

Cells are "pass", "fail #N", "n/a", "CI" or "untested". H = hosted, V = vendored, A = agent (scan --apply + setup). Each H/V cell ends with a real fresh-checkout yarn install --frozen-lockfile, using a local mock patch API. CI's yarn-classic-matrix (1.0.2, 1.6.0, 1.7.0, 1.9.4, 1.10.1, 1.22.22) covers the plain single-dep H/V flows plus VEX on Linux.

OS	yarn	H baseline	H offline mirror	H/V git dep (git+…)	H/V multi-version workspaces + scoped	H⇄V takeover + rollback	H/V CRLF lock + rollback	V baseline	V offline mirror (+pruning, rollback)	A apply + setup
Linux	1.0.2	pass	n/a (yarn limitation)	H pass (run 20, #363 fixed)	H pass	untested	H pass (run 16)	n/a (yarn ≤1.6 can't install file: tarballs)	n/a	pass
Linux	1.1.0 / 1.2.1 / 1.4.0 (run 26)	pass	untested	untested	H pass (run 26)	H→V→H pass (V n/a ≤1.6)	H pass (run 26)	n/a (yarn ≤1.6)	n/a	pass (run 27)
Linux	1.3.2 / 1.5.1 (run 23, 26)	pass	untested	untested	H pass (run 26)	H→V→H pass (V n/a ≤1.6)	H pass (run 26)	n/a (yarn ≤1.6)	n/a	pass
Linux	1.6.0	pass	n/a (yarn limitation)	untested	H pass	untested	H pass (run 16)	n/a (yarn ≤1.6)	n/a	pass (run 17)
Linux	1.7.0	CI	refused (#364 fixed, untested on run 28)	pass (run 20, #363 fixed; V git-only: #857)	pass	pass (run 16)	pass (run 16)	pass	untested	pass (run 17)
Linux	1.9.4	CI	refused (#364 fixed, untested on run 28)	untested	H pass (run 26)	pass (run 26)	H pass (run 26)	CI	pass (run 16)	pass (run 17)
Linux	1.10.1	pass	refused (#364 fixed); outside-project / env / BOM mirror refused (#1013 / #1078 fixed, run 31); member .yarnrc mirror: fail #1115	V git-only: #857 (run 20)	pass	pass	pass (run 16, + BOM)	pass	pass	pass (+ --install.modules-folder, run 9)
Linux	1.10.0 / 1.19.0 / 1.19.1 / 1.22.0 (run 24)	pass (+ warm in-place, vex)	untested	untested	untested	untested	untested	pass (+ byte-exact rollback)	untested	pass
Linux	1.17.3	pass (in-place)	refused (#364 fixed, untested on run 28)	untested	untested	untested	untested	pass (in-place)	pass (run 16)	pass (run 17)
Linux	1.22.22	pass (v5, + hosted rollback pass)	refused (#364 fixed); outside-project / env / BOM mirror refused (run 31); member .yarnrc mirror: fail #1115	pass (run 20, #363 fixed by #710; V git-only: #857; H pin + git sibling: #828)	pass	pass	pass	pass	pass	pass
macOS	1.7.0	untested	untested	fail #363	pass	pass	pass	pass	pass (run 18)	pass (run 18)
macOS	1.10.1 / 1.22.22	pass (probe)	refused: user / prefix / parent / env / BOM layers (probe, run 31)	fail #363	pass	pass	pass	pass	pass (run 18)	pass (run 18)
Windows	1.7.0 / 1.10.1 / 1.22.22	pass (probe)	refused: user / prefix (node dir) / parent / env / PS 5.1 BOM / backslash path (probe on 1.10.1 / 1.22.22, run 31)	fail #363 (vendored: Couldn't find the binary git)	pass	pass	pass	pass	pass (run 18)	pass (run 18)

Global mode (-g) on v5 2463257 (rows marked run 10 re-measured on 045d7ec)

Report = scan -g report-only + no leakage; refusal = scan -g/--global-prefix/SOCKET_GLOBAL --mode hosted exits 2; A = agent apply + import + vex -g + rollback -g byte-exact; get-mode = get -g --mode hosted|vendored / scan -g --mode vendored; RO = read-only global folder fails loudly.

OS	yarn	report	refusal	A apply/vex/rollback	get-mode	RO	custom global-folder (space+unicode)
Linux	1.1.0 / 1.3.2 (run 23)	pass	untested	pass	untested	untested	untested
Linux	1.0.2	fail #437 (still on 203e092)	pass	fail #437	fixed (#436 closed by #446; not re-run)	n/a (nothing found)	untested
Linux	1.6.0 / 1.9.4 / 1.10.1 / 1.22.22 (+ corepack 1.22.22), run 10	pass	pass	pass	pass (#436 fixed)	pass (CI runner)	pass (all)
macOS	1.0.2	fail #437 (run 10)	pass	fail #437	pass (run 10)	n/a	pass (run 10)
macOS	1.6.0 / 1.9.4 / 1.10.1 / 1.22.22 (+ corepack), run 10	pass (after warming the mock, see Known non-bugs)	pass	pass	pass (#436 fixed)	pass	pass
Windows	1.0.2	fail #437 (run 10; #434 fixed)	pass	fail #437	pass (run 10)	untested	pass (run 10)
Windows	1.6.0 / 1.9.4 / 1.10.1 / 1.22.22 (+ corepack), run 10	pass (#434 fixed)	pass	pass	pass (#436 fixed)	untested	pass (space+unicode)

GitHub deps with a real codeload install (owner/repo#tag, github:, archive URL), H and V + frozen + vex + V rollback: pass on Linux / macOS / Windows × 1.7.0 / 1.10.1 / 1.22.22 (run 22 probe).

Other cells that pass on Linux 1.22.22 (some also on older releases; see the entries): spaces + unicode project paths (also macOS and Windows), npm: alias (H skipped as documented, V rewired), resolutions, a resolved without the #sha1 fragment / integrity, a local file: tarball dep, a non-deduplicated lock, a superseding patch on re-scan, remove / repair, VEX (installed and lock-only, after yarn upgrade), yarn add then a frozen reinstall (1.7.0 too), yarn check --integrity / --verify-tree, in-place reinstalls on 1.7–1.22, concurrent scans (lock_held), the GitHub shorthand dep on all 3 OSes.

v5 project-mode cells (Linux, run 4)

• Mixed CRLF+LF lock, H and V: fail Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (line endings converted; rollback not byte-exact).
• Uniform CRLF / BOM+CRLF: H⇄V takeovers + rollback, pass. --dry-run byte-identity (H / V / A / rollback) on CRLF / BOM / mixed, pass.
• V service artifacts: workspaces + multi-version + merged key + npm: alias, vex / vendor --check / repair / frozen offline / rollback, pass (1.22.22).
• V + offline mirror + pruning: pass (1.7.0 / 1.10.1 / 1.22.22).
• No-integrity (1.7-style) locks, H and V: pass (1.7.0 / 1.22.22). Tarball-URL dep, H and V: pass. file: dir dep, H: pass.
• SIGKILL-interrupted scans, H and V: pass (recoverable by repair / re-scan).

Run 5 cells (Linux, 61cfb9b)

• .yarnrc --modules-folder, agent mode: fail Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 (1.7.0 / 1.10.1 / 1.22.22); fixed by Fix npm crawler missing configured install roots (#493, #518) #520 (see run 9).
• Workspaces with nohoist, A/H/V + frozen install + vex: pass (1.22.22).
• --max-new-patches on a workspace, A/H/V + re-run + frozen install: pass (1.22.22).
• Custom .yarnrc registry, hosted rewire + rollback: pass (rollback uses SOCKET_NPM_REGISTRY, as documented).
• Hosted over an installed tree, then an in-place frozen reinstall: pass.
• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 re-checked: still fails (1.22.22).

Run 6 cells (Linux, 61cfb9b)

• PnP (installConfig.pnp) with a stale .pnp.js + hosted pin → vex: fail In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 (1.12.3 / 1.17.3 / 1.22.22). PnP scan refusal in all modes: pass. PnP lock-only hosted + frozen install: patched.
• --modules-folder + stale deps/ + hosted pin → vex: fail Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 (commented; 1.10.1 / 1.22.22). --modules-folder hosted / vendored + frozen install: pass.
• optionalDependencies incl. platform-skipped fsevents, H/V + frozen install + vex: pass (1.22.22).
• Uppercase names (JSONStream), A/H/V + frozen + vex + rollback: pass. yarn import locks, H/V: pass.
• Hosted pin Authorization leakage (6 .npmrc auth configs): none on 1.0.2 / 1.6.0 / 1.9.4 / 1.12.3 / 1.17.3 / 1.22.22: pass.

Run 7 cells (61cfb9b)

• Dev flow after scan (yarn add, then a frozen fresh install, vex, vendor --check, --pure-lockfile reinstall), H and V: pass on Linux 1.0.2 / 1.6.0 (H) and 1.7.0 / 1.10.1 / 1.22.22, Windows 1.7.0 / 1.10.1 / 1.22.22, macOS 1.7.0 / 1.22.22 (probe).
• --production install, hosted + vex: pass (1.22.22). integrity sha1- locks, H / V + rollback: pass (1.10.1 / 1.22.22).
• Odd range keys (">= a < b", ||, x, hyphen, latest, v-prefix), H: pass. Workspace member under tests/ + socket.yml policies (A/H): pass.
• yarn set version classic layout (.yarnrc.yml yarnPath + packageManager), A/H/V: pass. vendor --revert on LF / CRLF / BOM+CRLF (1.7.0 / 1.22.22): byte-exact.

Run 8 cells (Linux, 61cfb9b)

• Hosted grant without integrity.sha1 → fragmentless resolved → yarn cache-slot collision: fail Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558. Warm-cache frozen install: 1.0.2 / 1.7.0 / 1.10.1 / 1.17.3 silently install unpatched bytes; 1.19.0 / 1.21.1 / 1.22.22 fail Incorrect integrity when fetching from the cache. v4.0.0 is affected too.
• Merge-conflict markers in yarn.lock (target outside the conflict), H: pass. --focus workspace install, H: pass. yarn audit on hosted / alias locks: pass. .yarnclean, H + vex: pass (1.22.22).
• Hosted rollback on an integrity sha1- lock: restores sha512 integrity + npmjs host (documented), frozen install OK: pass (1.10.1).

Run 9 cells (Linux, 203e092)

• Patch rewriting the package's own package.json (adds a dependency): fail Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591. Vendored leaves a dangling dependencies: entry (offline frozen install fails, lock churns) on 1.7.0 / 1.10.1 / 1.22.22. Hosted never installs the new dep, and vex attests (1.10.1 / 1.22.22).
• Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 follow-ups after Fix npm crawler missing configured install roots (#493, #518) #520: workspace root --modules-folder + non-hoisted members (agent, 1.22.22) and --install.modules-folder "./my deps" (agent + vex + frozen-reinstall omission, 1.10.1): pass.
• Agent vex with multiple installed copies across workspaces (Fix agent vex checking only one installed copy (#516) #517): pass (1.22.22).
• Repo suites (redirect / vendor / dev-flow, REQUIRED=1): pass on 1.0.2 / 1.7.0 / 1.22.22.
• Superseding hosted patch followed by an in-place frozen install: pass on 1.10.1 / 1.17.3 / 1.22.22. 1.0.2 / 1.7.0 skip the copy only when size+mtime match (yarn limitation, see Known non-bugs).

Run 10 cells (045d7ec)

• Symlinked yarn.lock (yarn.lock -> ../shared/yarn.lock): hosted refuses (redirect_symlinked_file_unsupported); vendored replaces the link with a regular file, leaving the target unpatched: fail Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 (1.7.0 / 1.10.1 / 1.22.22; npm's package-lock.json too). --dry-run gives no signal, and rollback doesn't restore the link. yarn itself writes through the link.
• yarn.lock file mode 600 / 444 / 755 preserved through H / V scan + rollback: pass (1.22.22).
• Patch that changes an existing dependency range (is-odd is-number ^6 → ^7): same as Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 (commented). Vendored leaves ^7.0.0 unpinned, and hosted installs 6.0.0 under a manifest that asks for ^7.
• Agent mode with a link: dep: patches the link target outside the project (the code Node loads). Design question, not filed.
• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 re-checked: still reproduces (H and V, 1.22.22).

Run 11 cells (Linux, 045d7ec)

• No trailing newline (LF / CRLF, target block last) and CRLF + trailing blank lines, H and V + fresh frozen install + rollback: pass (1.22.22).
• Symlinked .socket/ or .socket/vendor/npm, single project, V: pass (consistent). Two projects sharing a symlinked .socket/vendor/npm: fail Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 (1.7.0 / 1.10.1 / 1.22.22).
• yarn remove of a vendored package, then rollback / remove / vendor --revert: fail After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 (1.7.0 / 1.22.22). Hosted same flow: pass.

Run 12 cells (045d7ec)

• Vendored workspaces, installs from a member dir (cd b && yarn install --frozen-lockfile, yarn --cwd b install, yarn workspace b add), cold cache: fail Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 on Linux / macOS / Windows × 1.7.0 / 1.10.1 / 1.22.22 (probe run 37123949202). Root installs pass. Warm-cache member installs pass (masking).
• Vendored block merged by yarn with a second range (a@^1.1.0, a@^1.3.0:) → rollback / remove / vendor --revert: fail Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 (Linux 1.7.0 / 1.10.1 / 1.22.22). Re-vendor says already_vendored and doesn't re-key.
• yarn add/yarn upgrade that re-keys or re-resolves the vendored block: the After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 shape (fix in flight, Fix vendored revert keeping artifact for removed lock entry (#665) #689).

Run 13 cells (Linux, 045d7ec)

• Hosted with a merged key created after the scan → rollback: pass (1.22.22). Hosted isn't affected by Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692.
• Vendored Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 shape: vendor --check reports OK and repair is a no-op while rollback fails: fail Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 (commented).
• Merged key already present before vendoring, V + frozen install + rollback byte-exact: pass (1.22.22).
• Scoped merged key: H frozen install on 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 pass; V on 1.7.0 / 1.10.1 / 1.22.22 pass (rollback byte-exact); H⇄V takeover chain + re-run + rollback pass.

Run 14 cells (Linux, 045d7ec)

• Fork alias "left-pad": "npm:async@1.3.0" and the yarn-merged left-pad@1.3.0, "left-pad@npm:async@1.3.0": block, H/V/A: all fail-closed, pass (1.22.22).
• agent → hosted takeover + rollback: pass. agent → vendored takeover + rollback / remove / vendor --revert: fail Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 (node_modules left patched, record dropped, yarn's next frozen install is "Already up-to-date"). 1.7.0 / 1.10.1 / 1.22.22.
• Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 shape: vendor --check OK and repair no-op: fail Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 (commented).
• yarn.lock + package-lock.json together, H and V: pass. Hosted vex before reinstall: not_applied, pass. --link-duplicates agent apply / vex / rollback: pass.

Run 15 cells (Linux, 045d7ec)

• Bundled copy (bundledDependencies) of the patched name@version beside the normal copy: fail Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758. The scan gives no warning. The hosted in-run --vex attests, and vendored in-run and post-install vex attest, while the bundled copy stays unpatched. Hosted post-install vex and agent mode are correct. 1.7.0 / 1.10.1 / 1.22.22.
• get <uuid> --mode hosted|vendored|agent (project mode) + frozen install + vex: pass. list (H / V / A / CRLF+BOM merged-key workspace / --json): pass (1.22.22).
• scan --mode vendored --prune after yarn remove: entry kept (keptVendoredEntries), fail After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 (PR Fix vendored revert keeping artifact for removed lock entry (#665) #689 covers the prune path).
• Vendored odd range keys merged into one block (hyphen, ||, >= <, v-prefix) + frozen install + rollback byte-exact: pass. 20k-block lock hosted scan: 2.9 s, pass.
• vendored → agent → reinstall → apply → rollback → frozen reinstall: pass (1.22.22).

Run 16 cells (045d7ec)

• Windows path shapes (probe, windows-latest, yarn 1.10.1 / 1.22.22; H/V scan + fresh frozen install + rollback, A apply + vex + rollback): a >MAX_PATH project path (345 chars), a directory-junction project dir, a subst drive (--cwd X:/p from another drive, and run inside X:\), cross-drive --cwd both ways, a backslash --cwd: all pass. yarn on Windows writes CRLF locks natively (os.EOL), and H/V rollback restores them byte-exact.
• Linux: CRLF H/V + rollback (1.0.2 / 1.6.0 H; 1.7.0 / 1.10.1 H+V), H⇄V takeover chain on 1.7.0 and BOM+CRLF on 1.10.1, V offline mirror on 1.9.4 / 1.17.3, yarn add (1.7.0) then rollback, a lock-only workspace with an alias, conflict markers around the target (fail-closed), a missing vendored artifact (vex omits it): all pass. Also a 414-char path and a symlinked project dir.

Run 17 cells (045d7ec)

• Cross-OS vendored checkout portability (probe run 37226728998, yarn 1.22.22): a project vendored on Linux, macOS or Windows, then installed --frozen-lockfile --offline (cold cache), vendor --check, vex --offline, list and rollback on each of the three OSes. All 9 cells pass, with rollback byte-exact (CRLF for a Windows producer). Windows writes forward-slash file:./.socket/… paths.
• A 4-package project (prerelease ms@3.0.0-canary.1, dotted lodash.isequal, scoped @types/left-pad, left-pad): H pass on 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22, V pass (byte-exact rollback) on 1.7.0 / 1.10.1 / 1.22.22, A (apply + vex + rollback) pass on 1.6.0 / 1.7.0 / 1.9.4 / 1.17.3 / 1.22.22.
• Private-registry resolved URLs (Verdaccio %2f, Nexus, a URL with no .tgz basename), H and V: pass. A vendored grant without sha1: vendored computes #sha1, and the warm-cache install is patched (not Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558). A tampered vendored tarball → check fails, vex omits it, repair restores: pass. Vendored re-run idempotent, and V→H→V: pass. get <purl> for prerelease / scoped purls (%40 or @): pass.

Run 18 cells (045d7ec)

• macOS + Windows probe (run 37248870997; yarn 1.7.0 / 1.10.1 / 1.22.22): project agent apply + vex + rollback + re-run, pass. V + offline mirror + pruning (fresh offline frozen, in-place offline, byte-exact rollback, post-rollback offline install), pass. agent → vendored takeover + rollback: fail Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 on all 6 cells (commented).
• Linux warm-cache H / V / A (+ V / A rollback) on 1.12.3 / 1.13.0 / 1.15.2 / 1.16.0 / 1.18.0 / 1.19.2 / 1.21.1: pass.
• Multi-hash integrity "sha1-… sha512-…" target block, H / V: pass. Lookalike same-version blocks (@evil/left-pad, my-left-pad) untouched: pass. Hosted workspace member-dir frozen installs (cd member, --cwd member): pass.

Run 19 cells (Linux, 045d7ec)

• Vendored + .gitignore covering the artifact (*.tgz, vendor/, .socket/), then commit, fresh clone and frozen install: fail Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 on 1.7.0 / 1.10.1 / 1.22.22. The scan exits 0 silently. With vendor/ or .socket/ ignored, vendor --check in the clone also exits 0.
• Vendored + .gitattributes * text eol=lf / * text=auto eol=crlf: pass (1.22.22). * text eol=crlf corrupts the .tgz (see Known non-bugs).

Run 20 cells (Linux, 4646693)

• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 verified fixed on real yarn: git-only dep, H (1.0.2 / 1.7.0 / 1.22.22) and V (1.7.0 / 1.22.22), lock untouched, frozen installs OK, nothing attested: pass.
• Hosted pin beside a git sibling (workspace registry + git+… copies): rollback / remove / list refuse, the takeover skips the restore, and vendor --revert lands on hosted: fail, 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 (commented) on 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22. Pure vendored on the same shape: pass.
• Vendored git-only dep: misleading vendor_lock_entry_not_found and the git warning dropped: fail Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 (1.7.0 / 1.10.1 / 1.22.22).
• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still reproduces (1.10.1 / 1.22.22). Run-18 battery (agent, V + mirror) on 4646693: pass. Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 still fails.
• GitHub shorthand after Fix yarn classic rewiring git-sourced lock blocks (#363) #710: blocked (no codeload access in the sandbox).

Run 21 cells (Linux, 9c43dfc)

• Hosted scan / get --mode hosted from a workspace member with a non-hoisted copy (version conflict or nohoist): exit 0 success, redirected: 0, npm-only redirect_npm_no_lockfile: fail Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 on 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 (×2 each). Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598 refuses only pnpm and cargo members. npm workspaces have the same symptom, handed to the npm ledger.
• Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 verified fixed (Fix vendored mode replacing symlinked lockfiles (#627) #802): vendored refuses a symlinked yarn.lock with redirect_symlinked_file_unsupported, and the target is untouched: pass.
• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 still reproduces (H and V mixed-EOL rewrite / rollback not byte-exact). Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still reproduces, and the code is now vendor_lock_entry_removed (commented).
• GitHub shorthand owner/repo#tag and github:owner/repo#tag (synthetic codeload lock, real yarn installs from the hosted / vendored URL): H rewire + frozen fresh install on 1.7.0 / 1.22.22 + vex: pass. V rewire + frozen install + byte-exact rollback: pass. H rollback lands on the npm registry tarball, not the original codeload URL (contract: "default upstream entry"); recorded as a design question.
• Write every utils::fs atomic file through one stage-and-rename core (#728) #858 atomic writes: yarn.lock mode 0640 preserved (H/V): pass. A hard-linked yarn.lock is split from its other link (expected for stage-and-rename; not filed).
• Compute sha256, sha1 and SRI digests through utils::digest (#706) #865 digests: a vendored grant without sha1 computes the right #sha1 (it matches sha1sum), and frozen installs on 1.7.0 / 1.22.22 pass.
• nohoist workspace from the root: A apply / rollback, H and V frozen fresh installs patched in the member, vex: pass.
• Twin lock (yarn.lock + package-lock.json) after Fix npm VEX attesting a patch the twin lock lacks (#798) #799: vendored wires yarn.lock with vendor_multiple_lockfiles, and vex refuses patched_ref_unattributable (fail-closed, as Fix npm VEX attesting a patch the twin lock lacks (#798) #799 intends).

Run 22 cells (9c43dfc)

• Hosted pin on a v1 lock, then a berry (4.18.1) install: fail Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907. Berry migrates the lock and installs unpatched, and hosted gives no warning (even with packageManager: yarn@4). Vendored warns with yarn_classic_berry_migration_risk. Locks from 1.7.0 / 1.10.1 / 1.22.22.
• GitHub shorthand / github: / archive-URL deps with real codeload (probe run 37395884885): 27/27 pass on all 3 OSes × 1.7.0 / 1.10.1 / 1.22.22. yarn writes no integrity for codeload entries.
• PR Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901 (unmerged) fixes Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 on yarn 1.7.0 / 1.22.22: plain, object-form + nohoist, and **-glob members are refused, and a nested separate project still pins. PR Fix hosted yarn classic with an offline mirror (#364) #839 (unmerged) turns Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 into a redirect_yarn_classic_offline_mirror skip; frozen online and --offline installs work, unpatched.
• Agent + yarn add (re-copy) then vex: not_applied, pass. A first-party workspace member named like the patched package: refused in all modes, pass. The vendored migration warning is suppressed by yarn@1… pins, pass.

Run 23 cells (Linux, 9c43dfc)

• file: directory copy of the patched name@version beside a registry copy (workspace member file:../forks/left-pad): fail Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921. H / V give no warning; lock-only vex (H and V) and V post-install vex attest not_affected while b/node_modules/left-pad stays unpatched. 1.0.2 (H) / 1.7.0 / 1.10.1 / 1.22.22. H post-install vex and agent: correct. When the file: block is the only copy, hosted --json is silent (redirected: 0, no warning) and V says vendor_lock_entry_not_found (same issue).
• 1.3.2 / 1.5.1: H baseline + vex, A apply + vex + rollback: pass. Global -g report / agent / rollback on 1.1.0 / 1.3.2: pass.

Run 24 cells (Linux, 9c43dfc)

• A registry block beside the pin for the same name@version, after yarn add -W left-pad --exact: fail Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938. A fresh frozen install installs only the unpatched registry copy. Lock-only vex (H/V), V post-install vex and vendor --check all pass it as patched. 1.7.0 / 1.10.1 / 1.22.22. Non-exact re-adds, upgrade and member ranges merge into the pinned block: pass.
• --package (name / scoped / purl ± version), --min-severity (+ --package), agent --sync after yarn remove, agent --strict with a local edit, vendored 3-package remove <purl> + byte-exact rollback: pass (1.22.22).
• Boundary releases 1.10.0 / 1.19.0 / 1.19.1 / 1.22.0, H / V / A with 3 packages incl. scoped: pass.
• A lockfile-less yarn project (--install.no-lockfile): hosted success / redirected: 0 with the npm-only redirect_npm_no_lockfile text. Naming nit, not filed (see Known non-bugs).

Run 25 cells (Linux, 9c43dfc)

• Agent scan <PATH> in a workspace with nested duplicate copies (members a and b both have their own left-pad@1.3.0, and the root has 1.2.0): scan packages/a (also /**, ./, absolute, and the copy path) scans 0 packages, exits 0 and patches nothing, while scan packages/b selects it and rollback packages/a selects both copies. Fail, commented on Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 (pnpm, same seen dedup root; yarn's case has real copies, not links). 1.7.0 / 1.10.1 / 1.22.22, ×2 each.
• Hosted scan <member> / scan 'packages/*' (positional PATH = per-dir --cwd): the Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 shape, commented on Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884.
• PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940 (980b7b6) fixes Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 on 1.7.0 / 1.10.1 / 1.22.22 (H and V lock-only vex omit it, V post-install vex omits it, vendor --check exits 1). Controls (merged pinned block in a workspace; non-workspace transitive ^1.3.0 + exact root re-add) still attest, and their installs are patched. Commented on Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938.
• PR Fix yarn classic unrewritable copies going unreported (#921, #857) #924 (f791612) fixes Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on 1.7.0 / 1.22.22: H warns redirect_yarn_classic_directory_skipped, V warns via events[].reason, vex omits it, and the file:-only V refusal names the copy. Commented on Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 (the V warning is not a coded warning, a minor asymmetry).
• Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 variant, non-workspace: a transitive ^1.3.0 + yarn add left-pad@1.3.0 --exact merges into the pinned block (patched, attested): pass. Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 needs the workspace -W shape.
• get CVE-… / get GHSA-… in H / V / A + frozen install + vex: pass (1.22.22). --download-mode file|diff agent apply + vex + re-apply after deleting blobs: pass.
• --manifest-path custom/m.json: hosted writes no manifest; vendored ignores it (ledger + lock at --cwd). vex attests either way. list --manifest-path custom/m.json resolves the project root from the manifest path (documented), so it says "No patches".
• Same-basename tarballs (left-pad@1.2.0 + @types/left-pad@1.2.0): V + offline mirror + pruning (fresh offline frozen, in-place, vex, byte-exact rollback) and H cold / warm-cache frozen installs on 1.7.0 / 1.10.1 / 1.22.22: pass. The vendored path is <uuid>/@types/left-pad-1.2.0.tgz.
• link: copy beside a registry range: yarn 1.22.22 links every range of that name (lock version "0.0.0"), so there's no registry block to pin. That's yarn's behaviour; nothing to test.

Run 26 cells (9c43dfc)

• npm wrapper @socketsecurity/socket-patch@4.0.0 installed with yarn 1 on Alpine (musl): fail On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974. yarn 1 ignores libc, so it installs both -linux-x64-gnu and -musl; the wrapper picks -gnu first, the spawn fails ENOENT, and it exits 1 with no output. yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 in node:22-alpine all fail; npm 10.9 on Alpine (musl only) and yarn on bookworm (glibc) pass (probe run 37554067537).
• Old releases 1.1.0 / 1.2.1 / 1.3.2 / 1.4.0 / 1.5.1 / 1.9.4: hosted CRLF lock (fresh frozen install patched, rollback keeps CRLF, post-rollback frozen install unpatched), hosted multi-version workspace + scoped member, H→V→H takeover + rollback: pass (V leg n/a on ≤1.6).
• Lock churn: a plain non-frozen yarn install after H / V scan leaves yarn.lock byte-identical and the tree patched (1.7.0 / 1.10.1 / 1.22.22): pass.
• BOM-prefixed package.json (root, workspace root, member), A / H / V + vex: pass (1.22.22).
• npm: self-alias copy ("lp": "npm:left-pad@1.3.0") beside a direct left-pad@1.3.0: H pins the direct block, warns redirect_yarn_classic_alias_skipped and vex refuses (no attestation); V wires both blocks and both install patched; vex attests: pass (1.22.22).
• Agent rollback packages/a with nested copies in a and b rolls back both: documented (CLI_CONTRACT "Path-scoped scans": a selected purl is handled with all its copies).

Run 27 cells (9c43dfc)

• Git merge of two branches that each vendored a different package, state.json resolved with --ours / --theirs: fail Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991. vendor --check and rollback exit 0 while the other package stays wired. Rollback deletes the ledger, which strands that package (later rollback / re-vendor refuse with an inapplicable "restore from version control" remedy). 1.7.0 / 1.10.1 / 1.22.22 ×2. A manual JSON union of entries: pass. The conflicted ledger fails loudly everywhere except list (stderr warning, exit 0).
• Upgrade path, v4.0.0-written hosted / vendored state operated by main (list, vex, check, re-scan, takeover, rollback, frozen install): pass (1.22.22).
• Agent apply + vex + rollback on 1.1.0 / 1.2.1 / 1.4.0: pass.
• PR Fix npm wrapper running the glibc binary on musl (#974) #976 fixes On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 on x64 + arm64 Alpine (Node 18 / 22, yarn 1.7.0 / 1.22.22, local + global) (probe run 37582882236). PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 would drop the yarn-1 PnP diagnosis under an ancestor .yarnrc.yml nodeLinker or YARN_NODE_LINKER (commented on Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975).

Run 28 cells (Linux, 1c6c509)

• Hosted with yarn-offline-mirror set outside the project (parent-dir .yarnrc, ~/.yarnrc, ~/.npmrc, yarn config set user config): fail Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013. The Fix hosted yarn classic with an offline mirror (#364) #839 refusal reads only <project>/.yarnrc / .npmrc, so the scan reports success with no warning, every frozen install fails the integrity check, and VEX attests. Seen on 1.10.1 / 1.22.22, ×2 each. On 1.7.0 the install passes without --offline (no integrity line) and VEX still attests.
• Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 fix (Fix hosted yarn classic with an offline mirror (#364) #839), project .yarnrc mirror: refused, lock untouched, no attestation (1.22.22): pass.
• Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 fix (Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901), hosted scan from a member with its own nested copy: exits 1 redirect_workspace_lockfile_elsewhere, nothing written (1.22.22): pass.
• Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 fix (Fix yarn classic unrewritable copies going unreported (#921, #857) #924), file: member copy beside a root registry block: H warns redirect_yarn_classic_directory_skipped and VEX omits the package (1.22.22): pass.
• Re-triage: Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (mixed EOL, hosted) and Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 (vendored install from a member dir) still reproduce; commented on both.

Run 29 cells (Linux, 05ecc6e)

• Project .yarnrc / .npmrc with a UTF-8 BOM setting yarn-offline-mirror: fail Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078. The Fix hosted yarn classic with an offline mirror (#364) #839 refusal readers don't strip the BOM, so hosted pins, VEX attests, and every frozen / --offline install fails (1.10.1 / 1.22.22, LF and CRLF, ×2; .npmrc BOM on 1.22.22). A vendored→hosted takeover reverts a working vendored entry and pins it (same failure). 1.7.0 installs patched. Plain-file controls are refused: pass.
• npm: alias copy beside a direct dep (yarn 1.22.22 writes two blocks): in-run scan --mode hosted --vex attests not_affected while node_modules/x stays unpatched: fail Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081. Standalone vex refuses (exit 2). Same with a file: tarball direct dep. 1.0–1.22.21 merge the keys into one block (pinned whole, alias patched): pass.
• Same alias state: rollback / remove / list refuse patched_ref_unattributable, the vendored takeover skips the restore, and vendor --revert lands on hosted. Commented on 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 (third trigger; draft fix PR Fix open npm issues #1008).
• Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 follow-up: YARN_YARN_OFFLINE_MIRROR and npm_config_yarn_offline_mirror set for install + scan: hosted pins, VEX attests, frozen install fails integrity (1.10.1 / 1.22.22). Commented on Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013.
• Re-triage: Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still reproduces (H in-run and lock-only VEX, V in-run / lock-only / post-install VEX attest; H post-install omits). Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 still reproduces (1.10.1 unpatched, 1.22.22 integrity error; sha1-bearing control patched). Commented on both.
• Scoped alias name ("@my/lp": "npm:left-pad@1.3.0"): H skips with redirect_yarn_classic_alias_skipped, V rewires + frozen install patched + byte-exact rollback, A apply + vex + rollback: pass (1.22.22).
• yarn policies set-version layout (.yarnrc yarn-path → 1.10.1 release), H / V / A + frozen install: pass. The berry-migration warning still fires (correct: berry ignores .yarnrc).
• PR Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 (719a4159, yarn grammar refactor) vs main, 18-cell battery (LF / CRLF / BOM+CRLF / mixed / no trailing newline / header-less / no-integrity 1.7 lock / workspace merged key / npm: alias; H and V; fresh frozen install, rollback, post-rollback install): identical results, no regression. The PR narrows Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (hosted no longer converts the whole file), but vendored rollback is still not byte-exact on a mixed lock (commented on Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467). Its intended B16 change, where file: tarball / URL copies are skipped with redirect_yarn_classic_non_registry_entry_skipped and VEX omits them, behaves as described.

Run 30 cells (Linux, e61a845)

• Hosted scan from a workspace member whose root workspaces uses !packages/b (yarn 1 ignores negation) or an extglob (packages/@(a|b), packages/+(a|b)): fail Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097. The member has its own nested copy installed from the root lock, but the scan exits 0 with success / redirected: 0 (only redirect_npm_no_lockfile). Seen on 1.0.2 / 1.6.0 / 1.10.1 / 1.22.22, ×2. The packages/* control refuses redirect_workspace_lockfile_elsewhere (pass), and running from the root pins and installs patched (pass). Vendored from the member fails closed with vendor_lockfile_missing (pass).
• Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 (PnP follows nodeLinker): a yarn-1 PnP project with a classic lock keeps its loader live (code path effective_yarn_linker). Turning off installConfig.pnp and reinstalling deletes .pnp.js (1.22.22), so classic has no stale-loader shape: pass.
• Re-triage: In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 still reproduces on e61a845 (lock-only hosted pin + installed PnP → vex attests not_affected, ×2). Commented.

Run 31 cells (ea09714)

• Mirror set only in a workspace member's .yarnrc, install run from that member (cd or --cwd): fail Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 (1.10.1 / 1.22.22, ×2). The hosted scan from the root pins, says success, VEX attests, and the member install fails integrity. 1.7.0 installs patched.
• Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 resolution on Linux (root user): project / user (/usr/local/share, ~) / symlinked user rc / ancestor / prefix etc / env (both spellings) / NPM_CONFIG_USERCONFIG / symlinked project rc: refused, pass. false layers match real yarn on 1.7.0 / 1.10.1 / 1.22.22. V→H takeover with a user mirror: refused, vendored kept, pass.
• Cross-OS probe 37740151120 (ubuntu / macos / windows × 1.10.1 / 1.22.22, non-root): every mirror layer, PowerShell 5.1 BOM (project + user), backslash Windows path: all pass.
• Replace a superseded patch generation's wiring on re-pin and remove #1035 supersede gen1 → gen2: H / V on LF / CRLF / BOM+CRLF, H↔V and A→H/V takeovers, workspace merged key + remove / rollback: pass (1.22.22; H→V also 1.7.0).
• Decide which lockfile governs installs in one table #1044: yarn.lock + package-lock / shrinkwrap, H and V: unchanged, pass. yarn.lock + stale pnpm-lock.yaml: vendored routes to pnpm and warns that yarn.lock stays unpatched (documented).
• Re-triage: Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 and Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still reproduce; Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 also reproduces via get (all commented).

Run 32 cells (e2d9633)

• Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 battery, H/V + frozen install + VEX + rollback (1.22.22; base / CRLF / alias-merge also on 1.7.0 and 1.10.1; H on 1.0.2 / 1.4.0): key shapes latest / * / >=1 <2 / 1.x || ^1.3.0 / resolutions version force, and lock shapes CRLF / BOM+CRLF / no trailing newline / comment line / extra blank lines: pass.
• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467: hosted mixed-EOL fixed (each line keeps its own ending through scan and rollback). Vendored mixed-EOL still fails on Linux / macOS / Windows (probe 37781119597).
• Cross-OS probe 37781119597 (ubuntu / macos / windows × 1.10.1 / 1.22.22): H/V × native / LF / CRLF / BOM+CRLF locks, plus file: fork tarballs with backslash and ./ specs skipped or refused: pass.
• B16 forks: resolutions / member file: or URL forks are skipped and VEX doesn't attest them. v4.0.0 legacy hosted pins are named and rollback refuses them with a remedy. v4.0.0 legacy vendored wiring is kept and rolls back byte-exact: pass.
• Decide vendored-entry liveness through one discovery verdict #1050 scan --vendored --prune keeps live wiring in 8 shapes and reverts after yarn remove (×2): pass. Stop CI gates passing on missing paths, unverified agent patches and unreported hosted pins #1029 agent apply --check (workspaces, nested copies, modules-folder, nohoist): pass.
• Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 still reproduces. Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 also triggers through a member .npmrc (commented).

Run 33 cells (Linux, cf8b164)

• Make the vendored-to-hosted takeover atomic #1039 staged takeover V→H (1.22.22): wet takeover + fresh frozen install, dry run byte-identical, project .yarnrc mirror retract (redirect_takeover_kept_vendored, byte-identical), alias-only retract (byte-identical): pass. Mirror retract then clean takeover on 1.7.0 / 1.10.1: pass.
• Alias + direct copy (two blocks, 1.22.22) V→H takeover: the alias copy is un-patched and the takeover isn't retracted: fail Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 (v4.0.0 does the same).
• Route inline BOM strips through formats::text (#905) #1117 BOM: BOM package.json + BOM lock, H/V + frozen install + VEX + rollback; BOM+CRLF lock V→H→V chain (endings and BOM kept, every hop patched): pass.

Run 34 cells (Linux, 03b9418)

• Hosted battery + frozen install + VEX: base (1.0.2 / 1.7.0 / 1.22.22), merged workspace key (1.10.1 / 1.22.22), multi-version workspace, CRLF, resolutions, --modules-folder, 1.10.1 merged alias block: pass. Alias + direct (1.22.22): pins nothing, redirect_unattributable (Decide whether a hosted patch is pinned through lockfile discovery alone #1058 gate; fixed by PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180, verified).
• Vendored battery + check + rollback (base / merged ws key / CRLF / 1.7.0 / 1.10.1 ws; after another dep's add / upgrade; after yarn remove / upgrade of the patched dep): pass. Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still fails (now labelled vendor_lock_entry_removed).
• BOM / CRLF .yarnrc + BOM .npmrc mirror refusal: pass. Agent workspace + alias + nested copies, re-run, VEX, rollback: pass.
• V→H takeover with a member-.yarnrc mirror: not retracted (Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115, commented).

Run 35 cells (Linux, f3c6313)

• EOL battery (native / LF / CRLF / mixed / BOM+CRLF × H / V, plus the file: fork shapes) on 1.7.0 / 1.22.22: same results as run 34 (vendored mixed EOL is the Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 non-bug; on 1.7 the extra integrity line is by design). Hosted rollback fails without the plain-HTTP registry passthrough, a sandbox artifact.
• 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 yarn shape (registry pin beside a file: dir copy): H scan, rollback, re-scan, V takeover (upstream restored first) and vendor --revert back to upstream: pass.
• Renamed file: dir copy ("lp2": "file:./lpdir") / renamed git copy ("lp3": "git+file://…") beside registry left-pad: fail Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236. H and V, 1.7.0 / 1.10.1 / 1.22.22: no warning, in-run and lock-only VEX attest, the copy installs unpatched. Post-install vex correctly refuses. Same-name control: pass.
• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still fails (H and V; V post-install vex also attests). Commented.
• Case-only npm: aliases (LEFT-PAD, @Cs/lp): agent apply / VEX / re-run / rollback pass. Vendored with all 3 copies patched after a frozen install, plus check and byte-exact rollback: pass.
• Vendored merged workspace key left-pad@1.3.0, left-pad@^1.1.0 on 1.10.1 / 1.22.22: scan, in-sync re-run, frozen install, check, yarn add of another dep, check, rollback: pass (no regression from the generic driver).

Run 36 cells (Linux, a80b89e)

• Empty-range key ("left-pad": "" gives left-pad@:, merged workspace block left-pad@, left-pad@^1.3.0:): fail Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271. On 1.7.0 / 1.10.1 / 1.22.22 (×2 on 1.22.22), a lock-only H or V scan finds 0 patches (exit 0). An installed H scan exits 0 with redirect_yarn_classic_entry_not_found and pins nothing. An installed V scan exits 1 with vendor_lock_entry_not_found. No false VEX. Agent: pass. v4.0.0 behaves the same.
• Range-key controls, H and V + fresh frozen install + lock-only vex (1.22.22): *, latest, >=1.0.0 <2, 1.2.0 || 1.3.0, v1.3.0, =1.3.0, " 1.3.0", 1.3.0 - 1.3.0, npm:left-pad@latest, npm:left-pad@1.3.0 (self-alias): all pass.
• EOL battery after Pick inserted-line terminators through line_endings::terminator in vendored writers (#815) #1227 (1.7.0 / 1.22.22): unchanged from run 35. Vendored mixed EOL is still the Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 non-bug shape; the LF block in a CRLF-majority lock is re-ended CRLF, as before.
• Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still fails (vendor_lock_entry_removed, ×2). Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 still fails (1.10.1 silently unpatched, 1.22.22 Incorrect integrity on a warm cache). Both were already re-confirmed, so no new comments.

Run 37 cells (Linux, 9ab72d4)

• Alias battery after Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 (alias-only, scoped alias, ranged alias + direct, two aliases) × H/V, plus the V→H takeover and rollback: pass.
• Renamed registry-URL copies × H/V: pass. Renamed file: directory (root and member, 1.7.0 / 1.10.1 / 1.22.22): pass.
• rollback / remove / get × {name, versionless purl, purl, uuid, uppercase name} × H/V(/A): pass.
• BOM .yarnrc / .npmrc mirror refusal: pass. Vendored revert / check on plain, CRLF and workspace locks: pass.
• --production / --ignore-optional / --flat / .yarnclean / nohoist × A/H/V: pass. In-place install after a scan, on 1.7.0 / 1.10.1 / 1.22.22: pass.
• yarn add / upgrade dropping pins: check / vex fail closed, and a re-scan re-pins (pass). Hand-merged two-host duplicate blocks: pass.
• Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271 on main: fail (Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271). On PR Fix yarn classic empty-range lock keys (#1271) #1274: pass (incl. scoped). Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 on main: fail (Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558). On PR Fix fragmentless yarn classic hosted pins (#558) #1328: pass.

Backlog

0. After PRs Fix yarn classic empty-range lock keys (#1271) #1274 (Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271), Fix fragmentless yarn classic hosted pins (#558) #1328 (Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558), Warn on yarn classic member-dir vendored installs (#691) #1324 (Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691) and Refuse yarn classic pins with unlocked deps (#591) #1363 (Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591) merge: re-run on main and close-check. Fix yarn classic empty-range lock keys (#1271) #1274 and Fix fragmentless yarn classic hosted pins (#558) #1328 were verified on their heads in run 37.
   000000a. Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236's remaining follow-ups: the renamed file: tarball scan warning, renamed git copies, and renamed copies declared by a transitive dep's manifest. The member-relative shape is done (run 37: yarn 1 locks it root-relative).
   000000b. --focus member installs; yarn workspace <m> add × vendored; a macOS / Windows probe of the alias battery after Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180.

1. Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271 follow-ups (scoped @s/p@: passes on PR Fix yarn classic empty-range lock keys (#1271) #1274, run 37): in a transitive dep's manifest, and under resolutions; after a fix, H/V + frozen install + rollback + VEX. Ask yarn-berry / pnpm / bun how they lock "" (hand over if they also drop it).

2. Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 follow-ups: renamed file: tarball copies ("lp4": "file:./x.tgz", a Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 B16 shape) and renamed copies in transitive deps / workspace members; ask npm / pnpm / bun whether a renamed directory copy is a copy there (npm and pnpm link directories, so probably not).

3. (Alias battery + Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 close-check on main: done in run 37, pass.) Still open: (scoped / member shapes verified on the PR in run 34). Ask yarn-berry whether the Decide whether a hosted patch is pinned through lockfile discovery alone #1058 gate refuses a berry alias + direct project, and about the same partial-pin takeover gap with redirect_yarn_berry_alias_skipped. (Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 in the staged V→H takeover: done in run 34, commented.)

4. Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 follow-ups (member .npmrc done in run 32): yarn workspace <m> add, V→H takeover in that shape; macOS / Windows.

5. Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 follow-ups (get done in run 31): the same ! / extglob member shapes from get and on yarn berry / npm / bun roots (hand over npm extglob if it reproduces; npm supports negation, so only extglob applies there). Dot-dir members (packages/.x, which minimatch * skips).

6. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 / Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 follow-ups: the vendored→hosted takeover preflight with a user-level mirror; macOS / Windows home config paths; a BOM .yarnrc on a Windows probe (PowerShell 5 Set-Content -Encoding utf8). Re-check Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 on berry aliases (hand over to yarn-berry if redirect_yarn_berry_alias_skipped also attests in-run), and on npm / pnpm alias skips.

7. Re-check Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991 on npm / pnpm vendored, and hand it over if it's family-wide. On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 / Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 / Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 are closed (run 28 verified Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on main). Re-check Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975's yarn-1 PnP cell once PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 merges. Re-check once merged: 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 (PR Fix open npm issues #1008, incl. the run-29 alias trigger), Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 (re-run the run-29 battery on its final head), Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 (PR Fix yarn classic unrewritable copies going unreported (#921, #857) #924, Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 verified run 25), Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (PR Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901, verified run 22; also covers the positional PATH form), Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 (PR Fix hosted yarn classic with an offline mirror (#364) #839), Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (PR Fix vendored npm-family tarballs dropped by .gitignore (#831) #837), Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907 (PR Fix hosted yarn classic pins missing berry warning (#907) #917), Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 (yarn classic nested copies, run 25), plus 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's yarn git-sibling shape. Then Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 / Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758.

8. Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 on PR Fix yarn classic unrewritable copies going unreported (#921, #857) #924 (vendored git-only dep; needs a git dep, which worked in run 20 via github.com).

9. npm-workspace analogue of the Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 nested-copy scope miss (hand over to npm if it reproduces). Also rollback <PATH> / --sync <PATH> / --prune <PATH> on the same yarn layout.

10. Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on macOS / Windows (probe), plus file: copies in transitive deps and under nohoist.

11. Merge flows: both branches vendor the same package at different uuids; hosted on one branch and vendored on the other.

12. bitbucket: / gitlab: shorthands (needs a package mirrored there).

13. Cross-OS hosted checkout: embed one prebuilt patched tarball (base64) in the probe so every runner serves identical bytes. Add workspaces to the cross-OS vendored probe.

14. Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 follow-ups: a real registry package with bundledDependencies.

15. Maintainer request (global mode), what's left: the Windows MSI install of yarn, and a read-only prefix on Windows with a non-admin user. Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 (1.0.x) is still open. macOS case-insensitive name collisions.

16. Packages whose upstream tarball root isn't package/ (old @types/*, e.g. @types/left-pad@1.2.0 uses left-pad/): the vendored prebuilt check requires package/… paths. Whether the real patch service normalizes the root can't be checked from the sandbox.

Known non-bugs

• Run-36 harness: env.sh (mock env + Y for $S/y<ver>), tr.sh <mode> <spec> (range-key battery), tm.sh (merged empty-range workspace), t692.sh, and mock_nosha1.py (the run-32 mock with sha1 dropped from the grant, for Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558).

• patches-api.socket.dev isn't used here. Use a local mock API (--api-url). The mock must match purls with an unencoded @ for scoped packages, and vendored runs need --vendor-source build plus blobContent in the view stub. For hosted vex on lock-only checkouts, pass --patch-server-url <mock> (CLI_CONTRACT "Patch hosts"); otherwise package_not_found is expected.

• yarn 1.0.2 – 1.6.x install nothing (exit 0, empty node_modules) for file: tarball lock entries and offline-mirror installs, even without socket-patch. Bisected in run 2: Node 10.24.1 / 14.21.3 / 16.20.2 / 22 all behave the same, and 1.7.0 works on all of them. The cause is in yarn, not Node or socket-patch, which is why CI reports KNOWN LIMITATION for vendored ≤ 1.6. Not in docs/ecosystems.md.

• An npm: alias entry is left unpatched in hosted mode with redirect_yarn_classic_alias_skipped (documented), and vex omits the package. (Exception: a vendored→hosted takeover that un-patches an alias copy the vendored wiring had patched is Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158.)

• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (vendored rewrite of a mixed CRLF/LF yarn.lock re-ends the block CRLF; rollback not byte-exact) was closed not_planned by a maintainer on 2026-10-08. The hosted half is fixed by Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057. Don't re-file the vendored mixed-ending shape.

• A BOM plus no yarn header comment makes the first entry entry_not_found. Yarn always writes the header, so this is synthetic.

• file: directory and link: deps are skipped by design. (file: tarball deps are rewired and work.)

• The GitHub shorthand owner/repo#tag locks as a codeload tarball and is correctly rewired; only git+… patterns are Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363.

• Running scan from a workspace member dir whose deps are all hoisted: hosted says "No packages found" (exit 0, nothing to pin). Vendored refuses vendor_lockfile_missing (exit 1). Reclassified in run 21: when the member has its own non-hoisted copy, hosted's silent success is Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (the Hosted scan/get run from a pnpm workspace member (or with lockfile-dir=..) ignores the parent pnpm-lock.yaml and reports success while pinning nothing #590 shape), not a documented posture.

• hosted→agent / vendored→agent keep the existing wiring (hosted_wiring_retained / vendored_ownership_retained), as documented.

• Concurrent scans: the extras fail with lock_held (intended).

• Probe branches can't be deleted from the sandbox (the git proxy rejects ref deletion). Leftovers: bughunt/yarn-classic/20260930-mirror-git, bughunt/yarn-classic/20261001-win-crlf-git.

• v5 hosted rollback / remove need the npm registry. In the sandbox the CLI's rustls client rejects the TLS-intercepting proxy CA (error sending request for url (https://registry.npmjs.org/…)). That's a sandbox artifact. Use a local plain-HTTP registry passthrough with env -u HTTPS_PROXY -u https_proxy SOCKET_NPM_REGISTRY=http://127.0.0.1:<port>. With SOCKET_NPM_REGISTRY set, the restored resolved uses dist.tarball verbatim (registry.npmjs.org), not registry.yarnpkg.com. That's by design (npm.rs yarn_classic_tarball).

• v5 vendored mode has no local build (--vendor-source build is rejected). The mock must serve a tarball artifact from POST …/patches/package.

• scan -g also reports npm's own bundled deps (npm global root), e.g. @isaacs/string-locale-compare. That's correct global discovery.

• Probe branch bughunt/yarn-classic/20261001-global-mode is also left on the remote (the proxy blocks deletion).

• Hosted pins are recognized only on patch.socket.dev or the --patch-server-url / SOCKET_PATCH_SERVER_URL origin. With a mock at another origin and no such setting, rollback says Manifest not found (truly-empty project). Set SOCKET_PATCH_SERVER_URL=<mock>.

• Hosted rollback of a lock without integrity lines (yarn < 1.10) adds integrity lines. That's the "default upstream entry", and yarn 1.7 still installs it frozen.

• Vendored mode on yarn ≤ 1.6 installs nothing. The harness asserts this as a KNOWN LIMITATION (tests/common/yarn_classic_vex.rs:89); it's not in the user docs.

• A tarball-URL dependency of the patched name@version is rewired in both modes (it installs patched). Whether a URL "fork" should be refused, as vlt does, is a design question.

• A SIGKILL can leave the lock wired with no vendor/state.json. rollback then refuses with a remedy, and repair / a re-scan rebuild the ledger. That's intended crash handling.

• Hosted rollback ignores the .yarnrc registry and queries SOCKET_NPM_REGISTRY (default registry.npmjs.org). That's documented (CLI_CONTRACT Hosted unwind / env table). Set SOCKET_NPM_REGISTRY behind a private registry.

• A nested non-workspace project (its own yarn.lock under the root) in hosted mode from the root: redirect_yarn_classic_entry_not_found, because hosted reads only the root lock. That's the documented one-project model (run with --cwd per project).

• A stale node_modules left beside an active --modules-folder: Node loads node_modules first, so agent patching it is correct.

• Yarn classic never sends .npmrc registry auth (host token, bare _authToken, always-auth, scoped registry, _auth) to the hosted patch host, on any release from 1.0.2 to 1.22.22. The berry Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 leak doesn't apply to classic.

• Vendored vex attests from the committed artifact even when the installed tree is unpatched (by design, with a vendored_tree_out_of_sync warning).

• scan --vex in a PnP project exits 1 manifest_not_found only because there is nothing to attest. Plain scan exits 0 with yarn_pnp_unsupported, as pinned by e2e_safety_yarn_pnp.rs.

• A platform-skipped optional dep (fsevents on Linux) is rewired and attested from the lock pin in hosted mode: the documented lock-only basis, and it installs patched on macOS.

• The mock harness must exclude node_modules relative to the package dir, or it serves empty tarballs (a harness bug, not socket-patch).

• yarn classic ignores YARN_MODULES_FOLDER / npm_config_modules_folder (installs into node_modules), so the crawler needn't read them. A ~/.yarnrc --modules-folder resolves relative to $HOME, not the project.

• v5 has no setup subcommand. Agent cells use apply.

• Probe branch bughunt/yarn-classic/20261002-dev-flow is also left on the remote (the proxy blocks deletion).

• An npm: alias key merged with a direct key in one block isn't something yarn 1.22.22 writes (it emits two blocks), so don't test that shape.

• Hosted rollback on an integrity sha1- lock restores a sha512 integrity line (the default upstream entry); yarn 1.10 installs it frozen.

• patch.socket.dev / patches-api.socket.dev are blocked by the sandbox egress proxy, so what the real grant carries (e.g. whether sha1 is present) can't be checked from here.

• yarn 1.0.x–1.9.x in-place installs skip copying a file whose size and mtime match the installed one (yarn's copy optimisation). With same-length markers and mtime-0 mock tarballs, a superseded patch looks unapplied in place. Fresh installs and 1.10+ are fine. Use different-length markers in harnesses.

• A .yarnrc modules-folder that is absolute, or that resolves outside the project, is deliberately ignored by the crawler (fail-closed, npm_crawler.rs resolve_modules_folder).

• The local mock's batch route must filter by the requested purls, or scan -g "finds" packages it never inventoried.

• macOS probe harness: the first TCP connects to a freshly started Python mock on a macOS runner stall for 10–30 s. Before Bound patch API connects and stalled reads (#570) #581 the first scan -g simply took ~35 s. Since Bound patch API connects and stalled reads (#570) #581's 10 s connect bound, those batches fail (api_batch_failed / "All N API batch queries failed", exit 1). This is a harness artifact: warm the mock with a curl loop before the first scan. Once warm, -g report / agent / vex pass on macOS.

• Agent mode patches a link: / yarn link dependency's target directory, even outside the project. That's the code Node loads; whether to refuse it is a design question.

• Leftover probe branches (deletion blocked): bughunt/yarn-classic/20261003-global-rerun, bughunt/yarn-classic/20261003-macos-global.

• A symlinked .socket/ or .socket/vendor/npm in a single project works consistently in vendored mode (writes and cleans up at the link target). Only a store shared between projects is Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664.

• vex -o is --org, not --output. Use --output in harnesses.

• Hosted rollback after yarn remove of a patched package: pass (restores the remaining blocks, removes .socket/).

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261003-member-install.

• Quick vendored harness: a scratch cargo test using tests/prebuilt_common prepare_command (auto-mocks the service for vendor/repair) plus a staged .socket/manifest.json + blob, as in e2e_vendor_yarn_classic_dev_flow.rs. Other commands (rollback / remove / vendor --revert / --check) run offline with the plain binary.

• A plain root yarn add <pkg>@<new range> re-resolves a vendored block from the registry (unpatched). That's yarn's own behaviour; the follow-on rollback is After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665.

• A vendored lock after a hosted→vendored takeover, rolled back, restores registry.npmjs.org (the hosted-unwound entry, via SOCKET_NPM_REGISTRY), not the original registry.yarnpkg.com. Documented; frozen installs are fine.

• Agent-mode mock: serve GET /v0/orgs/<org>/patches/blob/<hash> for both the before and the after hash. …/patches/diff/<uuid> may 404 (it falls back to blobs). Without the before blob, rollback reports missing_blob.

• vex in a workspace root whose package.json has no version exits product_undetected. Pass --product.

• yarn classic itself merges left-pad@1.3.0 into an existing left-pad@npm:async@1.3.0 block (it installs the fork for the real name). That's a yarn bug; socket-patch fails closed on that block in all modes.

• With yarn.lock and package-lock.json both present, hosted rewrites both (and writes .npmrc allow-remote), and vendored wires yarn.lock with vendor_multiple_lockfiles. Intended.

• After yarn remove of a vendored package, list still shows the entry as "recorded in .socket/vendor/state.json". That's accurate about the ledger; the cleanup gap is After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665.

• Rebuilt the mock in run 15: the public-proxy path also calls GET /patch/by-package/<purl> (a SearchResponse with the patch summary) before /patch/view/<uuid>. Without it, scan says "could not fetch patch details".

• Windows probe harness: Git-Bash sed drops CR bytes, so a sed-normalised copy of yarn's CRLF lock never equals the original. Compare locks with raw cmp. Git-Bash also can't exec a program from a cwd longer than MAX_PATH; run yarn --cwd <long path> from a short dir.

• yarn 1.x on Windows writes new lockfiles with CRLF (os.EOL, writeFilePreservingEol), and keeps an existing file's EOL. CRLF locks are therefore the default on Windows, not an edge case.

• Running scan --mode agent from a workspace member dir finds nothing ("No packages found"), because the hoisted copies live under the root. That's the documented one-project model: run from the root.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261004-win-paths.

• Probe harness: actions/upload-artifact drops dot-directories (.socket/) unless you set include-hidden-files: true. A per-runner Python mock builds tarballs with that OS's zlib, so hashes differ across OSes. Ship one shared mock artifact for hosted cross-OS tests.

• get name@version (not a purl) runs the fuzzy package-name search, and against the mock it returns no_packages. Use a pkg: purl or a uuid.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261004-xos-vendored.

• Agent mode never crawls a workspace member under vendor/, build/, dist/, tmp/, temp/, coverage/, __pycache__/ or a hidden dir (e.g. .github/actions/*), even when yarn workspaces declares it. That's the documented walk (docs/ecosystems.md "npm: which node_modules trees are crawled"); whether declared workspaces should override it is a design question.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261005-agent-xos.

• Self-contained mock (run 18): one Python file serving left-pad@1.3.0 for all modes (batch, by-package, view with blobContent, …/package grant with a sha512+sha1 tarball artifact, /artifacts/<uuid>/…, blob/<hash> for before and after). It lives in the run-18 probe workflow on bughunt/yarn-classic/20261005-agent-xos.

• A .gitattributes * text eol=crlf (forced text for every file) corrupts the vendored .tgz on checkout. The same setting corrupts every binary in the repo, so it's not filed; vendor --check reports it (vendor_artifact_unreadable). vlt guards it with a <uuid>/.gitattributes * -text, and the tarball backend doesn't. * text=auto … and * text eol=lf are fine.

• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 / Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 / After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 were closed by Fix yarn classic rewiring git-sourced lock blocks (#363) #710 / Fix vendored revert deleting through a symlinked vendor dir (#664) #666 / Fix vendored revert keeping artifact for removed lock entry (#665) #689. Don't re-file the git-rewire shape; a git block is now skipped by design (docs/ecosystems.md "yarn classic git dependencies").

• yarn 1.0.2 installs a single copy (the git one, at the root) for a workspace that has both a registry block and a git block of the same name@version. The hosted pin then never reaches node_modules, but the scan's redirect_yarn_classic_git_skipped warning covers it and vex doesn't attest.

• The sandbox can't reach codeload.github.com, so GitHub-shorthand deps need a probe branch.

• Hosted rollback of a GitHub-shorthand dep (owner/repo#tag, codeload lock) restores the npm registry tarball, not the codeload URL. CLI_CONTRACT "Hosted unwind coverage" says pins go back to the default upstream registry entry. Vendored rollback is byte-exact. Whether a non-registry origin should be refused (as composer does) is a design question.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261006-gh-shorthand.

• yarn 1.22.x refuses to install when package.json declares a berry packageManager (corepack guard). To build a mid-migration fixture, install first and then add the packageManager field.

• Building two PR worktrees into one CARGO_TARGET_DIR can reuse the first binary unchanged ("Finished in 0.18s"). Touch the sources or use separate target dirs, and cmp the binaries.

• Agent-mode first-party refusal: JSON apply.failed is 0 while the human summary says "1 failed" (status: partial_failure, exit 1). Cross-ecosystem and minor; not filed.

• Keep yarn's --cache-folder outside the project in harnesses, or agent mode also patches the cache copies under it.

• file: directory deps are first-party source for link-based managers, but yarn 1 copies them into node_modules, and agent mode patches that copy. The hosted / vendored / VEX gap for that copy is Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921, not a non-bug.

• A yarn project with no lockfile (--install.no-lockfile) gets hosted success / redirected: 0 with redirect_npm_no_lockfile, whose text names only npm locks. The human stderr says nothing was switched, and vendored refuses with a message listing yarn.lock. Low-severity naming nit, not filed (pnpm has its own redirect_pnpm_no_lockfile).

• --min-severity judges severity from vulnerabilities[].severity in /patch/by-package. A mock that returns vulnerabilities: {} there makes every patch "unknown", so all of them are filtered. That's a harness artifact.

• --package pkg:npm/<name>@<version not installed> scans nothing and exits 0 success. That's expected filtering.

• After a hosted scan, yarn add / yarn upgrade / member installs with a range that matches the pinned version merge into the pinned block (pin kept). Only an exact root re-add (yarn add -W <pkg> --exact) writes a separate registry block (Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938).

• Run-24 mock: a 3-package variant of the run-18 mock (left-pad high, ms low, scoped @isaacs/string-locale-compare medium, tarballs read from a local dir). Kill the mock in its own Bash call; pkill -f mock.py in a command line that also contains mock.py kills the calling shell.

• link: deps: yarn 1 links every range of the same name to the link: target (version "0.0.0" blocks), so a link: copy can't sit beside a registry block.

• Run-25 multi-package mock (mockm.py <port> name@ver,…): downloads each upstream tarball, re-roots it to package/, patches index.js / index.d.ts / package.json, one uuid per package. Vendored service artifacts must use a package/ root, or vendored refuses vendor_prebuilt_layout_mismatch.

• scan <PATH> in hosted / vendored mode is a per-directory --cwd run (CLI_CONTRACT "Path-scoped scans"); with --json it takes one directory, so 'packages/*' with two members is a usage error (exit 2) by design.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261007-musl-wrapper.

• rollback <PATH> / agent scan <PATH> select at purl level: every copy of a selected package is handled, even copies outside the PATH (CLI_CONTRACT "Path-scoped scans"). Only the zero-selection miss is Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778.

• Hosted rollback in the sandbox needs SOCKET_NPM_REGISTRY=http://127.0.0.1:<port> with a plain-HTTP passthrough to registry.npmjs.org (python urllib with /root/.ccr/ca-bundle.crt) and HTTPS_PROXY unset. The restored resolved then reads registry.npmjs.org + an integrity line, so compare by a post-rollback frozen install, not cmp.

• The sandbox has a docker CLI but no daemon, and dl-cdn.alpinelinux.org / unofficial-builds.nodejs.org are blocked. Use a probe branch with docker run node:22-alpine for musl cells.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261007-musl-pr976.

• Probe harness: cp from a read-only bind mount drops the exec bit on busybox, so overlay files with cat src > dst to keep the mode.

• v4.0.0 has no scan --package and no vendor --check. Its vendored state (manifest + ledger) and hosted redirect-state.json are read correctly by main (run 27).

• Run-27 mock: the mock.py multi-package variant (mock.py <port> <left-pad tgz> [<is-number tgz>], one uuid per package, routes: batch / by-package / view / blob / package / artifacts). Use it with SOCKET_PROXY_URL + SOCKET_PATCH_SERVER_URL + SOCKET_API_URL pointed at the mock.

• Running yarn config set as root writes /usr/local/share/.yarnrc (yarn's root user home), not $HOME/.yarnrc. In run 28 the sandbox was left with yarn-offline-mirror false there, which is the same as no mirror.

• yarn 4.18.1 run directly (not through corepack) ignores packageManager: "yarn@1.22.22" and migrates a vendored v1 lock, dropping the vendored resolution. The yarn_classic_berry_migration_risk warning is suppressed by that pin, as documented (docs/ecosystems.md "yarn classic and yarn 2+"), and the code comment assumes berry refuses. Design note, not filed: through corepack the pin does select 1.22.22.

• yarn 1.22.22 writes left-pad@1.3.0: and "x@npm:left-pad@1.3.0": as separate blocks; every earlier release checked (1.10.1 … 1.22.21) merges them. Alias-shape cells need 1.22.22.

• The REST search API (/search/issues) is blocked from the sandbox. Use the GitHub MCP search_issues for duplicate checks; repo-scoped REST (/repos/…/issues, /pulls) works through the proxy.

• Run-29 harness: scratchpad/battery.sh <bin> <out> (9 shapes × H/V, yarn 1.22.22, with 1.7.0 for the no-integrity shape) plus regpass.py (a plain-HTTP registry passthrough on :8790 for hosted rollback). The run-18 mock is still extracted from the 20261005-agent-xos probe branch; a no-sha1 variant is the same file with "sha1": SHA1 dropped from the grant.

• yarn 1 deletes .pnp.js when installConfig.pnp is turned off and the project is reinstalled (1.22.22, run 30), so a stale yarn-1 loader needs a hand-committed file. Not a Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 shape.

• yarn 1 workspaces ignore ! patterns (1.0.2–1.22.22): ["packages/*", "!packages/b"] still installs b as a member. Any harness that tries to exclude a member with ! gets the wrong layout.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261008-mirror-xos.

• Running yarn config set as root writes /usr/local/share/.yarnrc; a probe harness must clean that too between cells, or mirror settings leak.

• yarn.lock + a stale pnpm-lock.yaml: vendored follows the governing-lock precedence (pnpm > yarn) and warns vendor_multiple_lockfiles that yarn.lock stays unpatched. Documented, not filed.

• A member-.yarnrc mirror (Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115) only breaks installs once the mirror holds the upstream tarball (a cold member install populates it); a no-op member install after a root install leaves it empty.

• Agent mode overwrites a same-name@version file: / URL fork copy with Socket's patched file. That's the documented default mismatch policy (--strict refuses), and the missing warning in scan --json is scan --mode agent --json and get --json overwrite a locally modified npm file without the documented content_mismatch_overwritten warning (not in the JSON, not on stderr) #1004. Hosted / vendored skip such copies (B16).

• A vendored fork-only yarn classic project exits 1 with vendor_lock_entry_not_rewritable. Documented.

• An API purl that lowercases an uppercase npm name (pkg:npm/jsonstream) fails closed in every mode. It can't be checked against the real service, so it's not filed. A case-preserving purl works.

• Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261008-grammar-xos.

• Run-32 harness: battery.sh <yarnfn> <name> <deps> [resolutions] (H/V, MUTATE hook), prune.sh, agent.sh, and a parameterised mock (MNAME / MVER env). The probe script is in the run-32 workflow commit 43a8c51.

• scan --vex <PATH> takes the output path; there's no --vex-output. get/scan --apply / --vendor / --no-apply were removed in Remove scan --apply/--vendor, get --no-apply and the download/gc aliases (#966) #1031: use --mode agent|vendored / --save-only.

• Member-dir cold-cache installs of a vendored yarn workspace fail whether or not there's a mirror (Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691). With a mirror, yarn falls back to the mirror's same-named upstream tarball, so the error reads Integrity check failed instead of "Tarball is not in network". Don't file it as a mirror bug.

• Run-34 harness: hb.sh (hosted) / vb.sh (vendored, with POST / MUT hooks) / t1158.sh / tws.sh / tmir.sh, with the run-32 mock.py extracted from probe branch 20261008-grammar-xos. yarn 1.22.22 lives at /opt/node-tools/node_modules/yarn/bin/yarn.js in the sandbox.

• Run-35 harness: h/env.sh (mock + plain-HTTP registry reg.py on :8788 via SOCKET_NPM_REGISTRY), probe.sh from the 20261008-grammar-xos workflow, t828.sh / tlp2.sh / tws.sh. Give every project its own --cache-folder: yarn 1's global cache keys a local file: tarball by name@version, so two projects with different bund-1.0.0.tgz bytes get the wrong sha1 in the lock (a harness artifact, not a bug).

• Run-37 harness: h/env.sh (MPORT picks the mock; B can be overridden for PR builds), h/t.sh <ver> <mode> <name> <pkgjson> (PRE / FRESHCP / FCHK hooks; VEX runs in the fresh install and in a lock-only copy), mocksc.py (the run-32 mock with NAME set to @isaacs/string-locale-compare@1.1.0), and mocknosha.py (sha1 dropped from the grant).

• Hosted vex run in the tree that was installed before the scan refuses not_applied. That's correct (node_modules still holds upstream bytes); run VEX after a fresh install or lock-only.

• repair is a no-op (exit 0) after yarn upgrade / yarn add drops a vendored pin. That matches docs/usage.md (repair restores artifacts and keeps the existing wiring). vendor --check fails and vex refuses vendor_unwired; re-run the vendored scan.

• yarn 1 (1.7.0 to 1.22.22) locks a workspace member's file:./x dependency root-relative (name@file:./packages/a/x), so lock readers needn't resolve it relative to the member.

[github-actions[bot]]

[agent] 2026-09-30: Yarn classic (1.x) bug-hunt run

This is the first run, so the ledger started empty and there were no pm:yarn-classic issues to re-triage.

Tested: main f6b7fb9 (CLI 4.0.0; latest release 4.0.0, also used to check for regressions). Yarn via corepack: 1.0.2, 1.6.0, 1.7.0, 1.9.4, 1.10.1, 1.17.3, 1.22.22 on Node 22 (Linux sandbox). One probe run covered ubuntu, macOS and Windows × 1.10.1 and 1.22.22.

Setup: I used a hold-open Python mock of the patch API (batch / by-package / package / view with blobContent / hosted tarball in the production URL shape) and patched tarballs built from the real npm pack tarballs. Every cell ended with a real yarn install on a fresh checkout and a patch-marker check.

Cells

• Hosted baseline (1.0.2, 1.6.0, 1.10.1, 1.22.22; fresh --frozen-lockfile): pass.
• Hosted + yarn-offline-mirror: fail → Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364. On 1.10+, an online install hits "Integrity check failed" because the mirror's upstream left-pad-1.3.0.tgz has the same basename as the hosted URL. --offline fails on 1.7+. Linux, macOS and Windows all fail. On 1.7.0 and 1.9.4 an online install passes. 1.0.2 and 1.6.0 are n/a, because they install nothing from a mirror even without socket-patch.
• Vendored + offline mirror (1.10.1, 1.22.22; online and --offline): pass.
• Hosted + vendored with a git-sourced dep (git+file://…#v1.3.0): fail → Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363. The block is rewritten, and yarn then runs git against the tarball, so every install fails ("Command failed" / "spawn ENOTDIR"). The in-run VEX says not_affected. Fails on Linux 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 and macOS 1.10.1 / 1.22.22. Windows is blocked (the fixture install couldn't find git).
• file: directory dep: skipped by both modes, pass. Remote tarball URL dep: rewired and installs patched, pass.
• Hosted workspaces + merged ranges (^1.3.0, 1.3.0, ~1.3.0) + resolutions + scoped package + npm: alias (1.22.22): pass. The alias is skipped with redirect_yarn_classic_alias_skipped (documented), and vex correctly omits left-pad because of the unpatched alias copy.
• Vendored, same project (1.22.22, 1.7.0): pass. It rewires the alias too, and all copies are patched.
• Hosted CRLF / BOM / BOM+CRLF / headerless locks, then rollback (1.22.22): pass, byte-exact restore.
• Vendored CRLF / BOM+CRLF, then vendor --revert: pass, byte-exact.
• Hosted in-place warm reinstall (1.0.2, 1.10.1, 1.22.22): pass.
• Re-run idempotency (hosted and vendored): pass (lock unchanged).
• Agent scan --apply + setup postinstall hook, then yarn add / --check-files / reinstall (1.0.2, 1.10.1, 1.22.22): pass.
• Agent mode on nested workspace copies (version conflict + nohoist): pass.

Issues

• Filed Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363: Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363
• Filed Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364: Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364

False positives ruled out

• Scoped packages at first looked "not redirected". That was my mock URL-encoding @ in purls; the CLI sends it unencoded.
• yarn 1.0.2 and 1.6.0 "exit 0 but nothing installed" from an offline mirror: this happens without socket-patch too (yarn / Node 22), the same family as CI's KNOWN LIMITATION for file: tarballs on ≤ 1.6.
• A lock with a BOM and no yarn header comment misses its first entry (redirect_yarn_classic_entry_not_found). Yarn always writes the header, so the lock is synthetic and not filed.
• GitHub-hosted git specs couldn't be fetched through the sandbox proxy, so I used a local git+file:// repo.

Probe branches

• bughunt/yarn-classic/20260930-mirror-git, run https://github.com/SocketDev/socket-patch/actions/runs/36761888480 (6/6 jobs green; the results are in the RESULT lines).
• Couldn't delete the branch. git push origin --delete fails through the session git proxy ("remote end hung up"). Sibling routines' probe branches are also still on the remote. A maintainer needs to delete bughunt/*/2026* branches.

Next

1. CI's early-1.x "failing" cells: find out why yarn ≤ 1.6 installs nothing from local tarballs or mirrors on modern Node (Node version bisect), and whether socket-patch should refuse vendored mode on those yarns instead of reporting success.
2. Windows: git-sourced dep with git on yarn's PATH, CRLF lock written by yarn on Windows, a path with spaces / unicode for vendored file:./.socket/…, and a drive-letter cwd.
3. Hosted ⇄ vendored takeovers and rollback on a project with an offline mirror, plus yarn-offline-mirror-pruning.
4. --frozen-lockfile after yarn upgrade / yarn add of an unrelated dep on 1.0–1.9 locks (integrity line insertion), and multiple patched versions of one package.
5. VEX on lockfile-only checkouts with aliases and resolutions; remove / repair / get <uuid> --mode hosted on yarn classic.

[github-actions[bot]]

[agent] 2026-10-01: Yarn classic (1.x) bug-hunt run

Tested: main f6b7fb9, the same as run 1 (CLI 4.0.0; latest release v4.0.0). Yarn via corepack on Node 22 (Linux sandbox): 1.0.2, 1.6.0, 1.7.0, 1.9.4, 1.10.1, 1.17.3, 1.22.22. For the ≤ 1.6 question I also ran Node 10.24.1, 14.21.3 and 16.20.2. One probe run covered ubuntu, macOS and Windows × 1.7.0, 1.10.1 and 1.22.22. Every cell ended with a real fresh-checkout yarn install --frozen-lockfile against a local multi-package mock API (left-pad 1.3.0 + 1.2.0, is-number 7.0.0, @isaacs/string-locale-compare 1.1.0).

Re-triage

• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (git-sourced blocks rewired): still reproduces. A new comment adds the Windows cells (1.7.0 / 1.10.1 / 1.22.22 fail in both modes; vendored shows Couldn't find the binary git), a real git+https://github.com/… spec on Linux, macOS and Windows, and a correction: the GitHub shorthand owner/repo#tag locks as a codeload tarball and installs patched. Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (comment)
• Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 (hosted + offline mirror): still reproduces on Linux 1.22.22 (Integrity check failed). I had nothing new to add, so I didn't comment.

Cells

• Multiple patched versions of one package (workspaces: a→left-pad 1.2.0, b→^1.3.0, plus is-number and a scoped package), hosted and vendored: pass on Linux 1.0.2 / 1.6.0 (hosted only) / 1.7.0 / 1.10.1 / 1.22.22, and on macOS and Windows 1.7.0 / 1.10.1 / 1.22.22 (probe).
• Takeovers hosted→vendored and vendored→hosted (redirect_takeover_reverted_vendored), each followed by a fresh frozen install and then rollback: pass. Patched after each takeover, and the lock is restored byte-exact. Linux 1.10.1 / 1.22.22 (local), plus probe macOS and Windows × 1.7.0 / 1.10.1 / 1.22.22 and Linux 1.22.22.
• CRLF lock (git autocrlf-style), hosted and vendored, then rollback: pass on macOS and Windows × 1.7.0 / 1.10.1 / 1.22.22 and Linux 1.22.22. CRLF is preserved (0 bare LF) and rollback is byte-exact.
• yarn add of an unrelated dep after scan, then frozen reinstall (1.7.0, 1.22.22, both modes): pass. The wiring is kept and the install is patched.
• In-place reinstall after scan (install --frozen-lockfile, install, install --check-files; warm cache) on 1.7.0 / 1.9.4 / 1.10.1 / 1.17.3 / 1.22.22, both modes: pass.
• yarn check / --integrity / --verify-tree on patched fresh checkouts (1.10.1, 1.22.22, both modes): pass.
• Project path with spaces + unicode (sp ace ü/), both modes, 1.7.0 / 1.22.22 on Linux and all 3 OSes in the probe: pass.
• Scoped package, hosted on 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 and vendored on 1.7.0 / 1.10.1 / 1.22.22: pass.
• resolved without a #sha1 fragment, without integrity, or without both, both modes on 1.22.22: pass. Both pins are re-added and the install is patched.
• Local file: tarball dep (file:./third/left-pad-1.3.0.tgz), both modes on 1.10.1 / 1.22.22: pass. It is rewired and installs patched.
• Non-deduplicated lock (two separate blocks at the same version): pass. Both blocks are rewired and rollback is byte-exact.
• Superseding patch (a new uuid and new bytes on re-scan), both modes on 1.10.1 / 1.22.22: pass. The lock moves to the new uuid, the old vendored artifact dir is removed, the install gets the v2 bytes, and rollback is byte-exact.
• remove <purl> (hosted hosted_reverted, vendored vendor_reverted): pass. Only that purl's block is reverted. repair: pass (hosted reports redirect_only_project).
• VEX: lock-only and installed checkouts with an npm: alias + resolutions + scoped + multi-version: pass. Hosted omits the unpatched alias; vendored attests it. After yarn upgrade left-pad, VEX omits the package with redirect_unwired / vendor_unwired: pass.
• Vendored + yarn-offline-mirror (with and without pruning), then install and rollback, 1.10.1 / 1.22.22: pass. Yarn doesn't mirror file: tarballs, so the upstream mirror file survives and online and --offline installs work after rollback.
• Concurrent scans (4 at once, both modes): pass. The losers fail with lock_held, and the lock and rollback stay intact.
• hosted→agent / vendored→agent: documented (hosted_wiring_retained / vendored_ownership_retained).
• GitHub shorthand dep (stevemao/left-pad#v1.3.0, a codeload tarball): pass in both modes on all 3 OSes.

Issues

• No new issues filed.
• Commented on Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363: Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (comment)

False positives ruled out / findings that aren't bugs

• Why CI's yarn 1.0.2 / 1.6.0 vendored cells "fail": I bisected by Node version. Yarn 1.0.2 and 1.6.0 exit 0 and install nothing for a file: tarball lock entry on Node 10.24.1, 14.21.3, 16.20.2 and 22. Yarn 1.7.0 installs it on all four. The cause is in yarn ≤ 1.6, not in socket-patch and not in Node, which matches CI's comment ("1.7.0 first vendored-capable"). socket-patch can't tell which yarn will run the install from the lock (1.6 and 1.9 locks look the same). This limitation appears only in CI comments, not in docs/ecosystems.md, so a docs note would help. Not filed.
• Running scan from a workspace member dir (cd packages/b): vendored fails cleanly (vendor_lockfile_missing, exit 1). Hosted exits 0 with redirected: 0 and redirect_npm_no_lockfile ("no package-lock.json / npm-shrinkwrap.json present"), whose wording ignores the root yarn.lock. That matches the documented "hosted refusals exit 0 + warning" stance, so it's a UX note, not filed.
• Hosted vex on a lock-only checkout said package_not_found. This is documented (CLI_CONTRACT "Patch hosts"): my mock host isn't Socket's patch server. With --patch-server-url it attests (redirected).
• The probe's Windows Couldn't find the binary git was Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 itself, not a missing git: the control install of the same dep passed in the same job.

Probe branches

• bughunt/yarn-classic/20261001-win-crlf-git, run https://github.com/SocketDev/socket-patch/actions/runs/36798411014 (9/9 jobs green; the script always exits 0, so read the RESULT lines). I read the RESULT lines for Linux 1.22.22, macOS 1.7.0 / 1.10.1 / 1.22.22 and Windows 1.7.0 / 1.10.1 / 1.22.22. The ubuntu 1.7.0 / 1.10.1 jobs were not read, so this run makes no probe claims for those two cells.
• Couldn't delete the branch (git push --delete → "remote end hung up" through the session git proxy, same as run 1). A maintainer needs to delete bughunt/yarn-classic/20260930-mirror-git and bughunt/yarn-classic/20261001-win-crlf-git.

Next

1. .yarnrc / package.json signals of yarn ≤ 1.6 (yarn-path, packageManager: yarn@1.6.0, engines.yarn): does vendored mode warn? If a pinned yarn ≤ 1.6 project gets status: success and then installs nothing, decide whether that's worth a docs or refusal issue.
2. Interrupted runs (SIGKILL mid-rewrite) and recovery via a re-run or rollback; --dry-run byte-identity on CRLF / BOM locks.
3. get <uuid> --mode vendored / --mode hosted for one version of a multi-version package; scan --prune / --sync on yarn classic after yarn remove.
4. Yarn 1.22.x .yarnrc --install.frozen-lockfile true, --pure-lockfile, and yarn import locks (converted from package-lock).
5. optionalDependencies / platform-skipped packages (lock-only entries) in both modes and in VEX.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Yarn classic (1.x) version and on Linux, macOS and Windows.

Where Yarn classic (1.x) puts global installs: yarn global add; discovery via yarn global dir. Cover a custom --global-folder / prefix in .yarnrc, and yarn installed via npm, corepack and the Windows MSI.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Yarn classic (1.x) package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Yarn classic (1.x) project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Yarn classic (1.x) version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Yarn classic (1.x) bug-hunt run

Tested: main 2463257, the v5 consolidation (#277), which replaced f6b7fb9. The binary still says 4.0.0; the latest release is v4.0.0, which I used as the regression baseline. Locally (Linux sandbox, Node 22) I ran yarn 1.0.2 / 1.1.0–1.6.0 (only for the yarn global dir bisect) / 1.10.1 / 1.22.22 through corepack and a yarn shim on PATH. One probe covered ubuntu, macOS and Windows × yarn 1.0.2 / 1.10.1 / 1.22.22, with yarn installed via npm i -g.

Setup notes for the next run (v5 changed them): --vendor-source build is gone, so the mock's POST …/patches/package must return a tarball artifact with sha512 + sha1 (the same shape the hosted path uses). Hosted rollback now re-resolves the upstream entry from the npm registry, and the CLI's rustls client doesn't trust the sandbox's TLS-intercepting CA, so error sending request here is a sandbox artifact. Work around it with a local plain-HTTP passthrough and env -u HTTPS_PROXY -u https_proxy SOCKET_NPM_REGISTRY=http://127.0.0.1:<port>. With that env set, the restorer writes dist.tarball verbatim (registry.npmjs.org) instead of registry.yarnpkg.com, which is expected.

Re-triage

• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (git-sourced blocks rewired): still reproduces on v5. New: hosted rollback reports success but "restores" the git block to the registry tarball, so installs keep failing. Comment: Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (comment)
• Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 (hosted + offline mirror): still reproduces on 1.22.22 (Integrity check failed). I had nothing new to add, so I didn't comment.

Cells

• v5 hosted rollback (upstream restore) on a 3-dep lock (plain, scoped and is-number), 1.22.22: pass. Exit 0, all 3 reverted, and the lock is byte-exact apart from the registry host (an artifact of the env above).
• Global mode (maintainer checklist), yarn global add left-pad is-number:
  • scan -g report-only finds the yarn-global packages, both inside and outside a project. There's no leakage either way: a scan without -g reports only the project, and the project lock is untouched. pass on Linux / macOS × 1.10.1 / 1.22.22.
  • scan -g --mode hosted, --global-prefix … --mode hosted and SOCKET_GLOBAL=1 --mode hosted all exit 2 and write nothing: pass on every OS and version.
  • scan -g --mode agent / get <uuid> -g patch the real global copy (require() works), vex -g attests only the applied copies (dropping one manually removes it from subcomponents), and rollback -g / --global-prefix rollback are byte-exact. SOCKET_GLOBAL=1 behaves the same. pass on Linux (sandbox + CI) and macOS × 1.10.1 / 1.22.22.
  • Custom .yarnrc global-folder / prefix with a space and unicode (gl ü): pass (Linux 1.22.22).
  • Read-only global folder (sudo chown root + chmod -R a-w, runner user): exit 1 partial_failure, left unpatched, pass on Linux / macOS × 1.10.1 / 1.22.22. The sandbox runs as root, so it can't test this.
  • get -g --mode hosted|vendored and scan -g --mode vendored → filed get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436. They rewrite the cwd project's yarn.lock, exit 0 and leave the global copy unpatched. Reproduces on all 3 OSes × 1.0.2 / 1.10.1 / 1.22.22. v4.0.0 behaves the same, so it's not a v5 regression.
  • yarn 1.0.x → filed Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437. yarn global dir doesn't exist before 1.1.0 (bisected: 1.0.2 fails, 1.1.0+ works), so yarn-global packages are silently missed on every OS.
  • Windows, every yarn → commented on On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (pm:npm, the bare yarn spawn never resolves yarn.cmd). scan -g, agent apply, vex and SOCKET_GLOBAL all fail on 1.10.1 / 1.22.22.

Issues

• Filed get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436: get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436
• Filed Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437: Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437
• Commented on Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363: Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (comment)
• Commented on On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434: On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (comment)

False positives ruled out

• Hosted rollback "error sending request for url (registry.npmjs.org)": the sandbox's TLS interception, not a bug (see the setup notes).
• My first local "yarn 1.0.2 / 1.10.1" global runs actually used a system yarn 1.22.22, because of a PATH mistake in my harness. I discarded them and re-ran with the shim.
• The @isaacs/string-locale-compare hit in scan -g comes from npm's own bundled deps in the npm global root. That's correct global discovery, not a leak.
• -g read-only prefix "FAIL" locally: root ignores the permission bits (sandbox artifact). It passes on the runners.

Probe branches

• bughunt/yarn-classic/20261001-global-mode, run https://github.com/SocketDev/socket-patch/actions/runs/36827174726 (9/9 jobs green; the script always exits 0, so read the RESULT lines). I read all 9 jobs.
• Couldn't delete it. git push --delete returns "Everything up-to-date" / "remote end hung up", and the ref survives, the same as runs 1 and 2. A maintainer needs to delete bughunt/yarn-classic/20260930-mirror-git, …/20261001-win-crlf-git and …/20261001-global-mode.

Next

1. Global mode: re-test Windows after On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 is fixed. Also: yarn via corepack / the MSI on Windows, and 1.6.0 / 1.9.4 on the probe.
2. v5 vendored mode with service artifacts on yarn classic edge shapes: CRLF / BOM locks, workspaces + multi-version, npm: alias, offline mirror (vendor --check, repair).
3. v5 hosted→vendored takeover and vendor --revert (now upstream-restore based) on CRLF / 1.9-style locks without integrity: is the lock still frozen-installable, and is CRLF preserved?
4. Yarn ≤ 1.6 pin signals (packageManager, .yarnrc yarn-path) in vendored mode; scan --max-new-patches and socket.yml filters on a yarn workspace.
5. Interrupted runs (SIGKILL mid-rewrite) and --dry-run byte-identity on CRLF / BOM locks.

[github-actions[bot]]

[agent] 2026-10-01: handover from the Yarn Berry (2+) bug-hunt routine (#305)

Lead for yarn classic on Windows, not verified with classic. The global discovery shells out with Command::new("yarn").args(["global","dir"]) (crates/socket-patch-core/src/crawlers/npm_crawler.rs:517). On windows-latest, where yarn is an npm .cmd shim, a probe showed the command is never run: a Berry project's global script, which runs on Linux and macOS (#440), ran 0 times on Windows (run https://github.com/SocketDev/socket-patch/actions/runs/36828589815). Rust's Command doesn't resolve .cmd via PATHEXT, so yarn classic's yarn global add packages are probably never found by scan -g on Windows. Worth a real yarn global add + scan -g cell on Windows.

[github-actions[bot]]

[agent] 2026-10-01: Yarn classic (1.x) bug-hunt run

Tested: main 2463257 (unchanged since the last run), latest release v4.0.0. Linux sandbox only, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22 from npm i yarn@<v> shims. I used no probe branches: every cell this run is pure lock-text handling and OS-independent, and the open Windows/global issues (#434 → PR #442, #436 → PR #446) haven't merged yet.

Harness for the next run (v5): a Python mock that serves POST /patch/batch, GET /patch/view/<uuid>, POST /patch/package (a granted tarball artifact with sha512/sha1/md5/sha256) and GET /artifacts/…. Point both SOCKET_API_URL and SOCKET_PROXY_URL at it (not SOCKET_PATCH_PROXY_URL), and set SOCKET_PATCH_SERVER_URL=<mock>. Without that last one, hosted pins aren't recognized and rollback correctly says Manifest not found. Hosted rollback uses the plain-HTTP registry passthrough + SOCKET_NPM_REGISTRY from earlier runs. vex on a nameless root package.json needs --product.

Re-triage

• No new commits on main since the last run, so Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 are unchanged. I added no comments. Fix PRs are open for get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (Fix -g touching the cwd project's state (#436, #445) #446) and the Windows spawn (Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442).

Cells (Linux, v5 2463257)

• Mixed CRLF+LF yarn.lock → fail, filed Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467. Hosted converts every LF line in the file (untouched blocks included) to CRLF. Vendored splices the rewired block with the file's dominant ending (detect_eol) instead of block_eol. In both modes rollback isn't byte-exact. Yarn install and check --integrity still pass, so severity is low.
• Uniform CRLF and BOM+CRLF locks: hosted→vendored and vendored→hosted takeovers, frozen install patched, rollback: pass (CRLF and BOM preserved; the only diff is the passthrough's registry host).
• --dry-run (scan in hosted / vendored / agent, plus rollback --dry-run) on CRLF / BOM+CRLF / mixed locks: pass, byte-identical, nothing created.
• Vendored v5 service artifacts on workspaces + multi-version (left-pad@1.3.0 / ~1.2.0), merged key is-number@7.0.0, is-number@^7.0.0, and an npm: alias: pass. All copies are patched, 1.2.0 is untouched, and the alias is vendored. vex attests both, vendor --check and repair succeed, a frozen --offline install works, and rollback is byte-exact with .socket/ removed. Hosted on the same project: pass (alias skipped with redirect_yarn_classic_alias_skipped, as documented).
• Vendored + yarn-offline-mirror + pruning on 1.7.0 / 1.10.1 / 1.22.22 (v5): pass. A frozen offline install from an empty cache is patched, rollback is byte-exact, and after rollback it reinstalls unpatched from the mirror.
• Locks from yarn 1.7 (no integrity): hosted and vendored, frozen install on 1.7.0 and 1.22.22: pass. Hosted rollback adds integrity lines the original lacked, and 1.7.0 still installs frozen, so this is harmless (see non-bugs).
• Direct tarball-URL dependency ("left-pad": "https://…/left-pad-1.3.0.tgz"): hosted and vendored rewire it and the frozen install is patched: pass. (Design question, not filed: a URL "fork" tarball with the same name@version would be replaced by Socket's patched upstream; vlt refuses that shape.)
• file: directory dep in hosted mode: left untouched, Not hosted … no lockfile entry pinning it could be rewritten, vex doesn't attest it: pass.
• Interrupted runs: SIGKILL at random points in 35 vendored and 20 hosted scans. Every state installs. One state is wired + tarballs present + no ledger: rollback refuses loudly with a remedy, and repair or a re-scan rebuilds the ledger, after which rollback is byte-exact. A stale .socket/apply.lock doesn't block the next run: pass.

Issues

• Filed Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467: Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467

False positives ruled out

• Hosted rollback "Manifest not found": the mock origin wasn't the recognized patch host. SOCKET_PATCH_SERVER_URL fixes it (CLI_CONTRACT "Hosted unwind coverage", Scope).
• An offline vendored install failing on a workspace with an unpatched left-pad@1.2.0: my empty cache didn't hold the registry tarball. That's a test artifact.
• Vendored mode on yarn ≤ 1.6 installs nothing: a known limitation the test harness asserts (tests/common/yarn_classic_vex.rs:89). Worth a docs note, but not filed.

Next

1. Global-mode Windows cells once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 / Fix -g touching the cwd project's state (#436, #445) #446 merge (then re-test On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437).
2. socket.yml filters and --max-new-patches on a yarn workspace. optionalDependencies / platform-skipped packages in both modes and vex.
3. .yarnrc --install.frozen-lockfile true, --pure-lockfile, yarn import locks.
4. Custom registry in .yarnrc (private mirror resolved hosts) through hosted → rollback: is the restored host acceptable to a frozen install behind the mirror?
5. Probe macOS/Windows for Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 only if a fix lands (string handling, OS-independent).

[github-actions[bot]]

[agent] 2026-10-01: Yarn classic (1.x) bug-hunt run

Tested: main 61cfb9b (includes #446, which fixed #436, and #365, the npm .store / pnpm virtualStoreDir crawler change). Latest release v4.0.0. Linux sandbox only, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22 from npm i yarn@<v> shims. I used no probe branches: this run's cells are OS-independent crawler and lock-text logic, and the Windows global work still waits on #442 (open).

Harness: mock.py (a Python mock patch API: /patches/batch, /by-package, /view, /patches/package with a granted tarball artifact, and the hosted tarball route; it builds the patched tgz from the installed dir) plus reg.py (a plain-HTTP registry passthrough). Same env as run 4: SOCKET_API_URL, SOCKET_PROXY_URL and SOCKET_PATCH_SERVER_URL all point at the mock.

Re-triage

• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 (git dep rewired): still fails on 1.22.22 / 61cfb9b. The frozen install runs git against the hosted tgz URL. Fix npm rewiring git/URL/file lock entries (#326) #345 (npm hosted and vendored modes rewire git-sourced lock entries, so npm ci silently installs the unpatched git bytes while scan and VEX report success #326) was npm package-lock only. No new information, so I added no comment.
• get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 was closed by Fix -g touching the cwd project's state (#436, #445) #446. Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 / Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 are unchanged (no yarn-classic code changed since 2463257).

Cells (Linux, 61cfb9b)

• .yarnrc --modules-folder deps, agent mode → fail, filed Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493. The package is reported notInstalled, and scan --mode agent exits 0 with applied: 0 and no warning. get + apply exits 1 with "not found on disk". This reproduces 2/2 on each of 1.7.0, 1.10.1 and 1.22.22. VEX correctly omits the package (package_not_found).
• A stale node_modules beside an active --modules-folder: agent patches node_modules, and Node resolves node_modules before NODE_PATH, so the loaded copy is the patched one. Not a bug.
• Workspaces with nohoist: ["**/left-pad"] (copies only in the member node_modules): agent / hosted / vendored all patch both copies, the frozen install is patched, and vex attests: pass (1.22.22).
• --max-new-patches 1 on a 2-member workspace, hosted / vendored / agent: 1 new + 1 deferred, then the re-run admits the second, and both frozen installs are patched: pass.
• A custom .yarnrc registry (private-registry host in resolved): the hosted rewire and offline rollback refusal pass. Online rollback ignores .yarnrc and queries registry.npmjs.org unless SOCKET_NPM_REGISTRY is set. That's documented (CLI_CONTRACT Hosted unwind, SOCKET_NPM_REGISTRY row), so it's a non-bug.
• Hosted over an already-installed tree: in-run --vex attests from the lock pin before the reinstall (documented), and an in-place yarn install --frozen-lockfile then installs the patched bytes: pass.
• A nested non-workspace project (examples/demo/yarn.lock) scanned from the root in hosted mode: the crawler finds its copy, but hosted reads only the root lock, so you get redirect_yarn_classic_entry_not_found and status: error. That's consistent with the documented one-project model (run once per --cwd). Not filed.

Issues

• Filed Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493: Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493

False positives ruled out

• The stale node_modules + --modules-folder "false VEX": Node's resolution order loads the patched node_modules copy.
• Rollback ignoring the .yarnrc registry: documented SOCKET_NPM_REGISTRY behaviour.
• A nested non-workspace lock in hosted mode: the documented cwd/workspace scope.

Next

1. Global mode on Windows once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges (re-test On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 and the Berry handover lead about the yarn .cmd shim).
2. optionalDependencies / platform-skipped packages (fsevents on Linux) in hosted and vendored mode, plus vex.
3. --modules-folder in hosted / vendored mode with a frozen install, and a workspace-level --modules-folder.
4. yarn import-generated locks and --pure-lockfile dev flows after hosted.
5. A socket.yml patches policy (minSeverity / ignore paths) on a yarn workspace member path.

[github-actions[bot]]

[agent] 2026-10-02: Yarn classic (1.x) bug-hunt run

Tested: main 61cfb9b (unchanged since run 5). Latest release v4.0.0 (npm @socketsecurity/socket-patch@4.0.0, used for bisecting). Linux sandbox only, Node 22. Yarn 1.0.2 / 1.6.0 / 1.9.4 / 1.10.1 / 1.12.3 / 1.17.3 / 1.22.22 from npm i yarn@<v>. I used no probe branches: this run's cells are OS-independent VEX and lock logic.

Harness (rebuilt): mock.py is a Python mock patch API taking name@ver=<installed dir> args. It serves batch / by-package / view / package (tarball artifact) / blob and the hosted tgz, patches the package's main file, and logs the Authorization header on tarball GETs. Beware: the earlier version filtered node_modules by absolute path and served empty tarballs. reg.py is a plain-HTTP registry passthrough for hosted rollback.

Re-triage

Main is unchanged since run 5 (no yarn code changed), so #363 / #364 / #437 / #467 / #493 stand. #436 stays closed.

Cells (Linux, 61cfb9b)

• PnP (installConfig.pnp), stale .pnp.js + hosted pin → vex: fail, filed In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 (1.12.3 / 1.17.3 / 1.22.22; v4.0.0 not affected because it has no manifest-less VEX). The suspect is vex.rs:603-611.
• PnP with .pnp.js present: agent / hosted / vendored scan all emit yarn_pnp_unsupported: pass. A PnP lock-only checkout: the hosted rewrite goes through, and the frozen install loads the patched copy via .pnp.js (it works, and that's how the stale state in In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 arises). Minor: the warning text names berry's .yarn/cache/*.zip and yarn patch, neither of which exists in yarn 1. I didn't file it.
• --modules-folder + hosted pin + stale deps/ → vex: attests falsely (1.10.1 / 1.22.22). Same root cause as Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493, so I commented on Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 (Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 (comment)). Vendored attests by design; only the vendored_tree_out_of_sync warning is missing.
• --modules-folder hosted / vendored rewrite + frozen fresh install: pass (patched in deps/).
• optionalDependencies incl. platform-skipped fsevents (not installed on Linux): hosted and vendored rewire all 3, the frozen install is patched, and vex attests the lock pins: pass. fsevents is attested from the lock with nothing installed, which is the documented lock-only basis.
• Uppercase names (JSONStream): agent / hosted / vendored + frozen install + vex pass. Vendored rollback is byte-exact; hosted rollback is fine (registry.npmjs.org host, documented).
• yarn import-generated lock (scoped + uppercase + caret ranges): hosted and vendored + frozen install pass.
• Hosted pin auth leakage (the Berry Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 analogue): .npmrc host token, bare _authToken, always-auth + host / bare token, scoped registry + token, _auth basic. On yarn 1.0.2 / 1.6.0 / 1.9.4 / 1.12.3 / 1.17.3 / 1.22.22, no Authorization header ever reached the patch host: pass. That confirms Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404's claim that classic is unaffected.
• Standalone vex with a stale default node_modules + hosted pin: omitted not_applied, which is correct.

Issues

• Filed In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519: In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519
• Commented on Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 (the false-VEX consequence).
• Handover to yarn-berry: entries/yarn-berry/20261002T005320Z-from-yarn-classic.md (berry PnP likely shares In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519).

False positives ruled out

• Hosted / vendored scan --vex exiting 1 in a PnP project: that's --vex with nothing to attest (manifest_not_found), not the PnP refusal. Without --vex it exits 0 as the test pins.
• Vendored vex attesting over an unpatched installed tree: by design (the committed artifact is the sole evidence).
• No auth leakage on any classic release.

Next

1. Global mode on Windows once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges (On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437, the .cmd shim lead).
2. --modules-folder at workspace level, and .yarnrc --modules-folder given via YARN_MODULES_FOLDER / npm_config_modules_folder env (the crawler can't see either).
3. --production / NODE_ENV=production installs: hosted vex on devDependencies that are in the lock but not installed.
4. The socket.yml patches policy on a workspace member path; --pure-lockfile dev flows.
5. Re-run the v4-only project columns (Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363, Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364) on macOS / Windows once fixes land.

[github-actions[bot]]

[agent] 2026-10-02: Yarn classic (1.x) bug-hunt run

Tested: main 61cfb9b (unchanged since run 5), latest release v4.0.0. Linux sandbox, Node 22, yarn 1.0.2 / 1.6.0 / 1.7.0 / 1.10.1 / 1.22.22 from npm i yarn@<v>. One probe branch for macOS / Windows (run https://github.com/SocketDev/socket-patch/actions/runs/36975456921). Local Python mock patch API, as in run 6.

Re-triage

Main is unchanged, so #363 / #364 / #437 / #467 / #493 / #519 stand. #493 now has the draft fix PR #520. It reads only the nearest .yarnrc --modules-folder, which matches what yarn honors (see the env-var finding below).

Cells (all pass)

• --production installs (dev dep in the lock, not installed), hosted, 1.22.22: both entries rewired, and the frozen --production and full installs are patched. vex attests the uninstalled dev dep from its lock pin, which is the documented lock-only basis (as with platform-skipped fsevents).
• integrity sha1-… locks (what yarn 1.10–1.12 writes for packages that have no registry sha512): hosted (1.10.1 / 1.22.22) and vendored (1.22.22) rewire to sha512. The frozen fresh install is patched, the lock is stable on re-install, and yarn check --integrity passes. Vendored rollback is byte-exact.
• Odd range syntax in lock keys (">= 1.2.0 < 1.4", "1.x || 2.x", latest, ~1.3, "1.2.2 - 1.2.4", =1.2.2, v1.2.2, across 3 workspaces), hosted, 1.22.22: the merged and quoted keys are rewired, and the frozen install is patched and stable.
• Workspace member under tests/e2e (the default discovery exclusion dir) with a nested multi-version copy: agent patches both copies. Hosted / vendored rewire the root lock.
• socket.yml policy on that workspace (packages, ignorePackages with version, ignorePaths: tests/**, includePaths: tests/**, minSeverity: critical), hosted and agent: everything behaves as docs/configuration.md says (a member is part of the root project, and package filters narrow it).
• yarn set version classic layout (.yarnrc.yml yarnPath + .yarnrc yarn-path + packageManager: yarn@1.22.22): hosted / vendored rewrite the v1 lock (not treated as berry), and the frozen install is patched. Agent apply works.
• vendor --revert after a vendored scan, on LF / CRLF / BOM+CRLF locks, yarn 1.7.0 and 1.22.22: byte-exact, and .socket/ is removed.
• Dev flow after scan (yarn add of another dep, then a fresh frozen install, vex, vendor --check, and a --pure-lockfile then plain reinstall), hosted and vendored:
  • Linux 1.0.2 / 1.6.0 (hosted) and 1.7.0 / 1.10.1 / 1.22.22 (both modes): pass.
  • Probe: Windows 1.7.0 / 1.10.1 / 1.22.22 and macOS 1.7.0 / 1.22.22: pass, all RESULT lines read. The yarn add keeps the hosted URLs and file:./.socket/vendor/… (no backslashes on Windows), and the lock stays stable. macOS 1.10.1 and ubuntu: the jobs were green but I didn't read their logs.
• CI npm-compatibility.yml on 61cfb9b: green.

Issues

None filed, commented on or closed this run.

False positives ruled out

• YARN_MODULES_FOLDER / npm_config_modules_folder env vars: yarn 1.22.22 ignores both (it installs into node_modules), so the crawler is right not to read them.
• ~/.yarnrc --modules-folder deps resolves relative to $HOME (yarn installs into ~/deps). That's exotic, so I didn't pursue it.
• Hosted standalone vex printing record_unavailable when only SOCKET_PATCH_SERVER_URL is set: it also needs --api-url (with a mock). That's a harness detail.
• v5 has no setup subcommand. The agent cells use apply.

Leftover

• The probe branch bughunt/yarn-classic/20261002-dev-flow couldn't be deleted (the proxy rejects ref deletion, same as earlier runs).

Next

1. Global mode on Windows once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges (On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437).
2. Re-check Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 after Fix npm crawler missing configured install roots (#493, #518) #520 merges: workspace-level --modules-folder and --install.modules-folder.
3. Hosted rollback on integrity sha1- locks (needs the reg.py registry passthrough): what integrity does the restored entry get?
4. .yarnclean / yarn autoclean versus the agent and hosted patched files and VEX hash verification.
5. Re-run the v4-only project columns (Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363, Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364) on macOS / Windows once fixes land.

[github-actions[bot]]

[agent] 2026-10-02: Yarn classic (1.x) bug-hunt run

Tested: main 61cfb9b (unchanged since run 5), latest release v4.0.0 (npm @socketsecurity/socket-patch@4.0.0, used to bisect). Linux sandbox only, Node 22, yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.17.3 / 1.19.0 / 1.21.1 / 1.22.22 from npm i yarn@<v>. No probe branches: this run's cells are OS-independent (yarn's own cache-key logic, lock text).

Harness (rebuilt): mock.py is a Python mock patch API taking name@ver=<installed dir> args. It serves batch / by-package / view (with blobContent) / package (tarball artifact) / blob and the hosted tgz. Env knobs: NOSHA1=1 serves a sha512-only artifact integrity, and MARK= sets the patch marker. reg.py is a plain-HTTP registry passthrough for hosted rollback (SOCKET_NPM_REGISTRY=http://127.0.0.1:<port>).

Re-triage

Main is unchanged, so #363 / #364 / #437 / #467 / #493 / #519 stand. #493 still waits on PR #520, and the Windows global-mode cells still wait on #442.

Cells

• Hosted grant without integrity.sha1 (sha512-only, the shape the repo's own npm / bun hosted fixtures use): fail, filed Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558. The lock gets resolved "<url>" with no #sha1, which lands in yarn's npm-<name>-<ver>-integrity cache slot. That's shared with fragmentless upstream entries and with earlier sha1-less hosted patches of the same version (superseding).
  • Warm-cache frozen install: yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.17.3 exit 0 and install unpatched bytes (or the superseded patch). yarn 1.19.0 / 1.21.1 / 1.22.22 exit 1 with Incorrect integrity when fetching from the cache.
  • Cold cache: patched. vex correctly omits the patch, so there's no false attestation. v4.0.0 is also affected, so it's not a regression.
• yarn.lock containing git merge-conflict markers (the conflict between two other deps, target outside it), hosted, 1.22.22: only the target entry is rewritten and the markers are kept: pass.
• Workspace member yarn install --focus --frozen-lockfile after a hosted rewrite, 1.22.22: patched: pass.
• yarn audit on a hosted lock and on an npm: alias lock, 1.22.22: works: pass.
• Hosted rollback on an integrity sha1- lock (1.10.1): restores resolved (registry.npmjs.org host + #sha1) and a sha512 integrity. Not byte-exact, but documented (default upstream entry, SOCKET_NPM_REGISTRY host), and the frozen install works: pass.
• .yarnclean (yarn autoclean --init + *.md, index.d.ts), hosted + frozen install + vex, 1.22.22: patched, not_affected: pass.
• An npm: alias plus a direct dep of the same version: yarn 1.22.22 writes two separate blocks (it doesn't merge them), so the documented alias skip applies only to the alias block.

Issues

• Filed Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558: Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 (plus a comment correcting the CLI_CONTRACT citation path).

False positives ruled out

• An alias key merged with a direct key in one block: yarn 1.22.22 never writes that form, so the shape isn't reachable.
• Hosted rollback on a sha1-integrity lock gaining a sha512 integrity: documented default upstream entry.

Next

1. Global mode on Windows once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges (On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437).
2. Re-check Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 after Fix npm crawler missing configured install roots (#493, #518) #520 merges: workspace-level --modules-folder and --install.modules-folder.
3. Re-run the v4-only project columns (Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363, Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364) on macOS / Windows once fixes land.
4. Vendored mode when the patch rewrites the package's own package.json dependencies (staged_pkg path), and whether hosted mode, which leaves the lock's dependencies: sub-map untouched, installs a missing new dependency.
5. Superseding hosted patch with sha1 on yarn ≤1.17 in-place installs (distinct slot, but .yarn-integrity short-circuit).

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

• On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434: closed 2026-10-02 17:07 UTC
• get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436: closed 2026-10-01 16:49 UTC
• Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493: closed 2026-10-02 16:15 UTC

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-02: Yarn classic (1.x) bug-hunt run

Tested: main 203e092 (latest release v4.0.0). Since run 8, main gained #520 (closes #493), #442 (global probe spawning), #496, #517, #555 and #465. Linux sandbox only, Node 22, yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.17.3 / 1.22.22 from npm i yarn@<v>. No probe branches this run: the cells are lock text and yarn resolver logic, which don't depend on the OS.

Harness (rebuilt in scratch): mock.py gained FILE=package.json PKGJSON='{"dependencies":{…}}' (a patch that rewrites the package's manifest), and its batch route now filters by the requested purls (before this fix it returned every patch). Caveat: the mock's gzip header carries the build time, so pins from an earlier mock instance won't verify after a restart.

Re-triage

• Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 was closed by Fix npm crawler missing configured install roots (#493, #518) #520. Follow-ups all pass: a workspace root .yarnrc --modules-folder deps with non-hoisted member copies (yarn puts member copies in packages/*/node_modules), agent scan patches all 3 copies (1.22.22). --install.modules-folder "./my deps" overriding --modules-folder: agent patch, vex not_affected, and after a frozen reinstall (unpatched) vex omits not_applied (1.10.1).
• Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 still reproduces after Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442: with yarn 1.0.2, yarn global dir is spawned and fails, there's no fallback, and the yarn global package is missing from scan -g (575 vs 576 packages with 1.22.22). No new information, so no comment.
• Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 still reproduces (1.22.22): a git+https entry is rewired to the hosted tgz, and the frozen install fails fatal: repository '…tgz/' not found.

Cells

• Patch rewrites the package's own package.json (adds is-odd ^3.0.0): fail, filed Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591.
  • Vendored recomputes the block's dependencies: sub-map but adds no is-odd@^3.0.0 block. The online frozen install resolves is-odd unpinned, --frozen-lockfile --offline fails "missing entry in the lockfile", and the next yarn install re-saves the lock. Same on 1.7.0, 1.10.1 and 1.22.22.
  • Hosted leaves the sub-map stale, so is-odd is never installed. There's no warning, and vex says not_affected (1.10.1 / 1.22.22). The code is the same as v4, so it's not a regression.
• Agent vex with 3 installed copies across workspaces (Fix agent vex checking only one installed copy (#516) #517): reverting one member's copy gives not_applied for that purl: pass (1.22.22).
• The repo's suites e2e_redirect_yarn_classic_build, e2e_vendor_yarn_classic_build and e2e_vendor_yarn_classic_dev_flow with SOCKET_PATCH_YARN_E2E_REQUIRED=1: all pass on 1.0.2, 1.7.0 and 1.22.22.
• Superseding hosted patch (A→B), then an in-place --frozen-lockfile install: 1.10.1 / 1.17.3 / 1.22.22 install B: pass. 1.0.2 / 1.7.0 keep A's bytes only when the changed file has the same size and mtime (yarn ≤1.9's copy skip). A longer B installs fine on 1.7.0. That's yarn's own behaviour, so it's a non-bug.

Issues

• Filed Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591: Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591

False positives ruled out

• yarn 1.0.2 / 1.7.0 keeping superseded bytes in place: yarn's size+mtime copy skip, caused by the mock's same-length markers and mtime 0, not by socket-patch.
• A "scan -g finds the yarn 1.0.2 global package" result was the mock returning every patch. After the fix it's a Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437 reproduction.

Next

1. Global mode on Windows now that Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 has merged (On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 is closed). Re-run the Windows global cells on a probe branch; the get-mode cells (get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 fixed) also need a re-run.
2. Superseding hosted / vendored patches where the patched file keeps its size, on yarn ≤1.9 in place. Check what mtime Socket-built tarballs and the vendored packer use (if it's the npm 1985 constant, an upstream→patched same-size change would be skipped in place).
3. Re-run the v4-only columns (Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363, Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364) on macOS / Windows once fixes land; re-check Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 / Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 when their PRs merge.
4. A manifest-rewriting patch that changes an existing dependency range (not just adds one), in vendored and hosted, once Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 is triaged.

[github-actions[bot]]

[agent] 2026-10-03: Yarn classic (1.x) bug-hunt run

Tested: main 045d7ec (latest release v4.0.0). Since run 9, main gained #581 (API connect/read bounds), #583, #582, #587, #572, #503 and #552. None of them touches the yarn classic rewriters. Locally: Linux, Node 22, yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 with a rebuilt mock (prep.sh + mock.py, reading the patch list from pkgs/index.json). Two probe runs: 37083449691 (global re-run, 18 jobs) and 37084536302 (macOS diagnosis, bisecting 045d7ec / 6cd3754 / bf0e0d1).

Re-triage

• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 still reproduces on 045d7ec: a mixed CRLF/LF lock goes from 6 CR lines to 13 (H) and 12 (V), and rollback isn't byte-exact. No new information, so no comment.
• Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591: commented with a new shape (a patch that changes an existing dependency range, not just adds one). Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 (comment)

Cells

• Global mode re-run (maintainer request): OS × yarn 1.0.2 / 1.6.0 / 1.9.4 / 1.10.1 / 1.22.22, plus yarn 1.22.22 via corepack.
  • Windows: every cell passes on 1.6.0 and newer, including corepack. That's report, the hosted refusal, agent apply + import, vex, rollback byte-exact, SOCKET_GLOBAL, --global-prefix rollback, the get-mode refusals and a custom --global-folder with a space and unicode. On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 and get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 are confirmed fixed.
  • Linux: all pass, as does read-only prefix (exit 1, unpatched).
  • macOS: the first scan -g failed (tcp connect error: deadline has elapsed on every batch). Diagnosis: the first connects to the freshly started Python mock stall on macOS runners. The pre-Bound patch API connects and stalled reads (#570) #581 build waited 35 s and succeeded, and since Bound patch API connects and stalled reads (#570) #581's 10 s connect bound the batches fail. Once the mock is warm, report, agent and vex all pass. This is a harness artifact, not filed (see Known non-bugs).
  • yarn 1.0.2: yarn global dir doesn't exist (Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437, still open), and the custom-global-folder cells pass.
• Symlinked yarn.lock → fail, filed Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627. Hosted refuses with redirect_symlinked_file_unsupported, but vendored exits 0, replaces the link with a regular file and leaves the target unpatched. The dry-run is silent, and rollback doesn't restore the link. Reproduced twice each on 1.7.0, 1.10.1 and 1.22.22; npm's package-lock.json does the same. Yarn writes through the link.
• yarn.lock mode 600 / 444 / 755 through H/V scan + rollback: pass.
• Agent mode with a link:../src/package dep patches the link target outside the project. That's the code Node loads, so it's a design question; not filed.

Issues

• Filed Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627: Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627
• Commented on Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591.
• Handover to npm (entries/npm/…-from-yarn-classic.md): Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 covers npm too.

False positives ruled out

• macOS scan -g api_batch_failed with connect deadline: the probe's Python mock is slow to accept its first connections, and the pre-Bound patch API connects and stalled reads (#570) #581 build waits 35 s on the same runner. Not a product bug.
• 1.0.2 global cells: the probe used yarn global dir's help text as a path (Global mode never finds yarn 1.0.x global packages: yarn global dir doesn't exist before yarn 1.1.0, and there's no fallback #437).

Next

1. Global mode: the Windows MSI install of yarn, and a read-only prefix with a non-admin Windows user.
2. Other symlinked inputs (.yarnrc, package.json, .socket/) in H/V/rollback.
3. vendor --check / repair on a Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591-shaped lock.
4. Same-size superseding patches on yarn ≤1.9 in place (the mtime question).
5. Re-check Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 / Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 / Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 once their fixes land.

[github-actions[bot]]

[agent] 2026-10-03: Yarn classic (1.x) bug-hunt run

Tested: main 045d7ec (unchanged since run 10; latest release v4.0.0). Linux, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, a rebuilt local mock (prep.sh + mock.py: batch / package grant / view / hosted tarball routes) and a plain-HTTP npm registry passthrough for hosted rollback (SOCKET_NPM_REGISTRY). No probe branches this run.

Re-triage

Main hasn't moved since run 10, so #363 / #364 / #467 / #519 / #558 / #591 / #627 stand as last measured. #627 gained a NuGet confirmation from that sibling (not ours to act on).

Cells

• yarn.lock with no trailing newline (LF and CRLF, target block last) and CRLF + trailing blank lines, H and V: scan, fresh frozen install patched, rollback. Pass. Vendored rollback is byte-exact. Hosted rollback differs only by the documented SOCKET_NPM_REGISTRY host; EOF bytes and line endings are preserved.
• Symlinked .socket/ (whole dir) and symlinked .socket/vendor/npm, single project, V: scan, vendor --check, rollback all consistent (they write and clean up at the link target). Pass on its own.
• Two projects sharing a symlinked .socket/vendor/npm → fail, filed Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664. Rollback / vendor --revert in A deletes B's tarballs through the link (exit 0, no warning), and B's frozen offline install then fails. 1.7.0 / 1.10.1 / 1.22.22. This contradicts sweep_vendor_dirs' own "symlinked eco dir cannot be ours" rule.
• yarn remove of a vendored package → fail, filed After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665. The missing lock block is treated as drift. rollback exits 1 permanently, remove exits 1 and its "re-run scan to normalize" remedy does nothing, vendor --revert exits 0 without cleaning up, and the stale artifact stays. 1.7.0 / 1.22.22. Hosted passes the same flow (rollback success, .socket/ removed, vex omits the removed package).

Issues

• Filed Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664: Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664
• Filed After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665: After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665
• Handover to npm: both probably apply to the npm-family backends (npm_lock.rs:1121 has the same missing-entry drift; remove_tree_and_prune(&uuid_dir…) has no lstat gate).

False positives ruled out

• Hosted rollback partial_failure with no registry: the known rustls-vs-proxy sandbox artifact. It's clean with the local registry passthrough.
• vex -o collides with --org (-o is the org short flag); use --output. Harness error.

Next

1. Global mode: the Windows MSI install of yarn, and a read-only prefix with a non-admin Windows user.
2. vendor --check / repair on a Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591-shaped lock.
3. Windows directory junctions for .socket/vendor/npm (Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 shape) via a probe.
4. Other drift shapes after yarn upgrade <pkg> to a different version (the block is renamed, not removed): does it hit After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665's dead end too?
5. Re-check Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 / Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 / Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 / Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 / After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 once fixes land.

[github-actions[bot]]

[agent] 2026-10-03: Yarn classic (1.x) bug-hunt run

Tested: main 045d7ec (unchanged since run 10; latest release v4.0.0). Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22 (npm i yarn@<v>). New harness this run: a scratch cargo test that reuses the repo's prebuilt_common wiremock fixture to run vendor against a staged .socket/manifest.json + blob (the e2e_vendor_yarn_classic_dev_flow.rs pattern). That's much quicker than rebuilding the Python mock. One probe run covered macOS / Windows: https://github.com/SocketDev/socket-patch/actions/runs/37123949202 (9 jobs: 3 OS × 1.7.0 / 1.10.1 / 1.22.22, embedding socket-patch's exact vendored lock + tarball).

Re-triage

Main hasn't moved, so every open issue stands as last measured. #665 now has a fix in flight (draft PR #689). I commented there that its plan would turn the #692 shape into a permanent refusal.

Cells

• Vendored workspaces, installs run from a member dir → fail, filed Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691. cd b && yarn install --frozen-lockfile, yarn --cwd b install and yarn workspace b add all fail on a cold cache with Tarball is not in network (yarn resolves file:./.socket/vendor/… against the cwd). Root installs pass, and so do warm-cache member installs. Reproduced on Linux / macOS / Windows × 1.7.0 / 1.10.1 / 1.22.22. Control: the pre-vendor registry lock passes from the member dir. A hand-written file: tarball dep fails the same way (the root cause is yarn's handling, but socket-patch introduces the entry, with no warning and nothing in the docs).
• Yarn merging a second range into the vendored block (left-pad@^1.1.0, left-pad@^1.3.0:) → fail, filed Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692. Rollback ×2 exits 1 ("no longer exists"), and the lock stays wired. remove exits 1, vendor --revert exits 0 as a no-op, and re-vendoring says already_vendored without re-keying, so the printed remedy loops. Linux 1.7.0 / 1.10.1 / 1.22.22.
• yarn add left-pad@^1.3.0 at a non-workspace root after vendoring (^1.1.0 → ^1.3.0): yarn re-resolves the block from the registry (unpatched). That's yarn's own behaviour; the rollback that follows is the After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 shape. Not filed again.
• Backlog item 4 (yarn upgrade to another version): the block is re-keyed, which is the After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 shape (covered by Fix vendored revert keeping artifact for removed lock entry (#665) #689).

Issues

• Filed Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691: Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691
• Filed Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692: Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692
• Commented on After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 (relationship to Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 / Fix vendored revert keeping artifact for removed lock entry (#665) #689).

False positives ruled out

• First probe attempt (run 37123880607): every job "failed" because bash -e aborted on the first expected failure. Harness error, fixed with set +e.
• Member-dir yarn add with a warm cache passes (cache-slot hit). That isn't a fix, just masking.

Probe branch

bughunt/yarn-classic/20261003-member-install: deletion was rejected by the git proxy again (left on the remote).

Next

1. vendor --check / repair on a Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591-shaped lock and on a Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 merged-key lock (does --check notice the stale key?).
2. Windows directory junctions as .socket/vendor/npm (Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 shape) via a probe.
3. Hosted mode: does a merged key break hosted rollback the way Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 breaks vendored rollback?
4. Global-mode leftovers (Windows MSI yarn, non-admin read-only prefix).
5. Re-check Hosted and vendored yarn classic modes rewire git-sourced yarn.lock entries, so every later yarn install fails while scan and VEX report success #363 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 / In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 / Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 / Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 / After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 once fixes land.

[github-actions[bot]]

[agent] 2026-10-06: Yarn classic (1.x) bug-hunt run

Tested: main 9c43dfc (unchanged since run 21; latest release v4.0.0). Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22. Also built PR heads #940 (980b7b6) and #924 (f791612). New multi-package mock for same-basename tarballs. No probe branches this run.

Re-triage

Main hasn't changed. Instead, I verified the two open fix PRs for my issues on real yarn:

• Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940: fixed on 1.7.0 / 1.10.1 / 1.22.22 (H and V lock-only vex omit it, V post-install vex omits it, vendor --check exits 1). Controls still attest. Comment: Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 (comment)
• Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / PR Fix yarn classic unrewritable copies going unreported (#921, #857) #924: fixed on 1.7.0 / 1.22.22 (H redirect_yarn_classic_directory_skipped, V events[].reason warning, vex omits it, and the file:-only V refusal names the copy). Comment: Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 (comment)
  No human replies on the discussion.

Cells

• Agent scan <PATH> with nested duplicate copies in a workspace: fail. Members a and b each have their own left-pad@1.3.0. scan packages/a scans 0 packages and exits 0 (also /**, ./, absolute and the copy path); scan packages/b selects it; rollback packages/a selects both copies. 1.7.0 / 1.10.1 / 1.22.22, ×2 each. Same root as Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 (pnpm, the crawler's seen name@version dedup), so I commented there instead of filing: Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 (comment)
• Hosted positional scan packages/a / 'packages/*': the Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 shape (per-dir --cwd). Comment: Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (comment)
• Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 non-workspace variant (transitive ^1.3.0 + exact root re-add): yarn merges it into the pinned block, so it's patched and attested. Pass on 1.7.0 / 1.10.1 / 1.22.22.
• get <CVE> / get <GHSA> in H / V / A + frozen install + vex: pass. --download-mode file|diff agent: pass.
• --manifest-path: hosted writes no manifest, and vendored ignores it. list --manifest-path resolves the root from the path (documented). Pass.
• Same-basename tarballs left-pad@1.2.0 + @types/left-pad@1.2.0: V + offline mirror + pruning (fresh offline, in place, vex, byte-exact rollback), and H cold / warm-cache frozen installs: pass on 1.7.0 / 1.10.1 / 1.22.22.
• link: copy beside a registry range: yarn links every range of that name, so there's nothing to pin (yarn behaviour).

Issues

No new issues. Comments on #938, #921, #778 and #884.

False positives ruled out

• Vendored vendor_prebuilt_layout_mismatch for @types/left-pad@1.2.0: my mock kept the upstream left-pad/ tarball root, and the check requires package/ by design. What the real service emits is unknown (backlog).
• The hosted post-install vex "miss" in a Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940 control ran against the stale pre-reinstall tree (not_applied, documented). The lock-only control attests on both main and the PR.

Next

1. Re-check Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 / Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 / Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907 / Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 once their PRs merge. Also Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 on PR Fix yarn classic unrewritable copies going unreported (#921, #857) #924.
2. npm-workspace analogue of the nested-copy scope miss (hand over to npm), and rollback / --sync / --prune with PATHs on the same yarn layout.
3. Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on macOS / Windows (probe), plus file: copies under nohoist.
4. Cross-OS hosted checkout with one embedded prebuilt tarball.
5. Global-mode leftovers (Windows MSI yarn, non-admin prefix).

[github-actions[bot]]

[agent] 2026-10-07: Yarn classic (1.x) bug-hunt run

Tested: main 9c43dfc (unchanged since run 21; latest release v4.0.0, plus the published @socketsecurity/socket-patch@4.0.0 npm package). Linux sandbox, Node 22, yarn 1.1.0 / 1.2.1 / 1.3.2 / 1.4.0 / 1.5.1 / 1.7.0 / 1.9.4 / 1.10.1 / 1.22.22. One probe branch (bughunt/yarn-classic/20261007-musl-wrapper, run https://github.com/SocketDev/socket-patch/actions/runs/37554067537).

Re-triage

Main hasn't changed and none of the fix PRs (#940, #924, #901, #839, #837, #917) has merged, so there was nothing to re-check. No human replies on the discussion or on the issues.

Cells

• New: npm wrapper on Alpine with yarn 1: fail, filed On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974. yarn 1 ignores the libc field and installs both socket-patch-linux-x64-gnu and -musl. bin/socket-patch takes -gnu first, the spawn fails with ENOENT, and it exits 1 with empty stdout and stderr. yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22 on node:22-alpine all fail. Controls pass: npm 10.9 on Alpine installs only musl, and yarn on bookworm (glibc) works.
• Old-release fill-ins, 1.1.0 / 1.2.1 / 1.3.2 / 1.4.0 / 1.5.1 / 1.9.4: hosted CRLF (fresh frozen install patched, rollback keeps CRLF), a hosted multi-version workspace with a scoped member, and an H→V→H takeover + rollback all pass, each followed by a post-rollback frozen install. The vendored leg is n/a on ≤1.6, as known.
• A plain yarn install after an H / V scan causes no lock churn: pass on 1.7.0 / 1.10.1 / 1.22.22.
• BOM-prefixed package.json (root, workspace root, member), A / H / V + vex: pass.
• npm: alias copy beside a direct copy of the same name@version: H warns and vex refuses, V wires and patches both: pass.

Issues

• Filed On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974

False positives ruled out

• Hosted rollback "not byte-exact" on old releases: the sandbox registry passthrough restores registry.npmjs.org + integrity, which is the documented default upstream entry. Post-rollback frozen installs pass.
• rollback packages/a also rolling back packages/b's copy: that's documented purl-level scoping.

Next

1. On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 follow-ups: arm64 Alpine, yarn global add on Alpine. Re-check once the wrapper changes.
2. Re-check Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 / Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 / Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907 / Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 once their PRs merge.
3. Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on macOS / Windows (probe), plus file: copies under nohoist.
4. Cross-OS hosted checkout with one embedded prebuilt tarball.
5. Agent-mode cells on 1.1.0 / 1.2.1 / 1.4.0, and H offline-mirror cells on 1.3.2 / 1.5.1.

[github-actions[bot]]

[agent] 2026-10-07: Yarn classic (1.x) bug-hunt run

Tested: main 9c43dfc (unchanged since run 21; latest release v4.0.0, plus the published @socketsecurity/socket-patch@4.0.0). Linux sandbox, Node 22, yarn 1.1.0 / 1.2.1 / 1.4.0 / 1.7.0 / 1.10.1 / 1.22.22. One probe branch (bughunt/yarn-classic/20261007-musl-pr976, runs https://github.com/SocketDev/socket-patch/actions/runs/37582670213 and https://github.com/SocketDev/socket-patch/actions/runs/37582882236). Also built PR #978 (59eac7e) locally. The local mock patch API was rebuilt again, now multi-package (left-pad@1.3.0 + is-number@7.0.0), plus the plain-HTTP registry passthrough.

Re-triage

• On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 (wrapper on musl): PR Fix npm wrapper running the glibc binary on musl (#974) #976 (162befe) fixes it. On x64 and arm64 × node:22-alpine / node:18-alpine × yarn 1.7.0 / 1.22.22, the 4.0.0 wrapper exits 1 silently, while the PR wrapper exits 0 via node bin, yarn socket-patch and yarn global add. Glibc controls pass. Exit codes pass through (usage 2). New fact: arm64 Alpine fails the same way on 4.0.0. Commented: On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 (comment)
• Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 (berry stale .pnp.js, PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978): the PR's nodeLinker gate also applies to yarn 1 PnP (installConfig.pnp), and yarn 1 ignores both .yarnrc.yml and YARN_NODE_LINKER. With an ancestor .yarnrc.yml nodeLinker: node-modules or that env var, a real yarn-1 PnP project loses yarn_pnp_unsupported: agent says "not installed; run your package manager's install first", and hosted / vendored pin with no warning. Main is correct. Commented: Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 (comment)
• No other fix PR has merged (Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940, Fix yarn classic unrewritable copies going unreported (#921, #857) #924, Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901, Fix hosted yarn classic with an offline mirror (#364) #839, Fix vendored npm-family tarballs dropped by .gitignore (#831) #837, Fix hosted yarn classic pins missing berry warning (#907) #917 are still open). No human replies on the discussion.

Cells

• New: git merge of two vendored branches → one-sided state.json resolution: fail, filed Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991. vendor --check and rollback exit 0 while the other package stays wired. Rollback deletes the ledger, and after that rollback and re-vendor refuse with "restore state.json from version control", which can't help after a merge. repair / scan already diagnose the uncovered reference. 1.7.0 / 1.10.1 / 1.22.22, ×2 each. A manual JSON union of entries passes end to end (check + byte-exact rollback). The conflicted (marker-laden) ledger fails loudly in check / vex / repair / rollback; list warns on stderr and exits 0 (minor, not filed).
• Upgrade path, v4.0.0-written state → main: hosted (v4 redirect-state.json) list / vex / re-scan (lock unchanged) / rollback / takeover to vendored + frozen install + rollback; vendored (v4 manifest + ledger) list / vex / vendor --check / re-scan (vendor_manifest_record_migrated) / rollback byte-exact: all pass (1.22.22). Frozen installs on the v4 output are patched.
• Agent apply + vex + re-run + byte-exact rollback on 1.1.0 / 1.2.1 / 1.4.0: pass.

Issues

• Filed Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991
• Commented on On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 and Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 (links above).

False positives ruled out

• Probe "Permission denied" (exit 126) for yarn socket-patch with the PR wrapper: a harness artifact, because cp from a 644 mount dropped +x. Rerun with cat > and it passes.
• left-pad "patched after rollback" in the Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991 repro: the repro's later scan --mode vendored re-vendored it. Not a rollback defect.
• v4.0.0 has no vendor --check and no scan --package, so Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991 is new v5 behaviour, not a regression.

Next

1. Re-check Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991 on npm / pnpm vendored, and hand it over if it's family-wide (the check loop is generic).
2. Re-check On Alpine/musl, @socketsecurity/socket-patch installed with yarn classic exits 1 with no output: yarn 1 ignores libc, installs both -gnu and -musl binaries, and the wrapper runs the glibc one #974 / Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 once PRs Fix npm wrapper running the glibc binary on musl (#974) #976 / Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 merge (Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 with the yarn-1 PnP cell above).
3. Re-check Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 / Vendored yarn classic drops the git-skip warning when the git block is the only copy, and refuses with vendor_lock_entry_not_found telling the user to run yarn install #857 / Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 / Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 / Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907 / Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 once their PRs merge.
4. Merge flows: two branches vendoring the same package at different patch uuids, and hosted + vendored on different branches.
5. H offline-mirror cells on 1.3.2 / 1.5.1 (expected n/a ≤1.6).

[github-actions[bot]]

[agent] 2026-10-07: Yarn classic (1.x) bug-hunt run

Tested: main 1c6c509 (29 commits past 9c43dfc: #839 closes #364, #924 closes #921 / #857, #901 closes #884, #976 closes #974, #837 closes #831, #918 changes npm-family restores). Latest release v4.0.0. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, with the run-18 mock (extracted from the 20261005-agent-xos probe branch). No probe branches this run.

Filed

• Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 (Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013): the hosted offline-mirror refusal from the Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 fix reads only the project's own .yarnrc / .npmrc. When the mirror is set in a parent-dir .yarnrc, ~/.yarnrc, ~/.npmrc or yarn's user config (what yarn config set yarn-offline-mirror writes), the scan rewrites the lock, reports success with no warning and VEX attests, then every frozen install fails the integrity check (1.10.1 / 1.22.22, ×2). 1.7.0 installs without --offline.

Re-triage

• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (mixed CRLF/LF lock, hosted): still reproduces. Commented: Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (comment)
• Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 (vendored install from a member dir): still reproduces. Commented: Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 (comment)
• Verified closed fixes on main: Hosted yarn classic redirect breaks every install in projects with a yarn-offline-mirror: the mirror's upstream tarball shares the hosted URL's basename and fails the new integrity pin #364 (project .yarnrc mirror refused, lock untouched), Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (member-dir hosted scan exits 1 redirect_workspace_lockfile_elsewhere), Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 (redirect_yarn_classic_directory_skipped, VEX omits the package). All pass on 1.22.22.

Cells

• H + mirror in project .yarnrc: pass. H + mirror in parent / ~/.yarnrc / ~/.npmrc / yarn user config: fail Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013.
• H member-dir refusal (Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884): pass. H file: member copy (Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921): pass.
• Env-var mirror (YARN_YARN_OFFLINE_MIRROR, npm_config_yarn_offline_mirror): blocked. The harness's initial yarn install failed (ENOENT on the mirror tarball), so retest.

False positives ruled out

• Running yarn config set as root writes /usr/local/share/.yarnrc, not $HOME. It's a sandbox detail, and it still reproduces Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013.

Next

1. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 follow-ups: env-var mirrors, the vendored→hosted takeover preflight with a user-level mirror, macOS/Windows home paths.
2. Re-check Yarn classic VEX attests not_affected when yarn.lock also has a registry block for the patched name@version (e.g. after yarn add -W <pkg> --exact), though yarn installs only the unpatched registry copy #938 / Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap) #907 / Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778 once their PRs merge; Vendored yarn classic: after a git merge resolves .socket/vendor/state.json to one side, vendor --check and rollback exit 0 while the other side's package stays wired, and rollback deletes the ledger, stranding it #991 on npm/pnpm vendored.
3. npm-workspace analogue of Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778; rollback <PATH> on the nested layout.
4. Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on macOS/Windows via a probe.

[github-actions[bot]]

[agent] 2026-10-07: Yarn classic (1.x) bug-hunt run

Tested: main 05ecc6e (after #940 closes #938, #917 closes #907, #657, #1015). Latest release v4.0.0. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.12.3–1.22.22, with the run-18 mock (plus a no-sha1 variant) and a plain-HTTP registry passthrough for hosted rollback. No probe branches this run.

Filed

• Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 (Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078): the hosted offline-mirror refusal (Fix hosted yarn classic with an offline mirror (#364) #839) misses a project .yarnrc / .npmrc that starts with a UTF-8 BOM. yarn 1.10.1 / 1.22.22 honour the file, the scan pins anyway, VEX attests, and every install fails integrity. A vendored→hosted takeover turns a working vendored project into a broken hosted one.
• Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 (Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081): on yarn 1.22.22, an npm: alias copy beside a direct dep is skipped by hosted (documented), but the in-run scan --mode hosted --vex still attests not_affected while standalone vex refuses. The cause: assume_applied (scan/hosted.rs:1337) doesn't exclude alias-skipped uuids.

Commented

• 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: the same alias state is a third ContestedWiring trigger, so rollback / remove / list refuse, and the takeover and vendor --revert land on hosted. 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 (comment)
• Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013: the env-var mirrors (YARN_YARN_OFFLINE_MIRROR, npm_config_yarn_offline_mirror) are missed too. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 (comment)
• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467: PR Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 narrows it but doesn't fix vendored rollback on a mixed lock. Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (comment)

Re-triage

• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758: still reproduces. Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 (comment)
• Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558: still reproduces, and the sha1-bearing control passes. Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 (comment)

Cells

• BOM .yarnrc / .npmrc mirror, H + takeover: fail Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 (1.10.1 / 1.22.22); 1.7.0 pass. Env-var mirror: fail Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013.
• npm: alias beside a direct dep, H in-run VEX: fail Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 (1.22.22); merged-block releases pass. H rollback / remove: fail 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.
• Scoped alias name, H / V / A + rollback: pass. .yarnrc yarn-path layout, H / V / A: pass.
• PR Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 18-cell battery: no regression versus main.

False positives ruled out

• Berry 4.18.1 run outside corepack migrates a yarn@1-pinned vendored lock while the migration warning is suppressed. That's documented posture (the pin is the documented remedy), so it's recorded as a design note, not filed.

Next

1. Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 on a Windows probe (PowerShell-written BOM .yarnrc), and Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 on berry / npm / pnpm alias skips (hand over if they reproduce).
2. Re-run the battery on PR Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057's final head, and verify 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 (alias trigger) once PR Fix open npm issues #1008 merges.
3. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013: takeover preflight with a user-level mirror, plus macOS / Windows home paths.
4. npm-workspace analogue of Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778; Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 on macOS / Windows.

[github-actions[bot]]

[agent] 2026-10-08: Yarn classic (1.x) bug-hunt run

Tested: main e61a845 (after #978 for PnP / nodeLinker and #1073 for brace / class workspace globs). Latest release v4.0.0. Linux sandbox, Node 22, yarn 1.0.2 / 1.6.0 / 1.10.1 / 1.22.22, with the run-18 mock. No probe branches this run.

Filed

• Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 (Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097): a hosted scan from a yarn classic workspace member still exits 0 with nothing pinned when the root workspaces uses a ! pattern (which yarn 1 ignores, so the dir is still a member) or an extglob (packages/@(a|b)). The Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 / Hosted scan/get from an npm workspace member still pins nothing and exits 0 when the root's workspaces glob uses braces or a character class (packages/{a,b}, packages/[a-c]), because the #884 refusal's matcher doesn't support them #1071 matcher (governing_root.rs workspaces_include) disagrees with yarn 1 about membership.

Re-triage

• In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 still reproduces on e61a845 (×2). Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 doesn't touch vex; PR Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033 is open. In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 (comment)

Cells

• ! / extglob member, H: fail Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 (1.0.2 / 1.6.0 / 1.10.1 / 1.22.22). packages/* control: pass. Root run: pass. V from the member: fails closed (pass).
• Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 on classic: a PnP loader beside a classic lock stays live, and disabling PnP deletes .pnp.js: pass.

False positives ruled out

• A stale yarn-1 .pnp.js after disabling PnP: yarn 1 deletes it on reinstall, so there's no Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 analogue.

Next

1. Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 on get, and on npm / berry / bun roots (hand over extglob to npm if it reproduces).
2. Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 on a Windows probe (PowerShell BOM .yarnrc); Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 on berry / npm / pnpm alias skips.
3. Re-check 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 (PR Fix open npm issues #1008), In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 (PR Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033) and Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 once merged.
4. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 takeover preflight with a user-level mirror; npm-workspace analogue of Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778.

[github-actions[bot]]

[agent] 2026-10-08: Yarn classic (1.x) bug-hunt run

Tested: main ea09714 (after #1083 for the mirror resolution, #1033, #1035 for supersede re-pin / remove, #1044 for the governing-lock table, and #1077 for the berry warning). Latest release v4.0.0. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, with the run-18 mock plus a two-generation variant (MOCK_UUID / MOCK_MARKER / MOCK_PUB). One probe branch.

Filed

• Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 (Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115): a mirror set in a workspace member's .yarnrc isn't seen by the Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 resolver. A hosted scan from the root pins, reports success, and in-run / standalone VEX attest. Every frozen install run from that member (cd member, --cwd member) then fails Integrity check failed. Seen on 1.10.1 / 1.22.22, ×2. 1.7.0 installs patched (no integrity line).

Re-triage

• Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 still reproduces on ea09714 (×2): Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 (comment)
• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still reproduces (×2; Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033 covered pnpm bundled copies only): Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 (comment)
• Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 also reproduces through get <uuid> --mode hosted from the member (×2): Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 (comment)

Cells

• Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 mirror resolution, Linux (root): project / /usr/local/share/.yarnrc / ~/.yarnrc / symlinked user rc / ancestor / YARN_YARN_OFFLINE_MIRROR / npm_config_* / NPM_CONFIG_USERCONFIG / <prefix>/etc/yarnrc / key = value .npmrc / symlinked project .yarnrc and .npmrc: all refused, pass. false layers (npm false + yarn path, project false + user path, env false + project path): pinned, mirror inactive in real yarn, installs patched, pass (1.7.0 / 1.10.1 / 1.22.22).
• Cross-OS probe (run 37740151120; ubuntu / macos / windows × 1.10.1 / 1.22.22, non-root): user yarn config set, user .npmrc, <prefix>/etc/yarnrc (node dir on Windows), parent .yarnrc, both env spellings, BOM+CRLF project .yarnrc, PowerShell 5.1 Set-Content -Encoding utf8 BOM project and user .yarnrc, backslash Windows mirror path, npm-false control: 12/12 (Windows) and 9/9 (Linux / macOS) pass on every leg.
• V→H takeover with a user-level mirror: refused, vendored entry kept, frozen install patched (×2), pass.
• Replace a superseded patch generation's wiring on re-pin and remove #1035 supersede (gen1 → gen2), H and V on LF / CRLF / BOM+CRLF, plus H→V, V→H, A→V and A→H across generations: frozen installs carry gen2, vex attests, rollback is byte-exact (V) or upstream (H), pass (1.22.22; H→V also 1.7.0). Workspace merged key (left-pad@1.3.0, left-pad@^1.3.0, left-pad@~1.3.0:) supersede + remove / rollback, H and V: pass.
• Decide which lockfile governs installs in one table #1044 twin locks: yarn.lock + package-lock.json / npm-shrinkwrap.json, H and V: pass (unchanged). yarn.lock + stale pnpm-lock.yaml: vendored wires pnpm (precedence pnpm > yarn) and warns vendor_multiple_lockfiles that yarn.lock stays unpatched; the yarn install is unpatched. Documented warning, not filed.

False positives ruled out

• The H→V supersede takeover failed redirect_revert_failed until SOCKET_NPM_REGISTRY pointed at the local passthrough (sandbox TLS, already in Known non-bugs).
• The first local probe pass "refused without mirror" after yarn config set as root: the root-only /usr/local/share/.yarnrc leaked between cells (harness).
• A member-rc mirror only breaks installs once the mirror holds the upstream tarball. When the member install is a no-op after a root install, the mirror stays empty and the install is patched.

Next

1. Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 follow-ups: member .npmrc, yarn workspace <m> add, and the V→H takeover in that shape.
2. Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 / Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 on older images (macOS 13 / Windows 2019), and 1.7.0 on the cross-OS probe.
3. Re-check 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 (PR Fix open npm issues #1008), Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 and Make the vendored-to-hosted takeover atomic #1039 once merged. Then Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692.
4. Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 on berry / npm / pnpm alias skips (hand over if it reproduces). npm-workspace analogue of Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778.
5. Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261008-mirror-xos.

[github-actions[bot]]

[agent] 2026-10-08: Yarn classic (1.x) bug-hunt run

Tested: main e2d9633. Since run 31 it adds #1057 (the yarn.lock grammar moved to formats/yarn, and non-registry copies are no longer pinned), #1050 (one vendored-entry liveness verdict for the prune GC) and #1029 (apply --check verifies agent patches; redirect.patches[]). Latest release v4.0.0. Linux sandbox, Node 22, yarn 1.0.2 / 1.4.0 / 1.7.0 / 1.10.1 / 1.22.22, with the run-18 mock (plus a no-sha1 variant and a name/version-parameterised variant). One probe branch.

Filed

• None. No new defect met the filing bar.

Re-triage and comments

• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467: the hosted half is fixed by Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 (a mixed CRLF/LF lock keeps every line's ending through scan and rollback). Vendored still reproduces on Linux, macOS and Windows (probe 37781119597, 6/6 legs). Comment: Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 (comment)
• Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 still reproduces ×2 (1.10.1 warm cache installs unpatched; 1.22.22 fails Incorrect integrity): Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 (comment)
• Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115: a member .npmrc (yarn-offline-mirror=./mirror) triggers it too, ×2: Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 (comment)

Cells (all pass unless noted)

• Move all yarn.lock parsing into formats/yarn and stop pinning non-registry copies #1057 regression battery, H and V, fresh frozen install + VEX + rollback, on yarn 1.22.22. Key shapes: exact, latest, *, >=1.0.0 <2.0.0, 1.x || ^1.3.0, a resolutions version force. Lock shapes: CRLF, BOM+CRLF, no trailing newline, a comment line before the block, extra blank lines. Also base / CRLF / alias-merge on 1.7.0 and 1.10.1, and H on 1.0.2 / 1.4.0 ×2. The alias copy beside a direct dep on 1.22.22 is still Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 / 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 (known).
• B16 fork shapes. resolutions to a file: tarball or URL: yarn 1.7 / 1.10 / 1.22 always add the fork pattern to the merged key, so H skips (redirect_yarn_classic_non_registry_entry_skipped) and V skips or refuses. Fork copy in a member beside a registry root copy: H/V pin the root, the fork stays the user's, and in-run and standalone VEX don't attest. v4.0.0 legacy pins on URL / file: forks: main names redirect_yarn_classic_non_registry_legacy_pin, and rollback refuses with a git-restore remedy. v4.0.0 legacy vendored wiring: main keeps it (vendor_yarn_classic_non_registry_legacy_wiring), vendor --check exits 0, and rollback is byte-exact.
• Decide vendored-entry liveness through one discovery verdict #1050 prune GC (scan --mode vendored --prune) keeps live wiring on base, BOM+CRLF, alias-merge (1.10 / 1.22), a real twin package-lock, a stale pnpm-lock.yaml, a workspace member dep, and no node_modules. After yarn remove, vendor --check says "dependency removed" and --prune reverts cleanly (×2).
• Stop CI gates passing on missing paths, unverified agent patches and unreported hosted pins #1029 apply --check (agent): base, workspaces with nested copies, --modules-folder from .yarnrc, nohoist. Exit 0 when patched, exit 1 after install --force or a tampered nested copy.
• nohoist workspaces, H/V + frozen install + VEX: pass.
• Uppercase package name (JSONStream@1.3.5), H/V/A: pass when the API purl keeps the case. A lowercased API purl fails closed in every mode (exit 1, entry_not_found / package_not_installed). What the real API returns can't be checked from here, so not filed.
• Cross-OS probe 37781119597 (ubuntu / macos / windows × 1.10.1 / 1.22.22): H/V × native / LF / CRLF / mixed / BOM+CRLF locks (frozen install, untouched bytes, rollback), plus file: fork tarballs with backslash and ./ specs. Everything passes on all 6 legs except vendored-mixed (Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467).

False positives ruled out

• Agent mode overwrites a yarn file: / URL fork copy (same name@version) with Socket's patched file. That's the documented default mismatch policy (warn and overwrite; --strict refuses). The missing warning in scan --json is scan --mode agent --json and get --json overwrite a locally modified npm file without the documented content_mismatch_overwritten warning (not in the JSON, not on stderr) #1004 (npm), so not re-filed.
• The vendored fork-only cell exits 1 vendor_lock_entry_not_rewritable. That's documented when the fork is the only copy.
• A lock with trailing spaces on every line: yarn itself refuses the frozen install. Synthetic.

Next

1. Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 follow-ups: yarn workspace <m> add, a V→H takeover in that shape, macOS / Windows.
2. Re-check 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 (PR Fix open npm issues #1008) and Make the vendored-to-hosted takeover atomic #1039 once merged; then Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692.
3. Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 on berry / npm / pnpm alias skips (hand over if it reproduces). npm-workspace analogue of Agent-mode scan packages/<member> finds nothing in a pnpm workspace (exit 0), while rollback packages/<member> selects the same packages #778.
4. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 / Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 on older images (macOS 13 / Windows 2019), and 1.7.0 on a cross-OS probe.
5. Leftover probe branch (deletion blocked): bughunt/yarn-classic/20261008-grammar-xos.

[github-actions[bot]]

[agent] Janitor: drift. These cells still say fail for closed issues: #519 (PnP stale .pnp.js + hosted pin → vex; closed as completed 2026-10-08), #907 (berry migration warning; closed by #917), #938 (registry block beside the pin; closed by #940), and #467 (mixed CRLF+LF lock; a maintainer closed it as not planned on 2026-10-08 13:15Z after your run-32 note that the hosted half is fixed). The rows that cite #1013 / #1078 as fail (outside-project / BOM mirror) are also stale; the table already says they're fixed.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-08: Yarn classic (1.x) bug-hunt run

Tested: main cf8b164. Since run 32 it adds #1039 (an atomic vendored→hosted takeover: staged revert, retract when the rewrite doesn't pin), #1117 (BOM strips routed through formats::text) and #1021 (SOCKET_FORCE removed). Latest release v4.0.0, also installed from npm for comparison. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, a local mock patch API, and a plain-HTTP registry passthrough for hosted rollback. No probe branches this run: the new bug is platform-independent planner logic, and ref deletion is still blocked.

Filed

• Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158: a vendored→hosted takeover un-patches a vendored npm: alias copy when the direct copy is pinned. The takeover commits with redirect_takeover_reverted_vendored instead of retracting, so node_modules/<alias> installs unpatched (exit 0). Reproduced ×3 (scan ×2, get <uuid>) on 1.22.22. The alias-only shape is retracted correctly. v4.0.0 behaves the same, so it isn't a Make the vendored-to-hosted takeover atomic #1039 regression, but it contradicts the new Staged takeover contract. Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158

Re-triage and comments

• Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still reproduces ×2 (merged key left-pad@^1.1.0, left-pad@^1.3.0: after a member adds ^1.3.0; rollback exits 1 vendor_lock_entry_drifted): Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 (comment)
• Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 still reproduces ×2 (frozen install from a member dir can't find ./.socket/vendor/…): Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 (comment)
• Yarn classic hosted and vendored rewrites convert LF lines of a mixed CRLF/LF yarn.lock to CRLF, so rollback is not byte-exact #467 was closed not_planned by a maintainer while its vendored mixed-ending half still reproduced. Recorded under Known non-bugs, so it won't be re-filed.

Cells (all pass unless noted)

• Make the vendored-to-hosted takeover atomic #1039 takeover, 1.22.22: a wet V→H takeover (fresh frozen install patched, .socket/ removed); a dry-run takeover (whole tree byte-identical, redirect_would_revert_vendored); a project .yarnrc mirror → retract (redirect_yarn_classic_offline_mirror + redirect_takeover_kept_vendored, tree byte-identical); an alias-only vendored copy → retract (byte-identical). The same mirror retract and then a clean takeover on 1.7.0 and 1.10.1.
• Alias + direct copy takeover: fail Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158.
• Route inline BOM strips through formats::text (#905) #1117 BOM: BOM package.json + BOM yarn.lock, H and V, with fresh frozen install + VEX + rollback (the BOM is kept; V rollback byte-exact, H differs only in the passthrough host). BOM+CRLF lock + BOM package.json: the V→H→V takeover chain keeps 8/8 CRLF lines and the BOM, every hop installs patched, and rollback is exact modulo host.

False positives ruled out

• Hosted rollback failing error sending request for registry.npmjs.org is the sandbox's rustls/proxy-CA artifact (already known). It passes through the passthrough.

Next

1. Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 follow-ups: the scoped alias (@my/lp) and alias-in-workspace-member takeover shapes. Ask yarn-berry whether redirect_yarn_berry_alias_skipped has the same partial-pin takeover gap (handover if it reproduces).
2. Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 follow-ups: yarn workspace <m> add, V→H takeover in that shape (now staged; a member mirror may not trigger the retract).
3. Re-check 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 (PR Fix open npm issues #1008) once merged; then Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558.
4. Hosted yarn classic offline-mirror refusal (#364 fix) only reads the project's own .yarnrc/.npmrc, so a mirror set in ~/.yarnrc, yarn's user config or a parent dir still breaks every install #1013 / Fix yarn classic offline-mirror config resolution (#1013, #1078) #1083 on older images (macOS 13 / Windows 2019) once probe-branch cleanup works again.
5. Leftover probe branches (deletion blocked): see state's Known non-bugs.

[github-actions[bot]]

[agent] 2026-10-09: Yarn classic (1.x) bug-hunt run

Tested: main 03b9418 (main was force-updated since run 33's cf8b164). It adds #1058 (a hosted pin is decided through lockfile discovery alone), #1147 (vendored revert reads a removed dependency as removed, not drift), #1108 / #1160 (line terminators and BOM through shared helpers) and #1031 (scan --apply/--vendor and get --no-apply removed). The latest tag is still v4.0.0. Also tested: PR #1180 head 46f1bc0. Linux sandbox, Node 22, yarn 1.0.2 / 1.7.0 / 1.10.1 / 1.22.22, and the run-32 mock (left-pad@1.3.0) extracted from the 20261008-grammar-xos probe workflow. No probe branches: nothing this run was platform-specific, and ref deletion is still blocked.

Filed

• None. The one new failure (below) is already handled by open PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180.

Re-triage and comments

• Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 still reproduces on main. PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 46f1bc0 fixes it for the unscoped alias, the scoped alias (@my/lp) and an alias declared in a workspace member: all three get redirect_takeover_kept_vendored, and a fresh frozen install has both copies patched. Commented: Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 (comment)
• New on main (Decide whether a hosted patch is pinned through lockfile discovery alone #1058 interaction, covered by PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180): a plain hosted scan of a project with left-pad@1.3.0 + lp: npm:left-pad@1.3.0 now pins nothing (exit 0, redirect_unattributable), so the direct copy also stays unpatched. On 1.10.1, where yarn merges the blocks, it pins and both copies are patched. The PR's 46f1bc0 exempts alias skips from the gate. With the PR, the direct block is pinned and the in-run --vex omits the package (Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 fixed). Not filed separately. It's noted in the Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 comment.
• Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still reproduces ×2. Since Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147 the warning is vendor_lock_entry_removed ("block no longer exists"), which is now wrong: the merged block is alive and still wired. Commented: Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 (comment)
• Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115: the staged V→H takeover isn't retracted for a member-.yarnrc mirror, so member frozen installs then fail the integrity check against the hosted URL (×2). Commented: Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 (comment)

Cells (Linux, main 03b9418; all pass unless noted)

• Hosted battery + fresh frozen install + VEX: base (1.0.2 / 1.7.0 / 1.22.22), workspace merged key ^1.1.0, 1.3.0 (1.10.1 / 1.22.22), multi-version workspace (only the 1.3.0 copy patched), CRLF lock, resolutions, --modules-folder via .yarnrc, and the 1.10.1 merged alias block.
• Hosted alias + direct (1.22.22): pins nothing, redirect_unattributable (fixed by PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180).
• Vendored battery + vendor --check + rollback + fresh frozen install: base, workspace merged key, CRLF, 1.7.0, 1.10.1 workspaces (rollback byte-exact). After yarn add / yarn upgrade of another dep, rollback restores only the left-pad block. After yarn remove left-pad / yarn upgrade left-pad@1.2.0, rollback exits 0 with vendor_lock_entry_removed and .socket/ is cleaned (Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147 OK).
• Hosted mirror refusal with a BOM .yarnrc, a CRLF .yarnrc and a BOM+CRLF .npmrc: redirect_yarn_classic_offline_mirror (no Hosted yarn classic offline-mirror refusal misses a project .yarnrc or .npmrc saved with a UTF-8 BOM, so the scan pins anyway and every install fails #1078 regression from Move BOM handling in 11 more files onto formats::text (#905) #1160).
• Agent: workspaces with a nested 1.3.0 copy, an alias copy and a 1.2.0 copy: the right two copies patched, re-run success, vex 0, rollback restores all.
• Vendored + root mirror: cold-cache root frozen install patched. Member-dir cold-cache installs fail (Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691, with or without a mirror; with a mirror yarn falls back to the mirror's same-named upstream tarball, so the error becomes Integrity check failed).
• V→H takeover + member-.yarnrc mirror: not retracted (Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115, commented).

False positives ruled out

• scan --vex --vex-output isn't a flag (--vex <PATH> takes the path). That was a harness error, not a bug.
• The member-dir integrity failure under vendored + mirror is Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691's relative file: path plus yarn's mirror basename fallback, not a new mirror bug.

Next

1. Once PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 merges: re-run the alias battery (plain hosted, V→H takeover, scoped, member, 1.10.1 merged) on main, and close-check Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081.
2. Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 after Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147: watch for a fix that matches the merged key line.
3. Ask yarn-berry whether the Decide whether a hosted patch is pinned through lockfile discovery alone #1058 gate also refuses a berry alias + direct project (redirect_yarn_berry_alias_skipped). Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180's 46f1bc0 exempts both.
4. Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 follow-ups (extglob / dot-dir members on other PMs).
5. Cross-OS re-run of the run-34 hosted/vendored battery once probe-branch deletion works.

[github-actions[bot]]

[agent] 2026-10-09: Yarn classic (1.x) bug-hunt run

Tested: main f3c6313 (since run 34: #1008 "Fix open npm issues", which moves the yarn classic vendoring backend onto the shared vendor_npm_family driver and adds #828 shadowed pins; plus #1152, #1191, #1190, #1183, #1205). Latest tag still v4.0.0. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, the run-32 mock from probe branch 20261008-grammar-xos, and a plain-HTTP registry passthrough for hosted rollback. No probe branches: nothing this run was platform-specific.

Filed

• Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236: Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name ("lp2": "file:./lpdir"), so scan --vex and lock-only vex attest not_affected while node_modules/lp2 installs unpatched. Reproduces on 1.7.0 / 1.10.1 / 1.22.22, H and V (×2 on 1.22.22). The same-name file: copy (Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921) is handled correctly. A renamed git copy has the same gap (comment). This is the yarn classic counterpart of Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (berry). Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236

Re-triage and comments

• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 still reproduces on f3c6313. H and V scans attest without a warning, the bundled copy installs unpatched, and V post-install vex attests as well. Fix open npm issues #1008 covered the npm / Bun / vlt bundled twins only. Commented: Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758 (comment)
• Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 git-copy variant: Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 (comment)
• Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081: PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 still open (46f1bc0, mergeable), nothing new.

Cells (Linux, f3c6313; all pass unless noted)

• EOL battery (native / LF / CRLF / mixed / BOM+CRLF × H / V + file: fork shapes), 1.7.0 / 1.22.22: unchanged from run 34.
• 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 yarn shape (registry pin + file: dir copy): H scan → rollback → re-scan → V takeover (upstream restored first) → vendor --revert lands on upstream.
• Renamed file: dir / git copy: fail Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236.
• Yarn classic VEX attests not_affected while a bundled copy of the patched package@version stays unpatched (yarn.lock has no inBundle, so the #325 fix can't see it) #758: fail (still).
• Case-only npm: aliases (LEFT-PAD, @Cs/lp, the Resolve VEX npm alias copies through the core resolver and delete vex_consumed's second alias walk #856 rule): agent apply / VEX / re-run / rollback. Vendored: all 3 copies patched after a frozen install, vendor --check, byte-exact rollback.
• Vendored merged workspace key on 1.10.1 / 1.22.22: scan, in-sync re-run, frozen install, check, yarn add, check, rollback.

False positives ruled out

• A vendored bund local-tarball project failed the frozen install with Integrity check failed for "bund". Cause: two scratch projects shared yarn's global cache, which keys file: tarballs by name@version, so the lock got the other project's sha1. It passes with a per-project --cache-folder. Harness artifact.
• Hosted rollback error sending request without SOCKET_NPM_REGISTRY pointing at the plain-HTTP passthrough: sandbox TLS interception (known).

Next

1. Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 follow-ups: renamed file: tarball copies, and renamed copies in workspace members / transitive deps.
2. Once PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 merges: alias battery on main and close-check Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081.
3. Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 watch for fixes.
4. Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 follow-ups (extglob / dot-dir members).
5. Cross-OS re-run of the batteries once probe-branch deletion works.

[github-actions[bot]]

[agent] 2026-10-09: Yarn classic (1.x) bug-hunt run

Tested: main a80b89e (since run 35: #1227 makes vendored writers pick the majority line ending, plus #1007 / #1041 / #1036 and others that don't touch yarn). Latest tag is still v4.0.0, and the published v4.0.0 binary was used to bisect. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, the run-32 mock (plus a no-sha1 variant). No probe branches: nothing this run was platform-specific.

Filed

• Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271: Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": "", or a merged left-pad@, left-pad@^1.3.0: block when another member or dependency asks for ^1.3.0). A lock-only scan reports 0 patches (exit 0). An installed hosted scan pins nothing (exit 0, redirect_yarn_classic_entry_not_found). An installed vendored scan exits 1 with vendor_lock_entry_not_found. There's no false VEX, and agent mode works. Reproduces on 1.7.0 / 1.10.1 / 1.22.22, and on v4.0.0, so it's not a regression. Root cause: split_pattern rejects an empty range (formats/yarn/patterns.rs:63). Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271

Re-triage

• Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 still reproduces ×2 on a80b89e (vendor_lock_entry_removed on a merged, still-wired block). Run 34 already commented, so no new comment.
• Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 still reproduces: 1.10.1 installs the unpatched bytes from a warm cache, and 1.22.22 fails with Incorrect integrity. No new comment.
• PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 (Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081) is still open. Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236's follow-ups are on that issue / PR Fix yarn classic copies locked under another name (#1236) #1242.

Cells (Linux, a80b89e)

• Empty-range key, single and merged, H / V × lock-only / installed: fail Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271. Agent: pass.
• Unusual range keys (*, latest, >=1.0.0 <2, ||, v1.3.0, =1.3.0, leading space, hyphen range, self-npm: alias): H and V pass, with patched frozen installs and lock-only VEX attesting.
• EOL battery (native / LF / CRLF / mixed / BOM+CRLF × H / V + fork shapes) on 1.7.0 / 1.22.22: no regression from Pick inserted-line terminators through line_endings::terminator in vendored writers (#815) #1227.

False positives ruled out

• Hosted rollback failures in the EOL battery: sandbox TLS without the registry passthrough (known).
• 1.7.0 "untouched-bytes" failures: the added integrity line on no-integrity locks (known, by design).
• The Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 repro's member yarn add failing on a cold path is Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691. It passes after a root frozen install warms the cache.

Next

1. Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271 follow-ups: scoped @s/p@:, a transitive manifest with "", resolutions. Ask siblings how they lock "".
2. Once PR Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180 merges: alias battery and close-check Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081.
3. Once PR Fix yarn classic copies locked under another name (#1236) #1242 merges: re-run the Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 battery, including the member-relative file: path.
4. Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Vendored yarn classic rollback can't undo a block yarn has merged with another range (left-pad@^1.1.0, left-pad@^1.3.0:): it reports the block as gone, exits 1 forever and leaves the lock wired #692 / Hosted yarn classic offline-mirror refusal misses a mirror set in a workspace member's .yarnrc, so installs run from that member fail the integrity check while the scan reports success and VEX attests #1115 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558: watch for fixes.
5. --flat, --ignore-optional, --production and .yarnclean (autoclean) installs × H/V/A (still untested).

[github-actions[bot]]

[agent] Janitor: drift. #778 (closed as completed 2026-10-09 07:19Z by #1007, 60300b8b) and #828 (closed as completed 2026-10-09 03:14Z by #1008, f3c6313a) are still marked as failing. Please re-verify on main a80b89e0 and update the cells.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-09: Yarn classic (1.x) bug-hunt run

Tested: main 9ab72d4. That's after #1180 (alias copies treated as pinned), #1242 (renamed copies), #1034 (one target grammar for get / remove / rollback), #1277 (BOM handling), #989 (shared vendored revert), and the chore(release): 5.0.0 commit. The latest tag is still v4.0.0. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, run-32 mock (plus a scoped-package variant and a no-sha1 variant). I also built the heads of open PRs #1274 and #1328. No probe branches: nothing this run was platform-specific.

Filed

None. No new bug met the filing bar.

Re-triage

• Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236: the reported shape is fixed on main (hosted redirect_yarn_classic_directory_skipped plus vex patched_ref_unattributable; vendored vendor_link_entry_skipped plus vendor_unwired). The member-relative follow-up doesn't reproduce: yarn 1.7.0 / 1.10.1 / 1.22.22 always lock a member's file:./lpdir root-relative (lp2@file:./packages/a/lpdir), hoisted or nested. Commented: Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 (comment)
• Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558: still reproduces on main (1.10.1 warm cache installs unpatched bytes; 1.22.22 fails with Incorrect integrity). PR Fix fragmentless yarn classic hosted pins (#558) #1328 head 494932e fixes both, writing #<sha1>. Commented: Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 (comment)
• Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158 / Hosted yarn classic scan --vex attests not_affected when an npm: alias copy of the patched package was skipped, while standalone vex refuses the same lock #1081 (closed by Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180): verified on main. Hosted alias + direct pins the direct copy, warns redirect_yarn_classic_alias_skipped, and vex refuses. A V→H takeover keeps vendored (redirect_takeover_kept_vendored).
• Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271: still reproduces on main, now reported as redirect_yarn_classic_non_registry_entry_skipped / vendor_lock_entry_not_rewritable. PR Fix yarn classic empty-range lock keys (#1271) #1274 head 0311ef8 fixes left-pad@:, merged left-pad@, left-pad@^1.3.0: and scoped "@isaacs/string-locale-compare@": in H/V (patched frozen install, VEX attests, vendored rollback byte-exact, hosted rollback frozen-installs unpatched). No comment posted (the cap is 2 re-triages per run).

Cells (Linux, 9ab72d4, yarn 1.22.22 unless noted): all pass

• Alias battery H/V: alias-only, scoped alias (@x/lp), ranged alias beside a direct copy, two aliases. Also V→H takeover on each, and rollback.
• Renamed registry-URL copies (lp3 / lp4 URL deps, with and without a direct copy) H/V. Vendored URL-only: vendor_lock_entry_not_rewritable.
• Target grammar (Use one package target grammar for get, remove, rollback and the UUID shortcut #1034): rollback / remove × {name, versionless purl, purl, uuid, LEFT-PAD} × H/V (20/20). get × {name, purl, uuid} × H/V/A.
• BOM / no-BOM .yarnrc and .npmrc offline-mirror refusal (Move BOM handling in 8 more files onto formats::text (#905) #1277 regression check).
• Vendored scan → re-scan → --check → vendor --revert (byte-exact) → --check, on plain / CRLF / workspace locks.
• Install flags × A/H/V: --production (dev dep), --ignore-optional, --flat, .yarnclean; nohoist workspace.
• In-place yarn install after a scan, on 1.7.0 / 1.10.1 / 1.22.22 × H/V.
• yarn add / yarn upgrade / range re-add after pins on 1.10.1 / 1.22.22: yarn drops the pin. vendor --check fails, vex refuses, and a re-scan re-pins.
• Two hand-merged blocks of the same name@version from different registry hosts: both pinned H/V. Vendored rollback is byte-exact.

False positives ruled out

• Hosted vex right after a scan in the already-installed tree refuses not_applied. That's correct: node_modules wasn't reinstalled.
• A lock-only vex in a checkout missing the file: directory attests. That's unrealistic: yarn can't install without the directory.
• repair exits 0 with no events after yarn upgrade drops the vendored wiring. The docs say repair only restores artifacts and keeps the existing wiring, and vendor --check / vex both fail closed.
• .yarnclean deleting index.js: synthetic.

Next

1. After PRs Fix yarn classic empty-range lock keys (#1271) #1274 / Fix fragmentless yarn classic hosted pins (#558) #1328 / Warn on yarn classic member-dir vendored installs (#691) #1324 / Refuse yarn classic pins with unlocked deps (#591) #1363 merge: re-run Yarn classic hosted and vendored modes can't see or patch a yarn.lock block whose key has an empty range (left-pad@: from "left-pad": ""), so a lock-only scan reports no vulnerable package and an installed scan leaves it unpatched #1271 / Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558 / Vendored yarn classic wiring breaks every install run from a workspace member directory: yarn resolves the file:./.socket/vendor/… tarball against the member dir #691 / Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 on main, and close-check them.
2. Yarn classic hosted and vendored scans miss a file: directory copy of the patched package declared under another dependency name, so scan --vex and lock-only vex attest not_affected while that copy installs unpatched #1236 remaining follow-ups: the renamed file: tarball scan warning, and a renamed git copy.
3. Transitive renamed URL / file: copies (a dep's manifest declaring "lp3": "<url>").
4. macOS / Windows probe of the alias battery after Fix yarn npm: alias copies treated as pinned (#1081, #1158) #1180.
5. --focus member installs; yarn workspaces run / yarn workspace <m> add × V.