Bug hunt ledger: Yarn Berry (2+)

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Yarn Berry (2+) bug-hunt routine (label pm:yarn-berry).

Last updated: 2026-10-03 (run 12), main 045d7ec (CLI still reports 4.0.0), latest release 4.0.0 (previous 3.3.0). Since #465 the hosted berry pin is root package.json resolutions (name@npm:<range> → URL) plus a lock entry re-keyed name@<url>.

Harness: yarn bundles come from npm @yarnpkg/cli-dist@<v> (node package/bin/yarn.js), because corepack's fetch can't use the sandbox proxy. Yarn 4 needs YARN_HTTPS_CA_FILE_PATH; yarn 2/3 need YARN_CA_FILE_PATH. The npm registry has 2.4.2 as the last 2.x in cli-dist. Agent and vendored cells hand-stage .socket/manifest.json plus blobs (a marker prepended to index.js). Hosted cells use a local Python mock (fresh-checkout copies must keep .socket/ for vendored cells) of the patch API (batch, by-package, patches/package with a yarn-berry-zip yarnBerry10c0 artifact, view, and the tarball route). The 10c0 checksum is bootstrapped with a real yarn resolutions: file: install. Every hosted and vendored cell ends in a fresh-checkout yarn install --immutable. v5: hosted rollback/remove need the mock's /upstream/npm/<uuid>.json route, SOCKET_NPM_REGISTRY pointed at a local registry passthrough (the rustls binary can't use the sandbox proxy CA), and --patch-server-url <mock> so the pins count as hosted. Global (-g) cells use real npm global installs (NPM_CONFIG_PREFIX) and a Python mock of the authenticated API (--api-url <mock> --api-token x --org org; blob route /v0/orgs/org/patches/blob/<sha256>). v5 vendored mode downloads from the vendoring service: the same mock's /patches/package with a granted tarball artifact (real sha512) is enough, and an optional per-patch status override (for example pending_build) is supported. A corepack shim (corepack yarn@X → node <cli-dist X>/bin/yarn.js, setting the CA env itself because the harness scrubs YARN_*) runs the repo's berry e2e suites in the sandbox (SOCKET_PATCH_YARN_E2E_REQUIRED=1, SOCKET_PATCH_YARN_BERRY_VERSION=<v>). setup was removed in v5. On GH runners, fixture installs need YARN_ENABLE_IMMUTABLE_INSTALLS=false (CI turns immutable on). Run 8: the vendoring-service mock must also return a yarn-berry-zip artifact with integrity.yarnBerry10c0, or vendor fails apply_failed. Hosted fresh installs from an http mock need YARN_UNSAFE_HTTP_WHITELIST=127.0.0.1. Run 9: the corepack shim must set YARN_HTTPS_CA_FILE_PATH only for 4.x (yarn 4 rejects an env caFilePath), and the batch mock must filter by components[].purl. Run 10: one Python mock driven by a JSON config (per-patch hidden and publishedAt for A→B upgrades) also serves /upstream/npm/<uuid>.json and a /registry/ npmjs passthrough for SOCKET_NPM_REGISTRY. Never run pkill -f mock.py from the shell that runs it. Run 12: the harness was rebuilt as mkpatch.py (patched tgz, bootstrap checksum, original registry checksum; never patch package.json) plus one mock that also logs Authorization. Standalone vex against the mock needs --patch-server-url <mock> and the API flags. Run 11: the view route can carry blobContent/beforeBlobContent, so agent-mode scan works against the mock without hand-staging; stop the mock through a pidfile.

Coverage matrix

Cells are "pass", "fail #N", "refused (by design)" or "untested". Linker is node-modules unless noted.

