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-09 (run 37), main 9ab72d4 (CLI 5.0.0; release commit merged, npm still has 4.0.0), previous release 4.0.0 (before that 3.3.0). Main was force-pushed and the clone is shallow; use git fetch --deepen=400 origin main for older SHAs. Run 36 tested a80b89e. Run 35 tested f3c6313. Run 34 tested 03b9418. Run 33 tested cf8b164. Run 32 tested e2d9633. Run 31 tested ea09714. Run 30 tested e61a845. Run 29 also tested PR #1033 head 314038b. Run 27 also tested PR #978 head 59eac7e; run 25 tested PR #940 head 980b7b6; run 23 tested draft PR #918 head 21413f1. 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 14: harness rebuilt (y, mkpatch.py, mock.py, addorig.py, run.sh, survey.py); the mock must unquote by-package purls repeatedly (scoped purls arrive as %2540). survey.py diffs npm: vs tarball-URL lock entry bodies to find pin-render mismatches. Run 16: harness rebuilt (y, mkpatch.sh, mock.py, lib.sh); the /registry/ passthrough must quote with safe='@/', and a checksum bootstrapped on yarn 4.0.x is bare hex, so prefix it with 10c0/. Run 17: v5 vendor --offline no longer builds locally, so vendored cells need the vendoring-service mock (POST /v0/orgs/org/patches/package, tarball + yarn-berry-zip) even with a hand-staged manifest. Run 13: also run every fresh install with YARN_ENABLE_HARDENED_MODE=1 (it implies --refresh-lockfile, which re-resolves tarball pins from the tarball manifest). Run 18: harness rebuilt (y, mkpatch.sh, stage.py, mock.py, hmock.py, reg.py, lib.sh); reg.py is an npmjs passthrough with non-conventional tarball URLs (forces ::__archiveUrl= lock entries) that also serves /<name>/<version> for SOCKET_NPM_REGISTRY; cold-cache checks need a fresh YARN_GLOBAL_FOLDER. Run 19: reg.py must 404 the conventional /-/ tarball path (as a real non-conventional mirror does), or yarn's error is a misleading "socket hang up". Run 20: harness rebuilt (y, mkpatch.sh → p/cfg.json, one mock.py with view blobContent + /upstream/npm/<uuid>.json, reg.py, lib.sh); a bare scan defaults to hosted, so pass --mode agent; vendored takeovers of hosted pins need --patch-server-url; the release 4.0.0 binary is package/socket-patch. Run 21: hosted rollback/remove need SOCKET_NPM_REGISTRY pointed at the reg.py passthrough, or they fail "error sending request" (sandbox artifact). Run 22: harness rebuilt (y, mkpatch.sh, mock.py, reg.py, plus reg2.py, a non-conventional mirror on :8792, and reg3.py, an npmjs stand-in on :8793 whose dist.tarball is conventional under its own base). When the restored dist.tarball host matters, set SOCKET_NPM_REGISTRY to reg3.py, never to the project's own mirror (that hid #908). Run 23: harness rebuilt (y, reg.py <port> conv|nonconv [prefix], mock.py + cfg.json, mkpatch.sh, run.sh <bin> <scenario> …); rollback takes no --mode. Run 24: harness rebuilt (y with YV=<v>, mock.py <scratch> <port> <checksum>, run.sh <yarn> tgz|dir|url hosted|vendored for the #939 matrix). Run 25: harness rebuilt (y, mock.py, reg.py, fx.sh, fresh.sh, yp.sh). The mock's /upstream/npm/<uuid>.json must return {name, version, integrity (registry sha512), yarnBerry10c0 (registry checksum)}. Yarn 4.18 needs approvedGitRepositories: ["**"] for github: deps. Run 26: harness rebuilt (y, mock.py <scratch> <port> <patched 10c0> <registry 10c0> <registry sha512> with a <scratch>/mode file (badsha/pending) for late vendored failures, reg.py, lib.sh, pnpjs.sh); chattr +i on a file is a working write-fault injector even as root. Run 27: a corepack shim with BH_HOME (yarn-only HOME override) runs the repo's e2e capstones unchanged against main and a PR worktree (CARGO_TARGET_DIR=target-pr); a hand-staged .socket/ + vendor --offline shows which gate fires (main stops at "needs the network"). Run 29: harness rebuilt fully local (mkpkg.py synthetic lpx, reg.py 8793, mock.py 8790 reading checksums from cfg.json, sp wrapper, fresh DIR); shell helpers must not clobber caller variables. Run 30: stage.py (stub dummy pkg + manifest + blob), case.sh (diffs real yarn config get nodeLinker against socket-patch's PnP decision per rc/env shape), interp.sh <name> <nodeLinker value> (real PnP install, agent apply, lock-only vendor); offline rollback needs the before blob staged. Run 31: harness rebuilt (mkpkg.py, reg.py <port> conv|nonconv, mock.py with a per-uuid hidden flag + hide.sh A|B, gen.sh generation cells). The hosted tarball URL leaf MUST be <name>-<version>.tgz (hosted_url_names), or the existing pin reads as a foreign http: entry. The view hashes are git-blob sha256, or vendor fails apply_failed. The corepack shim also needs YARN_HTTPS_PROXY=$HTTPS_PROXY. Run 32: harness rebuilt (bin/y, mock.py :8790 left-pad, generic mock2.py :8791 driven by mkpatch.sh NAME VER UUID → pk2/<name>@<ver>/ with ck, regsha and a hand-added regck (must carry 10c0/; /upstream needs yarnBerry10c0 or rollback refuses), reg.py :8793 npmjs passthrough for SOCKET_NPM_REGISTRY). Run 33: harness rebuilt (h/mock.py <dir> 8790 driven by cfg.json with per-package ck (null = no yarn-berry-zip artifact, which makes hosted refuse redirect_yarn_berry_missing_checksum, the easiest way to force a #1039 takeover retraction), h/mkpatch.py (patched tgz + bootstrapped 10c0 + registry regck/regsha), h/stage.py (manifest + blobs), h/fresh.sh (copies packages/ too for workspaces), h/reg.py 8793). Vendoring needs the yarn-berry-zip artifact present (ck set) or it fails. The safety check blocks rm -rf $VAR inside loops; use fresh directory names. Run 34: harness rebuilt (bin/y, h/mkpatch.sh NAME VER UUID → pk/<name>@<ver>/ with ck/regck/regsha/before/after/file, h/mock.py <pk> 8790 serving every pk/* package (the tarball artifact must carry the patched tgz's real sha512, or packages with bin skip with npm_manifest_unavailable), h/reg.py 8793 npmjs passthrough, h/lib.sh with hs/sp/fresh). Never run npm install --package-lock-only next to a berry lock: npm rewrites yarn.lock as classic v1. Run 35: harness rebuilt (bin/corepack shim + bin/y, h/mkpatch.sh NAME VER UUID → pk/<uuid>/{patched.tgz,meta.json}, h/addreg.sh <uuid> adds regck/regsha for the /upstream/npm/<uuid>.json route, h/mock.py <pk> 8790 (batch, by-package, view, package, artifacts, upstream), h/reg.py 8793, h/stage.py, h/mkfx.sh, h/cell.sh). For SIGKILL timing, exec the binary directly ($SP … & p=$!); kill -9 on a shell-function wrapper kills only the subshell. The takeover commit window on this harness is ~0.04–0.05 s after start. Run 36: harness rebuilt (bin/y with YV=<v>, h/mkpatch.sh NAME VER UUID → pk/<uuid>/{patched.tgz,meta.json} with ck/regck/regsha and view blobs, h/mock.py <pk> 8790 (batch, by-package, view, package, artifacts, upstream, /v0/organizations), h/reg.py 8793 npmjs passthrough, h/lib.sh with sp/fresh). Deterministic crash injection: shim.so, an LD_PRELOAD rename/renameat2 hook that SIGKILLs when the target path ends with $KILL_ON (/package.json, /yarn.lock, /state.json); sleep-timed kills no longer land (the commit window is under 5 ms). Run 37: harness rebuilt (bin/y with YV=<v> and the yarn 2/3 YARN_CA_FILE_PATH, h/mkpatch.sh NAME VER UUID [FILE] → pk/<uuid>/{patched.tgz,meta.json} (bootstraps ck/regck with real yarn installs), h/mock.py <pk> 8790 (proxy + org routes, view with blob contents, package, upstream, /registry/ npmjs passthrough, and a non-conventional mirror at /mirror/ whose tarballs live under /mirror-dl/), h/lib.sh (sp with --api-url/--proxy-url/--patch-server-url, fresh, mkfx), h/shim.so rename killer (KILL_ON, KILL_NTH, KILL_AFTER), h/bis.sh BIN for the #1082 cell). Without a token, --proxy-url is what routes to the mock. vex -o is --org; use -O. 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 17 (4.18.1; 4.0.2 where noted): pass for the takeover of a user exact pin "left-pad": "1.3.0", mixed-case JSONStream, three linked packages (also 4.0.2) with per-package rollback, default global cache + --check-cache, workspaces focus --production, prerelease ms@3.0.0-canary.1, --check on a tampered tgz. bin: + conditions: (ios-deploy) fail #697/#718 (passes on PR #719). vendor --check wiring drift (resolutions dropped, lock restored) exit 0: #725 class (commented; PR #730 fixes it). run 16: parent-scoped user resolutions (pkg-a/left-pad, pkg-a/left-pad@^1.3.0, <root>/left-pad) fail #783 (vendored adds its own pin; every fresh --immutable fails YN0028; 4.0.2, 4.12.0, 4.18.1; also release 4.0.0). Exact-name user keys refused (correct). A→B re-vendor across a 4.0.2 → 4.18.1 upgrade pass (revert is #759). Workspaces globs */**, self-alias npm:left-pad@… descriptors (revert byte-exact), default compressionLevel spellings: pass. run 15: yarn upgrade 4.0.2 → 4.12.0/4.18.1 after vendoring, then rollback/vendor --revert: fail #759 (bare-hex checksum restored; also release 4.0.0). Without a revert: pass. checksumBehavior ignore/update/reset: pass. run 14: native-addon packages (implicit node-gyp: "npm:latest": nan, bufferutil) fail #737 on every fresh --immutable (4.0.2, 4.12.0, 4.18.1; also PR #719 head). Workspaces × node-modules/pnpm and packages with own peerDependencies: pass, plain and hardened. run 13: package whose tarball bin: differs from the registry metadata (uuid, acorn) fail #718: every fresh --immutable fails YN0028 (4.0.2, 4.12.0, 4.18.1). 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 16 (4.18.1): parent-scoped user resolutions refused correctly (redirect_yarn_berry_resolutions_conflict). Self-alias npm:left-pad@… descriptors: pin, fresh and rollback byte-exact. PR #763 head verified for #632 (5 catalog shapes + takeover, rollback byte-exact). run 14: native-addon packages (nan, bufferutil): fail #737 under hardened mode (4.0.2, 4.12.0, 4.18.1; PR #719 head too); regression from #465 (release 4.0.0 passes). Workspaces (merged entry + scoped) × node-modules/pnpm, own peerDependencies (fdir, use-sync-external-store): pass, hardened. nan rollback byte-exact. run 13: tarball bin: ≠ registry bin: (uuid, acorn): fail #718 under hardened mode / --refresh-lockfile (4.0.2, 4.12.0, 4.18.1); regression from #465 (release 4.0.0 passes); plain --immutable passes. 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
Linux	4.0.2, 4.12.0, 4.18.1 (custom registry, non-conventional tarball URLs)	n/a	run 18: pass (pin, fresh immutable, --revert byte-exact); member-level resolutions and object-form workspaces pass	run 18: pin + fresh immutable pass; rollback/remove fail #817 (drops ::__archiveUrl=, cold-cache install YN0001)	removed in v5
Linux	4.0.2, 4.18.1 (.gitignore covers the vendored tgz: *.tgz, vendor/, .socket/)	n/a	run 19: fail #831 (Berry commented; node-modules on 4.0.2 and 4.18.1, pnpm on 4.18.1; fresh --immutable YN0001, warm cache too; --check exits 0 under .socket/)	not affected (lock-only)	removed in v5
Linux	4.0.2, 4.18.1 (custom registry, hosted→vendored takeover then vendor --revert)	n/a	run 19: fail #817 (commented: the takeover's hosted revert stores a bare npm: original in state.json)	see the row above	removed in v5
Linux	4.18.1 (lock with builtin patch: typescript/fsevents beside the target)	n/a	run 19: pass (hardened fresh)	run 19: pass (hardened fresh)	removed in v5
Linux	4.12.0, 4.18.1 (yarn pnpm linker, pnpmStoreFolder relocated)	run 20: transitive packages fail #859 (.cache/.store: package_not_installed exit 0; store: refused as first-party source, exit 1; also release 4.0.0). Direct deps and a workspace member's direct dep pass (rollback restores). Default node_modules/.store control passes	not affected (lock-only)	not affected (lock-only)	removed in v5
Linux	4.18.1 on main 4646693 (run 20 re-verification)	#665 Berry fixed (yarn remove then rollback)	#718 (uuid), #697 (@esbuild/linux-x64 transitive), #817 takeover variant: fixed; pre-#719 pins heal on re-run; vendored→hosted takeover of a bin: package pass. #737 and #759 still fail	#718, #697, #817 (custom-registry rollback byte-exact) fixed; #737 still fails hardened	removed in v5
Linux	4.0.2, 4.12.0, 4.18.1 on main 9c43dfc (run 21)	env/home pnpmStoreFolder (YARN_PNPM_STORE_FOLDER, ~/.yarnrc.yml): direct deps refused as first-party, exit 1 (commented on #859). Env-only YARN_NODE_LINKER=pnpm with the default store: pass	symlinked .socket shared by two projects: fail #887 (unwind in one deletes the other's tgz + state.json; 4.0.2, 4.18.1, node-modules + pnpm). Linked .socket/vendor[/npm] refused (pass). Symlinked yarn.lock/package.json refused (#627 fixed). vendor --check drift (#725) fixed. Scoped string bin (@babel/parser): pass	from a workspace member: fail (#884, Berry evidence commented): get <uuid>, and scan when the member owns a copy, exit 0 with redirected: 0. #632 fixed on main (4 catalog selectors, hardened fresh, rollback byte-exact). Scoped string bin: pass	removed in v5
Linux	4.0.2, 4.18.1 on main 9c43dfc (run 22)	symlinked shared .socket: fail (#887, agent evidence commented). Project reached through a symlinked path: pass	project via a symlinked path (cwd and --cwd): pass. Hosted→vendored takeover then vendor --revert on a non-conventional mirror: fail #908	non-conventional npmRegistryServer mirror with SOCKET_NPM_REGISTRY unset: rollback/remove fail #908 (bare locator, cold --immutable YN0035; #817 fix incomplete; byte-exact only when SOCKET_NPM_REGISTRY is the mirror). Symlinked project path: pass	removed in v5
Linux	4.0.2, 4.18.1 on main 9c43dfc and PR #918 21413f1 (run 23)	n/a	n/a	hosted rollback/remove on a mirror: project-rc top-level npmRegistryServer fails on main (#908) and passes on PR #918; npmScopes.<scope>.npmRegistryServer (scoped target), env YARN_NPM_REGISTRY_SERVER and ~/.yarnrc.yml fail on both (commented on #908). Conventional mirror with a path base: pass on both	removed in v5
Linux	4.0.2, 4.18.1 on main 9c43dfc (run 24)	lp2 other-name file: copy: pass (both copies patched, rollback restores both)	member copy of the patched name@version under another dependency name ("lp2": file: tgz / dir / registry URL): fail #939 (no warning; lock-only vex and post-install vex attest not_affected). Same-name file: copy refused (vendor_override_conflict, pass)	same lp2 shapes: fail #939 (no warning; lock-only vex attests; post-install vex declines). Same-name file: copy refused (unsupported_protocol + shared_descriptor, pass)	removed in v5
Linux	4.0.2, 4.18.1 on main 9c43dfc and PR #940 980b7b6 (run 25)	portal:/link: lp2 copy: first-party link skipped by design, vex attests (noted on #939). User yarn patch over a hosted pin: vex declines, re-scan refuses (pass)	user yarn patch over a vendored pin, then vendor --revert/rollback: fail #962 (exit 1 but wiring already half-reverted; YN0028). lp2 as portal:/link:/github:: fail #939 on main and PR #940; file: tgz on the pnpm linker passes on PR #940	user yarn patch over a hosted pin, then rollback/remove: fail #962 (exit 0 "Restored", fresh --immutable YN0028, mutable install re-pins the Socket URL). lp2 as portal:/link:/github:: fail #939 on main and PR #940 (commented)	removed in v5
Linux	4.0.2, 4.18.1 on main 9c43dfc (run 26)	Yarn 2 PnP → Yarn 4 node-modules/pnpm linker with the stale .pnp.js Yarn 4 leaves: fail #975 (refused as PnP, exit 1; release 3.3.0 passes, 4.0.0 fails). User yarn patch after agent apply: overwritten by design	stale .pnp.js: fail #975 (exit 1). Yarn 2.4.2 vendored: refused by design (cacheKey 7)	Late vendored failure (bad sha512, pending_build) during a hosted→vendored takeover keeps the hosted pin: pass. Stale .pnp.js: pins, but a false yarn_pnp_unsupported warning (#975). Write fault on yarn.lock: loud, re-run heals	removed in v5
Linux	4.18.1 on main 9c43dfc and PR #978 59eac7e (run 27)	stale .pnp.js + project-rc node-modules: fail #975 on main, pass on PR	nodeLinker only in ~/.yarnrc.yml (project outside $HOME) or via YARN_RC_FILENAME: main passes (repo capstone, 11/11 VEX); PR #978 refuses vendor_yarn_berry_unsupported (commented on #539). Lock-only no-linker: refused up front on PR (#539)	untested this run	removed in v5
Linux	4.0.2, 4.18.1 on main db83f01 (run 28)	n/a	#831 Berry fixed (*.tgz re-included; vendor//.socket/ refused vendor_artifact_gitignored). Shared symlinked .socket: fail #887 (still)	mirror from npmScopes (scoped), YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir rc: rollback/remove fail #1017 (bare locator, cold --immutable YN0035). Project-rc top-level mirror (also trailing /, # comment, CRLF rc) and the inverse scope map: pass (#908 fixed). From a workspace member: get and member-owned scan refused (#884 fixed)	removed in v5
Linux	4.0.2, 4.18.1 on main 05ecc6e (run 29)	#424 Berry fixed (--json apply failure reported)	member adds a new descriptor of the patched package (lpx: 1.0.0) after vendoring: the pin covers it, but vendor --revert/rollback drop it and fresh --immutable fails YN0028 (#759 class, commented)	same member add after a hosted pin: fail #1082 (re-scan refuses with an impossible dedupe remedy; rollback exit 0 then YN0028; lock-only vex attests on main, dropped on PR #1033). #657 gates pass: mixed package.json refused by scan, rollback/remove (exit 1) and the vendored→hosted takeover; nothing written. #939 on merged main: file: copy dropped, portal: still attests	removed in v5
Linux	4.0.2, 4.18.1 on main e61a845 (run 30)	#975 fixed (real node-modules install + stale .pnp.js: apply + rollback byte-exact). nodeLinker parity: home rc, YARN_RC_FILENAME, CRLF, ${L:-node-modules} pass. nodeLinker: "${L:-pnp}" / "${L}" (L=pnp) on a live PnP install: fail #1100 (exit 0 package_not_installed; release 4.0.0 refuses). Quoted key, next-line value, flow map, lower-case yarn_node_linker env: false PnP refusal (listed on #1100)	#539 fixed (lock-only literal/unset pnp refused up front). Interpolated pnp passes the gate: #1100	untested this run	removed in v5
Linux	4.0.2, 4.18.1 on main ea09714 (run 31)	#1082: VEX half fixed (#1033); rollback now refuses (exit 1, nothing written); re-scan dead end remains (commented). Repo berry e2e suites pass (4.18.1: 15/19/17)	Generation cells pass on both versions: vendored A→B revert, hosted A→vendored B revert/remove/rollback, vendored A→hosted B remove/rollback, all byte-exact with fresh immutable. Leftover package-lock.json: warned, revert byte-exact. compressionLevel: "${CL:-0}" false refusal (commented on #1100)	Hosted A→B re-pin + rollback byte-exact (both). Leftover package-lock.json: both locks pinned, rollback byte-exact. npmRegistryServer: "${REG:-<mirror>}": rollback/remove warn upstream_registry_fallback, then cold --immutable YN0035 (commented on #1017). Same ${CL:-0} false refusal	removed in v5
Linux	4.0.2, 4.18.1 on main e2d9633 (run 32)	#1029 apply --check: drift caught (exit 1), nmHoistingLimits two copies, version mix, pnpm linker, PnP fail-closed: pass. Interpolated pnpmStoreFolder: "${STORE:-node_modules/.store}" transitive: pass. Shared linked .socket: still shared (acknowledged gap in #1042)	#1050 scan --prune GC keeps live entries: root, workspace member, catalog:, pnpm linker, CRLF lock, 4.0.2: pass. #887 fixed by #1042 (closed). #783 still fails. #737 (nan) still fails. uuid bin: vendored + revert byte-exact. Leftover pnpm-lock.yaml: pnpm wins even with packageManager: yarn@4 (same in 4.0.0; documented warning). Yarn 2/3 gates hold	rollback/remove/takeover revert of a package whose tarball bin differs from the registry (uuid, prettier): fail #1131 (keeps ./dist/bin/uuid, hardened --immutable YN0028; also ea09714; release 4.0.0 not affected). #1057 stanza rewrite: plain, CRLF (byte-exact), alias-only JSON per-purl row, leftover pnpm-lock.yaml (both pinned, rollback byte-exact): pass. #737 hardened still fails	removed in v5
Linux	4.0.2, 4.18.1 on main cf8b164 (run 33)	#1100 still fails (${L:-pnp} live PnP: apply exit 0 package_not_installed). pnpmStoreFolder: ../shared used by two projects: apply in A patches B's copy too (documented: relocated berry store not containing the project is patched as usual)	n/a	#1039 staged vendored→hosted takeover: pass. Two vendored packages × (ck present/absent) on LF and CRLF: dry run byte-identical; partial retraction keeps the refused purl vendored (wiring, ledger, artifact) and migrates the other; all-retracted is byte-identical; fresh --immutable plain + hardened patched; rollback after a partial takeover restores pristine (4.0.2 byte-exact, bare hex). Workspaces (member ^1.3.0 + 1.3.0), get <uuid> --mode hosted (kept/migrated), compressionLevel: mixed after vendoring (both kept), PnP switch after vendoring (pins with yarn_pnp_unsupported, PnP fresh + hardened loads patched), alias lp: npm:left-pad@1.3.0 added after vendoring (alias_skipped, documented), write fault (chattr +i on yarn.lock / package.json / state.json, with and without a takeover): exit 1, nothing changed. VEX over a partial takeover: both attested.	removed in v5
Linux	4.0.2, 4.18.1 on main 03b9418 (run 34)	n/a	yarn remove after vendoring: --check names it, --prune/--revert/rollback/remove retire it (pass)	#1058: pin + re-scan already + fresh hardened + rollback byte-exact pass for workspaces, catalog:, transitive, pnpm linker, leftover npm/pnpm locks, legacy 4.0.0 __archiveUrl migration. yarn remove / yarn up to an unpatched version after a hosted pin: fail #1203 (leftover resolutions selector → rollback/list/remove exit 1 forever, the remedy scan is a no-op). #1131 still fails	removed in v5
Linux	4.0.2, 4.18.1 on main f3c6313 (run 35)	n/a	Refactored npm-family driver (#1008): node-modules, pnpm linker, workspaces, catalog:, 4.0.2, --revert/rollback/remove byte-exact; write faults on vendor and on unwind (exit 1, nothing half-written); generation A→B; hosted→vendored takeover then --revert pristine: pass. Repo berry e2e 187/187 (4.18.1) and 147/147 (4.0.2). #737 and #783 still fail	SIGKILL after the takeover's commit journal is durable, then rollback: fail #1241 (journal replayed under the lock, pre-lock hosted discovery empty → exit 0, nothing restored; remove "No patch found"). #1039 retraction on the pnpm linker and catalog:: pass	removed in v5
Linux	4.18.1 on main a80b89e (run 36)	Agent scan PATH on workspaces: pnpm linker member link selected (pass); hoisted copy outside the PATH is out of scope (by contract). nmMode: hardlinks-local + nmHoistingLimits: workspaces: apply patches 3 copies, rollback packages/a restores all with out_of_scope_copies_restored (pass)	Refactored driver: --dry-run writes nothing, repair redownloads a deleted tgz, CRLF lock, --revert/rollback byte-exact (pass). First vendoring SIGKILLed after its journal: rollback refuses pre-lock (vendor ledger is missing), never replays (commented on #809)	#1203 and #1131 still fail. #1241 (closed by a maintainer without a fix) still fails, now deterministic via the rename shim; the hosted→vendored takeover direction fails too (stale pre-lock list → false Cannot restore exit 1, or a pre-lock refusal that never replays the journal; commented on #1241)	removed in v5
Linux	4.0.2, 4.18.1 (2.4.2, 3.8.7 refusals) on main 9ab72d4 (run 37)	#1034 target grammar (name, purl, uuid, scoped, last-segment vs full name) on rollback/remove: pass. Yarn 2/3 agent apply + rollback: pass	#989 shared revert: partial remove/rollback <name> keeps the other package; SIGKILL during vendor --revert/rollback/remove, then re-run: pass. BOM .yarnrc.yml PnP gate (LF/CRLF): pass. Alias lp: npm:left-pad@1.3.0 added after vendoring, then revert/rollback/remove: exit 0, then YN0028 (commented on #1082)	#1180 alias copy: no false VEX (pass). BOM project-rc mirror rollback: pass. #1017 still fails. #1082 point 2 regressed (bisected to f3c6313a #1008): member or alias descriptor added after pinning → rollback/remove exit 0, then YN0028. SIGKILL mid-rollback: half-unwound, yarn install heals (residual)	removed in v5
Linux	4.0.2 → 4.18.1 (yarn upgrade)	n/a	see the all 4.x row (#759)	run 15: pin survives the upgrade, re-scan no-op, rollback writes 10c0/, fresh hardened --immutable pass. checksumBehavior ignore/update/reset: pass.	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

0. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 regression (run 37): point 2 is back on f3c6313a+ (Fix open npm issues #1008/npm hosted pin next to a bundled copy can't be unwound: rollback/remove refuse it, and the vendored takeover skips the restore, so vendor --revert lands back on hosted and allow-remote=all stays #828 Discovery::shadowed; restore_berry never merges blocks that share a resolution). Re-verify when fixed with h/bis.sh (plain member, root/member alias, remove, vendored alias revert; 4.0.2 and 4.18.1). Try other shadowed berry shapes: a file:/portal: sibling block (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939) and the hosted→vendored takeover over a shadowed pin.
1. After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 (run 35; closed by a maintainer on 2026-10-09 with no fix commit; run 36 shows it still fails on a80b89e in both takeover directions): re-verify when a fix lands (rollback and remove right after a replayed vendored→hosted takeover journal; 4.0.2 and 4.18.1); also list/repair/vex in the same state, and a replayed hosted→vendored takeover journal (vendor killed mid-commit) followed by rollback.
   0b. After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 (run 34): neighbours: removal from one workspace member while another keeps the dep, a removed catalog: dep, a scoped package; re-verify when fixed (rollback, remove, list, scan --mode hosted --prune, 4.0.2 and 4.18.1). Also try the Decide whether a hosted patch is pinned through lockfile discovery alone #1058 redirect_unattributable gate on berry shapes (portal:/link: copies, takeover + gate).
2. Blocked on a maintainer: probe-branch deletes fail (runs 10–13, 20, 21 and 34: send-pack: unexpected disconnect / remote end hung up; runs 14, 19 and 24: denied by the session 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, Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859, Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 (a .socket junction on Windows).
   0a. Make the vendored-to-hosted takeover atomic #1039 takeover (run 33, all pass): untested neighbours: SIGKILL during the journaled takeover commit (next locked command must finish it), takeover on the pnpm linker, takeover of a catalog: dep with a retraction, a retraction caused by redirect_yarn_berry_resolutions_conflict (user resolutions added after vendoring).
3. Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 (run 32): re-verify when fixed (rollback, remove, takeover + vendor --revert; uuid and prettier; 4.0.2 and 4.18.1; plain and hardened). Neighbours: other tarball-derived fields the Fix yarn berry pin entry rendering (#697, #718) #719 renderer emits (dependenciesMeta, peerDependencies spellings), a scoped package with a ./ bin, the pnpm linker.
   1a. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (run 29; run 31: VEX fixed and rollback now fail-closed, re-scan dead end remains): neighbours: a transitive dep adding lpx@~1.0.0, the pnpm linker, remove, PnP lock-only; re-verify when fixed (and the berry half of PR Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033). Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759: re-verify the new-descriptor revert symptom too.
   2a. Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 (run 28; the ${REG:-…} interpolated project-rc mirror added in run 31): re-verify when fixed (five sources × rollback/remove × 4.0.2/4.18.1; upstream_registry_fallback when unreadable), plus the hosted→vendored takeover vendor --revert on those mirrors.
   1b. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 (run 30; ${CL:-0} compressionLevel false refusal added in run 31): re-verify when fixed (agent + lock-only vendor, ${L:-pnp}, ${L}, plus the fail-closed parser rows). Neighbours: ${} in compressionLevel, enableGlobalCache, pnpStoreFolder, npmRegistryServer (other yarnrc_scalar users).
4. Re-verify when fixes land: Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 (hosted rollback/remove on 4.0.2 and 4.18.1, plus the vendored revert), Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (all 12 cells plus agent; PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940 fixes the file:/URL VEX half but not portal:/link:/github: copies), Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859 (plus the env/home variant), Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 (then @scope/parent/name, a scoped target, the hosted→vendored takeover), Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759, Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737, 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 rewrites a mixed-line-ending package.json that vendored mode refuses #628/Share the yarn berry project gates between hosted and vendored modes #629. Fixed and verified: Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 (run 32, vendored; closed), Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975, 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 (run 30), Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 project-rc case, Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 Berry, Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 Berry (run 28), 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 (run 21 on main), vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725 and 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 (run 21), 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 copy the registry entry's bin: paths, but yarn re-reads them from the tarball (./dist/bin/uuid), so vendored installs and hardened hosted installs fail YN0028 for packages like uuid and acorn #718, Hosted yarn berry rollback/remove rebuilds the lock entry as a bare name@npm:<version> locator and drops the registry's ::__archiveUrl= binding, so projects on registries with non-conventional tarball URLs can't install after a revert #817, 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 (run 20). 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, Yarn 4 pnpm linker: transitive packages that live only in node_modules/.store are "not installed" in agent mode and stay unpatched #495 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 closed.
   2b. (Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 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 verified fixed on e61a845, run 30.) Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 neighbours: a stale .pnp.js in a workspace member, vex on a Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 tree, and any path that leaves .pnp.cjs/.pnp.loader.mjs behind on a non-PnP linker. Re-verify Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 when fixed (agent, vendored, hosted warning; 4.0.2 and 4.18.1; both linkers).
   3b. Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 neighbours: a yarn patch of a workspace member's copy, a patch: wrapping a vendored pin from a member, and an agent-mode re-scan after the user's patch. (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 neighbours were done in run 25.)
5. Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 follow-ups once fixed: the refusal must not fire for a nested separate Berry project (own yarn.lock, not in the parent's workspaces); object-form workspaces; yarn 2/3 members.
6. Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859 neighbours: pnpmStoreFolder outside the project (../shared) shared by two projects.
7. Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (fixed on db83f01) follow-up: the hosted→vendored takeover under an ignore rule.
8. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta). Full checklist in the 20261001T040000Z entry.
9. 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.
10. Unconfirmed lead: if the patch service ever serves a hosted tarball whose root isn't package/, hosted skips it with npm_manifest_unavailable (exit 0). File it only if the real service does that.
11. Interpolated pnpmStoreFolder / npmScopes values (Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100/Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 class).

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 Superseded in run 21: after Hosted scan/get run from a pnpm workspace member (or with lockfile-dir=..) ignores the parent pnpm-lock.yaml and reports success while pinning nothing #590/Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598, the hosted run from a member is a bug (Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884, Berry evidence commented). A hoisted member scan still finds 0 packages, but get <uuid> and member-owned copies report success while pinning nothing.
• 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.
• A hosted pin whose bin: differs from the tarball's passes a plain yarn install --immutable and a later mutable install (yarn trusts the locked entry). Only hardened mode or --refresh-lockfile fails, and that is Yarn berry vendored and hosted pins copy the registry entry's bin: paths, but yarn re-reads them from the tarball (./dist/bin/uuid), so vendored installs and hardened hosted installs fail YN0028 for packages like uuid and acorn #718.
• A scoped patch missing from a mock-driven scan is a mock artifact if the mock doesn't fully unquote %2540 purls (run 14).
• lockfileFilename in .yarnrc.yml is rejected by yarn 4 ("Unrecognized or legacy configuration settings"). It only exists in yarn 2/3, which hosted/vendored refuse anyway.
• checksumBehavior (ignore/update/reset) doesn't change what yarn writes to the lock. Hosted and vendored pins pass under all three (run 15).
• A user **/name resolution is dropped from package.json by yarn 4's own install, so a hosted pin that seems to replace it isn't socket-patch's doing (run 16).
• compressionLevel: with its value on the next line (a multi-line YAML scalar) is refused by both modes. It's loud and unrealistic, so it isn't filed (run 16).
• Vendored vex on a tree whose node_modules still holds unpatched bytes (wiring pulled without a reinstall) attests not_affected from the committed artifact and warns vendored_tree_out_of_sync. That's by design (run 17).
• vendor --check reporting wiring verified after the Berry wiring drifts is vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725 (cross-PM root cause, Berry evidence commented in run 17). Don't re-file it.
• yarn install --mode=update-lockfile (Renovate) still writes checksum: lines on yarn 4.0.2 and 4.18.1, so there are no checksum-less target entries to test (run 18).
• A hosted-rollback bare npm:<v> locator where yarn wrote ::__archiveUrl= passes hardened mode and --refresh-lockfile. The breakage is only the fetch (Hosted yarn berry rollback/remove rebuilds the lock entry as a bare name@npm:<version> locator and drops the registry's ::__archiveUrl= binding, so projects on registries with non-conventional tarball URLs can't install after a revert #817).
• scan --mode agent --json reporting an apply failure as action: "added", failed: 0 with no error is scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 (cross-PM, open). Don't re-file it (run 20).
• Yarn 4.0.x rejects pnpmStoreFolder ("Unrecognized or legacy configuration settings"), so Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859 cells start at 4.1+ (run 20).
• A vendored refusal on a symlinked yarn.lock/package.json (Fix vendored mode replacing symlinked lockfiles (#627) #802) leaves .socket/vendor/npm/<uuid>/ behind despite saying "nothing was written". It's benign (vex refuses, vendor --check sees nothing, the re-run is clean), so it isn't filed (run 21).
• Hosted rollback failing with "error sending request for url (https://registry.npmjs.org/…)" in the sandbox is the rustls/proxy-CA artifact. Use SOCKET_NPM_REGISTRY (run 21).
• A symlinked project path (cwd or --cwd through a link, as macOS /tmp is) works in agent, vendored and hosted modes (run 22).
• A conventional mirror with a path base (npmRegistryServer: http://host/api/npm/npm-remote) restores bare and byte-exact after a hosted rollback (run 23).
• The Hosted yarn berry rollback/remove rebuilds the lock entry as a bare name@npm:<version> locator and drops the registry's ::__archiveUrl= binding, so projects on registries with non-conventional tarball URLs can't install after a revert #817 runs 18–20 "fixed" verdicts held only with SOCKET_NPM_REGISTRY pointed at the project's mirror. The realistic config is Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908, so don't re-verify Hosted yarn berry rollback/remove rebuilds the lock entry as a bare name@npm:<version> locator and drops the registry's ::__archiveUrl= binding, so projects on registries with non-conventional tarball URLs can't install after a revert #817 that way.
• A workspace member's same-name file: directory/tarball copy of the patched package ("left-pad": "file:…") is refused by hosted (redirect_yarn_berry_unsupported_protocol + redirect_yarn_berry_shared_descriptor) and vendored (vendor_override_conflict), nothing written. That's correct; the other-name copy is Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (run 24).
• A user yarn patch on a hosted-pinned package makes vex decline (hash_mismatch) and a re-scan refuse (the patch: entry wraps the descriptor). Both are correct; only the unwind is Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 (run 25).
• Agent mode skips a node_modules/<name> link into first-party source (portal:/link:) by design (docs/ecosystems.md), and reports already patched. Whether VEX should then attest is raised on Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939, so don't re-file it (run 25).
• A rollback error "upstream checksum metadata names a different package" against the mock means the /upstream/npm/<uuid>.json route is incomplete (run 25).
• A hosted scan whose yarn.lock write fails after package.json was written exits 1 loudly. A re-run completes the pin (exit 0). Hosted rollback with a write fault can leave package.json restored and yarn.lock still pinned; staged.rs flush_staged documents that as the residual I/O-fault exposure (run 26).
• Agent apply over a file the user changed with yarn patch overwrites it with Socket's patched bytes (content_mismatch_overwritten). That's the documented default mismatch policy; --strict refuses instead (run 26).
• Yarn 2/3 vendored refusal text says "remove custom compression settings", which can't help on cacheKey 7/8 (an upgrade to yarn 4 is the real remedy). It's cosmetic, so it isn't filed (run 26).
• Yarn 2.4.2 and 3.8.7 linker switches, and yarn classic turning off installConfig.pnp, all delete .pnp.js; only Yarn 4 leaves it (Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975, run 26).
• A hoisted workspace-member scan --mode hosted finds 0 packages and exits 0 after Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901. Only a member-owned copy, or get <uuid>, triggers redirect_workspace_lockfile_elsewhere (run 28).
• Yarn 4.18 quarantines registry versions whose packument has no time field (YN0016, "All versions … are quarantined"). Mock registries must serve time (run 28).
• Fix yarn berry project gates drifting between modes (#628, #629) #657 berry gates: a hosted scan over a mixed-EOL root package.json exits 0 with redirect_yarn_berry_mixed_line_endings, nothing written (per-package hosted refusals exit 0); hosted rollback/remove refuse it with exit 1. The rollback hint naming git checkout -- yarn.lock and the --json top-level failed: 0 are cosmetic (run 29).
• Lock-only vex in agent mode on a live PnP tree omits the package (package_not_found) whatever the nodeLinker spelling, so Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 doesn't produce a false attestation (run 30).
• remove <uuid> naming a superseded generation (A, after a re-pin or re-vendor to B) refuses with exit 1 and leaves B wired. That's correct (run 31).
• scan --mode agent over a vendored package with a newer patch published keeps the vendored generation (vendored_ownership_retained), so the remove <uuid> deletes the manifest entry but leaves the package vendored when the vendor ledger holds an older patch generation #999 manifest-B/ledger-A shape can't arise on berry this way (run 31).
• A leftover package-lock.json beside a berry yarn.lock: vendored warns vendor_multiple_lockfiles, and VEX declines with patched_ref_unattributable. Hosted pins both locks, and rollback restores all three files byte-exact (run 31).
• A hosted re-pin that reports redirect_yarn_berry_unsupported_protocol + entry_not_found against a mock means the mock's tarball leaf isn't <name>-<version>.tgz (run 31).
• A leftover pnpm-lock.yaml beside a berry yarn.lock: vendored wires pnpm (vendor_multiple_lockfiles names yarn.lock as unwired), even with packageManager: yarn@4.18.1. Same in release 4.0.0 and documented as a warning, so not filed. Hosted pins both locks and rolls back byte-exact (run 32).
• Agent-mode state under a symlinked .socket is still shared between projects (rollback in one empties the shared manifest). Guard .socket links and agent writes with one containment helper #1042 keeps it deliberately and calls it a known gap; the vendored half of Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 is fixed (run 32).
• scan --mode vendored --prune needs a patch to exist for the human path to run the GC (Human scan --mode vendored --prune silently skips the vendored GC when no remaining package has a patch, so an npm uninstalled vendored entry is never reverted (exit 0), while --json reverts it and vendor --check keeps pointing at that same command #1127, npm-owned); use --json (run 32).
• A Yarn pnpm-linker pnpmStoreFolder outside the project (../shared) shared by two projects: agent apply in one patches the other's copy. docs/ecosystems.md explicitly patches a relocated berry store that does not contain the project, so it isn't filed (run 33).
• A Make the vendored-to-hosted takeover atomic #1039 takeover retraction (redirect_takeover_kept_vendored) exits 0, also for get <uuid> --mode hosted, like every per-package hosted refusal (run 33).
• npm install --package-lock-only beside a berry yarn.lock rewrites it as a classic v1 lock, so a later hosted scan warns redirect_yarn_classic_berry_migration_risk. That's a harness artifact, not a socket-patch bug (run 34).
• Decide whether a hosted patch is pinned through lockfile discovery alone #1058's discovery-based "already pinned" decision counts berry resolutions pins (plain, merged workspace entry, catalog:, pnpm linker) as already, and migrates release-4.0.0 __archiveUrl pins (run 34).
• A SIGKILL before the takeover's journal is renamed into place (only .socket/vendor/.socket-stage-.commit-journal.json-* exists) commits nothing, and rollback unwinds the vendored state byte-exact. The stray stage file stays untracked; benign, not filed (run 35).
• After a replayed takeover journal, the orphaned .socket/vendor/npm/<uuid>/ dirs are A vendored-to-hosted takeover interrupted after its commit journal is written leaves the vendored artifact directory behind for good: recovery finishes the files but not the deferred deletions, and no GC can reclaim it once the ledger is gone #1157 (pnpm-owned, cross-PM); don't re-file them (run 35).
• A plain hosted scan (no takeover) commits without a journal by design (CLI_CONTRACT "Staged takeover"): a SIGKILL between the package.json and yarn.lock renames leaves a half-pinned pair. rollback refuses hosted_wiring_contested with a working remedy, and a re-scan heals it. Not filed (run 36).
• A SIGKILL leaves .socket-stage-<file>-<uuid> temp siblings, and journal replay doesn't remove them. The contract promises a clean tree only after a successful write; the npm routine already noted it on vendor --check and vex misreport a crashed vendored run whose commit journal is pending, because only lock-taking commands replay it #809 (run 36).
• Agent scan PATH: a member's dependency hoisted to the root node_modules is out of scope for scan packages/a (contract: in scope only if some installed copy sits under the PATH) (run 36).
• After a SIGKILL between the package.json and yarn.lock renames of a hosted rollback/remove (journal-less by design), the lock keeps an orphaned pin. The re-run refuses patched_ref_invalid, and its "re-run the hosted scan" remedy is a no-op, but a plain yarn install (or git checkout -- package.json yarn.lock) heals it. Loud, so not filed (run 37).
• Target grammar (Use one package target grammar for get, remove, rollback and the UUID shortcut #1034): rollback/remove name@version, CVE and GHSA ids select no hosted or vendored pin (documented); is next to @sindresorhus/is selects only is (the full name wins, by design); a hoisted member dependency is out of reach of rollback packages/a (path_glob_no_match, by contract) (run 37).
• A berry alias at another version (lp: npm:left-pad@1.1.3) beside a pinned ^1.3.0 doesn't block VEX or the pin (run 37).

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

Tested: main 9c43dfc (unchanged since run 21; CLI reports 4.0.0) and PR #940 head 980b7b6. Latest release 4.0.0 (its binary was used only for the #962 bisect attempt). Yarn 4.18.1 (still the newest cli-dist) and 4.0.2, on Node 22 and Linux.

Probes: none. Branch deletion is still blocked (runs 14, 19, 24), so no new probe branches were pushed. bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still need deleting by hand.

Harness (run 25, rebuilt): bin/y (cli-dist wrapper, YV=<v>); bin/mock.py <scratch> <port> <yarnBerry10c0> (batch, by-package, view with blob contents, patches/package tarball + yarn-berry-zip, .tgz route, /upstream/npm/<uuid>.json). The upstream route must return {name, version, integrity (registry sha512), yarnBerry10c0 (registry 10c0 checksum)}, or rollback fails "upstream checksum metadata names a different package". Also bin/reg.py <port> (npmjs passthrough for SOCKET_NPM_REGISTRY), bin/fx.sh <dir> portal|link|file (#939 neighbour fixture), bin/fresh.sh <bin> <src> <dst> (lock-only vex with --product, cold --immutable, copy check, post-install vex), and bin/yp.sh <bin> <yarn> rollback|remove <dir> (the #962 flow). Yarn 4.18 needs approvedGitRepositories: ["**"] for github: deps; 4.0.2 rejects that key. A root package.json without version needs vex --product.

Re-triage

Main hasn't moved. I verified PR #940 (VEX same-lock copies, Refs #939) against the #939 neighbours (see below) and commented on #939. Nothing closed.

Cells

Cell	main	PR #940
lp2 other-name file: tgz copy, node-modules (control)	fail #939	pass (patched_ref_unattributable)
Same, pnpm linker, hosted + vendored (4.18.1)	fail #939 (hosted post-install vex attests too)	pass, lock-only and post-install
lp2 = portal:../../vend/lp, hosted + vendored (4.18.1, 4.0.2)	fail #939: no warning; lock-only and post-install vex attest	still fails (commented on #939)
lp2 = link:../../vend/lp, hosted + vendored (4.18.1)	fail #939	still fails
lp2 = github:stevemao/left-pad#v1.3.0, hosted + vendored (4.18.1, 4.0.2)	fail #939 (hosted post-install declines not_applied; vendored attests)	still fails lock-only (the entry has no name; left alone)
Agent mode, portal:/link: lp2 (4.18.1)	vend/lp untouched (links into first-party source are skipped by design), apply reports already patched exit 0, vex attests. Noted on #939, not filed	n/a
Hosted pin, then the user runs yarn patch left-pad + patch-commit -s; vex / re-scan	pass: vex declines hash_mismatch; re-scan refuses (patch: wraps the descriptor), nothing written	n/a
Same, then rollback / remove (4.18.1, 4.0.2)	fail #962: exit 0 "Restored", fresh --immutable YN0028, and a mutable install re-pins the Socket URL	n/a
Same over a vendored pin: vendor --revert / rollback (4.18.1)	fail #962 (secondary): exit 1 loudly, but package.json and yarn.lock are already half-reverted, so fresh --immutable fails YN0028	n/a

Filed / commented / closed

• Filed Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962: Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962
• Commented on Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (portal/link/git neighbours on main and PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940): Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (comment)

Ruled out

• Release 4.0.0 can't be used to bisect Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962: its __archiveUrl pins make yarn's own patch-commit + install fail, and v4 rollback needs a manifest.
• The first hosted rollback failure ("upstream checksum metadata names a different package") was a mock artifact: the /upstream/npm/<uuid>.json shape was incomplete.

Next

1. Re-verify Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 once PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940 lands: also the portal/link/git rows, and the scan-warning half.
2. Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 neighbours: a yarn patch on a workspace member's copy, a patch: wrapping a vendored pin from a member, and an agent-mode re-scan after the user's patch.
3. Re-verify Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 once PR Fix npm-family restore ignoring project registry (#908, #521) #918 lands (all four registry sources, a parent-dir rc, the inverse npmScopes case).
4. Re-verify when fixes land: Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887, Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (Berry; PR Fix hosted runs from npm/yarn/bun workspace members pinning nothing (#884) #901), Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859, Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831, Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783, Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759, Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737, 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.
5. Probes (macOS/Windows) once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 21; CLI reports 4.0.0). Latest release 4.0.0, previous 3.3.0; both binaries were used to bisect #975. Yarn 4.18.1 (still the newest cli-dist), 4.0.2, 3.8.7 and 2.4.2, plus yarn 1.22.22 for one neighbour check, on Node 22 and Linux.

Probes: none. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script are still there, and deletes have been blocked since run 14.

Harness (run 26, rebuilt): bin/y (cli-dist wrapper, YV=<v>); bin/mock.py <scratch> <port> <patched 10c0> <registry 10c0> <registry sha512> (batch, by-package, view with blob contents, patches/package tarball + yarn-berry-zip, .tgz, /upstream/npm/<uuid>.json; a <scratch>/mode file set to badsha or pending makes patches/package serve a bad sha512 or pending_build); bin/reg.py <port> (npmjs passthrough for SOCKET_NPM_REGISTRY); bin/lib.sh (sp, $API, fresh <src> <dst>); bin/pnpjs.sh <yarn4> <linker> <dir> (the #975 matrix). chattr +i works in the sandbox and makes a good write-failure injector, even as root.

Re-triage

Main hasn't moved, and no new PR touches the open Berry issues. PR #963 (keep the hosted pin when a vendored takeover is refused, #853/#944) has no Berry counterpart: on main, a Berry hosted→vendored takeover that fails late already keeps the hosted pin (see the cells below). Nothing was closed.

Cells

Cell	Result
Hosted→vendored takeover, vendoring service returns a bad sha512 / pending_build (4.18.1)	pass: vendored fails loudly, and package.json/yarn.lock keep the hosted pin byte-for-byte
Write fault (chattr +i) on yarn.lock during hosted scan	exit 1 loud; package.json already pinned. A re-run heals it (exit 0, lock completed). Not filed (see below)
Write fault on package.json during hosted scan	exit 1, nothing written: pass
Write fault on yarn.lock / package.json during hosted rollback	exit 1; with yarn.lock immutable, package.json is already restored (half-unwound). Documented residual exposure (staged.rs flush_staged), not filed
Agent apply, then the user's yarn patch + patch-commit of the same file, then apply	Socket's bytes overwrite the user's edit. This is the documented default (content_mismatch_overwritten; --strict refuses), not filed
Yarn 2.4.2 vendored	refused by design (vendor_yarn_berry_cache_unsupported, cacheKey 7), nothing written. The remedy text ("remove custom compression settings") doesn't fit yarn 2/3. Noted only
Yarn 2 PnP → Yarn 4 nodeLinker: node-modules/pnpm (stale .pnp.js), 4.0.2 + 4.18.1	fail #975: agent and vendored exit 1 "Plug'n'Play", hosted pins but warns yarn_pnp_unsupported "NOT scanned". Release 3.3.0 patches the same tree, 4.0.0 refuses it. Yarn 2.4.2/3.8.7 linker switches delete .pnp.js, and so does yarn classic (no handover)

Filed / commented / closed

• Filed Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975: Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975

Ruled out

• A hosted partial write after an I/O fault: forward scan is loud and self-heals on a re-run, and the revert is the documented residual exposure.
• The agent overwrite of a user yarn patch edit is designed behaviour (CLI_CONTRACT mismatch policy).

Next

1. Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 neighbours: .pnp.cjs left behind by a crashed or interrupted switch (yarn 4 deletes it on install, so check whether any path leaves it), a stale .pnp.js in a workspace member, and vex on a Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 tree.
2. Re-verify Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 once PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940 lands (portal/link/git rows plus the scan warning).
3. Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 neighbours: a yarn patch on a workspace member's copy, and a patch: wrapping a vendored pin from a member.
4. Re-verify Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 once PR Fix npm-family restore ignoring project registry (#908, #521) #918 lands (all four registry sources, a parent-dir rc, the inverse npmScopes case).
5. Probes (macOS/Windows) once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 21; CLI reports 4.0.0) and PR #978 head 59eac7e ("Fix yarn PnP detection ignoring nodeLinker (#975, #539)"). Latest release 4.0.0. Yarn 4.18.1 (still the newest cli-dist) and 4.0.2, Node 22, Linux.

Probes: none. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still need deleting by hand.

Harness (run 27, new): bin/y, plus a shim/corepack (corepack yarn@X … → node <cli-dist X>/bin/yarn.js; sets the CA env; BH_HOME overrides HOME for yarn only). With this shim, the repo's own e2e capstones run against both trees as-is. For example, crates/socket-patch-cli/tests/e2e_vendor_yarn_berry_build.rs, copied with one .yarnrc.yml line changed, runs with cargo test --release --test <copy> -- --nocapture and SOCKET_PATCH_YARN_E2E_REQUIRED=1 SOCKET_PATCH_YARN_BERRY_VERSION=4.18.1. A PR tree builds in its own worktree with CARGO_TARGET_DIR=target-pr. A hand-staged .socket/ plus vendor --offline is enough to see which gate fires: main reaches "needs the network", while a refusal fires before that.

Re-triage

• Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 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 still reproduce on main (vendor and apply refuse a stale .pnp.js under project-rc nodeLinker: node-modules).
• PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 head: Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 fixed for vendor and apply --dry-run. 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: a lock-only PnP checkout (no nodeLinker anywhere) is now refused up front.

Cells

Cell	main 9c43dfc	PR #978 59eac7e
Stale .pnp.js + project-rc nodeLinker: node-modules (#975), vendor / apply	fail #975	pass
Lock-only, no nodeLinker anywhere (#539), vendor	vendors (then #539 on re-run)	refused up front (pass)
nodeLinker: node-modules only in ~/.yarnrc.yml, project outside $HOME, real node-modules install (repo capstone, 4.18.1)	pass (vendor, fresh --immutable, 11/11 VEX matrix, revert)	fail: exit 1 vendor_yarn_berry_unsupported "no .yarnrc.yml sets nodeLinker" (regression in the PR; commented on #539)
Same, project under $HOME	pass	pass (the ancestor walk reaches home)
YARN_RC_FILENAME=.yarnrc.ci.yml carrying the linker	pass	fail (same refusal; commented on #539)

Filed / commented / closed

• Commented on 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 with the PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 home-rc / YARN_RC_FILENAME gap: 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 (comment)
• Nothing filed (the gap exists only on an unmerged PR). Nothing closed (main unchanged).

Ruled out

• Nothing new.

Next

1. Re-verify Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975/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 once PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 (or a successor) lands: agent, vendored and hosted warning; 4.0.2 and 4.18.1; both linkers; home rc outside $HOME; YARN_RC_FILENAME; stale .pnp.js plus a home-rc linker. If the home-rc refusal ships on main, file it.
2. Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 neighbours: a stale .pnp.js in a workspace member, and vex on a Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 tree.
3. Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 neighbours: a yarn patch on a workspace member's copy.
4. Re-verify Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (PR Fix VEX attesting beside an unpatched same-lock copy (#935, #938, #939) #940) and Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 (PR Fix npm-family restore ignoring project registry (#908, #521) #918) when they land.
5. Probes (macOS/Windows) once the stale branches are deleted. Windows matters for the home-rc case (project on D: and home on C:).

[github-actions[bot]]

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

Tested: main db83f01 (33 commits past 9c43dfc, including #918 for #908, #901 for #884, #837 for #831 and #955 for #424; the CLI still reports 4.0.0, the latest release). Yarn 4.18.1 and 4.0.2 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting bughunt/yarn-berry/20260930-builtin-patch-takeover was denied again ([Git Destructive]), so both stale branches still need deleting by hand.

Harness (run 28, rebuilt): it is fully local and needs no npmjs. mkpkg.py builds synthetic lpx@1.0.0 and @acme/lp@1.0.0 tarballs (original and patched), plus git-sha256 before/after hashes and SRI. reg.py PORT mirror|default serves packuments with a time field (yarn 4.18 quarantines versions that have none, YN0016), version documents at /<name>/<ver> (the restore's checksum check needs them), and tarballs. The mirror on :8792 serves /_t/<name>/<ver>.tgz and returns 404 for /-/. The default registry on :8793 is conventional and is set as SOCKET_NPM_REGISTRY. mock.py :8790 is the patch API: batch, by-package, view, patches/package with tarball and yarn-berry-zip artifacts, the tarball route, and /upstream/npm/<uuid>.json. cell.sh YV PKG RCMODE rollback|remove runs install → bootstrap checksum → get --mode hosted → revert → byte-exact diff → cold fresh --immutable. ws.sh covers workspace members and vend.sh covers vendored mode under a .gitignore rule, with a git clone fresh checkout.

Re-triage

• Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 is closed by Fix npm-family restore ignoring project registry (#908, #521) #918. The project-rc top-level npmRegistryServer now passes (byte-exact, cold --immutable ok, 4.0.2 and 4.18.1). The other sources still fail, so I filed Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017.
• Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 still reproduces on db83f01 (4.0.2). vendor --revert in project B, through a .socket symlinked to a shared dir, exits 0 and deletes project A's tgz and state.json.
• Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (Berry) is fixed. get <uuid> --mode hosted from a member, and scan from a member that owns a copy (nmHoistingLimits: workspaces), are refused with redirect_workspace_lockfile_elsewhere, exit 1, nothing written. A hoisted member scan still finds 0 packages and exits 0 (unchanged known behaviour).
• Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Berry) is fixed. With *.tgz ignored, the vendored tgz is re-included and a git clone plus --immutable installs patched bytes (4.0.2 and 4.18.1). With vendor/ or .socket/ ignored, vendoring is refused with vendor_artifact_gitignored, exit 1, nothing written.

Cells (Linux, db83f01)

Cell	4.0.2	4.18.1
Hosted rollback, mirror as project-rc top-level npmRegistryServer	pass	pass
Same, spelled with a trailing /, an inline # comment or a CRLF rc	—	pass
Mirror via npmScopes.acme (scoped target), rollback/remove	fail #1017	fail #1017
Mirror via YARN_NPM_REGISTRY_SERVER	fail #1017 (remove)	fail #1017 (rollback, remove)
Mirror via ~/.yarnrc.yml, project outside $HOME	fail #1017	fail #1017
Mirror via a parent-directory .yarnrc.yml	fail #1017	fail #1017 (rollback, remove)
Inverse: top-level mirror, npmScopes.acme → conventional registry	—	pass
Hosted from a workspace member (get, and scan of a member-owned copy)	pass (refused)	pass (refused)
Vendored under *.tgz / vendor/ / .socket/ ignore rules	*.tgz pass	pass (refused loudly for the last two)
Shared symlinked .socket, revert from the second project	fail #887	—

Filed / commented / closed

• Filed Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017: Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017
• Nothing closed. Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908, Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 were already closed by their PRs.

Ruled out

• Vendored get refused for an ignored artifact reports top-level failed: 0, downloaded: 1 beside status: partial_failure and vendor.summary.failed: 1. Exit 1 and the error code are correct, so it isn't filed.

Next

1. Re-verify Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 once fixed: all four sources × rollback/remove × 4.0.2/4.18.1, plus YARN_NPM_SCOPES-style env scopes, and confirm upstream_registry_fallback fires when the registry is unreadable.
2. The hosted→vendored takeover followed by vendor --revert on an env/home/scoped mirror (the same restore path as Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017).
3. Re-verify Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975/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 when PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 lands, including the home-rc and YARN_RC_FILENAME cells.
4. Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 and Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 re-checks on db83f01, and scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 (fixed by Fix scan/get --json dropping apply failures (#424) #955) for Berry agent mode.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger still lists these issues as fail or open, but each was closed as completed by a PR merged on 2026-10-07: #424 (PR #955), #831 (PR #837), #884 (PR #901), #908 (PR #918). #908's fix covers only the project rc's top-level key, and #1017 tracks the npmScopes / env / user rc variants. Please re-verify them on main db83f014 and update the cells.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 05ecc6e (CLI 4.0.0, latest release 4.0.0), which now includes #940 (#939 VEX half), #657 (shared berry gates, #628/#629) and #955 (#424). Also open PR #1033 head 314038b. Yarn 4.0.2 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still exist, and earlier runs couldn't delete them.

Harness (run 29, rebuilt and fully local): mkpkg.py builds synthetic lpx@1.0.0, original and patched (a marker prepended to index.js), with git-sha256 hashes and SRI. reg.py 8793 is a conventional registry with time, version docs and tarballs. mock.py 8790 is the authenticated API: batch, by-package, patches/package with tarball + yarn-berry-zip, view with blobContent, the tarball route and /upstream/npm/<uuid>.json. It reads its 10c0 checksums from cfg.json, bootstrapped with a real yarn URL install. sp wraps the CLI with --api-url/--api-token x/--org org/--patch-server-url and SOCKET_NPM_REGISTRY. fresh DIR copies the tracked files and runs --immutable. Gotcha: fresh must not reuse a caller's shell variable (it clobbered $d once).

Re-triage

• Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 on merged main matches the run-25 PR result: the file: tgz copy is dropped (patched_ref_unattributable, exit 2). A portal: copy still attests not_affected lock-only, and no scan warns. Commented: Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (comment)
• scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 (Berry agent mode) is fixed. scan --mode agent --json with a write-faulted index.js exits 1, with apply.failed: 1 and action: failed, apply_failed.

Cells (Linux, 05ecc6e)

Cell	4.0.2	4.18.1
Hosted basic pin, fresh --immutable patched, rollback byte-exact	—	pass
#657: mixed-EOL root package.json: hosted scan refused (redirect_yarn_berry_mixed_line_endings, nothing written, exit 0); yarn install normalizes it (the remedy works)	—	pass
#657: hosted pin, then a mixed package.json: rollback/remove refuse, exit 1, nothing written	—	pass
#657: vendored→hosted takeover with a mixed package.json: refused before the vendored revert	—	pass
Hosted pin, then a member adds lpx: 1.0.0 (a separate registry entry): re-scan dead end, rollback → YN0028, lock-only vex attests	fail #1082	fail #1082
Same on PR #1033: lock-only vex drops the ref; re-scan dead end remains	fail #1082 (re-scan)	fail #1082 (re-scan)
Vendored, same member add: pin covers it (fresh --immutable patched)	pass	pass
Vendored, same member add, then vendor --revert/rollback: exit 0, fresh --immutable YN0028	fail (#759 class, commented)	fail (#759 class)
#424 Berry agent --json apply failure	—	pass (fixed)

Filed / commented / closed

• Filed Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082: Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082
• Commented on Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939 (merged-main re-check) and Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759 (a new-descriptor symptom of the verbatim restore): Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759 (comment)
• Closed: none.

Ruled out

• A hosted rollback refusal on a mixed package.json suggests "git checkout -- yarn.lock" and the --json top-level reads failed: 0 beside hosted.failed[1]. Exit 1 is correct, so both are cosmetic and not filed.
• The vendored→hosted refusal prints "server status redirect_yarn_berry_mixed_line_endings". The wording is odd but the behaviour is correct.

Next

1. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 neighbours: a transitive dependency adding lpx@~1.0.0 (not a member), the pnpm linker, remove, and PnP lock-only.
2. Re-verify Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 and the berry half of PR Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033 when they land.
3. Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 re-verification once fixed. The hosted→vendored takeover vendor --revert on env/home/scoped mirrors.
4. Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975/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 via PR Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978; Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962 re-check.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main e61a845 (CLI 4.0.0; latest release 4.0.0), which now includes #978 (the #975/#539 fix). Yarn 4.18.1 and 4.0.2 from @yarnpkg/cli-dist, on Node 22 and Linux. Release 4.0.0 (@socketsecurity/socket-patch-linux-x64-gnu) was used for the bisect.

Probes: none. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still need deleting by hand.

Harness (run 30): stage.py (stub node_modules/dummy + manifest + blob, offline), case.sh (compares real yarn config get nodeLinker with socket-patch's PnP decision for each rc/env shape) and interp.sh (real PnP install of left-pad, agent apply, lock-only vendor --offline).

Re-triage

• Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 (closed by Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978): verified fixed. A real node-modules install with a leftover .pnp.js applies and rolls back byte-exact, on 4.0.2 and 4.18.1.
• 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 (closed by Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978): verified fixed. A lock-only checkout with nodeLinker: pnp, or with it unset, is refused up front with vendor_yarn_berry_unsupported.
• The run-27 PR findings (home rc outside $HOME, YARN_RC_FILENAME): pass on main.
• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 and Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962: main hasn't touched them since run 29, so they weren't re-run.

Cells (Linux, e61a845)

Cell	yarn says	result
nodeLinker: node-modules / CRLF / home rc / YARN_RC_FILENAME + stale loader	node-modules	pass
nodeLinker: pnp / unset, live loader	pnp	pass (refused)
nodeLinker: "${L:-node-modules}"	node-modules	pass
nodeLinker: "${L:-pnp}", real PnP install, agent apply (4.18.1 ×2, 4.0.2)	pnp	fail #1100 (exit 0 package_not_installed; release 4.0.0 refuses)
nodeLinker: "${L}", L=pnp	pnp	fail #1100
Same, lock-only vendor	pnp	fail #1100 (PnP gate passes)
Quoted key / next-line value / flow map / lower-case yarn_node_linker env	node-modules	false PnP refusal (fail-closed; listed on #1100)
Agent vex on the #1100 tree	—	pass (package omitted)

Filed / commented / closed

• Filed Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100: Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100
• Closed: none (Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 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 were already closed by Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978).

Ruled out

• The hosted lock-only PnP pin under an interpolated linker installs fine under PnP (known non-bug), so the hosted side wasn't filed.

Next

1. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 neighbours: ${} in other yarnrc_scalar settings (compressionLevel, enableGlobalCache, pnpStoreFolder, npmRegistryServer).
2. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 neighbours (transitive lpx@~1.0.0, the pnpm linker, remove, PnP lock-only).
3. Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 re-verification once fixed.
4. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main ea09714 (CLI 4.0.0; latest release 4.0.0), which adds #1033 (VEX over PnP and other copies), #1035 (owned-pin generations) and #1044 (lockfile precedence table) since run 30. Yarn 4.18.1 and 4.0.2 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. The stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still need deleting by hand.

Harness (run 31): rebuilt in the scratchpad: mkpkg.py (synthetic lpx/@acme/lp, with patched v1 and v2 tgzs), reg.py <port> conv|nonconv (:8792 non-conventional mirror, :8793 conventional), mock.py (view, by-package, batch, /package filtered by uuids, /upstream/npm/<uuid>.json, /t/<uuid>/<leaf>, plus a per-uuid hidden flag driven by hide.sh A|B), and gen.sh YV MODE1 MODE2 UNDO for generation cells. Two gotchas cost time. The hosted tarball URL leaf must be <name>-<version>.tgz: hosted_url_names requires it, and otherwise the existing pin reads as a foreign http: entry (redirect_yarn_berry_unsupported_protocol). The view afterHash/beforeHash are git-blob sha256 (blob <len>\0…), and otherwise vendor fails apply_failed ("prebuilt tarball … does not carry the patched files"). A corepack shim that sets YARN_HTTPS_PROXY and the CA runs the repo's e2e suites.

Re-triage

• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (comment Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (comment)): partly fixed. The VEX half is fixed by Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033. rollback now refuses (exit 1, nothing written). The re-scan dead end remains, and the rollback remedy ("re-run scan") now loops back to it. Same on 4.0.2 and 4.18.1.
• The repo's berry e2e suites pass on 4.18.1: e2e_redirect_yarn_berry_build 15/15, e2e_yarn4_workspaces_build 19/19, e2e_yarn4_pnpm_linker_build 17/17.

Cells (Linux, ea09714)

Cell	4.0.2	4.18.1
Hosted A → hosted B re-pin, then rollback / rollback B (byte-exact, fresh immutable unpatched)	pass	pass
Vendored A → hosted B (takeover), then remove B / rollback	pass	pass
Hosted A → vendored B, then vendor --revert / remove B / rollback	pass	pass
Vendored A → vendored B, then --revert	pass	pass
remove <superseded uuid A> after a move to B	—	refused, exit 1, B left wired (correct)
Vendored A, then scan --mode agent with B published	—	vendored_ownership_retained (by design)
Leftover package-lock.json, hosted (both locks pinned; rollback restores all 3 files byte-exact)	—	pass
Leftover package-lock.json, vendored (vendor_multiple_lockfiles warning; VEX declines via patched_ref_unattributable; revert byte-exact)	—	pass
npmRegistryServer: "${REG:-<mirror>}", hosted rollback/remove	fail (remove)	fail (rollback ×2, remove). Warns upstream_registry_fallback, writes a bare locator, cold --immutable YN0035. Commented on #1017
compressionLevel: "${CL:-0}"	false refusal (hosted exit 0, vendored exit 1)	same. Commented on #1100

Filed / commented / closed

• Filed: none.
• Commented: Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (re-triage), Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 (${} mirror, Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 (comment)), Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 (${} compressionLevel, Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 (comment)).
• Closed: none.

Ruled out

• The A→B "re-pin skipped" result (unsupported_protocol + entry_not_found) came from the mock's tarball leaf. It passes once the leaf is lpx-1.0.0.tgz.
• The vendored apply_failed result came from the mock's plain-sha256 hashes.
• Leftover package-lock.json is a documented vendor_multiple_lockfiles warning, not a bug.

Next

1. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 / Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours: pnpmStoreFolder: "${X:-…}" (agent, Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859 class) and npmScopes values with ${}.
2. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 neighbours (transitive lpx@~1.0.0, pnpm linker, PnP lock-only), plus a re-verify once a fix lands.
3. Re-verify Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017, Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962, Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939, Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887, Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859, Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783, Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759, Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737 when fixes land.
4. Leftover pnpm-lock.yaml in a berry project (pnpm wins the precedence table): check that vendored warns, and that hosted rewrites both locks and rolls back byte-exact.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main e2d9633 (CLI 4.0.0; latest release 4.0.0), which adds #1029 (apply --check verifies agent patches, per-purl hosted JSON), #1045 (PurlKey), #1050 (vendored GC liveness via discovery) and #1057 (yarn.lock grammar moved into formats/yarn, berry rewrite/restore on a shared stanza view) since run 31. Bisect build: ea09714. Yarn 4.18.1, 4.0.2, 3.8.7 and 2.4.2 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none (still blocked; the stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script need deleting by hand).

Harness (run 32): bin/y, mock.py (:8790, left-pad), generic mock2.py (:8791) fed by mkpatch.sh NAME VER UUID (patched tgz, bootstrapped 10c0, registry sha512; add regck with a 10c0/ prefix by hand, because the /upstream/npm/<uuid>.json route must carry yarnBerry10c0 or rollback refuses), and reg.py (:8793 npmjs passthrough for SOCKET_NPM_REGISTRY).

Re-triage

• Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 (Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887 (comment)): fixed by Guard .socket links and agent writes with one containment helper #1042, closed. A symlinked .socket is refused up front (vendor_dir_symlink_unsupported). Unwinding release-4.0.0 state (vendor --revert, rollback, remove) exits 1 and deletes nothing. The agent half stays shared on purpose (Guard .socket links and agent writes with one containment helper #1042 calls it a known gap).
• Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783: still fails on e2d9633 (4.18.1; vendored adds a bare left-pad pin beside pkg-a/left-pad, fresh --immutable YN0028). No comment.
• Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737: still fails (nan 2.22.2; vendored fresh --immutable and hosted hardened YN0028, node-gyp subtree kept). No comment.

Cells (Linux, e2d9633)

Cell	Result
#1050 scan --mode vendored --prune --json on live vendored entries: root, workspace member, catalog:, pnpm linker, CRLF lock, 4.0.2	pass (nothing reverted; vendor --check ok)
#1057 hosted pin + fresh immutable + rollback: plain, CRLF lock + package.json	pass (byte-exact)
BOM / no-trailing-newline lock	control fails --immutable on its own (known non-bug)
Vendored on CRLF lock, --revert	pass (byte-exact)
Yarn 3.8.7 / 2.4.2 cacheKey gates after #1057	pass (refused, nothing written)
#1029 agent apply --check: patched, reinstalled (drift → exit 1), nmHoistingLimits 2 copies + one reverted (exit 1), version mix 1.2.0/1.3.0, pnpm linker, PnP (fail-closed)	pass
#1029 hosted JSON for an alias-only entry (unpinned / redirect_unconfirmed row plus alias warning)	pass
Interpolated pnpmStoreFolder: "${STORE:-node_modules/.store}", transitive dep, agent	pass
Leftover pnpm-lock.yaml (with and without packageManager: yarn@4.18.1)	vendored wires pnpm with vendor_multiple_lockfiles (same in 4.0.0, documented); hosted pins both, rollback byte-exact
uuid bin: vendored + --revert (4.0.2, 4.18.1)	pass
uuid / prettier hosted rollback, remove, takeover + vendor --revert	fail #1131: restore keeps the tarball bin: (./dist/bin/uuid), hardened --immutable YN0028 (4.0.2, 4.18.1; also ea09714; release 4.0.0 not affected)

Filed / commented / closed

• Filed: Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131
• Commented and closed: Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887.

Ruled out

• A single CRLF rollback exit 1 didn't reproduce in three re-runs (byte-exact each time).
• uuid rollback "no valid upstream Berry checksum" was the mock missing yarnBerry10c0; a bare-hex regck (from a 4.0.2 lock) fails the same way.
• The leftover pnpm-lock.yaml routing is a documented warning, unchanged since 4.0.0.

Next

1. Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours (other Fix yarn berry pin entry rendering (#697, #718) #719-rendered fields, scoped ./ bin, pnpm linker), then re-verify when fixed.
2. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 / Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours: npmScopes values with ${}.
3. Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 neighbours (transitive lpx@~1.0.0, pnpm linker, PnP lock-only).
4. Re-verify Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017, Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962, Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939, Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859, Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783, Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759, Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737 when fixes land.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

[agent] Janitor: drift. These cells still say fail for closed issues: #539 (PnP lock-only, 4.0.2 row; closed as completed 2026-10-08 by #978), #975 (run 26/27 rows; closed by #978, and your run-30 row already says fixed) and #887 (shared symlinked .socket; closed as completed 2026-10-08 13:08Z after your re-triage on e2d9633).

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main cf8b164 (CLI 4.0.0; latest release 4.0.0, previous 3.3.0). Since run 32 (e2d9633) main adds #1039 (staged, atomic vendored→hosted takeover; the berry takeover pre-gates are deleted), #1117 (BOM strips via formats::text) and non-npm changes. Yarn 4.18.1 (still latest) and 4.0.2 from @yarnpkg/cli-dist, Node 22, Linux.

Probes: none. Deleting the stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script was again denied by the session permission policy; they still need deleting by hand.

Re-triage

• Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100: still fails on cf8b164 (nodeLinker: "${L:-pnp}", live PnP install, apply exit 0 package_not_installed). Nothing new, no comment.
• Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 and the other open berry issues: no commit since run 32 touches their code paths; not re-run.

Cells (Linux, cf8b164), focus #1039

Cell	Result
Takeover dry run, one purl retracted (no yarnBerry10c0)	pass (tree byte-identical, would_revert + kept_vendored)
Takeover wet, partial retraction (either package), LF and CRLF	pass (refused purl stays vendored byte for byte; other pinned; CRLF kept; fresh --immutable plain + hardened patched)
Takeover, all retracted	pass (byte-identical)
Workspaces (member ^1.3.0 + 1.3.0), partial retraction	pass (both selectors pinned, fresh immutable)
get <uuid> --mode hosted over a vendored package (kept / migrated)	pass
compressionLevel: mixed after vendoring	pass (both kept vendored, nothing written)
PnP switch after vendoring	pass (pins + yarn_pnp_unsupported; PnP fresh + hardened loads patched)
Alias lp: npm:left-pad@1.3.0 added after vendoring	documented redirect_yarn_berry_alias_skipped
Write fault (chattr +i yarn.lock / package.json / .socket/vendor/state.json), with and without a takeover	pass (exit 1, "nothing was changed", tree identical)
Rollback after a partial takeover (hosted + vendored mix), 4.18.1 CRLF and 4.0.2	pass (4.0.2 byte-exact with bare hex; .socket/vendor removed)
vex / scan --vex over a partial takeover	pass
pnpmStoreFolder: ../shared shared by two projects, agent apply	patches the other project's copy too; documented (relocated berry store not containing the project is patched as usual), not filed

Filed / commented / closed

None. No new bug met the filing bar.

Ruled out

• A workspace takeover "YN0028" was the harness: the fresh-checkout copy lacked packages/.
• A CRLF "left-pad not vendored" was the mock serving no yarn-berry-zip artifact at vendor time (vendored needs it).
• The repo's mode_migration_npm berry takeover test can't run in the sandbox (its in-process reqwest to registry.npmjs.org fails TLS through the proxy).

Next

1. Make the vendored-to-hosted takeover atomic #1039 neighbours: SIGKILL during the journaled takeover commit, pnpm linker, catalog: dep retraction, a retraction caused by a user resolutions entry added after vendoring.
2. Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours (scoped ./ bin, pnpm linker), then re-verify when fixed.
3. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100 / Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours (npmScopes with ${}).
4. Re-verify Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017, Yarn berry hosted rollback/remove report success after a user yarn patch of the pinned package, but leave a lock that every yarn install --immutable rejects (YN0028); the next install re-pins the Socket tarball #962, Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939, Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859, Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783, Vendored yarn berry revert restores the pre-vendor lock entry verbatim, so after upgrading from yarn 4.0.x it writes back a bare-hex checksum and every yarn install --immutable fails YN0028 #759, Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737, Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 when fixes land.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main 03b9418 (CLI 4.0.0; latest release 4.0.0, previous 3.3.0). Since run 33 (cf8b164), main adds #1058 (hosted "already pinned" now decided by lockfile discovery only, plus the new redirect_unattributable attribution gate), #1147 (vendored revert of a removed dependency), #1085, #1030, #1031 (removes scan --apply/--vendor and get --no-apply), #1027 (--json errors are {code, message}) and the rollback/hosted_unwind refactor. Yarn 4.18.1 (still the latest) and 4.0.2 from @yarnpkg/cli-dist, Node 22, Linux.

Probes: none. Deleting the stale branches bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script failed again (send-pack: unexpected disconnect). They still need deleting by hand.

Re-triage

• Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131: still fails on 03b9418 (uuid@9.0.1: rollback restores uuid: ./dist/bin/uuid, and a hardened fresh --immutable hits YN0028). No comment.
• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082: unchanged (re-scan prints the redirect_yarn_berry_ambiguous_entry "dedupe" remedy, nothing written). No comment.
• Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100: no berry gate change since run 33 (only the BOM helper). Not re-run.

Cells (Linux, 03b9418, 4.18.1 unless noted)

Cell	Result
#1058 hosted pin + re-scan (already counted, nothing rewritten) + fresh plain/hardened --immutable + rollback byte-exact: workspaces (merged ^1.3.0/1.3.0 + scoped member dep), catalog: default + named, transitive + npm: alias of another version, pnpm linker	pass
Leftover package-lock.json / pnpm-lock.yaml beside the berry lock: pin, re-scan already, rollback byte-exact (.npmrc removed)	pass
Legacy release-4.0.0 __archiveUrl pins (root, workspaces, transitive) re-scanned by main: migrated to the resolutions pin, fresh hardened patched; rollback byte-exact both before and after the migration	pass
Vendored, then yarn remove one package: vendor --check names it (exit 1), scan --vendored --prune, vendor --revert, rollback, remove <uuid> retire it, --immutable passes	pass
Hosted, then yarn remove (4.0.2, 4.18.1) or yarn up to an unpatched version	fail #1203 (leftover resolutions selector → rollback/list/remove exit 1 forever with hosted_wiring_contested; the remedy scan is a no-op; release 4.0.0 not affected)

Filed / commented / closed

• Filed After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 (After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203) and commented with the yarn up variant.

Ruled out

• A lo-npm "classic migration risk" warning plus a non-byte-exact rollback came from the harness: npm install --package-lock-only rewrites an existing yarn.lock as classic v1. With the berry lock restored, the cell passes.
• npm_manifest_unavailable ("hosted tarball does not match its published sha512") for uuid came from the mock: packages with bin need the real sha512 of the patched tgz in the tarball artifact.

Next

1. After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 neighbours: removal from a workspace member while another member keeps the dep, a catalog: dep removed, yarn remove of a scoped package; re-verify when fixed (rollback, remove, list, --prune).
2. Decide whether a hosted patch is pinned through lockfile discovery alone #1058 gate (redirect_unattributable) on berry shapes: portal:/link: lp2 copies (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939), member-level registry copies, takeover + gate.
3. Make the vendored-to-hosted takeover atomic #1039 neighbours (SIGKILL during the takeover commit, pnpm linker, catalog: retraction).
4. Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours (scoped ./ bin, pnpm linker); Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100/Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main f3c6313 (CLI 4.0.0; latest release 4.0.0, previous 3.3.0). Since run 34 (03b9418), main adds #1008 (the npm open-issue batch, including the npm-family vendor backends refactored onto one generic driver (#920/#922; yarn_berry_lock.rs now runs through vendor_npm_family), "keep an older vendored patch only while its wiring is still live", and the #898/#1005 failed-commit reporting) plus #1191 BOM helpers. Yarn 4.18.1 (still the latest) and 4.0.2 from @yarnpkg/cli-dist, Node 22, Linux.

Probes: none (the stale probe branches still need deleting by hand; see the backlog).

Re-triage

• Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737 (nan, implicit node-gyp: "npm:latest"): still fails on f3c6313. Vendored fresh --immutable hits YN0028. No comment.
• Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 (parent-scoped pkg-a/left-pad resolution): still fails. Vendored adds a bare left-pad pin, and fresh --immutable hits YN0028. No comment.

Cells (Linux, f3c6313)

Cell	Result
Repo berry e2e suites (vendor, redirect, workspaces, pnpm linker, PnP safety) on 4.18.1 (187/187) and 4.0.2 (147/147)	pass
Refactored vendored driver, two packages: node-modules (--revert), pnpm linker (rollback), 4.0.2 (remove <uuid> ×2), workspaces, catalog: default + named. Fresh cold --immutable is patched, vendor --check passes, and the unwind is byte-exact	pass
Write fault (chattr +i) on yarn.lock / package.json during vendor: exit 1, both failed vendor_commit_failed, nothing written, no artifacts or ledger left (#898/#1005)	pass
Write fault on yarn.lock during vendor --revert / rollback / remove: exit 1, wiring intact, --check passes, retry is byte-exact	pass
Vendored generation A→B (manifest swap, vendor): vendor_stale_artifact_removed, fresh install loads B, --revert byte-exact (4.18.1, 4.0.2)	pass
Hosted→vendored takeover via vendor, then vendor --revert lands on the pristine registry lock (4.18.1, 4.0.2 bare hex)	pass
#1039 neighbours: vendored→hosted takeover with one purl retracted (redirect_yarn_berry_missing_checksum → redirect_takeover_kept_vendored) on the pnpm linker and on catalog: deps. Fresh install patched, rollback pristine	pass
SIGKILL during the vendored→hosted takeover commit, then rollback	fail #1241: killed after the journal is durable but before any file is replaced, the next rollback replays the journal and exits 0 having restored nothing (hosted pins left). remove says "No patch found". 4.18.1 and 4.0.2. Kills elsewhere in the window recover correctly; a second rollback restores the project

Filed / commented / closed

• Filed After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 (After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241). It's cross-PM CLI ordering: rollback.rs/remove.rs discover hosted pins before acquire_or_emit replays the journal.

Ruled out

• An early SIGKILL loop "showed" rollback misbehaving, but kill -9 $! on a shell function only kills the wrapper subshell; the binary kept running. Exec the binary directly.
• A kill before the journal is renamed into place (only .socket-stage-.commit-journal.json-* exists) isn't a bug: nothing was committed, and rollback unwinds the vendored state byte-exact. The stray stage file stays untracked under .socket/vendor/. It's benign, so not filed.
• Orphaned .socket/vendor/npm/<uuid>/ dirs after a journal replay are A vendored-to-hosted takeover interrupted after its commit journal is written leaves the vendored artifact directory behind for good: recovery finishes the files but not the deferred deletions, and no GC can reclaim it once the ledger is gone #1157 (pnpm), not re-filed.

Next

1. Re-verify After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 when fixed (rollback and remove after a replayed takeover journal; 4.0.2 and 4.18.1), and check list/repair in the same state.
2. After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 neighbours (member-level removal, catalog:, scoped); Decide whether a hosted patch is pinned through lockfile discovery alone #1058 redirect_unattributable gate on portal:/link: copies.
3. Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours (scoped ./ bin, pnpm linker); Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100/Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours.
4. Vendored-driver refactor follow-ups: repair of a deleted tgz, vendor --dry-run parity, CRLF lock + package.json through the new driver.
5. Probes on macOS/Windows once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main a80b89e (CLI 4.0.0; latest release 4.0.0, previous 3.3.0). Since run 35 (f3c6313), main adds #1007 (15 pnpm fixes, including the shared npm-family upstream restore and the agent scan PATH copy scoping, #778), #1041 (org resolved once per run), #1227 (line_endings::terminator in vendored writers; berry's block_eol fallback now uses the majority rule), plus non-npm fixes. I used yarn 4.18.1 from @yarnpkg/cli-dist, Node 22, on Linux.

Probes: none. Deleting the stale probe branches was denied again by the session permission policy, so they still need deleting by hand.

Re-triage

• After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203: still fails (after yarn remove, rollback exits 1 with hosted_wiring_contested and the hosted re-scan is a no-op). list now exits 0 with "No patches". No comment.
• Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131: still fails (uuid bin: ./dist/bin/uuid is kept, so hardened --immutable hits YN0028). No comment.
• After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241: closed by a maintainer at 07:50 with no fix commit (the only reference is the run-35 ledger commit). It still fails on a80b89e and is now deterministic. Commented: After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 (comment)

Cells (Linux, a80b89e, 4.18.1)

Cell	Result
Agent scan --mode agent packages/a in a berry workspace: pnpm linker (member link) / node-modules (hoisted to the root)	pass / out of scope by contract
nmMode: hardlinks-local + nmHoistingLimits: workspaces: apply patches all 3 copies; rollback packages/a restores all 3 with out_of_scope_copies_restored; unscoped rollback	pass
Vendored driver: scan --mode vendored --dry-run writes nothing; repair redownloads a deleted tgz (--check 1 → 0); CRLF yarn.lock; fresh cold --immutable (plain and hardened) is patched; --revert / rollback byte-exact	pass
Vendored→hosted takeover SIGKILLed at the package.json / yarn.lock rename (LD_PRELOAD shim), then rollback	fail #1241: exit 0 with nothing restored, or exit 1 hosted_wiring_contested; hosted-pinned either way. remove <uuid> reports "No patch found"
Hosted→vendored takeover SIGKILLed at the package.json / yarn.lock / state.json rename, then rollback	fail (#1241 root cause, commented): either a false Cannot restore … no hosted wiring exit 1 after the replay, or a pre-lock refusal (orphaned resolutions; "vendor ledger is missing, restore state.json from version control", a file that was never committed) that never replays the journal
First vendoring SIGKILLed at the yarn.lock / state.json rename, then rollback	fail: pre-lock "ledger missing" refusal, and the journal stays pending (commented on #809: #809 (comment))
Plain hosted scan SIGKILLed between the package.json and yarn.lock renames	half-pinned. No journal by design; rollback refuses with a working remedy and a re-scan heals it (not filed)

Filed / commented / closed

• No new issues. Commented on After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 (still open in substance, both takeover directions) and on vendor --check and vex misreport a crashed vendored run whose commit journal is pending, because only lock-taking commands replay it #809 (rollback doesn't replay either).

Ruled out

• Hoisted member deps under agent scan PATH: out of scope by contract.
• A crash in a non-takeover hosted commit: journal-less by design.
• .socket-stage-* litter after a SIGKILL: already noted on vendor --check and vex misreport a crashed vendored run whose commit journal is pending, because only lock-taking commands replay it #809.

Next

1. Re-verify After a vendored-to-hosted takeover is interrupted once its commit journal is written, the next rollback replays the journal, then exits 0 having restored nothing, and the project stays hosted-patched (remove says "No patch found") #1241 (both takeover directions, plus the first-vendoring rollback) when a fix lands, using the rename shim. Also try vendor --revert and repair from each kill point.
2. Shim-driven kills during unwinds: vendor --revert, rollback and remove killed mid-commit on berry, then re-run.
3. After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 neighbours (member-level removal, catalog:, scoped); Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours (scoped ./ bin, pnpm linker).
4. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100/Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours; 4.0.2 legs of this run's cells.
5. macOS/Windows probes once the stale branches are deleted.

[github-actions[bot]]

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

Tested: main 9ab72d4 (CLI 5.0.0; chore(release): 5.0.0 has merged, but npm still has 4.0.0 as the latest published release). Since run 36 (a80b89e), main adds #1180 (yarn npm: alias copies no longer count as pinned; #1081/#1158), #1034 (one target grammar for get/remove/rollback), #989 (vendored reverts finish through one shared step), #1277 (BOM handling), #1262 (VEX writes through the stage + rename writer) and the 5.0.0 release. I used yarn 2.4.2, 3.8.7, 4.0.2 and 4.18.1 from @yarnpkg/cli-dist, Node 22, on Linux. Note: main was force-pushed, so the clone is shallow; run git fetch --deepen=400 to reach older SHAs.

Probes: none (the stale probe branches still need deleting by hand).

Re-triage

• Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 (vendored with a parent-scoped pkg-a/left-pad resolution): still fails YN0028 on 4.18.1. No comment.
• Yarn berry vendored and hosted pins of native-addon packages (nan, bufferutil, utf-8-validate, node-addon-api) keep the registry entry's implicit node-gyp: "npm:latest" dependency, so vendored installs and hardened hosted installs fail YN0028 #737 (vendored nan, implicit node-gyp: npm:latest): still fails YN0028. No comment.
• Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 (YARN_NPM_REGISTRY_SERVER mirror, then rollback): still drops ::__archiveUrl=. No comment.
• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 point 2 has regressed: rollback/remove exit 0 again and fresh --immutable fails YN0028, on 4.0.2 and 4.18.1. Bisected to f3c6313a (Fix open npm issues #1008; parent b17a114a is good, and run 31's ea09714 refused). The npm: alias variant and the vendored alias variant fail the same way. Commented: Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (comment)

Cells (Linux, 9ab72d4)

Cell	Result
Hosted + vendored basic (left-pad + ms), 4.0.2 and 4.18.1: pin, fresh --immutable patched, rollback byte-exact	pass
#1180 on berry: hosted pin, then yarn add lp@npm:left-pad@1.3.0; scan --mode hosted --vex, standalone vex	pass (alias copy warned, nothing attested)
#1180: alias at another version (lp/@x/lp → npm:left-pad@1.1.3) beside a pinned ^1.3.0	pass (in-run VEX attests; fresh patched)
Vendored → hosted takeover with an alias added after vendoring	pass (alias warned, no retraction needed: the alias block was never vendored)
#1034 target grammar, hosted and vendored rollback/remove: name, upper-case name, versionless purl, versioned purl, uuid (also upper-case), @scope/name, is beside @sindresorhus/is (full name wins, by design)	pass. name@version, CVE and GHSA select nothing (documented)
get <name> / get <uuid> / get pkg:npm/x@v → hosted pin	pass. A versionless purl is sent to the API verbatim; the mock has no versionless route, so this is unverified
#989 vendored unwinds: vendor --revert, rollback, remove <name>, rollback <name>, remove <uuid> with two vendored packages	pass (the others are kept; fresh --immutable correct)
SIGKILL (rename shim) during vendored vendor --revert/rollback/remove at the package.json / 2nd yarn.lock / state.json renames, then re-run	pass (re-run completes; pristine and byte-exact). Stage-file litter only (#809)
SIGKILL during hosted rollback/remove between the package.json and yarn.lock renames	half-unwound: the re-run refuses patched_ref_invalid (orphaned lock pin), and the printed "re-run the hosted scan" remedy is a no-op. yarn install heals it. Known journal-less residual (not filed)
BOM'd .yarnrc.yml (nodeLinker: pnp, LF/CRLF) lock-only vendored	pass (refused as PnP)
BOM'd .yarnrc.yml with nodeLinker: node-modules, lock-only vendored + revert	pass
BOM'd project-rc npmRegistryServer (non-conventional mirror), hosted rollback	pass (byte-exact ::__archiveUrl=)
Path-scoped rollback packages/a (hosted and vendored) on workspaces: pnpm linker / node-modules (hoisted)	pass / path_glob_no_match exit 1 (contract: hoisted copy is not under the path)
Yarn 3.8.7 and 2.4.2: hosted/vendored refusal (nothing written), agent apply + rollback	pass
Hosted pin, then a member left-pad@1.3.0 or an alias lp: npm:left-pad@1.3.0, then rollback / remove left-pad	fail (#1082 regression, commented)
Vendored, then lp: npm:left-pad@1.3.0, then vendor --revert / rollback / remove left-pad	fail (same unmerged-block cause; on #1082, #759 class)

Filed / commented / closed

• No new issues. Commented on Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 (regression bisected to f3c6313a).

Ruled out

• The rollback hint "use ./left-pad@1.3.0" for name@version: the grammar has no name@version (documented).
• rollback is choosing is over @sindresorhus/is: the full name beats a last-segment match by design (utils/target.rs).
• Hoisted member deps under rollback packages/a: out of scope by contract (the wording "patches for uninstalled packages" is a bit misleading).
• An upper-case UUID passed to get reaches the API unchanged; my mock is case-sensitive, so this isn't confirmed against the real API (cross-PM if real).

Next

1. Re-verify Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 when a fix lands: plain member, root/member alias, remove, vendored alias revert; 4.0.2 and 4.18.1. Other npm hosted pin next to a bundled copy can't be unwound: rollback/remove refuse it, and the vendored takeover skips the restore, so vendor --revert lands back on hosted and allow-remote=all stays #828 shadowed shapes on berry: a file:/portal: sibling block (Yarn berry hosted and vendored scans miss a file:/URL copy of the patched package locked under another dependency name, so lockfile VEX (and vendored VEX after install) attests not_affected while that copy installs unpatched #939), plus the hosted→vendored takeover over a shadowed berry pin.
2. Kill hosted rollback mid-commit with three or more pins (the lock written first?), and a hosted→vendored takeover killed mid-unwind.
3. After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203 neighbours (member-level removal, catalog:, scoped); Hosted yarn berry rollback/remove keep the pin's tarball-form bin: paths (./dist/bin/uuid) on the restored npm: entry, so hardened yarn install --immutable fails YN0028 for packages like uuid and prettier #1131 neighbours.
4. Yarn berry PnP refusal misses a live Plug'n'Play project whose .yarnrc.yml sets nodeLinker through ${VAR} interpolation: agent apply exits 0 "not installed" and lock-only vendor passes the PnP gate (regression from #978) #1100/Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 interpolation neighbours.
5. macOS/Windows probes once the stale branches are deleted.