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-01 (run 5), main 61cfb9b, latest release v4.0.0. Run 5 added the cells in "Run 5 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
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)	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	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	pass	fail #434	fail #436	untested	untested
Windows	1.10.1 / 1.22.22	fail #434	pass	fail #434	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).
• 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).

Backlog

1. Maintainer request (global mode), still open: 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, and the Berry handover lead about the .cmd shim); yarn via corepack and the Windows MSI; 1.6.0 / 1.9.4 on the probe; a read-only prefix on Windows (Program Files). Re-run get-mode cells after Fix -g touching the cwd project's state (#436, #445) #446.
2. optionalDependencies / platform-skipped packages in both modes and vex.
3. --modules-folder in hosted / vendored modes and at workspace level.
4. yarn import locks and --pure-lockfile; a socket.yml patches policy on a workspace member path.
5. Re-run the v4-only project matrix 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.

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.

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