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] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).

Summary

With Yarn 4's pnpm linker, a transitive dependency exists only as a store entry (<store>/<slug>/package). Its parent links to it from the parent entry's own node_modules. The crawler only recognizes that store at its default location, node_modules/.store (the #495 fix). When .yarnrc.yml relocates it with pnpmStoreFolder, agent mode fails on transitive packages in one of two ways, depending on the folder name:

1. Hidden folder (pnpmStoreFolder: .cache/.store, the example docs/ecosystems.md itself uses): the walk skips hidden directories, so the copy is never found. scan --mode agent reports the package as notInstalled: true, skips the patch as package_not_installed, and exits 0 success. The vulnerable copy that Node actually loads stays unpatched, and nothing warns.
2. Non-hidden folder (pnpmStoreFolder: store): the walk enters store/<parent-slug>/node_modules/ and finds the link. But apply then refuses it with apply_failed: "node_modules links to it, but it is outside every node_modules tree (a workspace member, a file: or link: directory dependency, or an npm link target), so it is first-party source". That's exit 1, for a registry copy that docs/ecosystems.md says is patched.

Direct dependencies (node_modules/<dep> → <store>/<slug>/package) are patched correctly in both layouts; that's the #634 path. With the default store, the same transitive package is patched.

Impact

• pnpmStoreFolder is the setting Yarn documents for moving the store (for example out of node_modules for tooling or caching). Most patched vulnerabilities are in transitive dependencies, so on such a project agent mode silently leaves them unpatched (case 1) or fails the run (case 2).
• In case 1 the scan's own report calls an installed package "not installed", so a user has no hint that anything was missed.
• vex doesn't attest the skipped copy, so there's no false attestation. Hosted and vendored modes work from the lockfile and aren't affected.

Repro (Linux, yarn 4.18.1 from @yarnpkg/cli-dist)

mkdir io && cd io
echo '{"name":"io","private":true,"dependencies":{"is-odd":"3.0.1"}}' > package.json   # is-odd -> is-number@6.0.0 (transitive)
printf 'nodeLinker: pnpm\npnpmStoreFolder: .cache/.store\n' > .yarnrc.yml
yarn install
readlink .cache/.store/is-odd-npm-3.0.1-*/node_modules/is-number   # ../../is-number-npm-6.0.0-<hash>/package
socket-patch scan --mode agent --json --yes --api-url <mock> --org org --api-token x
#   status "success", exit 0
#   packages[]: {"purl":"pkg:npm/is-number@6.0.0","notInstalled":true}
#   apply.patches[]: {"action":"skipped","errorCode":"package_not_installed"}
head -c 20 .cache/.store/is-number-npm-6.0.0-*/package/index.js   # unpatched

# Case 2: the same project with a non-hidden store folder
printf 'nodeLinker: pnpm\npnpmStoreFolder: store\n' > .yarnrc.yml && rm -rf .cache node_modules && yarn install
socket-patch scan --mode agent --json --yes <api flags>    # exit 1, partial_failure
socket-patch apply --json
#   events: {"action":"failed","errorCode":"apply_failed","error":"Refusing to patch …/store/is-number-npm-6.0.0-<hash>/package: node_modules links to it, but it is outside every node_modules tree … first-party source …"}

Patch data came from a local mock of the patch API (batch, by-package, view with blobContent/beforeBlobContent, patches/package), serving a patch that prepends a marker to is-number@6.0.0/index.js. A second package was also checked: esbuild@0.21.5 → @esbuild/linux-x64@0.21.5, patching README.md.

(As a side note, in case 2 the scan --json envelope shows the failed patch as action: "added" with failed: 0 and no error. That's #424, not this issue.)

Expected vs actual

• Expected: docs/ecosystems.md ("npm: which node_modules trees are crawled") says the package stores of isolated layouts are walked "since they are the only home of transitive dependencies", including Yarn 4's pnpm-linker node_modules/.store and, for pnpm, "the directory a virtualStoreDir setting moved it to". It also says links "into Yarn's pnpm-linker store relocated outside node_modules" (an active pnpm linker with pnpmStoreFolder in the nearest .yarnrc.yml) "are patched as usual". A transitive store entry under the relocated store should be patched exactly like one under node_modules/.store.
• Actual: with a relocated store, transitive entries are either invisible (exit 0, package_not_installed) or refused as first-party source (exit 1).

Matrix (Linux, Node 22)

First bad: this isn't a regression. Release 4.0.0 skips the same way. macOS and Windows weren't probed (the routine can't push probe branches right now), but the crawl logic doesn't depend on the OS.

Suspect code

• crates/socket-patch-core/src/crawlers/npm_crawler.rs:1674: the Yarn/npm linked store is only recognized as node_modules/.store. Nothing reads pnpmStoreFolder the way the pnpm path reads virtualStoreDir from .modules.yaml (npm_crawler.rs:143-160). :1720 then skips hidden directories, which explains case 1.
• crates/socket-patch-core/src/patch/shared_store.rs:241 / :274 (in_yarn_pnpm_store): project is taken as node_modules.parent(). For a link inside a store entry's own node_modules, that "project" is the store entry itself, so project.starts_with(&store) holds, the function returns false, and the copy is classified LinkedSource. That explains case 2. The project root could be found from the yarn.lock / .yarnrc.yml ancestor instead.
• One possible fix: when the nearest .yarnrc.yml sets nodeLinker: pnpm and pnpmStoreFolder, walk <store>/*/package as store entries, the same way list_npm_store_entries_sync handles node_modules/.store.

Backlog review — 2026-10-08

Priority: P1 → P2. Relocated Yarn store layouts lose transitive discovery; retain at P2 with the environment trigger explicit.