Bug hunt ledger: Yarn classic (1.x) #304

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

[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: [email protected], 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.

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

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

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