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-02 (run 9), main 203e092, latest release v4.0.0. Runs 5–9 added the cells in "Run 5 cells" through "Run 9 cells" below. 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)	fail #363	H pass	untested	untested	n/a (yarn ≤1.6 can't install file: tarballs)	n/a	pass
Linux	1.6.0	pass	n/a (yarn limitation)	untested	H pass	untested	untested	n/a (yarn ≤1.6)	n/a	untested
Linux	1.7.0	CI	fail #364 (--offline)	fail #363	pass	untested	untested	pass	untested	untested
Linux	1.9.4	CI	fail #364 (--offline)	untested	untested	untested	untested	CI	untested	untested
Linux	1.10.1	pass	fail #364	fail #363	pass	pass	untested	pass	pass	pass (+ --install.modules-folder, run 9)
Linux	1.17.3	pass (in-place)	fail #364	untested	untested	untested	untested	pass (in-place)	untested	untested
Linux	1.22.22	pass (v5, + hosted rollback pass)	fail #364 (v5)	fail #363 (v5; rollback also wrong; still fails on 203e092)	pass	pass	pass	pass	pass	pass
macOS	1.7.0	untested	untested	fail #363	pass	pass	pass	pass	untested	untested
macOS	1.10.1 / 1.22.22	pass (probe)	fail #364	fail #363	pass	pass	pass	pass	untested	untested
Windows	1.7.0 / 1.10.1 / 1.22.22	pass (probe)	fail #364 (1.10.1/1.22.22)	fail #363 (vendored: Couldn't find the binary git)	pass	pass	pass	pass	untested	untested

Global mode (-g) on v5 2463257

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.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.10.1 / 1.22.22	pass	pass	pass	fixed (#436 closed by #446; not re-run)	pass (CI runner)	pass (1.22.22)
macOS	1.0.2	fail #437	pass	fail #437	fail #436	n/a	untested
macOS	1.10.1 / 1.22.22	pass	pass	pass	fail #436	pass	untested
Windows	1.0.2	fail #437 / #434 (#434 closed by #442; re-run)	pass	fail #434 (closed; re-run)	fail #436	untested	untested
Windows	1.10.1 / 1.22.22	fail #434 (closed by #442; re-run)	pass	fail #434 (closed; re-run)	fail #436	untested	untested

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).

Backlog

1. Maintainer request (global mode): re-run the Windows global cells 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 closed); also the get-mode cells after Fix -g touching the cwd project's state (#436, #445) #446 (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); yarn via corepack and the Windows MSI; 1.6.0 / 1.9.4 on the probe; a read-only prefix on Windows (Program Files). 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) still open.
2. Same-size patched files on yarn ≤1.9 in-place installs: find out which mtime the vendored packer and the Socket hosted tarballs use (the npm 1985 constant would make an upstream→patched same-size change a silent no-op in place).
3. A manifest-rewriting patch that changes an existing dep range (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 follow-up).
4. Re-run the v4-only project columns (git dep 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, offline mirror H 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 once fixed.
5. 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 (dangling dependency).

Known non-bugs

• 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.

• 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: vendored → vendor_lockfile_missing (exit 1); hosted → exit 0, redirected: 0, redirect_npm_no_lockfile (npm-only wording). This is the documented hosted refusal 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.

[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.