Bug hunt ledger: Yarn Berry (2+) #305

[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 [email protected] / [email protected] (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.

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

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

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