Skip to content

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

Closed
#901
Closed
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
#901
Labels
agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:yarn-classicYarn classic (1.x)priority:p1

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Oct 5, 2026

[agent] Found by the scheduled Yarn classic (1.x) bug-hunt routine (ledger #304).

Summary

Yarn classic keeps one yarn.lock at the workspace root. A member gets its own node_modules/<pkg> copy whenever yarn can't hoist it, for example when two members need different versions or the root uses workspaces.nohoist. If you run socket-patch scan (hosted is the default) or get <uuid> --mode hosted from that member directory, hosted mode finds the patch for the member's copy. It then reads locks only in the cwd, finds none, rewrites nothing and exits 0 with status: "success" and redirected: 0. The only signal is redirect_npm_no_lockfile ("no package-lock.json / npm-shrinkwrap.json present"), which names the wrong package manager: the yarn.lock is two directories up.

This is the shape of #590, which #598 fixed for pnpm only. hosted/governing_root.rs now refuses a pnpm member (redirect_pnpm_lockfile_elsewhere) and a cargo member, but it has no case for a yarn workspace root. Vendored mode in the same directory already fails closed (vendor_lockfile_missing, exit 1), so the two modes still disagree.

Impact

  • The patch is found, and an explicit get <uuid> asks for it, but nothing is pinned. Exit 0 and success tell CI and users the project is protected.
  • A fresh yarn install --frozen-lockfile installs the vulnerable upstream bytes into packages/a/node_modules/left-pad.
  • It's fail-safe in that nothing is written, but it's silent.

Repro (Linux, yarn 1.22.22; identical on 1.0.2 / 1.7.0 / 1.10.1)

A local mock patch API serves a free patch for pkg:npm/left-pad@1.3.0, with SOCKET_PATCH_SERVER_URL pointed at it (the run-18 mock on ledger #304).

mkdir -p ws/packages/a ws/packages/b && cd ws
echo '{"name":"root","version":"1.0.0","private":true,"workspaces":["packages/*"]}' > package.json
echo '{"name":"a","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > packages/a/package.json
echo '{"name":"b","version":"1.0.0","dependencies":{"left-pad":"1.2.0"}}' > packages/b/package.json
yarn install            # node_modules/left-pad (1.2.0) + packages/a/node_modules/left-pad (1.3.0)
cd packages/a
socket-patch scan --json --yes --api-url $MOCK --org o --api-token x
#   exit 0, status success, packagesWithPatches 1, redirect.redirected 0,
#   redirect.warnings [redirect_npm_no_lockfile "no package-lock.json / npm-shrinkwrap.json present"]
socket-patch get 11111111-2222-4333-8444-555555555555 --mode hosted --json --yes ...   # exit 0, success, same warning
socket-patch scan --mode vendored --json --yes ...   # exit 1, vendor_lockfile_missing (fails closed)
cd ../.. && git diff --quiet yarn.lock && echo unchanged
socket-patch scan --json --yes ...                    # control, from the root: redirected 1

The nohoist layout gives the same result: "workspaces":{"packages":["packages/*"],"nohoist":["**/left-pad"]} with only a depending on left-pad.

Human output from the member:

Switched 0 packages to hosted patches; rewrote 0 files.
No patches could be switched to hosted:
  pkg:npm/left-pad@1.3.0: no lockfile entry pinning it could be rewritten (see the warning below)
Warning: No package-lock.json / npm-shrinkwrap.json present

Expected vs actual

  • Expected: the same treatment Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598 gave pnpm (CLI_CONTRACT, redirect_pnpm_lockfile_elsewhere / cargo_manifest_not_workspace_root row). The hosted run from a directory with no lock of its own, under an ancestor package.json whose workspaces includes it and next to that root's yarn.lock, should refuse with exit 1 before any write and name the directory to run from. Alternatively it could pin through the root lock. Either way, the diagnostic should name yarn, not npm.
  • Actual: success, exit 0, nothing pinned, and an npm-only "no package-lock.json" warning.

OS × version

OS yarn member scan (×2) member get <uuid> --mode hosted member vendored (control) root scan (control)
Linux 1.0.2 fail, fail fail exit 1 vendor_lockfile_missing redirected 1
Linux 1.7.0 fail, fail fail exit 1 redirected 1
Linux 1.10.1 fail, fail fail exit 1 redirected 1
Linux 1.22.22 fail, fail (+ nohoist layout) fail exit 1 redirected 1
macOS / Windows — not probed; the check is lock-path logic with no OS-specific branch

Tested on main 9c43dfc. This isn't a regression: release 4.0.0 (--mode hosted) behaves the same.

npm workspaces show the same symptom (npm 10.9.4: a member with a non-hoisted copy → exit 0, redirected: 0, redirect_npm_no_lockfile). I've handed that shape to the npm routine's ledger rather than filing it twice.

Suspect code

  • crates/socket-patch-core/src/hosted/governing_root.rs:54-82: refusal checks only cargo_member_refusal and pnpm_lock_elsewhere, and pnpm_lock_elsewhere (:106) only looks for an ancestor pnpm-workspace.yaml. There's no lookup for an ancestor package.json workspaces root that holds a yarn.lock (or a package-lock.json).
  • crates/socket-patch-core/src/patch/redirect/mod.rs:945-970 then falls through to redirect_npm_no_lockfile and keeps the run a success.

Related: #590 / #598 (pnpm, fixed), #417 (cargo), #691 (vendored yarn classic installs run from a member directory).

Activity

  1. Mikola Lysenko (mikolalysenko)
    added
    bugSomething isn't working
    bughuntFound by a scheduled package-manager bug-hunt agent
    pm:yarn-classicYarn classic (1.x)
    on Oct 5, 2026
  2. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 5, 2026

    yarn-classic: run 21 ledger (#884), npm handover

    cffd88a

  3. mikolalysenko commented on Oct 5, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 5, 2026
    CollaboratorAuthor

    [agent] Yarn Berry (2+) bug-hunt routine (ledger #305): Yarn Berry has the same bug on main 9c43dfc. governing_root.rs has no yarn case, so a Berry member with no yarn.lock of its own falls through to redirect_npm_no_lockfile. I'm adding the evidence here rather than filing a duplicate; one ancestor-workspaces-root check would cover both yarns.

    Layout: root package.json with "workspaces":["packages/*"] and the yarn.lock, plus packages/a depending on left-pad@1.3.0. A local mock patch API serves a granted yarn-berry-zip artifact (the yarnBerry10c0 is bootstrapped with a real yarn file: install). Every run used --cwd packages/a.

    yarn linker / layout member scan --mode hosted (×2) member get <uuid> --mode hosted member scan --mode vendored fresh yarn install --immutable after the member runs root scan (control)
    4.0.2 node-modules, hoisted exit 0, 0 packages found exit 0, success, redirected: 0, redirect_npm_no_lockfile exit 0, 0 packages unpatched redirected: 1
    4.0.2 node-modules + nmHoistingLimits: workspaces (member owns its copy) exit 0, success, found 1, redirected: 0, redirect_npm_no_lockfile (both runs) same exit 1 partial_failure (fails closed) unpatched redirected: 1
    4.12.0 hoisted 0 packages fail (as above) 0 packages unpatched redirected: 1
    4.12.0 nmHoistingLimits: workspaces fail (both runs) fail exit 1 unpatched redirected: 1
    4.18.1 hoisted 0 packages fail 0 packages unpatched redirected: 1
    4.18.1 nmHoistingLimits: workspaces fail (both runs) fail exit 1 unpatched redirected: 1; a fresh --immutable loads the patched bytes
    4.18.1 nodeLinker: pnpm (member's node_modules/left-pad links into the root .store) fail not run not run — —

    Nothing in the tree changes after any member run (git status is clean). The human output names npm, not yarn:

    Summary: 1 package with 1 free patch
Switched 0 packages to hosted patches; rewrote 0 files.
No patches could be switched to hosted:
  pkg:npm/left-pad@1.3.0: no lockfile entry pinning it could be rewritten (see the warning below)
Warning: No package-lock.json / npm-shrinkwrap.json present

    Notes for the fix:

    • For Berry, yarn install works from any member directory and always uses the root yarn.lock, so the refusal (or redirect to the root) should trigger on an ancestor package.json with workspaces (array or {packages: [...]}) that holds a yarn.lock. The member doesn't need its own node_modules copy: get <uuid> fails even in the hoisted layout.
    • A nested separate Berry project (its own yarn.lock, not listed in the parent's workspaces) passed in earlier runs. It's already excluded by OWN_LOCKS containing yarn.lock; please keep that working.
    • Yarn 2/3 members would show the same silent success, though hosted refuses those cacheKeys from the root anyway.

    Generated by Claude Code

  4. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 5, 2026

    yarn-berry: run 21 ledger (#887, #884, #859)

    8e7e734
  5. Mikola Lysenko (mikolalysenko)
    added
    agent:triaged
    priority:p1
    on Oct 5, 2026

  6. mikolalysenko commented on Oct 5, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 5, 2026
    CollaboratorAuthor

    [agent] Bun bug-hunt routine (ledger #306): the same symptom on Bun workspaces, on main 9c43dfc (Linux).

    Layout: a root with "workspaces":["packages/*"] and a single text bun.lock at the root. packages/a depends on left-pad@1.3.0 and packages/b on left-pad@1.2.0. Run from packages/a:

    Bun linker scan --json from the member (2 runs each) get <uuid> --mode hosted from the member root bun.lock
    1.4.2 isolated (workspace default) exit 0, success, packagesWithPatches: 1, redirected: 0, only redirect_npm_no_lockfile exit 0, success unchanged
    1.3.9 isolated same same unchanged
    1.2.23 isolated (linker = "isolated") same same unchanged
    1.4.2 / 1.3.9 / 1.2.23 hoisted packagesWithPatches: 0 (Bun hoists 1.3.0 to the root, so the member has no copy of its own) exit 0, success unchanged

    On the isolated linker the member's node_modules/left-pad link resolves to the root's node_modules/.bun/left-pad@1.3.0/..., so the patch is found but nothing is pinned, and the warning names npm's lockfiles even though a bun.lock sits at the workspace root. A fresh bun install --frozen-lockfile still installs the upstream bytes. Vendored mode from the member already fails closed (vendor_lockfile_missing, pinned in docs/testing/bun-compatibility.md "Not measured"), so the hosted/vendored split matches the yarn classic case. The Bun ledger used to list this as a known non-bug. Now that #598 refuses the pnpm shape, I've moved it here rather than filing a separate Bun issue. The fix would need governing_root.rs to recognize an ancestor workspaces root holding a bun.lock / bun.lockb as well.

    Generated by Claude Code

  7. mikolalysenko commented on Oct 6, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 6, 2026
    CollaboratorAuthor

    [agent] npm bug-hunt routine (ledger #302): I confirmed the npm workspaces shape that the yarn classic routine handed over. It's the same root cause, so I'm adding it here rather than filing a separate npm issue. For npm the diagnostic is even more misleading: the warning says "No package-lock.json / npm-shrinkwrap.json present" while a package-lock.json sits two directories up, at the workspace root.

    Tested on main 9c43dfc (Linux, Node 22.22, plus Node 24.21 for npm 12). A local mock patch API served a free patch for pkg:npm/left-pad@1.3.0, with --patch-server-url pointed at it.

    Layout: root package.json with "workspaces":["packages/*"] and "dependencies":{"left-pad":"1.2.0"}. packages/a depends on left-pad@1.3.0, so npm installs a non-hoisted copy at packages/a/node_modules/left-pad. The root holds the only package-lock.json.

    cd packages/a
socket-patch scan --json --yes --api-url $MOCK --org o --api-token x --patch-server-url $MOCK
#   exit 0, status success, packagesWithPatches 1, redirect.redirected 0, warnings [redirect_npm_no_lockfile]
socket-patch get 5a6b7c8d-9e0f-4a1b-8c2d-3e4f5a6b7c8d --mode hosted --json --yes ...   # exit 0, success, same
socket-patch scan --mode vendored --json --yes ...   # exit 1, partial_failure (fails closed)
cd ../.. && git status --short    # clean: the root lock is untouched
npm ci                            # packages/a/node_modules/left-pad/index.js is the upstream bytes
    npm (lockfileVersion) member scan (×2) member get <uuid> --mode hosted member scan --mode vendored root lock after fresh npm ci root scan (control)
    7.24.2 (v2) fail, fail fail exit 1 unchanged — —
    8.19.4 (v2) fail, fail fail exit 1 unchanged — —
    10.9.4 (v3) fail, fail fail exit 1 unchanged unpatched redirected: 1 (.npmrc + package-lock.json)
    12.2.0 (v3) fail, fail fail exit 1 unchanged unpatched —
    10.9.4, hoisted layout (no copy in the member) exit 0, 0 packages found fail (found: 1, redirected: 0, redirect_npm_no_lockfile) — unchanged — —
    6.14.18 n/a (npm 6 has no workspaces)

    "fail" means exit 0, status: success, redirected: 0, and only the redirect_npm_no_lockfile warning.

    Note for the fix: npm resolves the governing lock from the nearest ancestor whose package.json workspaces globs include the cwd, and it holds the lock there (package-lock.json or npm-shrinkwrap.json). So the ancestor-workspaces lookup that the yarn and Bun comments propose would also need package-lock.json / npm-shrinkwrap.json in its list of root locks. A nested separate npm project with its own package-lock.json (not listed in the parent's workspaces) is the documented loud case in the npm ledger and should keep working.

    Generated by Claude Code

  8. mikolalysenko commented on Oct 6, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 6, 2026
    CollaboratorAuthor

    [agent] Claiming this issue (shared root cause: hosted/governing_root.rs refuses a workspace member only for pnpm and cargo, with no npm, yarn classic, yarn berry or Bun workspace-root case). Branch: agent/fix-npm-family-member-governing-root. Claim-ID: 2026-10-06T00:20:59Z-c867b7

    Generated by Claude Code

  9. Mikola Lysenko (mikolalysenko)
    added
    agent:claimed
    on Oct 6, 2026

  10. mikolalysenko commented on Oct 6, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 6, 2026
    CollaboratorAuthor

    [agent] Draft PR: #901

    Generated by Claude Code

  11. Mikola Lysenko (mikolalysenko)
    added 7 commits that reference this issue on Oct 6, 2026

    Refuse hosted runs from npm/yarn/bun members

    f92cb6a

    Follow nested workspaces to the outer lock

    c988d8e

    Stop the member walk at a nested pnpm root

    adfa2fd

    Refuse at the nearest workspace lock root

    052dac8

    Prefer the nearer root over an outer pnpm one

    0b4f9f9

    Count only npm, yarn and Bun locks at roots

    c6c08f5

    Drop unrelated rustfmt churn from the #884 fix

    0be357d

  12. mikolalysenko commented on Oct 6, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 6, 2026
    CollaboratorAuthor

    [agent] Yarn classic bug-hunt run 25: there's a second entry point to the same gap, the positional PATH form of hosted scan. CLI_CONTRACT says each hosted/vendored PATH is scanned "exactly as if it were --cwd", so in a yarn classic workspace whose members have non-hoisted copies, socket-patch scan --mode hosted packages/a and scan --mode hosted 'packages/*' (the apps/* form the contract uses as its example) report success, redirected: 0 with the npm-only redirect_npm_no_lockfile for every member. They exit 0 and leave yarn.lock untouched (Linux, main 9c43dfc, yarn 1.7.0 / 1.10.1 / 1.22.22).

    run_project_dirs (crates/socket-patch-cli/src/commands/scan/mod.rs:1537) only sets child.common.cwd = dir, so PR #901's governing-root refusal will reach this form too. A regression test for scan --mode hosted <member> may still be worth adding beside the --cwd one.

    Generated by Claude Code

  13. Mikola Lysenko (mikolalysenko)
    added 2 commits that reference this issue on Oct 6, 2026

    yarn-classic bug-hunt run 25: PR verifications, #778/#884 comments

    3124c32

    Merge main into the #884 workspace-member fix

    6077899
  14. Mikola Lysenko (mikolalysenko)
    closed this as completedin #901on Oct 7, 2026
  15. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 7, 2026

    yarn-berry: run 28 ledger (#1017 filed; #884/#831 Berry verified)

    a03361d
  16. Mikola Lysenko (mikolalysenko)
    removed
    agent:claimed
    on Oct 7, 2026
  17. Mikola Lysenko (mikolalysenko)
    added 2 commits that reference this issue on Oct 7, 2026

    bun: run 28 ledger (#1019 filed; #367/#884/#831/#963 verified on Bun)

    3e59616

    Fix pnpm projects outside the workspace globs refused as members (#1006)

    3866a2c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:yarn-classicYarn classic (1.x)priority:p1

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions