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-06 (run 24), main 9c43dfc (unchanged since run 21; CLI still reports 4.0.0), latest release 4.0.0 (previous 3.3.0). Run 23 also 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 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 (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

1. Blocked on a maintainer: probe-branch deletes fail (runs 10–13, 20 and 21: 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).
2. Re-verify when fixes land: 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), 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 (draft PR Fix npm-family restore ignoring project registry (#908, #521) #918 fixes only the project-rc top-level key; re-check all four registry sources (project rc, npmScopes, env, home rc) plus a parent-dir rc and the takeover + vendor --revert path), 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 and agent), 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), 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 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), 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: 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.
3. 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 neighbours (run 23 covered npmScopes, env, home and the path-base mirror): left are a parent-directory .yarnrc.yml, and the inverse case (top-level mirror, npmScopes pointing a scope at npmjs) on PR Fix npm-family restore ignoring project registry (#908, #521) #918.
   3b. 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: a git/github: copy under another name, a portal:/link: to an unpatched checkout of the same version, and the pnpm linker.
4. 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.
5. 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.
6. 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 follow-ups once fixed: the <uuid>/.gitignore !* re-include under *.tgz, and the hosted→vendored takeover under an ignore rule.
7. Global (-g) on macOS/Windows, and a version-manager prefix (nvm/volta). Full checklist in the 20261001T040000Z entry.
8. 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.
9. 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.

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

[github-actions[bot]]

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Probe

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

False positives ruled out

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

Probe

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

Next

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

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Yarn Berry (2+) version and on Linux, macOS and Windows.

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

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Yarn Berry (2+) package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Yarn Berry (2+) project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Yarn Berry (2+) version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

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

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

Re-triage

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

Cells (global mode)

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

Observations not filed

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

Probe branches

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Ruled out

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

Harness notes

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

Next

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

[github-actions[bot]]

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

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

[github-actions[bot]]

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

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

Re-triage

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

Handover from yarn-classic (#519)

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

Cells (Linux)

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

Ruled out

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

Unconfirmed lead (not filed)

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Filed

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

Cells (Linux)

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

Ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Filed

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

Cells (Linux, all pass unless noted)

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

Ruled out

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

Next

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

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

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

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

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 203e092b on the next run:

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

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

---

Generated by Claude Code

[github-actions[bot]]

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

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

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

---

Generated by Claude Code

[github-actions[bot]]

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

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

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

Re-triage

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

Cells (Linux, all pass unless noted)

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

Filed

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

Ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells (Linux)

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

Filed / commented

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

Ruled out

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

Next

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

[github-actions[bot]]

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

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

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

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

Re-triage

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

Cells (Linux, node-modules linker unless noted)

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

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

Filed / commented / closed

None.

Ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Harness: I rebuilt it from scratch.

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

Re-triage

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

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

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

Filed / commented

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

Ruled out

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

Next

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

[github-actions[bot]]

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

Tested: main 045d7ec, unchanged since run 10; the CLI reports 4.0.0, the latest release. Release 4.0.0 from npm was used for the regression check. Yarn 4.0.2, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. git push origin --delete of the two stale bughunt/yarn-berry/* branches failed again (send-pack: unexpected disconnect).

Harness: rebuilt as mkpatch.sh (npm pack, a marker prepended to one file, and a 10c0 bootstrap via resolutions: file:) plus a Python mock serving batch, by-package, patches/package (tarball + yarn-berry-zip), view and the tarball route. A run.sh script does scan, commit, then a fresh clone running yarn install --immutable with YARN_ENABLE_HARDENED_MODE 0 and 1. New check worth keeping: run every fresh install in hardened mode too (hardened mode implies --refresh-lockfile).

Re-triage

• 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, 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, 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 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 are still open, and main hasn't changed since they last reproduced, so I didn't re-run them.

Cells

• Packages whose tarball bin: differs from the registry metadata (./dist/bin/uuid vs dist/bin/uuid): fail, filed 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. Both pins copy the registry entry's body. Yarn re-reads the tarball manifest for tarball-URL and file: locators, so the lock diverges.
  • Vendored: every fresh --immutable install fails YN0028.
  • Hosted: a plain --immutable install passes, but hardened mode or --refresh-lockfile fails YN0028.
  • Reproduced on uuid@9.0.1 (yarn 4.0.2, 4.12.0, 4.18.1) and acorn@8.11.3 (4.18.1).
  • The hosted half is a regression from Fix yarn berry hosted pin leaking npm auth (#404) #465: release 4.0.0's ::__archiveUrl pin passes a hardened fresh install with patched bytes. Release 4.0.0's vendor flow couldn't be driven against the mock.
• A survey of 20 bin packages found 6 with a registry/tarball bin: mismatch: uuid, nanoid, acorn, rimraf, node-gyp-build and typescript (typescript is refused anyway as a builtin patch). left-pad, semver, js-yaml, which, mkdirp, json5, he, esprima and others match.

Filed / commented / closed

• Filed 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: 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

Ruled out

• A hosted pin with a mismatched bin: under a plain (non-hardened) --immutable install, or a later mutable yarn install: passes and leaves the lock untouched. Yarn trusts locked tarball entries unless it refreshes them.

Next

1. Re-verify 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 once it's fixed, plus the dependency-map variant: a package whose registry dependencies/optionalDependencies differ from its tarball package.json. Use the cmp.sh-style survey: install via npm: and via a tarball-URL resolutions, then diff the entry bodies.
2. Run hardened-mode fresh installs on the earlier passing cells (workspaces, scoped, packageExtensions, catalog: 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).
3. Re-verify Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697, 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, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 (after Share rollback artifact retention across remove and rollback #600) and 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.
4. Probes (macOS/Windows: CRLF resolutions pin, 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, Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697) once the stale branches are deleted.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the CLI reports 4.0.0, the latest release). Release 4.0.0 from npm was used for the regression check, and PR #719's head 635ca29 was built in a worktree. Yarn 4.0.2, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. git push origin --delete is now denied by the session permission policy, so I opened no probe branches (each would need deleting). The two stale bughunt/yarn-berry/* branches still need deleting by hand.

Harness: rebuilt from scratch in about 150 lines: y (cli-dist wrapper), mkpatch.py, mock.py (batch, by-package, view with blobContent, package grant, tarball route, /upstream/npm/<uuid>.json, /registry/ passthrough), addorig.py (fills the original checksum and integrity for rollback) and run.sh (scan, commit, then fresh clone --immutable with hardened 0 and 1). Gotcha: the mock must unquote by-package purls repeatedly, because a scoped purl arrives as %2540. Otherwise the scoped patch silently drops out of the mock's results (a mock artifact, not a CLI bug). New tool: survey.py, which installs a set of packages via npm: and via a registry tarball-URL resolutions entry and diffs the lock entry bodies. It finds #718/#737-class candidates fast.

Re-triage

• main hasn't changed, so 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's siblings (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, 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, 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, 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, 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) are still open and weren't re-run on main.
• 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/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: the fix PR Fix yarn berry pin entry rendering (#697, #718) #719 is open. Its head fixes neither the bin: survey's new examples (not re-run) nor the dependency variant (see below).

Cells

• Native-addon packages (implicit node-gyp: "npm:latest" in the registry entry): fail, filed 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 fails every fresh --immutable install. Hosted passes a plain --immutable install but fails hardened. Reproduced on nan@2.22.0 (4.0.2, 4.12.0, 4.18.1) and bufferutil@4.0.8 (4.12.0), and still fails on PR Fix yarn berry pin entry rendering (#697, #718) #719's head. The hosted half is a regression from Fix yarn berry hosted pin leaking npm auth (#404) #465: release 4.0.0 passes hardened with patched bytes. The survey also found node-addon-api, utf-8-validate, microtime, iconv and ref-napi; bindings and deasync are not affected.
• bin: survey (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 class): nodemon, jest, eslint, prettier, next, mocha, karma, puppeteer and node-pre-gyp have ./-prefixed tarball bins (commented on 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). npm@6 also differs (bundled deps), which isn't relevant here.
• Workspaces (root + 2 members, ^1.3.0 and 1.3.0 merged entry, scoped @sindresorhus/is in root and member) × node-modules and pnpm linkers × hosted and vendored: pass, with fresh --immutable passing plain and hardened, and patched bytes in both packages.
• Patched packages that declare peerDependencies (fdir: optional peer; use-sync-external-store with react): pass in hosted and vendored, plain and hardened.
• Hosted rollback of the nan pin (with /upstream and the registry passthrough): pass, byte-exact.

Filed / commented / closed

• Filed 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 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
• Commented on 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 (the dependency variant isn't covered by Fix yarn berry pin entry rendering (#697, #718) #719, plus the wider bin: survey): 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 (comment)

Ruled out

• The scoped package missing from the workspace scan was a mock purl-decoding artifact. It passes with the fixed mock.

Next

1. Re-verify 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, 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 and 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 once Fix yarn berry pin entry rendering (#697, #718) #719 (or a follow-up) lands: uuid, acorn, nan, bufferutil, @img/sharp-*.
2. Run survey.py over more fields: packages whose registry peerDependencies/optionalDependencies differ from the tarball, and packages with directories.bin and no bin.
3. Re-verify Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, remove <purl> garbage-collects the beforeHash blobs of every other patch still in the manifest, so a later offline rollback of those patches fails missing_blob #559 (Share rollback artifact retention across remove and rollback #600) 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 when main moves.
4. Probes (macOS/Windows) once a maintainer deletes the stale branches and branch deletes are allowed again.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 14; the CLI reports 4.0.0, the latest release). Releases 4.0.0 and 3.3.0 from npm were used for the regression check. Yarn 4.0.2, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none (branch deletes are still blocked, see backlog item 1).

Harness: rebuilt as y, mkpatch.py (patched tgz plus bootstrap 10c0 checksum), mock.py (batch, by-package, view with blobContent, package grant with tarball + yarn-berry-zip, the tarball route, /upstream/npm/<uuid>.json from the cfg's origChecksum/origIntegrity, and a /registry/ npmjs passthrough for SOCKET_NPM_REGISTRY), run.sh and survey.py. Gotcha: run.sh must realpath the project dir before it copies the fresh checkout.

Re-triage

• main hasn't moved since run 14, so nothing could have been fixed. 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 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, 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, 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, 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 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 stay open (PR Fix yarn berry pin entry rendering (#697, #718) #719 still open).

Cells

• Yarn upgrade after vendoring (4.0.2 → 4.12.0 / 4.18.1), then rollback or vendor --revert: fail, filed 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. The revert restores the recorded pre-vendor block verbatim, which brings back 4.0.x's bare-hex checksum: into a lock yarn has respelled to 10c0/, so every later --immutable install fails YN0028. Reproduced 4/4 on main and on release 4.0.0, so it isn't a regression.
• Yarn upgrade after a hosted pin (4.0.2 → 4.18.1): pin survives, re-scan is a no-op, and rollback (with the registry passthrough) writes 10c0/ and passes a fresh hardened --immutable. Pass.
• Yarn upgrade after vendoring, without revert: the pin survives, the re-scan is a no-op, and fresh plain and hardened --immutable installs pass.
• checksumBehavior: ignore | update | reset × hosted/vendored on 4.18.1: pass, with patched bytes on fresh plain and hardened --immutable.
• lockfileFilename: n/a. Yarn 4 rejects the setting (removed), and yarn 2/3 are refused anyway.
• survey.py over 40 popular packages (react, webpack, typeorm, sharp, canvas, better-sqlite3, bcrypt, …): only the known classes showed up. ./bin paths (webpack-cli, typeorm, lint-staged) are 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; the implicit node-gyp dependency (canvas, better-sqlite3) is 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. No peerDependencies/optionalDependencies divergence was found.

Filed / commented / closed

• Filed 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: 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

Ruled out

• Release 3.3.0 doesn't vendor this setup (scan exit 2), so it can't be compared for 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.

Next

1. Re-verify 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 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, 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 and 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 (Fix yarn berry pin entry rendering (#697, #718) #719).
2. A vendored A→B patch upgrade across a yarn upgrade (expected to hit 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 too), and a vendored entry carrying other fields yarn re-renders between 4.x releases.
3. Probes (macOS/Windows) once the stale branches are deleted and branch deletes are allowed.
4. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 14; the CLI reports 4.0.0, the latest release). Release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu@4.0.0) was used for the regression check, and draft PR #763 head 55dc0cb was built separately. Yarn 4.0.2, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none (branch deletes are still blocked, see backlog item 1).

Harness (run 16): rebuilt as y (cli-dist wrapper), mkpatch.sh, mock.py and lib.sh (spm <mode>, fresh <dir> <file>). mock.py serves batch, by-package, view (with blobContent), patches/package (tarball + yarn-berry-zip), the tarball route, /upstream/npm/<uuid>.json (cfg origIntegrity/origChecksum) and a /registry/ npmjs passthrough. Gotchas: the passthrough must quote(path, safe='@/') (an encoded / gets a 405), and a checksum bootstrapped on yarn 4.0.x is bare hex, so prefix it with 10c0/ before serving it.

Re-triage

• main hasn't moved, so nothing could have been fixed. 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 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, 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, 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, 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 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 stay open.
• 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: verified draft PR Fix yarn berry hosted pin of catalog deps (#632) #763 (commented on 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). Root catalog:, named catalog:legacy, two workspaces with both (merged entry), catalog: + ^1.3.0, and dev+peer catalog: all pass: patched fresh --immutable (plain and hardened), re-scan no-op, rollback byte-exact. The vendored→hosted takeover of catalog: and catalog:legacy passes too. main still fails YN0028.

Cells

• Vendored with a parent-scoped user resolutions entry (pkg-a/left-pad, pkg-a/left-pad@^1.3.0, <root>/left-pad): fail, filed Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783. resolutions_gate matches selectors with split_pattern, so the parent-scoped key isn't seen as the target. Vendored adds a bare left-pad: file: pin, reports success, and every fresh --immutable fails YN0028 (a mutable install drops to unpatched; vex attests nothing). Hosted refuses correctly (redirect_yarn_berry_resolutions_conflict). Reproduced on 4.0.2, 4.12.0 and 4.18.1, and on release 4.0.0 (not a regression).
• User resolutions keyed left-pad, left-pad@^1.3.0, left-pad@npm:^1.3.0, left-pad@1.3.0 or left-pad@npm:1.3.0: refused by both modes (correct).
• .yarnrc.yml default compressionLevel spellings ('0', CRLF, BOM, padding, tab comment, quoted key, flow mapping): pass in both modes.
• Vendored A→B patch upgrade across a yarn 4.0.2 → 4.18.1 upgrade: pass (B pinned, stale A tgz removed, fresh plain and hardened installs patched). A later vendor --revert restores the 4.0.2 bare-hex checksum, which is 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 again (not commented).
• Workspaces globs * and ** (which would cover .socket/) × vendored/hosted: pass.
• Self-alias descriptors (npm:left-pad@^1.3.0, npm:^1.3.0, npm:left-pad@1.3.0, npm:left-pad@latest) × vendored/hosted: pass, with hosted rollback and vendored --revert byte-exact.

Filed / commented / closed

• Filed 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 misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783
• 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 (PR Fix yarn berry hosted pin of catalog deps (#632) #763 verification): 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

• **/left-pad user resolution: yarn 4 itself drops that entry from package.json on install, so hosted "overwriting" it is yarn's doing.
• 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.

Next

1. Re-verify Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 and Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 (after Fix yarn berry hosted pin of catalog deps (#632) #763 merges), plus 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 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 and Yarn berry vendored and hosted pins put checksum: out of yarn's field order on platform-conditional lock entries (conditions: os=…), so every yarn install --immutable fails YN0028 #697 when fixes land.
2. Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 variants once fixed: @scope/parent/left-pad, a scoped target, and the hosted→vendored takeover with a parent-scoped key.
3. Probes (macOS/Windows) once the stale branches are deleted and branch deletes are allowed.
4. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 14; CLI 4.0.0, the latest release). Also PR heads #719 (635ca29) and #730 (46e47d9). Yarn 4.0.2 and 4.18.1 from @yarnpkg/cli-dist, Node 22, Linux.

Probes: none (branch deletes are still blocked, see backlog item 1).

Harness (run 17): rebuilt as y (cli-dist wrapper; YH=1 turns on hardened mode, YG=<dir> turns on the global cache), mkpatch.sh (patched tgz, sha512, 10c0 checksum bootstrapped with a real file: install), stage.py (hand-stages .socket/manifest.json + blobs), mock.py (only POST /v0/orgs/org/patches/package with tarball + yarn-berry-zip artifacts, plus /tgz/<uuid>) and lib.sh (spv = vendor --json --api-url <mock> --api-token x --org org, fresh). Gotcha: v5 vendor --offline no longer builds artifacts locally (vendor_service_offline_conflict), so even hand-staged vendoring needs the service mock.

Re-triage

• main hasn't moved, so 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 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, 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, 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, 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 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 stay open. Nothing to close.

Cells (vendored unless noted)

• Takeover of a user's exact "resolutions": {"left-pad": "1.3.0"} pin: pass (fresh --immutable patched; --revert restores the user's pin byte-exact).
• Mixed-case JSONStream@1.3.5: pass (plain and hardened fresh installs, revert byte-exact).
• Three linked packages at once (JSONStream → through, jsonparse): pass on 4.18.1 and 4.0.2 (bare hex). Per-package rollback pkg:npm/through@2.3.8 leaves the other two pinned and fresh-installs cleanly. Full revert is byte-exact.
• bin: + conditions: (ios-deploy@1.12.2, darwin-only, installed on Linux via supportedArchitectures): fail on main, as both 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 (checksum after conditions:) and 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 (bin ./build/Release/ios-deploy from the tarball). Not a new issue. PR Fix yarn berry pin entry rendering (#697, #718) #719 head passes (plain and hardened fresh --immutable, patched). Backlog item 6 is done.
• Default yarn 4 global cache (no enableGlobalCache: false) plus --immutable --check-cache: pass.
• yarn workspaces focus a --production on a fresh vendored checkout: pass (patched, lock unchanged).
• Prerelease ms@3.0.0-canary.1: pass (plain and hardened, revert byte-exact).
• vendor --check with a tampered tgz: pass (exit 1, vendor_hash_mismatch).
• vendor --check wiring drift: fail, same root cause as 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 (commented, not filed). All three drift shapes report "committed artifact and wiring verified" with exit 0: resolutions deleted then yarn install (fresh --immutable then installs unpatched), resolutions deleted, and the lock restored to the registry entry. vex refuses correctly. PR Fix vendor --check passing unwired vendored entries (#725) #730 head fails all three and passes the control.

Filed / commented / closed

• Commented 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 (Berry evidence plus PR Fix vendor --check passing unwired vendored entries (#725) #730 verification): 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 (comment)
• Filed: none. Closed: none.

Ruled out

• Vendored vex on a tree whose node_modules still has the unpatched bytes (wiring pulled in without a reinstall) attests not_affected from the committed artifact and warns vendored_tree_out_of_sync (commands/vex.rs:671). That's by design.

Next

1. Re-verify when fixes land: 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/Fix vendor --check passing unwired vendored entries (#725) #730 on Berry, Fix yarn berry pin entry rendering (#697, #718) #719 (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, including ios-deploy), Fix yarn berry hosted pin of catalog deps (#632) #763 (Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632), Vendored yarn berry 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, 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, 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.
2. Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 variants once fixed: @scope/parent/left-pad, a scoped target, and the hosted→vendored takeover with a parent-scoped key.
3. Probes (macOS/Windows) once the stale branches are deleted.
4. Hosted cells with the run-17 harness extended (batch, view, /upstream, /registry/ passthrough), for example hosted vendor --check/vex drift after a user drops the resolutions pin.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 14; the CLI reports 4.0.0), plus release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu@4.0.0) for the regression check. Yarn 4.0.2, 4.12.0 and 4.18.1 come from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none (branch deletes are still blocked, see backlog item 1).

Harness (run 18): rebuilt as y (cli-dist wrapper; YH=1 turns on hardened mode), mkpatch.sh (patched tgz, sri, 10c0 checksum and zip bootstrapped with a real file: install), stage.py (manifest + blobs), mock.py (vendoring service: patches/package with tarball + yarn-berry-zip, /tgz, /zip), hmock.py (hosted: batch, by-package, view with blobContent, patches/package, /patch/npm/... tarball, /upstream/npm/<uuid>.json), reg.py (npmjs passthrough that rewrites every dist.tarball to a non-conventional /files/<encoded url> path, and also serves /<name>/<version> for SOCKET_NPM_REGISTRY) and lib.sh (spv, sph, mkproj, fresh). Gotchas: a fresh cold-cache check needs a fresh YARN_GLOBAL_FOLDER, because yarn's mirror otherwise serves the zip by checksum. SOCKET_NPM_REGISTRY must answer /<name>/<version>.

Re-triage

• main hasn't moved, so 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, 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 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, 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, 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, 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 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 stay open. Nothing to close.

Cells

• Survey (backlog 7): registry packument vs tarball package.json for yarn's lock fields (deps + optional → dependenciesMeta, peerDependencies, peerDependenciesMeta, bin, directories.bin, os/cpu/libc, binding.gyp). The sample was 900 packages at latest plus 700 at an old version (a BFS from about 200 seeds). The only mismatch classes were bin (59 ./ prefixes, plus sass-graph@4.0.1 with directories.bin only), which are 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, and binding.gyp, which is 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. No new class.
• yarn install --mode=update-lockfile (Renovate-style) locks: yarn 4.0.2 and 4.18.1 still write checksum:, even with an empty global folder. The cell is moot.
• Vendored, workspace member with its own (yarn-ignored) resolutions: {"left-pad": "1.3.0"}: pass (fresh immutable patched, --revert byte-exact).
• Vendored, object-form "workspaces": {"packages": [...]}: pass (fresh immutable patched, --revert byte-exact).
• Vendored on a custom registry with non-conventional tarball URLs (lock npm:1.3.0::__archiveUrl=...): pass (fresh immutable, --revert byte-exact).
• Hosted on the same custom registry: pin and fresh immutable pass. rollback and remove fail, filed 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. restore_berry rebuilds resolution: "left-pad@npm:1.3.0" without the registry's ::__archiveUrl= binding, so a cold-cache yarn install --immutable fetches the conventional path and fails YN0001 (4.0.2, 4.12.0, 4.18.1; each twice). Hardened mode and --refresh-lockfile accept the rebuilt entry, so only the fetch breaks. Release 4.0.0 kept the original entry in .socket/vendor/redirect-state.json (its manifest-less rollback reports "Manifest not found" in this harness). Control on the default registry: rollback byte-exact.

Filed / commented / closed

• Filed 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: 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 (the suspect line is upstream/npm.rs:559; the issue body says 557).

Ruled out

• An update-lockfile lock without checksums: yarn writes them anyway.
• The rolled-back bare npm: locator under hardened mode or --refresh-lockfile: yarn accepts it, so there's no YN0028.

Next

1. Re-verify when fixes land: 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, 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 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/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 (Fix yarn berry pin entry rendering (#697, #718) #719), 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 (Fix yarn berry hosted pin of catalog deps (#632) #763), 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 (Fix vendor --check passing unwired vendored entries (#725) #730), 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, 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.
2. 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 variants: a scoped package via npmScopes registry, the hosted→vendored takeover (does the vendored revert of a hosted pin go through restore_berry?), and yarn classic's counterpart (yarn_classic_tarball uses the SOCKET_NPM_REGISTRY tarball; hand over if it breaks).
3. Vendored yarn berry misses a parent-scoped user resolutions entry (pkg-a/left-pad), reports success, and every yarn install --immutable fails YN0028 #783 variants once fixed: @scope/parent/left-pad, a scoped target, and the hosted→vendored takeover.
4. Probes (macOS/Windows) once the stale branches are deleted.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

I filed #831 (#831) for yarn classic. Vendored mode writes .socket/vendor/npm/<uuid>/<name>-<ver>.tgz and never probes git ignores. With an ordinary .gitignore rule, the scan still exits 0 with no warning, the commit drops the tarball, and every fresh-checkout frozen install fails:

• *.tgz (GitHub's stock Node.gitignore)
• vendor/
• .socket/

With vendor/ or .socket/ ignored, state.json is dropped as well, and vendor --check exits 0 (discovered: 0) while the lock still points into .socket/vendor. Only the vlt backend has the vendor_artifact_gitignored probe (vlt_lock.rs:762) and the <uuid>/.gitignore !* re-include.

The tarball backends look like they share this, but I haven't tested yarn-berry. Please check it with a real yarn-berry install (repro shape in #831). If it reproduces, comment on #831 with your matrix rather than filing a duplicate, unless the fix clearly differs.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the CLI reports 4.0.0) with yarn 4.0.2 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting the stale branches was denied again ([Git Destructive], auto-mode classifier), see backlog item 1.

Harness (run 19): rebuilt as y (cli-dist wrapper, YH=1 for hardened mode), patched.tgz plus a 10c0 checksum bootstrapped with a file: install, and stage.py (manifest + blobs). mock.py (:8787) is the vendoring service: POST …/patches/package with tarball + yarn-berry-zip. hmock.py (:8788) is the hosted API: batch, by-package, view with blobContent, patches/package, /patch/npm/… and /upstream/npm/<uuid>.json with the original registry checksum and integrity. reg.py (:8789) is an npmjs passthrough that rewrites dist.tarball to /files/<quoted url> and returns 404 for the conventional /-/ tarball path, as a real non-conventional mirror does. Without that 404, yarn's error is a misleading "socket hang up". Drivers: gi.sh (ignore rule × yarn × linker), tk.sh (hosted → takeover → revert on the custom registry) and ts.sh.

Re-triage

• main hasn't moved, so 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, 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 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, 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, 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, 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 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 stay open. Nothing to close.

Cells

• Handover from yarn-classic (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 with the tgz gitignored: fail, commented on 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. Rules *.tgz, vendor/ and .socket/ on 4.18.1 node-modules, 4.0.2 node-modules and 4.18.1 pnpm: vendor exits 0 with no warnings, the tgz isn't committed, and a fresh clone's yarn install --immutable fails YN0001 ENOENT. A warm global cache fails too (file: is read from disk). Under .socket/, vendor --check in the clone exits 0. The no-rule control passes.
• 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 variant, hosted→vendored takeover on a custom registry with non-conventional tarball URLs: fail, commented on 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. The takeover's internal hosted revert writes bare left-pad@npm:1.3.0, and state.json stores that as the original. vendor --revert drops ::__archiveUrl=, and a cold-cache fresh --immutable fails YN0035 404. Runs: 4.18.1 vendor, 4.18.1 scan --mode vendored, 4.0.2 vendor.
• Lock carrying unrelated builtin patch: entries (typescript 5.4.5, fsevents 2.3.3) while pinning left-pad: pass in vendored and hosted (only left-pad's lines change; fresh hardened --immutable loads patched bytes).
• npmScopes variant of 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: not run. It has the same root cause, and the checksum path verifies against SOCKET_NPM_REGISTRY/npmjs, so a public scope mirror doesn't change anything.

Filed / commented / closed

• Commented on 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 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 (comment)
• Commented on 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: 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 (comment)
• Nothing filed or closed.

Ruled out

• A CRLF or odd .yarnrc.yml compressionLevel can't produce a wrong checksum. The lock's cacheKey gate is the backstop (already in Known non-bugs).

Next

1. Re-verify when fixes land: 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), 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 (plus the takeover path), 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 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/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 (Fix yarn berry pin entry rendering (#697, #718) #719), 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 (Fix yarn berry hosted pin of catalog deps (#632) #763), 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 (Fix vendor --check passing unwired vendored entries (#725) #730), 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, 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.
2. Probes (macOS/Windows) once a maintainer deletes the stale branches.
3. 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 follow-ups once fixed: a nested re-include (<uuid>/.gitignore !*) under *.tgz on Berry, and the hosted→vendored takeover under an ignore rule (does the refusal fire before the hosted revert?).
4. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 4646693 (47 commits past 045d7ec, including #719, #818, #689, #634 and #600; the CLI still reports 4.0.0), plus release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu@4.0.0, binary at package/socket-patch). Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting a stale branch still fails (fatal: the remote end hung up unexpectedly), see backlog item 1.

Harness (run 20): rebuilt as y (cli-dist wrapper, YH=1 for hardened mode), mkpatch.sh <name> <ver> <file> <uuid> (npm pack, prepend a marker, repack as package/, bootstrap the 10c0 checksum with a file: install, append to p/cfg.json) and one mock.py (:8790) serving batch, by-package, view (with blobContent/beforeBlobContent, so agent scan works), patches/package (tarball + yarn-berry-zip), /patch/npm/… and /upstream/npm/<uuid>.json (needs orig_ck/orig_sri in the config). reg.py (:8791) is the non-conventional npmjs passthrough (returns 404 on /-/). lib.sh has sp (with --patch-server-url), spv (without) and fresh (git clone plus a cold-cache --immutable). Gotchas: a default scan is hosted mode, so pass --mode agent explicitly. A vendored takeover of a hosted pin needs --patch-server-url, or the pin reads as user-authored (vendor_override_conflict).

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): still fails on 4646693 after Fix yarn berry pin entry rendering (#697, #718) #719 merged. Vendored fresh --immutable gives YN0028, and hosted hardened gives YN0028. Commented: 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 (comment)
• 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: still fails. Vendored on 4.0.2, then yarn install on 4.18.1, then vendor --revert writes a bare-hex checksum, and a fresh --immutable gives YN0028. No comment (nothing new).
• Verified fixed on main (all closed already):
  • 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: uuid, hosted and vendored, hardened fresh, pass. A pre-Fix yarn berry pin entry rendering (#697, #718) #719 pin with the registry bin: heals on re-run in both modes.
  • 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: transitive @esbuild/linux-x64 conditional entry, both modes, plain and hardened fresh, pass.
  • 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 (Fix hosted restore dropping registry tarball URLs (#557, #817) #818): hosted rollback on the custom registry keeps ::__archiveUrl=, byte-exact, cold-cache fresh passes. The hosted→vendored→vendor --revert takeover variant is also byte-exact.
  • 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): vendor, yarn remove left-pad, then rollback gives vendor_lock_entry_removed with the artifact removed, and fresh passes.

Cells

• Vendored→hosted takeover of a bin: package (uuid): pass. The pin carries the tarball bin: (./dist/bin/uuid), hardened fresh passes.
• Agent mode with yarn's pnpm linker and pnpmStoreFolder (new Fix agent mode patching linked first-party source (#626) #634 path): fail, filed 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. Transitive packages (is-odd→is-number@6.0.0, esbuild→@esbuild/linux-x64) under .cache/.store are skipped as package_not_installed with exit 0. Under a non-hidden store they're refused as "first-party source" with exit 1. 4.12.0 and 4.18.1; release 4.0.0 behaves the same. The control (default node_modules/.store) patches them. Direct deps pass, including a workspace member's direct dep (rollback restores). Yarn 4.0.2 rejects pnpmStoreFolder.

Filed / commented / closed

• Filed 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: 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
• Commented on 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 (above).
• Nothing closed (the fixed issues were already closed by their PRs).

Ruled out

• The scan --mode agent --json envelope showing 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). Not filed or handed over.
• The vendored vendor_override_conflict on a hosted pin came from the harness: --patch-server-url was missing.

Next

1. Re-verify when fixes land: 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 (Berry), 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, 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 (PR Fix yarn berry hosted pin of catalog deps (#632) #763, now conflicted), 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.
2. 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 between two projects: does agent mode patch every project's copy?), and YARN_NODE_LINKER/YARN_PNPM_STORE_FOLDER given by env only (does Fix agent mode patching linked first-party source (#626) #634's rc-only check refuse direct deps?).
3. Fix yarn berry pin entry rendering (#697, #718) #719 renderer edge cases: a string bin on a scoped package, empty-string bin values (yarn drops them), and a served tarball whose top directory isn't package/ (the hosted fetch reads only package/package.json, so a bin: package would be skipped as npm_manifest_unavailable).
4. Probes (macOS/Windows) once a maintainer deletes the stale branches.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[github-actions[bot]]

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

Tested: main 9c43dfc (27 commits past 4646693, including #598, #763, #730, #802, #829; the CLI still reports 4.0.0). Yarn 4.0.2, 4.12.0 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting bughunt/yarn-berry/20260930-builtin-patch-takeover failed again (send-pack: unexpected disconnect, remote end hung up), so no new probe branch could be guaranteed cleanup. See backlog item 1.

Harness (run 21): y (cli-dist wrapper, YH=1 for hardened mode), mkpatch.sh <name> <ver> <file> <uuid> (npm pack, prepend a marker, package/ repack, 10c0 bootstrapped with a file: resolution, appended to p/cfg.json), one mock.py (:8790: batch filtered by components[].purl, by-package, view with blobContent/beforeBlobContent, patches/package with tarball + yarn-berry-zip, /patch/npm/…, /upstream/npm/<uuid>.json from orig_ck/orig_sri), and reg.py (:8791, an npmjs passthrough for SOCKET_NPM_REGISTRY; hosted rollback fails "error sending request" without it). lib.sh: sp (with --patch-server-url), spn (without), fresh (git clone plus a cold-cache --immutable).

Re-triage

• 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: still fails as filed (.cache/.store → package_not_installed, exit 0; store → first-party refusal, exit 1). I commented a new variant (below).
• 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 (Berry, closed by Fix vendored mode replacing symlinked lockfiles (#627) #802): verified fixed. A symlinked yarn.lock or package.json is refused (redirect_symlinked_file_unsupported), the link stays intact, and a re-run after replacing the link vendors cleanly. Leftover: the refusal says "nothing was written" but leaves .socket/vendor/npm/<uuid>/ (tgz + socket-patch.vendor.json) with applied: 1. It's benign (vex gives manifest_not_found, vendor --check sees nothing, the re-run is clean), so it isn't filed.
• 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 (Berry, closed by Fix vendor --check passing unwired vendored entries (#725) #730): verified fixed. vendor --check exits 1 vendor_check_failed when resolutions is dropped, the lock is restored, or both (4.0.2, 4.18.1).
• 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 (closed by Fix yarn berry hosted pin of catalog deps (#632) #763): verified on main. Root catalog: plus member catalog:legacy pins 4 selectors (npm:1.3.0, npm:^1.3.0, catalog:, catalog:legacy), hardened fresh loads the patched bytes, and rollback is byte-exact (4.12.0, 4.18.1).

Cells

• Hosted from a workspace member (the Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598 follow-up): fail. Commented on 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 (yarn classic, same root cause: governing_root.rs has no yarn case). On 4.0.2, 4.12.0 and 4.18.1, get <uuid> --mode hosted from packages/a exits 0 with success, redirected: 0 and an npm-only redirect_npm_no_lockfile. A member scan does the same whenever the member owns a copy (nmHoistingLimits: workspaces, or the yarn pnpm linker). The hoisted scan finds 0 packages. Vendored fails closed (exit 1). The root control pins, and its fresh install is patched. This supersedes the old "Known non-bugs" line about member scans finding 0 packages.
• 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 variant: pnpmStoreFolder from env (YARN_PNPM_STORE_FOLDER) or ~/.yarnrc.yml: fail, commented on 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. Agent mode refuses even direct deps as "first-party source" (exit 1) on 4.12.0 and 4.18.1, because in_yarn_pnpm_store (shared_store.rs:235) reads only ancestor .yarnrc.yml. YARN_NODE_LINKER=pnpm alone with the default store: pass.
• Symlinked .socket shared by two projects: fail, filed 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. The Fix vendored revert deleting through a symlinked vendor dir (#664) #666 guard covers .socket/vendor and below only. Rollback, vendor --revert or remove in project a deletes the shared tgz and state.json with exit 0. Project c's fresh --immutable fails YN0001 and its vendor --check exits 0. Reproduced 4 times: 4.18.1 node-modules (rollback, remove), 4.18.1 pnpm (rollback), 4.0.2 (vendor --revert). Controls pass: a linked .socket/vendor or .socket/vendor/npm is refused with vendor_dir_symlink_unsupported.
• Fix yarn berry pin entry rendering (#697, #718) #719 renderer edge case, a scoped package with a string bin (@babel/parser@7.24.0, bin: parser:): pass in hosted and vendored (hardened fresh, .bin/parser linked).
• Fix yarn berry pin entry rendering (#697, #718) #719 renderer edge case, a served tarball rooted at parser/ instead of package/: hosted skips with npm_manifest_unavailable ("hosted tarball has no package/package.json"), exit 0, redirected: 0, nothing written. It's a listed per-package skip that only happens if the real service serves a non-package/ root (unconfirmed), so it isn't filed.

Filed / commented / closed

• Filed 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
• Commented on 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: 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 (comment)
• Commented on 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: 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 (comment)
• Nothing closed (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, Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632 and 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 were already closed by their PRs).

Ruled out

• Hosted rollback failing with "error sending request for url (https://registry.npmjs.org/…)" is a sandbox artifact: rustls can't use the proxy CA. Use SOCKET_NPM_REGISTRY → reg.py.
• The .socket orphan after a symlinked-lock refusal is benign (see re-triage).

Next

1. 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), 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 (+ env/home variant), 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), 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, 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.
2. Probes (macOS/Windows) once a maintainer deletes the two stale branches.
3. 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 neighbours: a .socket junction on Windows; .socket/manifest.json shared through the link (agent-mode rollback in one project).
4. 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), or for object-form workspaces.
5. Global (-g) on macOS/Windows, and a version-manager prefix.

[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), latest release 4.0.0. Yarn 4.0.2 and 4.18.1 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. The two stale probe branches (bughunt/yarn-berry/20260930-builtin-patch-takeover, bughunt/yarn-berry/20261001-global-script) are still on the remote; see backlog item 1.

Harness (run 22, rebuilt): y (cli-dist wrapper, YV=<v>, YH=1 for hardened mode), mkpatch.sh <name> <ver> <file> <uuid> (patched tgz, 10c0 bootstrapped via file: resolutions, original checksum from a plain install, into p/cfg.json), mock.py (:8790, authenticated + public routes: batch, by-package, view with blobContent, patches/package with tarball + yarn-berry-zip, /patch/npm/…/<uuid>/x.tgz, /upstream/npm/<uuid>.json), reg.py (:8791, npmjs passthrough), reg2.py (:8792, a non-conventional mirror: dist.tarball = /_t/<name>/<ver>.tgz, /-/ 404s) and reg3.py (:8793, an npmjs stand-in whose dist.tarball is conventional under its own base, as npmjs's is). lib.sh: sp, mkproj, fresh.

Re-triage

Main hasn't moved since run 21, so every open pm:yarn-berry issue (#887, #859, #783, #759, #737, #539, #628, #629) stands as last verified. Nothing closed.

Cells

• Project reached through a symlinked path (lnk -> real, cwd under the link; the macOS /tmp → /private/tmp shape), 4.18.1: pass in vendored (relative file:./.socket/…, fresh --immutable patched, rollback clean; also --cwd <link>), hosted (fresh patched, rollback byte-exact with a registry passthrough) and agent (apply + rollback).
• Hosted rollback/remove on a non-conventional mirror with SOCKET_NPM_REGISTRY unset (modelled by the npmjs stand-in): fail, filed 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. The restore fetches dist.tarball from npmjs, not the project's npmRegistryServer, so it writes a bare left-pad@npm:1.3.0. Every cold yarn install --immutable then fails YN0035 404. Cells: 4.18.1 rollback, 4.18.1 remove, 4.18.1 hosted→vendor→vendor --revert, 4.0.2 rollback (all fail). Control with SOCKET_NPM_REGISTRY=<mirror>: byte-exact. With an npmjs passthrough (:8791) as SOCKET_NPM_REGISTRY, the restore writes ::__archiveUrl=https%3A//registry.npmjs.org/…, moving the project off its mirror. The run-18/20 verification of 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 used the mirror as SOCKET_NPM_REGISTRY, which hid this.
• Agent mode with a symlinked .socket shared by two projects: fail, commented on 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. Rollback in a empties the shared manifest. b's apply then says "No patches to apply" (exit 0), and after a reinstall b is unpatched.

Filed / commented / closed

• Filed 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 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
• Commented on 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)
• Handed over the 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 root cause as an unverified lead to yarn-classic and pnpm (entries/<pm>/20261006T010742Z-from-yarn-berry.md).

Ruled out

• Hosted rollback failing with "error sending request" to registry.npmjs.org, even with SSL_CERT_FILE set: a sandbox artifact (the rustls binary can't use the proxy CA). Model npmjs with reg3.py, not reg.py, when the dist.tarball host matters.

Next

1. Re-verify when fixes land: 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, 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 + agent), 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), 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.
2. 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 neighbours: npmScopes.<scope>.npmRegistryServer for a scoped target; a conventional mirror with a path base (/api/npm/npm-remote/), which should stay bare.
3. Probes (macOS/Windows) once a maintainer deletes the two stale branches.
4. 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 (nested separate Berry project, object-form workspaces).

[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), latest release 4.0.0, and the head of draft PR #918 (21413f1, the fix for #908/#521). Yarn 4.18.1 and 4.0.2 from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting the two stale probe branches failed again (send-pack: unexpected disconnect), so they still need deleting by hand (backlog item 1).

Harness (run 23, rebuilt): y (cli-dist wrapper), reg.py <port> conv|nonconv [path-prefix] (:8792 non-conventional mirror, :8793 npmjs stand-in used as SOCKET_NPM_REGISTRY, :8794 conventional mirror under /api/npm/npm-remote), mock.py (:8790, the authenticated API with /upstream/npm/<uuid>.json, driven by cfg.json), mkpatch.sh <name> <ver> <file> <uuid> (patched tgz; the 10c0 checksum is bootstrapped and the original checksum comes from a plain install), and run.sh <bin> <scenario> <dep> <ver> <uuid> rollback|remove (install, get --mode hosted, rollback/remove, byte-compare, then a cold --immutable in a fresh copy). rollback takes no --mode.

Re-triage

Main hasn't moved. #908 was claimed by a maintainer agent, and draft PR #918 is open for it. Everything else stands as last verified.

Cells (hosted rollback/remove on a mirror)

Where the mirror is set	main	PR #918
project rc top-level npmRegistryServer (non-conventional)	fail (#908)	pass (rollback and remove byte-exact, cold --immutable)
npmScopes.isaacs.npmRegistryServer, scoped target @isaacs/string-locale-compare	fail	fail (rollback and remove; 4.18.1 and 4.0.2)
env YARN_NPM_REGISTRY_SERVER	fail	fail (rollback and remove)
~/.yarnrc.yml npmRegistryServer	fail	fail (rollback)
conventional mirror with a path base (/api/npm/npm-remote)	pass (byte-exact)	pass (byte-exact)

Each failing cell: a bare npm:<v> locator is written in place of ::__archiveUrl=, the command exits 0 with no warning, and a cold --immutable fails YN0035 404.

Filed / commented / closed

• Commented on 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 with the PR Fix npm-family restore ignoring project registry (#908, #521) #918 verification and the three variants it still misses: 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 (comment)
• Nothing new filed (same root cause as 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). Nothing closed.

Ruled out

• The path-base conventional mirror stays bare and byte-exact on both main and the PR. Not a bug.

Next

1. 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 (or a follow-up) lands, covering all four registry sources plus a parent-directory .yarnrc.yml, and the inverse case (top-level mirror, npmScopes pointing a scope at npmjs).
2. 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), 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.
3. Probes (macOS/Windows) once a maintainer deletes the two stale branches.
4. 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.

[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), latest release 4.0.0. Yarn 4.18.1 (still the newest; no new cli-dist since 2026-09-24) and 4.0.2, from @yarnpkg/cli-dist, on Node 22 and Linux.

Probes: none. Deleting a stale probe branch was denied by the session permission policy this run, so no new probe branches were pushed (they must be deleted before the run ends). bughunt/yarn-berry/20260930-builtin-patch-takeover and bughunt/yarn-berry/20261001-global-script still need deleting by hand.

Harness (run 24, rebuilt): y (cli-dist wrapper; YV=<v>), mock.py <scratch> <port> <yarnBerry10c0> (one Python mock: batch filtered by components[].purl, by-package, view with blobContent/beforeBlobContent, patches/package with a tarball (real sha512/sha1) and a yarn-berry-zip artifact, and the .tgz route), p/left-pad-1.3.0.tgz (marker prepended to index.js, checksum bootstrapped with a file: install), and run.sh <yarn> tgz|dir|url hosted|vendored (workspace fixture, scan, lock-only vex on a fresh copy, cold --immutable, check the copy, vex after install).

Re-triage

Main hasn't moved, so nothing new to re-check on main. PR #918 gained only test/CI commits plus 688d77c (npmScopes packages stay on the default lookup), so run 23's verdict on #908 stands. PR #924 (yarn classic #921) touches classic code only.

Cells

Cell	Result
Workspace member with a same-name file: dir copy ("left-pad": "file:…") beside a registry left-pad@^1.3.0, hosted (4.18.1)	pass: refused loudly (redirect_yarn_berry_unsupported_protocol + shared_descriptor), nothing written
Same, vendored (4.18.1)	pass: refused loudly (vendor_override_conflict), nothing written
Member copy under another name ("lp2": file: tgz / file: dir / registry tarball URL) × hosted / vendored × 4.0.2 / 4.18.1 (12 cells)	fail #939: no warning; lock-only vex attests not_affected; fresh --immutable installs node_modules/lp2 unpatched; vendored vex still attests after the install (hosted declines not_applied)
Same lp2 fixture, agent mode (4.18.1)	pass: both node_modules/left-pad and node_modules/lp2 patched, vex attests, rollback restores both

Filed / commented / closed

• Filed 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: 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
• Nothing closed or commented.

Ruled out

• The same-name file: copy (the pnpm VEX attests not_affected while a file: directory or file: tarball copy of the patched package@version in the same pnpm-lock.yaml installs unpatched, and hosted/vendored scans give no warning for that copy #935/Yarn classic VEX attests not_affected while a file: directory copy of the patched package@version installs unpatched, and hosted scan gives no warning for that copy #921 shape) is already refused by both berry rewriters. Not a bug for berry.
• Hosted scan --vex exiting 1 with manifest_not_found after that refusal is the known "nothing to attest" exit.

Next

1. 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 (or a follow-up) lands: all four registry sources, a parent-directory .yarnrc.yml, and the inverse npmScopes case.
2. 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: a git/github: copy under another name, a portal:/link: to an unpatched checkout of the same version (agent mode patches through the link?), and the pnpm linker.
3. Re-verify when fixes land: 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, 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), 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.
4. Probes (macOS/Windows) once a maintainer deletes the two stale branches, or once branch deletion is allowed.