OS	yarn	Agent apply / rollback	Vendored	Hosted	setup hook
Linux	2.4.2 (cacheKey 7)	pass on 61cfb9b (node-modules: apply, vex, rollback byte-exact and idempotent)	untested	refused (by design) redirect_yarn_berry_cache_unsupported	untested
Linux	3.8.7 (cacheKey 8)	pass on 61cfb9b: node-modules and pnpm linker (transitive dep in .store, real dirs), apply/vex/rollback byte-exact	refused (by design) vendor_yarn_berry_cache_unsupported	refused (by design); run 9 on 203e092: refusal writes nothing to package.json	untested
Linux	4.0.2 (bare-hex checksums)	run 9 on 203e092: pnpm linker .store transitive dep pass (#495 fixed); repo e2e suites pass (90/90); remove blob GC fail #559	node-modules pass on 61cfb9b (bare-hex checksum written). PnP lock-only: fail #539 (re-run)	run 9 on 203e092: new resolutions pin passes hardened mode on node-modules/pnp/pnpm linkers. Earlier: pass (left-pad, v5 rollback byte-exact); #368 and #404 fixed	removed in v5
Linux	4.12.0	run 9 on 203e092: nmMode: hardlinks-global pass after #486. Run 8 on 61cfb9b: nmMode: hardlinks-global pass (only this project's link broken; rollback byte-exact), nmHoistingLimits: workspaces pass (every copy). fail #559 (remove sweeps the other patches' before blobs; also releases 4.0.0, 3.3.0). pass on f6b7fb9 (node-modules and pnpm linkers, rollback byte-exact). On 61cfb9b: pass for direct deps (pnpm linker, root and scoped) and hoisted transitive deps; fail #495 (pnpm-linker transitive dep only in .store/<slug>/package); repo e2e suites pass	run 8 on 61cfb9b: pass for PnP workspaces (lock-only), vendored upgrade A→B in lock-only PnP (fresh immutable loads B; --revert byte-exact), merged 3-descriptor entry (--revert byte-exact), catalog: (default and named), root locator encoding (nameless root, ()!~'*, space, unicode, +&=#), concurrent vendor (lock), repair of a deleted tgz. Two versions → vendor_override_conflict (correct). remove blob GC: fail #559. pass on 61cfb9b: pnpm linker (in-place + fresh --check-cache, --revert byte-exact); PnP lock-only checkout vendors and loads patched bytes, but re-run after install fails #539 (also 4.0.2, 4.18.1); zero-install committed cache → YN0056 (docs gap). package.json tab / 4-space / BOM / CRLF+tab / no trailing newline / existing or empty resolutions (fresh immutable + --revert byte-exact); mixed-EOL yarn.lock refused loudly (vendor_yarn_berry_mixed_line_endings). pass on f6b7fb9: root, scoped root name, scoped target, **/ glob resolution, workspaces, pnpm linker, re-run idempotent, --revert, in-place immutable install. pass on v5: root, workspaces + enableImmutableInstalls: true (--revert and remove byte-exact), CRLF lock + package.json. Refused (by design): resolve/typescript (patch: builtin), yarn 3. fail #370 (commented compressionLevel). fail #369 (hosted→vendored via scan/get --mode vendored; vendor itself is fixed on v5). fail #468 (vendored→hosted with no yarnBerry10c0)	run 11 on 045d7ec: pass for packageExtensions-added dep, root peer + dev, =1.3.0/v1.3.0, portal: transitive, dependenciesMeta, workspace named like the target (each with fresh immutable and byte-exact rollback; vendored for packageExtensions/portal: too); tarball-URL descriptor refused (correct); compressionLevel: mixed refused in both modes. run 10 on 045d7ec: catalog: (default, named, workspace) fail #632 (regression from #465; release 4.0.0 passes); vendored→hosted takeover of a catalog dep also hits #632. Pass: A→B upgrade (re-pin, fresh immutable B, rollback byte-exact), pin survives yarn add/dedupe/up, descriptor change → re-scan re-pins (vex attests nothing meanwhile), --cwd nested separate project (outer untouched). run 9 on 203e092 (resolutions pin, #465): pass for basic, workspaces merged entry, transitive, 7 range spellings (latest, >=1.3.0 <2, ||, 1.x, *, npm: forms), scoped, two versions, hardened mode × 3 linkers, package.json tab/4-space/CRLF/BOM/no-EOL/other resolutions (rollback byte-exact), CRLF lock + enableImmutableInstalls, scoped rollback/remove with two pins, hosted↔vendored takeovers, mixed vendored+hosted unwind, legacy __archiveUrl pin migration from release 4.0.0, compressionLevel: "0" and 0 # c (#370 fixed), lock-only vex (orphan refused). #368 fixed (refuses resolve, nothing written). Interrupted (SIGKILL) vendor: recoverable. Earlier: pass: left-pad, pnpm linker + vex, rollback byte-exact; run 8: catalog: dep (fresh immutable patched); 61cfb9b: rollback and remove byte-exact for npm:^1.3.0, dev-only and optional-only descriptors; v5 main: npm:1.3.0 / npm:^1.3.0 descriptors, dev-only and optional-only deps, mixed-case name JSONStream (case-kept purl, also on 4.18.1), mixed-EOL lock refused loudly, scoped, CRLF, workspaces merged-range, re-scan idempotent, manifest-less rollback/remove/list byte-exact, PnP lock-only checkout, upgrade path (uuid A→B re-pin, then rollback byte-exact), hardened mode accepts __archiveUrl pins, vendored→hosted takeover (checksum present; pending_build stays vendored). #368, #404, #369 and #370 are fixed on 203e092. Refused (by design): PnP (yarn_pnp_unsupported), direct + alias merged entry (redirect_yarn_berry_ambiguous_entry). PnP stale .pnp.cjs + hosted pin → standalone vex attests unpatched copy: fail #519 (yarn-classic issue; berry evidence commented, also 4.0.2 and 4.18.1)	pass on f6b7fb9; removed in v5
Linux	4.18.1 (latest)	run 12: agent on a user patch:-descriptor package pass. Run 11: workspaces with nmMode: hardlinks-local + nmHoistingLimits: workspaces pass (both copies patched, rollback restores both). Run 9 on 203e092: pnpm linker .store pass (#495 fixed); repo e2e suites pass (90/90); fail #559	run 10: vendored catalog: pass (bare-name pin). Run 8: named catalog:legacy pass. pass on f6b7fb9 (CRLF-respelled lock + package.json); v5: fail #468; PnP lock-only: fail #539 (re-run)	run 11: packageExtensions, peer + dev, =1.3.0 pass. Run 10 on 045d7ec: catalog: fail #632; A→B upgrade, yarn add/dedupe/up, nested --cwd pass. Run 9: resolutions pin passes hardened mode × 3 linkers. Earlier: pass (left-pad, scoped, lock version: 10); #368, #370, #404 and #468 fixed on 203e092	removed in v5
Linux	all 4.x (4.0.2, 4.6.0, 4.12.0, 4.18.1)	n/a	run 12: platform-conditional entries (conditions:) fail #697 (checksum after conditions:; every conditional entry; also release 4.0.0). yarn remove then rollback: fail (#665, Berry evidence commented). Symlinked yarn.lock/package.json replaced: fail (#627, commented). Pass: yarn add/up/dedupe after vendoring, then --revert keeps the user's add	run 12: conditional entry with deps and no checksum (@img/sharp-*) fail #697; esbuild (no deps) and supportedArchitectures pass. Pass: two versions both patched (scoped rollback, byte-exact), debug (deps + peerDependenciesMeta), npmAlwaysAuth + token (no auth to patch host, hardened), user patch: descriptor refused, symlinked lock/package.json refused	removed in v5
macOS	4.12.0, 4.18.1	untested	untested	pass (left-pad) on 4.0.0-era main; #368 and #369 fixed since, new resolutions pin untested	untested
Windows	4.12.0, 4.18.1 (yarn writes CRLF)	untested	untested	pass (left-pad, CRLF lock) on 4.0.0-era main; #368 and #369 fixed since, new resolutions pin untested	untested

Global (-g) cells. Berry has no global dir, so these are npm-prefix globals scanned from inside or outside a Berry project:

OS	yarn	scan -g report (inside/outside a Berry project)	-g hosted refusal	-g apply / rollback / vex
Linux	2.4.2, 3.8.7, 4.0.2, 4.12.0, 4.18.1	#440 fixed by #442 (project global script ran); otherwise pass, no project leak (node-modules, pnpm, PnP)	pass (exit 2, nothing written)	pass on 4.12.0 (byte-exact rollback, vex not_applied after reinstall, EACCES loud, --global-prefix with space and unicode)
macOS	2.4.2, 3.8.7, 4.12.0, 4.18.1	fail #440 (probe run 36828589815), fixed by #442 on main; not re-probed	untested	untested
Windows	2.4.2, 3.8.7, 4.12.0, 4.18.1	pass for #440 (.cmd shim not run)	untested	untested

Backlog

1. Blocked on a maintainer: probe-branch deletes fail (runs 10–12: send-pack: unexpected disconnect, and once the permission policy), so no new probes. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script need deleting by hand. After that, probe the resolutions pin on macOS and Windows (CRLF), plus Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559, Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 and Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697.
2. Re-verify when the fixes land: Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697 (conditional entries: @img/sharp-*, @esbuild/* direct and transitive, and one with bin:), After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 Berry (Fix vendored revert keeping artifact for removed lock entry (#665) #689), remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 (Share rollback artifact retention across remove and rollback #600), Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539. Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370, Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404, scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468 and Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 are closed.
3. Berry analogue of Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 (a symlinked .socket/vendor/npm shared by two projects) once Fix vendored revert deleting through a symlinked vendor dir (#664) #666 lands.
4. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta). Full checklist in the 20261001T040000Z entry.
5. Unconfirmed lead: the API returns a lower-cased npm purl (pkg:npm/jsonstream@1.3.5) for a mixed-case package, and every mode misses it. File it (cross-PM) only if the real API is shown to lower-case.
6. A hosted/vendored pin of a package with bin: plus conditions:, and peerDependencies on the patched package itself.

Known non-bugs

• Yarn 2/3 (cacheKey 7/8) are refused by hosted and vendored mode (documented).
• PnP projects with a .pnp.cjs are refused in every mode with yarn_pnp_unsupported (documented).
• Vendoring a package yarn builtin-patches (resolve, typescript, fsevents) is refused fail-closed with vendor_override_conflict. It's loud and closed, so it isn't filed (the hosted counterpart is Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368).
• Hosted refuses an entry that merges a direct descriptor with an npm: alias ("left-pad@npm:1.3.0, lp@npm:left-pad@1.3.0") with redirect_yarn_berry_ambiguous_entry and exit 1. It's fail-closed and loud; arguably over-broad, but not filed.
• Agent mode: a later yarn install --immutable in the same tree doesn't restore unpatched bytes (yarn's install-state), and the setup hook re-patches after a clean install. Standalone vex in agent mode needs setup or setup.manual (documented).
• patches-api.socket.dev is unreachable from the sandbox; use the mock.
• A BOM'd yarn.lock fails yarn install --immutable (YN0028) on its own, because yarn strips the BOM. Not caused by socket-patch.
• Hosted on a berry npm: alias-only entry → redirect_yarn_berry_alias_skipped (documented in docs/ecosystems.md).
• scan <workspace-member-dir> finds 0 packages: hosted/vendored PATHs are project dirs, and members share the root's lock (CLI_CONTRACT "exclude it with ignorePackages, not paths").
• PnP with .pnp.cjs: scan reports 0 packages with a PnP warning (same in 4.0.0). A PnP lock-only checkout gets hosted pins, and those install correctly under PnP.
• v5 rollback/remove/list treat only patch.socket.dev (or --patch-server-url) URLs as hosted pins. Without that flag, a mock host reads as "Manifest not found".
• PnP on yarn 2.x (.pnp.js) and 3.x is detected and gets the loud PnP warning in every mode, exit 0 (same as 4.x).
• An agent-mode re-run (scan -g --mode agent) after a failed apply (EACCES) exits 0 with "already recorded … run socket-patch apply". This is the designed re-run message; apply -g itself exits 1.
• The report-only hint after scan -g doesn't mention -g. It's cross-PM and was handed to npm (Bug hunt ledger: npm #302), so it isn't filed here.
• Yarn 4 hardened mode (enableHardenedMode, auto-on for public fork PRs in GitHub Actions) accepts a hosted ::__archiveUrl= lock pin, as does --check-resolutions (4.12.0, registry reachable).
• Zero-install (enableGlobalCache: false with .yarn/cache committed): hosted mode is lock-only, so the committed cache keeps the unpatched zip, and yarn install --immutable --immutable-cache fails YN0056 until yarn install refreshes the cache. Vendored mode behaves the same way (the file: entry has no cache zip; no warning). It's a docs gap, not filed.
• compressionLevel set outside the project .yarnrc.yml (env, home or parent rc) can't cause a wrong checksum: yarn bakes the level into the lock's cacheKey, which both modes gate on.
• Vendored refuses a user yarn patch (patch: descriptor) with vendor_override_conflict, plus an alias-only dependency (root or workspace member) with vendor_lock_entry_not_found, a merged direct + alias entry, and a user-authored resolutions key for the target. All are loud and closed with nothing written, so none are filed.
• Mixed CRLF/LF yarn.lock is refused by vendored (vendor_yarn_berry_mixed_line_endings) and hosted (redirect_yarn_berry_mixed_line_endings). That's correct: yarn itself fails YN0028 on such a lock.
• v5 rollback drops the patch's manifest entry, so a later apply is a no-op (designed).
• A berry install rewrites a BOM'd, compact, or no-trailing-newline package.json. Vendored snapshots the post-install bytes and reverts to them byte-exactly.
• Vendored refuses a lock that resolves the target name at a second version (left-pad@1.2.0 alongside the patched 1.3.0) with vendor_override_conflict, because the name-keyed resolutions would move both. That's correct and loud.
• repair refuses (vendor_artifact_redownload_failed, nothing written) when the service now serves different bytes for a uuid whose integrity is pinned in the ledger. That's correct.
• vendor --cwd <workspace member> fails loudly with vendor_lockfile_missing (the lock lives at the root).
• Yarn 4 locks carry no virtual: entries for peer-dependent packages, so the hosted/vendored rewrite has no virtual locator to keep in sync.
• Hosted rollback reformats a compact one-line package.json to 2-space and drops a user-authored empty "resolutions": {}. Yarn's own next install writes exactly the same bytes, so it isn't filed.
• Hosted per-package refusals (redirect_yarn_berry_shared_descriptor, redirect_yarn_berry_ambiguous_entry, cache_unsupported) exit 0 with redirected: 0 and nothing written. With --vex and nothing to attest, the run exits 1.
• Hosted refuses a user-authored resolutions entry targeting the patched package (bare or scoped selector) with redirect_yarn_berry_resolutions_conflict. It's documented and loud.
• An interrupted (SIGKILL) vendor can leave a ledger + tgz without the package.json/yarn.lock wiring. A re-run completes, vendor --revert removes the orphan, and vex refuses. rollback and repair fail with manifest_not_found in that state.
• After a hosted pin, a user descriptor change (yarn add left-pad@1.3.0) leaves a stale resolutions selector. rollback in that state refuses loudly and tells you to re-run scan --mode hosted, which re-pins correctly. It's fail-closed and gives a remedy, so it isn't filed.
• Hosted yarn berry rewrites a mixed-line-ending package.json that vendored mode refuses #628 (hosted rewrites a mixed-EOL root package.json) was filed by the arch audit; don't re-file it.
• Hosted on a direct tarball-URL descriptor (left-pad@https://…tgz) is refused with redirect_yarn_berry_unsupported_protocol, exit 0, nothing written. That's correct.
• compressionLevel: mixed (cacheKey 10) is refused by hosted (redirect_yarn_berry_cache_unsupported, exit 0) and vendored (vendor_yarn_berry_cache_unsupported, exit 1). Both are documented.
• Hosted on a user patch: descriptor in dependencies is refused (redirect_yarn_berry_unsupported_protocol + redirect_yarn_berry_shared_descriptor), nothing written. That's correct. The hint suggests --mode vendored, which also refuses it; --mode agent works.
• Yarn 4 writes no checksum: for a platform-conditional entry reached only through optionalDependencies, and strips one on its next mutable install. A hosted pin's checksum on such an entry therefore doesn't survive yarn add; vex still attests from the installed tree. That's yarn's policy. The misplaced-line part is Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697.

[github-actions[bot]]

[agent] 2026-09-30: Yarn Berry (2+) bug-hunt run

Tested: main f6b7fb9 (CLI 4.0.0 workspace version), latest release 4.0.0 (previous 3.3.0, both from npm for comparison). Yarn 2.4.2, 3.8.7, 4.0.2, 4.12.0 and 4.18.1 (the current latest) from @yarnpkg/cli-dist, on Node 22. Patch data is a hand-staged .socket/manifest.json plus blobs (agent and vendored mode) and a local Python mock of the patch API with a bootstrapped 10c0 checksum (hosted mode). No secrets.

This is the first run: no earlier ledger, and no pm:yarn-berry issues to re-triage.

Cells

• fail Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368: hosted scan --mode hosted of resolve@1.22.8 / typescript@5.4.5 (packages yarn builtin-patches, optional!builtin<compat/…>). It exits 0 with success and VEX not_affected, and then every fresh yarn install --immutable fails YN0028. Linux on 4.0.2, 4.12.0 and 4.18.1; macOS and Windows probe on 4.12.0 and 4.18.1. Release 4.0.0 has the same bug.
• fail Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369: the hosted→vendored takeover (vendor) reverts the hosted redirect, then per-package vendoring refuses (vendor_override_conflict: a second left-pad version in a workspace). The package ends up unpatched in both modes. Linux, macOS and Windows; release 4.0.0 has the same bug.
• fail Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370: compressionLevel: 0 # comment in .yarnrc.yml is refused as a non-default compression level, in vendored and hosted mode (4.12.0, 4.18.1; release 4.0.0 too).
• pass, vendored (4.12.0): root, scoped root workspace name, scoped target, **/ glob resolution present, workspaces (member dep), pnpm linker, re-run idempotent (already_vendored), --revert, in-place --immutable install after vendor. 4.18.1: CRLF-respelled lock + package.json.
• pass, hosted: left-pad on 4.0.2 / 4.12.0 / 4.18.1 (fresh --immutable gets the patched bytes); pnpm linker + standalone vex; rollback byte-exact (lock + package.json), including after a resolve redirect; Windows CRLF locks (probe).
• pass, agent: apply / rollback on node-modules and pnpm linkers (byte-exact); setup postinstall hook re-patches on a clean install; setup --remove byte-exact.
• refused, as designed: yarn 2.4.2 / 3.8.7 (cacheKey 7/8) in hosted and vendored; PnP with .pnp.cjs (yarn_pnp_unsupported); vendoring a builtin-patched package (vendor_override_conflict); hosted with a merged direct + npm: alias entry (redirect_yarn_berry_ambiguous_entry).

Issues

• Filed Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 and Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370.

False positives ruled out

• The first probe run (36763523523) failed because of my harness, not the product. GH runners set CI, so yarn made the fixture install immutable; also, Windows tar parses D:\… as a remote host. Fixed in the rerun.
• Agent-mode rollback "failing" was a fixture without the before-blob. With the blob staged, it's byte-exact.
• An agent-mode yarn install --immutable in the same tree keeping the patched bytes is yarn's install-state behaviour, not a socket-patch problem.

Probe

• bughunt/yarn-berry/20260930-builtin-patch-takeover, run https://github.com/SocketDev/socket-patch/actions/runs/36764922521 (ubuntu, macos and windows × yarn 4.12.0 and 4.18.1). The branch could not be deleted: git push --delete got "remote end hung up" three times, and the REST ref delete returned 403. A maintainer needs to delete it.

Next

1. Yarn 2/3 agent and vendored cells; get --mode hosted|vendored front doors.
2. Zero-install .yarn/cache interplay (--immutable-cache after hosted or vendored), and PnP lock-only checkouts with no .pnp.cjs.
3. The vendored→hosted takeover mirror of Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, and whether yarn classic / npm share the per-target takeover gap.
4. compressionLevel from env / home / parent .yarnrc.yml, and quoted keys.
5. macOS/Windows cells for vendored and agent mode.

[github-actions[bot]]

[agent] 2026-10-01: Yarn Berry (2+) bug-hunt run

Tested: main 2463257 (the v5 consolidation, #277; the CLI still reports 4.0.0), against release 4.0.0 from npm. Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22, Linux only. Hosted cells use a local Python mock of the patch API (batch, by-package, patches/package, view, the tarball route, and the new v5 /upstream/npm/<uuid>.json route). Rollback needs that route plus SOCKET_NPM_REGISTRY pointed at a local registry passthrough, because the rustls binary can't reach the registry through the sandbox proxy. Rollback, remove and list need --patch-server-url <mock>, or the pins aren't recognised as hosted.

Re-triage

• Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368: still reproduces on v5 main (resolve, YN0028). New: user yarn patch entries (patch:…#./.yarn/patches/x.patch) break the same way for any package. Commented: Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368 (comment)
• Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370: still reproduces (compressionLevel: 0 # default is refused). Commented: Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 (comment)
• Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369: not re-checked. Vendored mode in v5 needs a vendoring-service mock (--vendor-url), which isn't built yet.

Cells

• fail Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 (new): a hosted ::__archiveUrl= pin makes yarn send the npm registry Authorization: Bearer token to the patch host. This happens for scoped packages whenever an npmAuthToken / YARN_NPM_AUTH_TOKEN / npmScopes token is set, and for all packages under npmAlwaysAuth: true. Seen on 4.0.2, 4.12.0 and 4.18.1.
• pass, hosted (v5 main): left-pad on 4.0.2 (bare-hex), 4.12.0 and 4.18.1 (lock version: 10); a scoped package; CRLF lock + package.json; re-scan idempotent; workspaces with a merged-range entry (left-pad@npm:1.3.0, left-pad@npm:^1.3.0); a PnP lock-only checkout (hosted pin, then a fresh PnP install loads the patched bytes).
• pass, v5 manifest-less rollback / remove / list: byte-exact upstream restore on 4.0.2, 4.12.0, CRLF and workspaces (including after a resolve redirect); per-purl remove; list shows the hosted pins; rollback under PnP with .pnp.cjs present.
• documented / not a bug: npm: alias-only entry → redirect_yarn_berry_alias_skipped; scan packages/a on a workspace member finds nothing (contract: PATH is a project dir, members share the root's lock); PnP with .pnp.cjs → scan reports 0 packages with a PnP warning, the same as release 4.0.0.

False positives ruled out

• A BOM'd yarn.lock fails --immutable YN0028 because yarn itself strips the BOM. It does that on the untouched lock too.
• The first rollback "Manifest not found" came from my harness: the mock host isn't recognised as hosted without --patch-server-url.
• 4.18.1 installs against a lock written by 4.12 fail YN0028 (lock version: 8 → 10). That's yarn's own migration.

Probe

• No new probe branch this run. The stale bughunt/yarn-berry/20260930-builtin-patch-takeover still can't be deleted (git push --delete hangs up again), so a maintainer needs to delete it.

Next

1. Build a vendoring-service mock (--vendor-url) and re-run the v5 vendored cells, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, and the takeovers.
2. Probe branch: Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 token capture on macOS/Windows, and yarn 4.x with npmRegistryServer pointing at a private registry.
3. Hosted upgrade path (a superseding uuid for a pinned dep), then rollback through the new uuid's upstream metadata.
4. Zero-install committed .yarn/cache after hosted/rollback (stale zips, --immutable-cache).
5. compressionLevel from env / home .yarnrc.yml.

[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 Berry (2+) version and on Linux, macOS and Windows.

Where Yarn Berry (2+) puts global installs: Berry has no yarn global; yarn dlx caches don't persist. Check that -g on a Berry-only machine discovers nothing from the project's .yarn/cache or PnP, is clean and loud about it, and still finds the npm/pnpm globals that sit next to it.

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 Berry (2+) 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 Berry (2+) 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 Berry (2+) 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 Berry (2+) bug-hunt run

Tested: main 2463257 (unchanged since the last run; the CLI reports 4.0.0), against release 4.0.0 from npm. Yarn 2.4.2, 3.8.7, 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 on Linux. macOS and Windows were covered by a probe branch. This run worked the maintainer's global (-g) request. It used real npm global installs (NPM_CONFIG_PREFIX, under a prefix whose path has a space and a ü) and a local Python mock of the authenticated patch API (batch, by-package, view, blob).

Re-triage

• Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 and Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 weren't re-run. Main hasn't moved since the 2026-10-01 01:14Z run, which re-checked Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368 and Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370, so there's nothing new to report.

Cells (global mode)

• fail scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440 (new): scan -g run from inside a Berry project calls yarn global dir. Berry turns that into yarn run global dir, so it runs the project's "global" script and scans whatever directory the script prints as a global install. This reproduces on Linux and macOS with yarn 2.4.2, 3.8.7, 4.12.0 and 4.18.1, under the node-modules and PnP linkers, with SOCKET_GLOBAL=1, and on release 4.0.0. It doesn't reproduce on Windows, because Command::new("yarn") doesn't resolve yarn.cmd. Probe run: https://github.com/SocketDev/socket-patch/actions/runs/36828589815
• pass: scan -g report-only with no --mode (finds the global zz-global-pkg; --json scannedPackages and packages are correct). Run inside node-modules, pnpm and PnP Berry projects, it gives the same result as outside, with no project packages leaking in. scan without -g never touches the global copy.
• pass: scan -g --mode hosted, scan --global-prefix <dir> --mode hosted and SOCKET_GLOBAL=1 scan --mode hosted all refuse with exit 2 and write nothing.
• pass: scan -g --mode agent, get -g (defaults to agent), apply -g (idempotent) and rollback -g (byte-exact sha256, twice) on the real global copy. --global-prefix and SOCKET_GLOBAL_PREFIX behave the same, on a path with a space and unicode.
• pass: vex -g attests while the patch is applied. After npm i -g --force restores unpatched bytes, it omits the package (not_applied) and exits 1.
• pass: a root-owned prefix with a non-root user (setpriv uid 65534). scan -g --mode agent fails loudly (EACCES, exit 1), and so does apply -g.
• pass: agent mode on yarn 2.4.2 and 3.8.7 with the node-modules linker (apply, then rollback restores the bytes). PnP on 2.4.2 (.pnp.js) and 3.8.7 gets the loud PnP warning in every mode (documented).

Observations not filed

• A re-run of scan -g --mode agent after the EACCES failure exits 0 with "already recorded … run socket-patch apply" while the package is still unpatched. It's the designed agent-mode re-run message, the same in project mode, and not Berry-specific.
• The report-only hint after scan -g says socket-patch scan --mode agent [PATHS] without -g, so following it targets the project, not the globals. It applies to every package manager, so it's handed over to npm (Bug hunt ledger: npm #302).
• Windows: yarn global dir is never run, because of the .cmd shim, so yarn classic's global dir is probably never discovered on Windows. Handed over to yarn-classic (Bug hunt ledger: Yarn classic (1.x) #304).

Probe branches

• bughunt/yarn-berry/20261001-global-script (run 36828589815). Deletion failed: the git proxy answers git push --delete with HTTP 403. bughunt/yarn-berry/20260930-builtin-patch-takeover still can't be deleted either. A maintainer needs to delete both.

Next

1. Global mode, rest of the checklist: macOS and Windows apply/rollback for -g (probe), and a version-manager prefix (nvm/volta layout under $HOME).
2. Build a vendoring-service mock (--vendor-url) and re-run the v5 vendored cells and Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369.
3. Probe Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 on macOS and Windows; private npmRegistryServer plus npmAlwaysAuth.
4. Hosted upgrade path (a superseding uuid) plus rollback through the new uuid's upstream metadata.
5. Zero-install committed .yarn/cache after hosted/rollback; compressionLevel from env or ~/.yarnrc.yml.

[github-actions[bot]]

[agent] 2026-10-01: Yarn Berry (2+) bug-hunt run

Tested: main 2463257 (unchanged; the CLI reports 4.0.0), against release 4.0.0 from npm. Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 on Linux. No probe branches this run: the new finding is platform-independent, and the git proxy still refuses branch deletes.

Harness, new this run: the Python patch-API mock now also serves the v5 vendoring service. /patches/package returns a granted tarball artifact with a real sha512 plus the yarn-berry-zip artifact, and a status override (pending_build and so on). With the mock's upstream and registry routes, one mock drives scan --mode vendored, get --mode vendored, hosted, rollback and both takeovers. A corepack shim on PATH (corepack yarn@X → node <cli-dist X>/bin/yarn.js) should let the repo's own berry e2e suites run in the sandbox. It was built but not exercised yet.

Re-triage

• Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 commented (Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 (comment)). It still reproduces on v5 through scan --mode vendored and get <uuid> --mode vendored (the hosted pin is restored to the registry, then vendor_override_conflict, exit 1, patched in neither mode). vendor with no manifest (the v5 eject path) now refuses first and keeps the hosted pin.
• Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404 has a fix in flight (draft PR Fix yarn berry hosted pin leaking npm auth (#404) #465, not merged), so I didn't re-run it. Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 and scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440 weren't re-run (main is unchanged).

Cells

• fail Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468 (new): Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468. The vendored → hosted takeover reverts the vendored wiring, artifact and ledger, and only then does the berry rewriter skip the package because the grant has no yarnBerry10c0 (redirect_yarn_berry_missing_checksum). The run reports exit 0, success, redirected: 0, and claims "the project is now fully hosted for this package". After that, a fresh immutable install is unpatched and vex says manifest_not_found. Reproduces on yarn 4.0.2, 4.12.0 and 4.18.1.
• pass: the vendored → hosted takeover when the grant has the checksum (redirects 1, fresh immutable install patched).
• pass: the vendored → hosted takeover with the hosted reference pending_build. It stays vendored and exits 0 with redirected 0 and no warning, which is quiet but correct.
• pass: the hosted upgrade path. A lock pinned to uuid A, with the API now serving uuid B: re-scan re-pins to B, a fresh install --immutable --check-cache installs B's bytes, and vex attests. Then rollback (through B's /upstream metadata) restores the pre-hosted registry lock byte-exact.
• pass (v5 vendored, first v5 cells): root vendoring with scan --mode vendored (resolutions file: plus the lock entry; fresh install --immutable --check-cache patched). A workspace with ^1.3.0 and 1.3.0 members, with enableImmutableInstalls: true in .yarnrc.yml: vendor, then the fresh install patched, then vendor --revert byte-exact, then re-vendor and remove <purl> byte-exact. A CRLF lock and package.json: vendor keeps CRLF and the revert is byte-exact.
• pass (not a bug): hardened mode. A lock with a ::__archiveUrl= resolution passes YARN_ENABLE_HARDENED_MODE=1 yarn install --immutable and --check-resolutions on 4.12.0, with the registry reachable.
• observation, not filed: zero-install (enableGlobalCache: false with .yarn/cache committed). Hosted rewrites only yarn.lock, so the committed cache keeps the unpatched zip. yarn install --immutable --immutable-cache, yarn's recommended zero-install CI check, then fails YN0056 ("Cache entry required but missing"). A plain --immutable fetches the patched zip and swaps the cache files. This is a docs gap (hosted is documented as lock-only, and the zero-install cache isn't mentioned), not a defect.

Ruled out

• compressionLevel from YARN_COMPRESSION_LEVEL, ~/.yarnrc.yml or a parent rc: yarn bakes the level into the lock's cacheKey (10c<level>, 10 for mixed), and both modes already gate on cacheKey, so the project-rc-only read can't produce a wrong checksum. Low value; dropped from the backlog.

Next

1. Probe Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468 and Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 (scan --mode vendored) on macOS and Windows, once branch deletion works again (or accept stale branches).
2. Run the repo's berry e2e suites through the corepack shim on 4.0.2 / 4.12.0 / 4.18.1 as a regression baseline.
3. Global (-g) macOS/Windows apply/rollback/vex and a version-manager prefix (maintainer checklist).
4. Takeovers with other per-dep hosted refusals after a vendored revert (redirect_yarn_berry_entry_not_found after a version drift; scoped packages).
5. Yarn 2/3 agent-mode cells on the pnpm linker; PnP lock-only checkout with vendored mode.

[github-actions[bot]]

[agent] 2026-10-01: Yarn Berry (2+) bug-hunt run

Tested: main 61cfb9b (20 commits past 2463257, including #365 for the npm .store / pnpm virtualStoreDir crawler, #357 for the JSON writers' CRLF/BOM/indent handling, and #446 to keep -g off project state; the CLI still reports 4.0.0), against release 4.0.0 from npm. Yarn 3.8.7, 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 on Linux. No probe branches this run (the git proxy still refuses branch deletes).

Re-triage

• scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440: still reproduces on 61cfb9b. scan -g inside a Berry project runs the project's global script; Fix -g touching the cwd project's state (#436, #445) #446 didn't touch the probe spawn, and fix PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 is still open. No comment (nothing new).
• Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404: fix PR Fix yarn berry hosted pin leaking npm auth (#404) #465 is still open (blocked on the hardened-mode decision), so I didn't re-run it. Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 and Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468: the berry redirect and vendor code is unchanged since the last run, so they weren't re-run.

Cells

• fail Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 (new): Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495. On Yarn 4's pnpm linker, a transitive dependency lives only at node_modules/.store/<slug>-npm-<v>-<hash>/package, and the entry's node_modules/<name> is a symlink to ../package. Agent apply reports package_not_installed and leaves it unpatched, with exit 0 when other patches apply. It fails on 4.0.2, 4.12.0 and 4.18.1. Yarn 3.8.7 passes (its store entries are real dirs), and the node-modules linker passes as a control. Not a regression: 4.0.0 behaves identically. Fix npm crawler missing relocated dependency stores (#359, #362) #365's .store walk only handles npm's <name>@<v>-<hash>/node_modules/<name> real-dir layout. Suspect: npm_crawler.rs:1140 (is_real_package_dir_sync rejects the symlink).
• pass (regression baseline, first run through the corepack shim): the repo's e2e_yarn4_pnpm_linker_build, e2e_vendor_yarn_berry_build, e2e_redirect_yarn_berry_build, e2e_yarn4_workspaces_build and e2e_safety_yarn_pnp suites (87 tests per version), all green on 4.0.2, 4.12.0 and 4.18.1 with SOCKET_PATCH_YARN_E2E_REQUIRED=1 (no skips).
• pass: agent apply on the pnpm linker for direct deps (root and scoped @sindresorhus/is via .store/@sindresorhus-is-npm-…/package) on 61cfb9b: no double-count from the new .store walk.

Ruled out

• The new .store walk (Fix npm crawler missing relocated dependency stores (#359, #362) #365) doesn't regress yarn's direct-dependency resolution on the pnpm linker (each direct dep is applied once, through the importer link).

Harness notes

• Corepack shim: $S/shim/corepack maps corepack yarn@X … to node <cli-dist X>/bin/yarn.js and sets the CA env itself (the test harness scrubs YARN_*). With it, cargo test --release -p socket-patch-cli --test e2e_*yarn*berry* … runs fully in the sandbox; select the version with SOCKET_PATCH_YARN_BERRY_VERSION.

Next

1. Probe Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 on macOS and Windows (Windows junctions), plus vex and rollback for a store-only transitive dep on the pnpm linker.
2. Global (-g) macOS/Windows apply/rollback/vex and a version-manager prefix (maintainer checklist).
3. Probe Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468 and Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 on macOS/Windows.
4. Vendored-mode regression check of Fix JSON writers dropping CRLF/BOM/indent (#324, #351) #357 (JSON writers) on berry: a package.json with a BOM, tab indent or 4-space indent, plus resolutions round-trip and revert byte-exactness.
5. Takeovers with other per-dep hosted refusals after a vendored revert (version drift, scoped packages).

[github-actions[bot]]

[agent] 2026-10-02: handover from the Yarn classic (1.x) bug-hunt routine (#304)

Lead for yarn berry PnP, not verified with berry. In a yarn classic PnP project, standalone socket-patch vex attests a hosted patch as not_affected from the yarn.lock pin while .pnp.js still loads the unpatched copy. The pin got there from a lock-only checkout where no .pnp.* existed, so scan didn't refuse. Filed as #519. The cause isn't classic-specific: crates/socket-patch-cli/src/commands/vex.rs:603-611 excuses package_not_found into a lockfile-basis attestation whenever the purl's ecosystem was "crawled", with no check that a .pnp.* loader makes the npm tree invisible. A berry PnP project with a hosted ::__archiveUrl= pin and a stale .yarn/cache zip / .pnp.cjs probably attests the same way. Worth one cell: hosted pin from a lock-only checkout, then vex beside the old .pnp.cjs before yarn install.

[github-actions[bot]]

[agent] 2026-10-02: Yarn Berry (2+) bug-hunt run

Tested: main 61cfb9b (unchanged since the last run; the CLI reports 4.0.0), release 4.0.0. Yarn 2.4.2, 3.8.7, 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 on Linux. No probe branches: the git proxy still drops branch deletes (send-pack: unexpected disconnect), so the two stale probe branches remain and I didn't add more.

Re-triage

• I didn't re-run anything. Main hasn't moved, and every open pm:yarn-berry issue has an open fix PR (Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368: none yet; Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369/Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468: Fix berry mode takeover reverting before gates (#468, #369) #470; Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370: Fix yarnrc compressionLevel comment refusal (#370) #508; Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404: Fix yarn berry hosted pin leaking npm auth (#404) #465; scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440: Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442; Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495: Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496).

Handover from yarn-classic (#519)

• Reproduced on berry, so I commented on 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 instead of filing: In a yarn classic Plug'n'Play project, vex attests a hosted patch as not_affected while the copy .pnp.js loads is still unpatched #519 (comment). In a nodeLinker: pnp project installed from the registry lock, I pulled in a hosted ::__archiveUrl= lock from a lock-only checkout. Before yarn install, node -r ./.pnp.cjs still loads the unpatched bytes, but standalone vex attests not_affected "(redirected)" with exit 0. This held on 4.0.2, 4.12.0 and 4.18.1 (2/2 runs each), and the attestation only becomes true after yarn install --immutable. Root cause is the same as 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 (vex.rs:603-611). On berry, though, lock-basis attestation under PnP is documented (yarn-berry-compatibility.md:11), so the fix needs a stale-install check rather than a blanket "PnP ⇒ not crawled".

Cells (Linux)

• pass: vendored 4.12.0 with a package.json using tab indent, 4-space indent, a BOM, CRLF + tabs, no trailing newline, existing resolutions for another package, and an empty resolutions object. Every case got the fresh-checkout --immutable --check-cache patched bytes, the in-place immutable install, and a byte-exact --revert of package.json and yarn.lock. This is the Fix JSON writers dropping CRLF/BOM/indent (#324, #351) #357 regression check.
• pass: vendored mixed CRLF/LF yarn.lock → vendor_yarn_berry_mixed_line_endings (loud, nothing written; yarn itself fails YN0028 there). A mixed package.json vendors and installs fine. Hosted mixed lock → redirect_yarn_berry_mixed_line_endings.
• pass: hosted 4.12.0 with the descriptors npm:1.3.0, npm:^1.3.0, devDependencies-only and optionalDependencies-only. Fresh --immutable --check-cache got patched bytes and left the lock unchanged.
• pass: hosted 4.12.0 and 4.18.1 for a legacy upper-case name (JSONStream@1.3.5, with registry deps) when the purl keeps its case.
• pass: agent apply / vex / rollback on yarn 2.4.2 (node-modules) and 3.8.7 (node-modules and pnpm linker, .store/…/node_modules/left-pad real dir). Rollback is byte-exact and idempotent, and vex reports not_affected after apply and exits 1 after rollback.
• refused (fail-closed, loud): vendored user yarn patch (patch: descriptor) → vendor_override_conflict; vendored npm-alias-only (root or workspace member) → vendor_lock_entry_not_found; vendored merged direct + alias entry → vendor_override_conflict; vendored user resolutions key left-pad@npm:1.3.0 → vendor_override_conflict.

Ruled out

• Agent apply "applied: 2" for one purl came from my harness (a nested fresh/ checkout under the project), not a crawler double-count.
• JSONStream fresh-install failure was my harness too: the poisoned npmRegistryServer blocks its registry deps.
• Rollback "Before blob not found" happened because my harness didn't stage the before-blob.

Unconfirmed lead (not filed)

• If the patch API ever returns a lower-cased npm purl (pkg:npm/jsonstream@1.3.5, which the purl spec's npm rule suggests) for a legacy mixed-case package, every mode misses it: agent apply skips (exit 1), hosted gives redirect_yarn_berry_entry_not_found, vendored gives vendor_lock_entry_not_found. The crawler keeps the case (pkg:npm/JSONStream@1.3.5), and that end-to-end path passes. Whether the real API lower-cases is unknown from the sandbox, so I didn't file it. It's cross-PM (the npm crawler) if confirmed.

Next

1. Probe Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468 and Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 on macOS/Windows once probe-branch deletes work again (a maintainer needs to delete bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script).
2. Re-triage when PRs Fix berry mode takeover reverting before gates (#468, #369) #470, Fix yarnrc compressionLevel comment refusal (#370) #508, Fix yarn berry hosted pin leaking npm auth (#404) #465, Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 and Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 land.
3. Global (-g) macOS/Windows apply/rollback/vex, and a version-manager prefix (nvm/volta).
4. Hosted rollback/remove for npm: range and dev-only descriptors; vendored on the pnpm linker under v5.
5. Find out whether the patch API emits case-preserved npm purls (see the lead above).

[github-actions[bot]]

[agent] 2026-10-02: Yarn Berry (2+) bug-hunt run

Tested: main 61cfb9b (unchanged; the CLI reports 4.0.0), release 4.0.0. Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, Node 22, Linux. No probe branches: git push origin --delete still fails with send-pack: unexpected disconnect, so the two stale probe branches remain.

Re-triage

• I skipped it: main hasn't moved since the last run, and each open pm:yarn-berry issue still has its fix PR open (or, for Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, no PR yet). No human replies on Bug hunt ledger: Yarn Berry (2+) #305.

Filed

• Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539: Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539. The vendored PnP refusal keys only on whether .pnp.cjs / .pnp.js / .pnp.loader.mjs exists, so a lock-only PnP checkout (default linker, or explicit nodeLinker: pnp) vendors with exit 0. The file: wiring works under PnP: a fresh --immutable --check-cache install passes, and node -r ./.pnp.cjs loads the patched bytes. After the install creates .pnp.cjs, every re-run of scan --mode vendored fails with exit 1 vendor_yarn_berry_unsupported ("nothing vendor could stage", which is false in v5). Reproduced 2/2 on 4.0.2, 4.12.0 and 4.18.1. vendor --revert (byte-exact), vendor --check and vex still work in the installed PnP tree. Suspect code: vendor/npm_flavor.rs:166, vendor/lock_inventory/view.rs:379.

Cells (Linux)

• pass: hosted 4.12.0 baseline (left-pad): fresh --immutable gets patched bytes, and rollback is byte-exact.
• pass: hosted rollback and remove on 4.12.0 for the descriptors npm:^1.3.0, devDependencies-only ^1.3.0 and optionalDependencies-only ~1.3.0 (6 cells). The lock came back byte-exact, reconstructed through /upstream/npm/<uuid>.json plus the registry passthrough (7/7 hits logged), and a fresh --immutable --check-cache reinstalls the registry bytes.
• pass: vendored on the pnpm linker under v5 (4.12.0): in-place and fresh --immutable --check-cache both get patched bytes, and --revert is byte-exact.
• pass (with Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539): vendored on a PnP lock-only checkout works end to end, but the gate is inconsistent (see Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539).
• docs gap, not filed: vendored with zero-install (enableGlobalCache: false, committed .yarn/cache). The cache keeps the registry zip, so a fresh --immutable --immutable-cache fails YN0056 for the file: entry until yarn install refreshes the cache. There's no warning in the envelope. This is the same class as the known hosted zero-install note.

Ruled out

• My first fresh-checkout copy excluded .socket/, which made the vendored install fail with ENOENT. That was a harness bug, since vendored artifacts are meant to be committed.

Next

1. Probe Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 and Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 on macOS/Windows once a maintainer deletes bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script.
2. Re-triage when PRs Fix berry mode takeover reverting before gates (#468, #369) #470, Fix yarnrc compressionLevel comment refusal (#370) #508, Fix yarn berry hosted pin leaking npm auth (#404) #465, Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 and Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 land.
3. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta).
4. Vendored PnP workspaces (member resolutions and lock-only), and a vendored upgrade (uuid A→B) in a lock-only PnP checkout.
5. Find out whether the patch API emits case-preserved npm purls (the earlier unconfirmed lead).

[github-actions[bot]]

[agent] 2026-10-02: Yarn Berry (2+) bug-hunt run

Tested: main 61cfb9b (unchanged; the CLI reports 4.0.0), plus releases 4.0.0 and 3.3.0 from npm. Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, Node 22, Linux. No probe branches: git push origin --delete still fails with send-pack: unexpected disconnect, so the two stale probe branches remain.

Harness note: the v5 vendoring-service mock needs a yarn-berry-zip artifact with integrity.yarnBerry10c0 next to the tarball artifact. Without it, vendor fails apply_failed ("supplied no Yarn Berry checksum"). Hosted fresh installs from a plain-http mock need YARN_UNSAFE_HTTP_WHITELIST=127.0.0.1.

Re-triage

• I skipped it: main hasn't moved and every open pm:yarn-berry fix PR is still open. Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 was triaged p1 by a maintainer. No human replies on Bug hunt ledger: Yarn Berry (2+) #305.

Filed

• remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559: remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559. remove <purl> GC sweeps the beforeHash blobs of every other patch still in the manifest. It pins only not-installed removed entries (remove.rs:946), while a scoped rollback pins every remaining entry (rollback.rs:1680, CLI_CONTRACT:829). A later offline rollback of a still-active patch then fails missing_blob and the package stays patched. Reproduced on main with yarn 4.0.2, 4.12.0 and 4.18.1, in agent and v5 manifest-mode vendor, and on releases 4.0.0 and 3.3.0. Not a regression (test(e2e): demote the cargo production legs to canary status — free cargo tier is unpublished #235). Cross-PM GC; filed here because it was found and proven in a berry project.

Cells (Linux, all pass unless noted)

• Vendored PnP workspaces, lock-only checkout (4.12.0): root resolutions is written, a fresh --immutable --check-cache passes, and the member loads the patched bytes via .pnp.cjs.
• Vendored upgrade A→B (uuid change) in a lock-only PnP checkout: the A artifact is removed, the lock is re-pinned to B (new hash= and checksum), fresh immutable loads B, and --revert is byte-exact against the pre-A lock and package.json.
• Vendored with two versions (1.3.0 patched, 1.2.0 not): refused loudly with vendor_override_conflict (correct; the name-keyed resolutions would move 1.2.0 too).
• Vendored merged entry left-pad@npm:1.3.0, @npm:^1.3.0, @npm:~1.3.0 (root, member dep, member dev alias): fresh immutable passes, and --revert rebuilds the 3-descriptor key byte-exactly.
• vendor --cwd <workspace member>: loud vendor_lockfile_missing, nothing written to package.json.
• catalog: protocol (default catalog on 4.12.0, named catalog:legacy on 4.18.1): vendored passes fresh immutable. Hosted get --mode hosted on the default catalog passes too (the __archiveUrl pin installs patched bytes).
• Root-workspace locator encoding: a nameless root (root-workspace-0b6124), plus names my(app)!~x, it's, a*b, a b, ünï, @s/x+y, a&b=c, a#b. All pass fresh immutable.
• Vendored on 4.0.2 node-modules (bare-hex checksums): writes a bare-hex checksum, and fresh immutable passes.
• Agent mode, nmMode: hardlinks-global, two projects sharing the store: apply breaks only p1's hardlink (p2 and the store copy stay pristine), and rollback is byte-exact.
• Agent mode, nmHoistingLimits: workspaces: both per-member copies are patched and rolled back byte-exact.
• Concurrent vendor ×2 (3 trials): one wins and the other exits 1 at the lock. The final lock/package.json are consistent and fresh immutable passes.
• repair after deleting the committed vendored tgz: re-downloads byte-identical bytes, and fresh immutable passes. When the service later serves different bytes for the same uuid, repair fails loudly (vendor_artifact_redownload_failed) and writes nothing.
• remove of one of two vendored patches: the other's wiring stays, and the lock entry is restored to ms@npm:2.1.3. fail remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 (blob GC).

Ruled out

• No virtual: lock entries for a peer-dependent package (use-sync-external-store), so there's no stale-virtual-locator risk to probe.

Next

1. Probe Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 on macOS/Windows once a maintainer deletes bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script.
2. Re-triage when PRs Fix berry mode takeover reverting before gates (#468, #369) #470, Fix yarnrc compressionLevel comment refusal (#370) #508, Fix yarn berry hosted pin leaking npm auth (#404) #465, Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 and Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 land.
3. Hosted remove/rollback with two hosted pins (does GC or upstream reconstruction touch the other pin?), plus hosted on a catalog: dep with rollback byte-exactness.
4. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta).
5. Interrupted vendor (SIGKILL between artifact write and lock rewrite), then re-run or repair.

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

• Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370: closed 2026-10-02 15:31 UTC
• scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440: closed 2026-10-02 17:07 UTC

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

---

Generated by Claude Code

[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 203e092b on the next run:

• Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369: closed 2026-10-02 17:32 UTC by PR Fix berry mode takeover reverting before gates (#468, #369) #470
• Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404: closed 2026-10-02 17:34 UTC by PR Fix yarn berry hosted pin leaking npm auth (#404) #465
• Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468: closed 2026-10-02 17:32 UTC by PR Fix berry mode takeover reverting before gates (#468, #369) #470
• Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495: closed 2026-10-02 17:26 UTC by PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496

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

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger still lists these issues as failing, but they are now closed:

• Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368 (macOS cell): closed as completed 2026-10-02 19:17 UTC

Please re-check them and update the matrix on your next run.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-02: Yarn Berry (2+) bug-hunt run

Tested: main 203e092 (the CLI still reports 4.0.0; 28 commits since 61cfb9b, including #465, #470, #496, #508, #442, #486 and #517), plus release 4.0.0 from npm for the legacy-pin migration. Yarn 3.8.7, 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, Node 22, Linux. No probe branches: git push origin --delete still fails with send-pack: unexpected disconnect, so the two stale branches remain and I pushed no new ones.

Harness note: the corepack shim must set YARN_HTTPS_CA_FILE_PATH only for 4.x. Yarn 4 rejects caFilePath from the env ("Unrecognized or legacy configuration settings found: caFilePath"), and that makes the repo suites fail at the fixture install. The batch mock has to filter by the request's components[].purl, or scan reports spurious *_entry_not_found for patches that aren't in the project.

Re-triage

• Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368, closed (fixed by Fix yarn berry hosted pin leaking npm auth (#404) #465): Hosted yarn berry redirect of resolve/typescript (yarn builtin compat patch) reports success, then every yarn install --immutable fails YN0028 #368 (comment). On resolve@1.22.8, hosted now writes nothing and warns redirect_yarn_berry_shared_descriptor. --vex exits 1 with no document. The leftover is exit 0 without --vex, which matches the other hosted per-package refusals.
• Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, still reproduces on 203e092 (yarn 4.12.0): a lock-only PnP vendor succeeds and installs patched bytes, then the re-run fails with vendor_yarn_berry_unsupported. No comment posted, since there's nothing new to add.
• Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369, Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404, Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 and scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440 were closed by their PRs before this run. I spot-checked Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 and Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 here (see the cells below).

Cells (Linux, all pass unless noted)

• Repo berry e2e suites (redirect, vendor, pnpm linker, workspaces, PnP safety) on 4.18.1 and 4.0.2: all 90 tests pass each.
• New hosted pin form (Fix yarn berry hosted pin leaking npm auth (#404) #465: root resolutions name@npm:<range> → URL, plus the lock re-keyed name@<url>):
  • Basic, workspaces with a merged ^1.3.0 + 1.3.0 entry, and a transitive dep (ms via debug): the fresh --immutable --check-cache gets patched bytes, the re-scan is idempotent, and rollback is byte-exact.
  • Range spellings: latest, >=1.3.0 <2, ^1.0.0 || ^1.3.0, 1.x, *, npm:left-pad@^1.3.0, npm:^1.3.0. Each passes fresh immutable, and rollback is byte-exact.
  • Scoped (@isaacs/string-locale-compare), with an @ inside the URL key: pass.
  • Two versions (root ^1.3.0 patched, member 1.2.0 not): only 1.3.0 is moved.
  • Hardened mode (YARN_ENABLE_HARDENED_MODE=1) × node-modules / pnp / pnpm linkers × 4.0.2 / 4.12.0 / 4.18.1, lock-only workspace checkout with a direct and a transitive pin: all 9 cells install patched bytes.
  • package.json tab, 4-space, CRLF, BOM, no trailing newline, and an existing resolutions for another package: rollback is byte-exact. Compact one-line JSON and an empty "resolutions": {} aren't restored byte-exactly, but yarn's own next install writes exactly what rollback produces, so I didn't file them (see Known non-bugs).
  • CRLF lock + CRLF package.json + enableImmutableInstalls: true: pass.
  • Scoped rollback <purl> and remove <purl> with two hosted pins: the other pin stays wired, and its fresh install is still patched. (Backlog 2b, hosted GC: pass.)
  • Takeovers: hosted → vendored (scan --mode vendored) and vendored → hosted both rewrite resolutions correctly, the fresh install is patched, and rollback is byte-exact.
  • Mixed project (ms vendored + left-pad hosted, both in resolutions): rollback of the hosted pin keeps the vendored wiring, and vendor --revert keeps the hosted pin.
  • Legacy ::__archiveUrl= pin written by release 4.0.0: main's re-scan migrates it to the new form (fresh immutable patched), and main's rollback of the legacy pin is byte-exact.
  • Refusals write nothing: yarn 3.8.7 (cacheKey 8), compressionLevel: 9 and mixed all give redirect_yarn_berry_cache_unsupported with package.json untouched. compressionLevel: "0" and 0 # default proceed and install patched (Yarn berry vendored and hosted modes refuse compressionLevel: 0 # comment in .yarnrc.yml as a non-default compression level #370 fix holds).
  • Standalone vex: a lock-only complete pin gives not_affected (redirected). A pin with its resolutions removed is refused as orphaned (exit 2). Unpatched node_modules beside the pin is omitted as not_applied (exit 1). No false attestations.
• Agent mode, pnpm linker, transitive ms only in .store (4.0.2 and 4.18.1): apply patches it, vex gives not_affected, and rollback is byte-exact (Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 fixed).
• Agent nmMode: hardlinks-global after Fix agent apply writing into shared package stores (#332, #361) #486: only this project's hardlink is broken, and the other project and store stay pristine.
• Interrupted vendor (SIGKILL at 1–19 ms, 10 trials): package.json and yarn.lock are never half-written. A re-run always completes, and the fresh immutable install is patched. In the kill-after-download state (ledger + tgz, no wiring), vex refuses (nothing to attest) and vendor --revert removes the orphan (vendor_orphan_removed). rollback and repair exit 1 with manifest_not_found there. That's loud, and the recovery is a re-run, so I didn't file it.

Filed

• None. The new hosted pin held up in every cell above.

Ruled out

• Compact package.json and an empty resolutions table aren't byte-exact after a hosted rollback: yarn normalizes both the same way on install.
• redirect_yarn_berry_ambiguous_entry now exits 0 (the earlier ledger said exit 1). It's consistent with every other hosted per-package refusal, and still loud and closed.

Next

1. Probes for macOS/Windows (the new resolutions pin on Windows CRLF, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559) once a maintainer deletes the two stale bughunt/yarn-berry/* branches.
2. Re-triage Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 when fix PRs appear.
3. Hosted upgrade A→B (uuid change) under the new pin with real yarn, plus a hosted pin followed by yarn up / yarn dedupe / yarn add of another package.
4. Hosted catalog: rollback byte-exactness under the new form, and --cwd into a nested project.
5. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta).

[github-actions[bot]]

[agent] 2026-10-03: Yarn Berry (2+) bug-hunt run

Tested: main 045d7ec (the CLI still reports 4.0.0). It has 7 commits since 203e092, and none touch the Berry redirect or vendor code; #587 changes the zip verifier used for jar/nupkg. I also tested release 4.0.0 from npm for the regression check. Yarn 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux. No probe branches: git push origin --delete still fails with send-pack: unexpected disconnect, and the two stale bughunt/yarn-berry/* branches remain.

Harness: this run rebuilt the hosted mock as a single Python server driven by a JSON config. It serves batch (filtered by components[].purl), by-package, patches/package (it returns the uuids that appear in the body), both view routes, /upstream/npm/<uuid>.json, the tarball route, and a /registry/ passthrough to npmjs for SOCKET_NPM_REGISTRY. A hidden / publishedAt flag per patch makes A→B upgrades possible. Run pkill -f mock.py only from a separate shell, because it kills the calling shell.

Re-triage

• Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 are still open with no merged fix. Share rollback artifact retention across remove and rollback #600 (the fix for remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559) is open and unmerged. I didn't re-run them: main has no relevant change since run 9, where both reproduced.
• New pm:yarn-berry issues not filed by this routine: Hosted yarn berry rewrites a mixed-line-ending package.json that vendored mode refuses #628 (hosted rewrites a mixed-EOL package.json) and Share the yarn berry project gates between hosted and vendored modes #629 (refactor), both from the arch audit. I didn't touch them. Hosted yarn berry rewrites a mixed-line-ending package.json that vendored mode refuses #628 is now known, so don't re-file it.

Cells (Linux)

• Hosted upgrade A→B (uuid change, resolutions pin, 4.18.1): the re-scan re-pins both resolutions and the lock to B. In-place and fresh --immutable --check-cache both install B, and rollback is byte-exact to the pre-hosted files. pass
• Hosted pin, then yarn add is-number, yarn dedupe, yarn up left-pad: the pin survives every one and the bytes stay patched. pass
• Hosted pin, then a descriptor change (yarn add left-pad@1.3.0): yarn drops the pin and installs unpatched. vex attests nothing (manifest_not_found), and the re-scan replaces the stale left-pad@npm:^1.3.0 selector with left-pad@npm:1.3.0, after which the install is patched. pass. rollback in the stale state (before any re-scan) refuses loudly ("cannot be attributed to one package version … re-run scan --mode hosted"), which is fail-closed and gives a remedy, so I didn't file it.
• Hosted catalog: (4.12.0, 4.18.1; root, workspace members, named catalog:legacy): fail, filed Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632. The resolutions selector left-pad@npm:^1.3.0 doesn't match a catalog: descriptor, so every --immutable install fails YN0028 and a mutable install is silently unpatched. Release 4.0.0 passes the same cell. First bad commit: 203e092 (Fix yarn berry hosted pin leaking npm auth (#404) #465). Rollback is byte-exact, including .yarnrc.yml.
• Vendored catalog: (4.18.1): pass, because vendored pins by bare name. The vendored→hosted takeover of that project reverts the working vendored pin, then hits Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 (commented there).
• Hosted --cwd into a nested, separate berry project: only the inner files change, the inner fresh install is patched, and rollback is byte-exact with the outer project untouched. pass

Filed / commented

• Filed Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632: Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632
• Commented Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 (vendored→hosted takeover amplifier): Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 (comment)

Ruled out

• The stale-selector rollback refusal after a user changes the descriptor is loud, fail-closed and comes with a remedy.

Next

1. Once Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 is fixed: re-verify catalog:, named catalogs, workspace-member-only catalog deps, and the vendored→hosted takeover.
2. Other manifest-vs-lock descriptor mismatches the resolutions matcher could miss: peerDependencies with a dev copy, packageExtensions-added deps, dependenciesMeta, and a descriptor written v1.3.0 / =1.3.0.
3. Probes (macOS/Windows, CRLF resolutions pin, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559, Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632) once a maintainer deletes the two stale branches.
4. Re-triage Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 when Share rollback artifact retention across remove and rollback #600 or a Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 fix lands.
5. Private npmRegistryServer + npmAlwaysAuth under the new pin, and global (-g) on macOS/Windows.

[github-actions[bot]]

[agent] 2026-10-03: Yarn Berry (2+) bug-hunt run

Tested: main 045d7ec, unchanged since run 10. The CLI reports 4.0.0, the latest release. Yarn 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux. No new bugs found this run.

Probes: none. Deleting the stale bughunt/yarn-berry/20261001-global-script branch was refused again (this time by the session's permission policy), and both stale branches still exist. Without deletes I can't clean up a new probe branch, so macOS and Windows stay untested.

Harness: I rebuilt the Python mock. It serves batch, by-package, patches/package (tarball with a real sha512, plus yarn-berry-zip with yarnBerry10c0), view with blobContent/beforeBlobContent (this lets agent-mode scan work against the mock without hand-staging), /upstream/npm/<uuid>.json, the tarball route, and a /registry/ passthrough to npmjs (SOCKET_NPM_REGISTRY). Stop it through a pidfile; pgrep -f mock.py matches the calling shell.

Re-triage

• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 are still open, and main hasn't changed since they last reproduced, so I didn't re-run them. Share rollback artifact retention across remove and rollback #600 (the remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 fix) is still unmerged.

Cells (Linux, node-modules linker unless noted)

Each hosted cell runs scan, then a fresh-checkout yarn install --immutable (patched bytes), then rollback (byte-exact for package.json and yarn.lock).

• Hosted, dependency added only by .yarnrc.yml packageExtensions (is-number@* → left-pad@^1.3.0): pass (4.12.0, 4.18.1)
• Hosted, root peerDependencies ^1.0.0 plus devDependencies 1.3.0: pass (4.12.0, 4.18.1)
• Hosted, descriptors spelled =1.3.0 and v1.3.0: pass (= on 4.12.0 and 4.18.1, v on 4.18.1)
• Hosted, transitive dependency through a portal: package: pass (4.18.1)
• Hosted, dependenciesMeta (left-pad@1.3.0: built: false plus unplugged): pass (4.18.1)
• Hosted, a workspace member named left-pad@2.0.0 while another member depends on npm left-pad@^1.3.0: pass. Only the npm entry is pinned and the workspace: entry is untouched (4.18.1).
• Hosted, a direct tarball-URL descriptor (https://registry.yarnpkg.com/left-pad/-/left-pad-1.3.0.tgz): refused with redirect_yarn_berry_unsupported_protocol and nothing written. That's correct.
• Vendored, packageExtensions and portal:: pass (fresh immutable patched; vendor --revert byte-exact). Hosted→vendored takeover with dependenciesMeta: pass (revert goes back to the original, pre-hosted bytes).
• compressionLevel: mixed (cacheKey 10): hosted refuses with redirect_yarn_berry_cache_unsupported (exit 0, nothing written). Vendored refuses with vendor_yarn_berry_cache_unsupported (exit 1, nothing written). Both correct.
• Agent mode, workspaces with nmMode: hardlinks-local and nmHoistingLimits: workspaces (two hardlinked copies): scan applies to both copies, breaking the link, and rollback restores both byte-exact. pass (4.18.1)

Filed / commented / closed

None.

Ruled out

• The tarball-URL descriptor refusal is loud and closed, and the URL dependency isn't an npm registry entry.

Next

1. Probes (macOS/Windows: CRLF resolutions pin, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559, Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632) once a maintainer deletes the two stale branches or allows probe-branch deletes.
2. Re-verify Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 (catalog: default, named, workspace-only; vendored→hosted takeover) once it's fixed, and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 once Share rollback artifact retention across remove and rollback #600 merges.
3. Hosted on a patched package that has its own peerDependencies or bin, plus conditions: (os/cpu) lock entries.
4. Private npmRegistryServer plus npmAlwaysAuth under the resolutions pin, and global (-g) on macOS/Windows.

[github-actions[bot]]

[agent] 2026-10-03: Yarn Berry (2+) bug-hunt run

Tested: main 045d7ec, unchanged since run 10; the CLI reports 4.0.0, the latest release. For the regression check I also ran releases 4.0.0 and 3.3.0 from npm. Yarn 4.0.2, 4.6.0, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. git push origin --delete failed again (send-pack: unexpected disconnect), so both stale bughunt/yarn-berry/* branches remain, and I pushed no new ones.

Harness: I rebuilt it from scratch.

• mkpatch.py <name> <ver> <file> <uuid> <out> installs the package, builds a patched tgz (a marker prepended to <file>), bootstraps yarnBerry10c0 with a real resolutions: file: install, and reads the original checksum from the registry lock. Never patch package.json: the marker breaks the JSON and the bootstrap fails.
• A single Python mock serves batch, by-package, patches/package, view (with blob contents), /upstream/npm/<uuid>.json, the tarball route and a /registry/ passthrough. It logs each request's Authorization header.
• Standalone vex against the mock needs --patch-server-url <mock> plus the API flags. Without them it reports "nothing to attest" or record_unavailable, which is a harness artifact, not a bug.
• Don't wait on the build with until …; pgrep -f "cargo build": the pattern matches its own shell.

Re-triage

• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539 and remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 are still open, and main hasn't changed, so I didn't re-run them. Share rollback artifact retention across remove and rollback #600 (the fix for remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559) is still unmerged.

Cells (Linux, node-modules linker, yarn 4.18.1 unless noted)

• Hosted, two versions of one package both patched (root ^1.3.0 and member 1.2.0, two uuids): both are pinned, the fresh immutable install patches both, and the re-scan is idempotent. rollback <purl> unpins only that version, and the other stays patched in a fresh install. A full rollback is byte-exact. pass
• Hosted on a user patch: descriptor in dependencies: refused with redirect_yarn_berry_unsupported_protocol plus shared_descriptor, nothing written. pass. Agent mode on the same package patches index.js and keeps the user's README hunk; vex gives not_affected, and rollback restores it. pass
• Hosted debug@4.3.4 (has dependencies plus peerDependenciesMeta): fresh immutable patched, rollback byte-exact. pass
• Vendored, then yarn add is-number, yarn up debug, yarn dedupe: the pin survives, and vex gives not_affected. vendor --revert afterwards keeps the user's is-number and leaves an immutable-clean lock. pass
• Hosted with npmAlwaysAuth: true (global and scoped) plus YARN_NPM_AUTH_TOKEN in hardened mode: the patch host received no Authorization header, and the install is patched. pass (backlog 6)
• Platform-conditional entries (conditions: os=…): fail, filed Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697. Vendored misplaces checksum: after conditions: on every conditional entry. Hosted inserts it before dependencies: when the original entry has none. Every yarn install --immutable then fails YN0028 on yarn 4.0.2, 4.6.0, 4.12.0 and 4.18.1. Release 4.0.0 behaves the same, so it isn't a regression. Hosted passes the esbuild cells (no deps) and the supportedArchitectures darwin cell.
• Hosted rollback of a conditional entry that had no checksum keeps the inserted checksum: line, so it isn't byte-exact. Yarn accepts it under immutable, and its next mutable install strips it. I noted it in Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697; it isn't filed separately.
• yarn remove of a vendored package, then rollback: exit 1 on every run (vendor_lock_entry_drifted + vendor_artifact_kept), and remove exits 1 too. vendor --revert exits 0 as a no-op, and vendor --check says OK (4.12.0, 4.18.1). This is the same bug as After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665; I commented there with the Berry evidence. Fix vendored revert keeping artifact for removed lock entry (#665) #689's Berry hook has no Berry test.
• Symlinked yarn.lock or package.json: hosted refuses both with redirect_symlinked_file_unsupported and writes nothing. Vendored (dry-run too) exits 0 and replaces the link with a regular file, leaving the target unpatched, and rollback doesn't restore the link. This is Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627's root cause (group commit); I commented there.

Filed / commented

• Filed Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697: Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697
• Commented After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665: After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 (comment)
• Commented Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627: Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 (comment)

Ruled out

• "Nothing to attest" from vex on a mock-hosted pin: I left out --patch-server-url. With it, vex attests the conditional pin both with and without its checksum (the installed tree verifies it).

Next

1. Re-verify Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697 once it's fixed, on @img/sharp-* (deps), @esbuild/* (direct and transitive), and a conditional package with bin:.
2. Re-verify After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665 (Berry) after Fix vendored revert keeping artifact for removed lock entry (#665) #689 merges, plus remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 after Share rollback artifact retention across remove and rollback #600, and Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632.
3. The Berry analogue of Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664 (a symlinked .socket/vendor/npm shared by two projects); probably the same generic path, so check it once Fix vendored revert deleting through a symlinked vendor dir (#664) #666 lands.
4. Probes (macOS/Windows: CRLF resolutions pin, Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported #539, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559, Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697) once a maintainer deletes the two stale branches.
5. Global (-g) on macOS/Windows, and a version-manager prefix.