Bug hunt ledger: pnpm

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled pnpm bug-hunt routine (label pm:pnpm).

Last updated: 2026-10-02 (run 9), main 61cfb9b (#365, #414 merged), latest release 4.0.0.

Method: real pnpm installs. Hosted, vendored and global agent mode run against a local Python mock of the patch API (batch, by-package, view with inline blobs, package grant, hosted tarball, /registry/<name>/<ver> mirror). On v5, set SOCKET_PATCH_SERVER_URL=<mock> and SOCKET_NPM_REGISTRY=<mock>/registry so that hosted pins are recognised and rollback can restore upstream. The oracle is a marker prepended to index.js, checked after a fresh --frozen-lockfile install against a dead registry, or by running the global tool. The repo's pinned matrix (.github/workflows/pnpm-compatibility.yml) already covers plain hosted and vendored installs on pnpm 1–12. This ledger tracks what it doesn't.

Coverage matrix

Project modes (cells before run 3 were tested on main f6b7fb9; "v5" marks cells re-run on 2463257):

OS	pnpm	Agent: default .pnpm	Agent: global virtual store	Agent: custom virtualStoreDir	Agent: hoisted	Vendored: plain / hoisted	Vendored: workspace-file edge shapes	Hosted: plain / catalog	Hosted: trustLockfile edge shapes	Takeover vendored ⇄ hosted
Linux	7.33.7	untested	n/a	untested	untested	untested	n/a	pass (lock 5.4)	n/a (no trust)	untested
Linux	8.15.9	pass	n/a	pass (#365)	untested	untested	n/a	pass (lock 6.0)	n/a (no trust)	untested
Linux	9.15.9	pass	n/a	pass (#365)	untested	untested	untested	pass / pass; v5 rollback pass	untested	untested
Linux	10.0.0	untested	n/a	untested	untested	untested	pass (10.0 ignores user overrides)	untested	untested	untested
Linux	10.5.2 / 10.12.1	untested	fail #361 #362 (10.12.1)	untested	untested	untested	fail #360	untested	untested	untested
Linux	10.34.5	pass	fail #361 #362	pass (#365)	untested	pass	fail #360 (v5 too)	pass / pass; v5 rollback pass	fail #400 #402	untested
Linux	11.27.0 / 11.28.3	pass	fail #361 #362	pass (#365)	pass	pass	fail #400 #402	pass / pass; v5 rollback pass	fail #400 #402; pass CRLF, no-EOL, comment	v5 pass (#401 closed: pnpm_trust_lockfile_left warning)
Linux	12.8.1	pass	fail #361 #362	pass (#365)	untested	pass; fail #466 with packageManager (two-doc lock)	fail #400 #402	pass / pass; v5 rollback pass; two-doc lock pass	fail #400 #402	v5 pass (#401 closed); vendored→hosted on two-doc lock fail #466
macOS	10.34.5	pass	n/a on CI (pnpm 10 disables it)	fail #362	untested	untested	untested	untested	untested	untested
macOS	11.27.0 / 12.8.1	pass	fail #361 #362	fail #362	untested	untested	untested	untested	untested	untested
Windows	10.34.5	pass	n/a on CI	fail #362	untested	untested	untested	untested	untested	untested
Windows	11.27.0 / 12.8.1	pass	fail #361 #362	fail #362	untested	untested	untested	untested	untested	untested

Run 6 additions (main 61cfb9b, Linux):

pnpm	Hosted: sharedWorkspaceLockfile: false	Hosted: configDependencies (two-doc on 11+)	Vendored: configDependencies	Hosted: catalogs / peer-suffixed instances	Hosted: node-linker=hoisted	Agent: hard-linked CAS store
8.15.9	fail #492	untested	untested	untested	untested	untested
9.15.9	fail #492	n/a	n/a	pass / pass	pass	pass (hardlink broken, store pristine)
10.34.5	fail #492	pass (single doc)	pass	pass / untested	untested	untested
11.28.3	fail #492	pass (both docs pinned)	fail #466 (wrong doc, success)	pass / pass	untested	untested
12.8.1	fail #492	pass (both docs pinned)	fail #466 (wrong doc, success)	pass / pass	pass	pass

Run 7 additions (main 61cfb9b, Linux):

pnpm (lock)	Agent: transitive apply / rollback	Hosted: pin → fresh frozen → rollback	Agent: peer-suffixed	Alias npm: agent / hosted	Hosted: injected	Rush (hosted / vex / agent transitive)
2.25.7 (shrinkwrap.yaml, Node 10)	pass	pass, byte-exact	untested	untested	n/a	n/a
3.8.1 (5.1, Node 16)	pass	pass, byte-exact	untested	untested	n/a	n/a
4.14.4 (5.1)	pass	pass, byte-exact	untested	untested	n/a	n/a
5.18.10 (5.2)	pass	pass, byte-exact	untested	untested	n/a	n/a
6.35.1 (5.3)	pass	pass	untested	untested	n/a	n/a
7.33.7 (5.4)	untested	pass	untested	untested / pass	untested	untested
8.15.9 (6.0)	untested	pass	untested	untested / pass	pass	pass / fail #518 / untested
9.15.9 (9.0)	pass	pass	pass	pass / pass	blocked (upstream pnpm bug)	pass / fail #518 / fail #518
11.28.3	untested	pass	untested	untested / pass	untested	untested
12.8.1	pass	pass	pass	pass / pass	pass	untested

Run 8 additions (main 61cfb9b, Linux):

pnpm (lock)	Agent: hoisted + npm alias (two copies)	Agent: patchedDependencies instance	Hosted: patchedDependencies (other file / same file)	Hosted: scoped pkg	Agent: import-method copy / hardlink, hoisted, alias	Vendored: legacy lock	Hosted: legacy workspace (member dep)
5.18.10 (5.2) / 6.35.1 (5.3)	untested	untested	untested	untested	untested	pass (loud vendor_lockfile_version_unsupported)	untested
7.33.7 (5.4)	untested	pass	untested	pass	pass	pass; moved checkout: documented recovery + byte-exact rollback; workspace refused as documented	pass
8.15.9 (6.0)	untested	pass	pass / pass	pass	untested	pass, same as 7	pass
9.15.9	fail #356	pass	pass / pass (vex declines same-file)	pass	untested	n/a	n/a
10.34.5	fail #356	pass	pass / pass	untested	pass	n/a	n/a
11.28.3	untested	n/a (package.json field ignored)	pass / pass	untested	pass	n/a	n/a
12.8.1	fail #356	n/a (package.json field ignored)	pass / pass	pass	untested	n/a	n/a

Run 9 additions (main 61cfb9b, Linux):

pnpm	Hosted: gitBranchLockfile (both locks / branch lock only)	Hosted: lockfileIncludeTarballUrl pin + fresh frozen	Rollback byte-exact with tarball URLs	Hosted: catalog + patchedDependencies + overrides	Hosted from workspace member cwd
9.15.9	n/a (no branch lock written)	pass	fail #557	untested	untested
10.34.5	fail #556 / untested	pass	untested	untested	untested
11.28.3	fail #556 / untested	untested	untested	untested	untested
12.8.1	fail #556 / fail #556	pass	fail #557	pass (vex, rollback)	no-op + redirect_npm_no_lockfile (not filed; see #417)

Default isolated linker + alias: pass on 7.33.7 / 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 (one shared .pnpm copy).

#492 also reproduces on pnpm 7.33.7 (there's no root lock at all, only redirect_pnpm_no_lockfile).

Hosted --frozen-lockfile [--offline] over an upstream node_modules or warm store (run 5): VEX stays honest on 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 (pass).

"Edge shapes" means a whole-document flow mapping, a ... document end, and quoted or key : top-level keys.

Global mode (-g, v5 main 2463257):

OS	pnpm	pnpm root -g layout	scan -g report (direct)	scan -g transitive	get/apply -g direct	rollback -g	vex -g	duplicate copies across install groups	--mode hosted refusal
Linux	7.33.7 / 8.15.9 / 9.15.9 / 10.34.5	global/5/node_modules, virtualStoreDir: ../.pnpm	pass	fail #362 (fixed by PR #365)	pass	pass, byte-exact	pass	n/a (one shared .pnpm)	pass (9, 11)
Linux	11.0.0 / 11.27.0 / 11.28.3 (default)	global/v11/<hash>/ → global virtual store store/v11/links	pass	fail #362 (GVS half; also #361)	pass (writes the shared links dir)	pass	untested	pass (one shared copy)	pass
Linux	11.28.3, enableGlobalVirtualStore: false	global/v11/<hash>/node_modules/.pnpm	untested	untested	pass	untested	untested	fail #435	untested
Linux	12.4.2 / 12.8.1 / 12.8.2	global/v11/<hash>/node_modules/.pnpm	pass	pass	pass	pass, byte-exact	pass	fail #435 (regression since b32711f)	pass
Linux	any	unwritable global prefix	blocked (sandbox runs as root)
macOS / Windows	all		untested	untested	untested	untested	untested	untested	untested

Backlog

0. Maintainer request (global -g mode): the Linux cells are done. Still to do: macOS and Windows (corepack, standalone and npm-installed pnpm; PNPM_HOME with spaces or unicode; Windows %LOCALAPPDATA%\pnpm), and an unwritable prefix as a non-root user. Full checklist in the 20261001T040000Z entry. Needs a probe branch.
1. Delete the stale probe branch bughunt/pnpm/20260930-virtual-store. git push --delete failed through the git proxy in runs 1 and 3, and was denied by the permission policy in runs 2 and 5–9, so a maintainer needs to do it. macOS and Windows probes stay on hold until branch cleanup works.
2. Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556 follow-ups: vendored mode with gitBranchLockfile, merging branch lockfiles after a hosted pin, and agent vex on the branch.
3. Hosted and vendored from a workspace member cwd, and lockfile-dir / lockfileDir pointing at a parent directory.
4. Re-verify npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 (with Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493) when PR Fix npm crawler missing configured install roots (#493, #518) #520 lands. Then Rush subspaces (common/config/subspaces/*) and Rush + pnpm 10.
5. pnpm patch-commit after a hosted pin, then rollback. Agent hoisted with nested duplicate copies (pnpm side of Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516). package-import-method=clone on reflink (needs CI).
6. Re-verify Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492, Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466, Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361, the global-virtual-store half of Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362, Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435, Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556 and Hosted pnpm rollback drops the upstream tarball: URL from locks written with lockfileIncludeTarballUrl, so the restore isn't byte-exact #557 when fixes land.
7. Vendored on Windows and macOS (autocrlf: expect the vendor_lockfile_crlf_unsupported refusal; check that hosted handles the same checkout).

Known non-bugs

• patches-api.socket.dev and (for the Rust client) registry.npmjs.org are unreachable from the sandbox. Mock the API and point SOCKET_NPM_REGISTRY at a mirror.
• v5 recognises hosted pins only on the configured patch server. Against a mock without SOCKET_PATCH_SERVER_URL, rollback says "Manifest not found". That's a fixture artifact.
• v5 hosted rollback and takeover keep a user-edited trustLockfile: true and warn pnpm_trust_lockfile_left. A workspace file that exactly matches hosted mode's scaffold is deleted, including a user's own packages: ['.'] file that the trust append made identical to it (CLI_CONTRACT, upstream restore).
• pnpm 10 ignores enableGlobalVirtualStore when CI is set, so the global-virtual-store cells don't engage on GH runners with pnpm 10.
• pnpm 12 (and 11) ignore .npmrc for virtual-store-dir / enable-global-virtual-store. Put them in pnpm-workspace.yaml, or in the global config.yaml.
• pnpm 11+ pnpm root -g / pnpm add -g fail unless $PNPM_HOME/bin is on PATH. Put it there in fixtures.
• Vendored refusals that are intended, loud and fail-closed: a CRLF pnpm-lock.yaml or pnpm-workspace.yaml (vendor_lockfile_crlf_unsupported), a BOM package.json (vendor_pkg_json_unsupported), an inline / flow overrides: mapping (vendor_override_conflict, unit-tested), and patchedDependencies on the target (vendor_lock_entry_unsupported; the detail wrongly says "peer-suffixed snapshot key", which is cosmetic).
• Vendored vex attests from the committed artifact plus lock wiring even when the tree isn't installed. That's by design (CLI_CONTRACT "Manifest-less VEX").
• vex -g needs --product outside a project ("Could not auto-detect a top-level product PURL").
• Agent-mode get <purl> for an uninstalled package reports success, applied: 1 when another manifest entry applies. The nested apply fails only when nothing matches. It's not pnpm-specific (noted on Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362).
• A compact single-line package.json comes back 2-space-indented after vendor + rollback. There's no indent to detect, and indented files round-trip byte-exactly, so it's cosmetic.
• Hosted on pnpm 9 over an existing upstream node_modules: a frozen install keeps the upstream bytes. That's documented in the redirect_pnpm_trust_lockfile warning, and VEX doesn't attest it.
• pnpm 12 warns that package.json pnpm.overrides is ignored on vendored projects. The workspace-file override is what takes effect, so this is noise only.
• A vex --output /dev/stdout hang when stdout is a pipe is not pnpm-specific.
• Vendored refuses pnpm catalogs (catalogs: entry) and peer-suffixed snapshot keys with vendor_lock_entry_unsupported ("this lock shape is not supported yet"). It's loud and writes nothing. Hosted handles both.
• pnpm 10's configDependencies copy (node_modules/.pnpm-config/) stays unpatched under hosted mode while VEX attests the regular copy. Config deps run only at install time, and pnpm 10 keeps their integrity in pnpm-workspace.yaml.
• On v5, vendoring always downloads its artifact from the patch service (--vendor-source build was removed), so offline vendoring with only a staged manifest fails with vendor_service_offline_conflict. Fixtures need the mock grant to match the manifest UUID.
• rush update --full re-resolves the Rush lock and drops the hosted pin, like pnpm update. VEX then honestly reports nothing to attest.
• pnpm 9.15.9's frozen install fails on its own unmodified lock when a workspace uses dependenciesMeta.injected ("importer dependencies meta (undefined) doesn't match"). That's upstream pnpm, not socket-patch.
• Old pnpm needs an old Node (≤ 6 needs Node 16, ≤ 2 needs Node 10), and pnpm 3 takes --store rather than --store-dir. Fixture notes.
• Agent apply over a pnpm patchedDependencies edit to the same file overwrites it with the verified patched content and warns content_mismatch_overwritten (documented default mismatch policy; --strict refuses). Hosted composes both patches, and vex then declines (no_applicable_patches), because the file matches neither hash.
• Hosted on pnpm 11/12 respects an explicit trustLockfile: false (any YAML spelling) and warns redirect_pnpm_trust_lockfile with the remedy. The following frozen install fails, which is documented.
• Vendored refuses pnpm ≤ 6 locks (5.x up to 5.3) with vendor_lockfile_version_unsupported, and pnpm 7/8 workspace locks with vendor_lock_entry_unsupported. pnpm 7/8 vendored locks carry an absolute file: specifier (vendor_pnpm_legacy_absolute_specifier), so a moved checkout needs pnpm install --offline --no-frozen-lockfile once. Both are documented.
• pnpm 11+ ignores package.json pnpm.patchedDependencies. Put it in pnpm-workspace.yaml.
• A dead-registry fresh install fails when the fixture has any unpatched dependency (it still needs the registry). Use the live registry for those fixtures, or patch every dependency.

[github-actions[bot]]

[agent] 2026-09-30: pnpm bug-hunt run

Tested: main f6b7fb9 (CLI 4.0.0 workspace version), latest release 4.0.0 (previous 3.3.0, both installed from npm for comparison). pnpm 7.33.7, 8.15.9, 9.15.9, 10.0.0, 10.5.2, 10.12.1, 10.34.5, 11.27.0, 12.4.2 and 12.8.1 (the current latest), on Node 22 in the sandbox. Patch data is a hand-staged .socket/manifest.json plus blobs (agent and vendored mode) and a local Python mock of the patch API and tarball routes (hosted mode). No secrets.

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

Cells

• fail Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361: agent apply / rollback with enableGlobalVirtualStore. Writes land in the shared <store>/links dir: an unrelated project is patched, and one project's rollback unpatches another. Fails on Linux with pnpm 10.12.1–12.8.1, and on the macOS and Windows probe with pnpm 11.27.0 and 12.8.1. Releases 3.3.0 and 4.0.0 behave the same.
• fail Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362: agent apply on a transitive dep with a custom virtualStoreDir (pnpm 8–12) or the global virtual store (10.12+) is reported package_not_installed. Fails on Linux, macOS and Windows.
• fail Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360: vendored mode on pnpm 10.5.2, 10.12.1 and 10.34.5 with user overrides: in pnpm-workspace.yaml. vendor succeeds, then a fresh --frozen-lockfile install fails with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH, and a re-lock drops the user's overrides. Passes on 10.0.0, 11.27.0 and 12.8.1. Release 4.0.0 has the same bug.
• pass: vendored lifecycle on pnpm 10.34.5 and 11.27.0 (vendor → fresh frozen --offline install → vex → revert). Also passes with nodeLinker: hoisted and with a flow packages: ['.'] plus catalog: {…}.
• pass: agent apply / rollback with nodeLinker: hoisted (pnpm 11.27.0). The CAS file is not written through.
• pass: hosted scan --mode hosted on pnpm 11.27.0 against the mock API: fresh frozen install with an empty store gets the patched bytes. trustLockfile handling passes for CRLF, no-EOL and trailing-comment trustLockfile: true workspace files.
• fail, not filed (queued in the backlog): hosted trustLockfile append and vendored overrides append on a whole-document flow pnpm-workspace.yaml ({packages: [.]}) or a file ending in .... The command reports success, then pnpm can't parse the file ("end of the stream or a document separator is expected"). Reproduced on pnpm 11.27.0.
• refused, as designed: vendored with a CRLF pnpm-workspace.yaml or pnpm-lock.yaml (vendor_lockfile_crlf_unsupported), a BOM package.json (vendor_pkg_json_unsupported), inline overrides: {} / {x: y} (vendor_override_conflict, covered by the inline_workspace_overrides_mapping_is_refused unit test), and patchedDependencies on the target (vendor_lock_entry_unsupported).

Issues

• Filed Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361 and Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362.

False positives ruled out

• Vendored vex attesting not_affected in a fresh clone whose install failed is by design: vendored VEX stands on the committed artifact plus lock wiring (CLI_CONTRACT "Manifest-less VEX"; vendored_tree_out_of_sync is a warning only).
• The global virtual store "not reproducing" with pnpm 10.34.5 on GH runners is expected: pnpm 10 disables it when CI is set. pnpm 11+ keeps it.
• vex --output /dev/stdout hangs when stdout is a pipe. It's not pnpm-specific, so it wasn't filed here; it's noted for whoever owns the CLI.

Probe

• bughunt/pnpm/20260930-virtual-store, run https://github.com/SocketDev/socket-patch/actions/runs/36759597534 (ubuntu, macos and windows × pnpm 10.34.5, 11.27.0 and 12.8.1). The branch could not be deleted: the git proxy dropped git push --delete three times ("unexpected disconnect while reading sideband packet"). A maintainer needs to delete it.

Next

1. Flow-style or ...-terminated pnpm-workspace.yaml breaking under the hosted trust append and the vendored overrides append. Confirm on pnpm 10 and 12, then file.
2. Hosted mode on pnpm 7/8 (lock 5.4/6.0) workspaces with catalogs, and peer-suffixed instances with the mock API. Then Rush/subspace locks.
3. The vendored takeover (hosted → vendored → hosted) on pnpm 11/12, plus rollback byte-exactness of pnpm-workspace.yaml.
4. Agent apply with injected workspace deps (dependenciesMeta.injected) and package-import-method=clone/copy.
5. pnpm 1–6 legacy layouts (node_modules/.registry.npmjs.org, pnpm 4/5 nested host dirs) on Node 16 for agent mode.

[github-actions[bot]]

[agent] 2026-10-01: pnpm bug-hunt run

Tested: main f6b7fb9 (unchanged since run 1), latest release 4.0.0 (npm @socketsecurity/socket-patch@4.0.0, used for the regression checks). pnpm 7.33.7, 8.15.9, 9.15.9, 10.34.5, 11.27.0 and 12.8.1, on Node 22 in the Linux sandbox. Hosted mode ran against a local Python mock of the patch API and tarball routes, modelled on e2e_redirect_pnpm_build.rs. Vendored mode ran from a hand-staged .socket/manifest.json plus blobs. The oracle is a marker on left-pad/index.js after a fresh --frozen-lockfile install against a dead registry.

Re-triage

• Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361 and Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 are still open. Main hasn't moved, so there's no fix to verify. Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 has draft PR Fix npm crawler missing relocated dependency stores (#359, #362) #365 (the custom virtualStoreDir half; the global-virtual-store half stays open per the maintainer note). Nothing to close.

Cells

• fail Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400: a whole-document flow pnpm-workspace.yaml ({packages: [.]}), or one ending in .... The hosted trustLockfile: true append and the vendored overrides: append both write YAML pnpm can't load, and both report success. Hosted fails on 10.34.5, 11.27.0 and 12.8.1; vendored fails on 11.27.0 and 12.8.1. Release 4.0.0 behaves the same.
• fail Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401: hosted → vendored takeover (vendor and scan --mode vendored) on pnpm 11.27.0 and 12.8.1 leaves trustLockfile: true plus an orphan redirect_pnpm_workspace_trust ledger edit with no records. vendor --revert doesn't remove it either. npm's .npmrc gets a last-one-out unwind in the same situation. Release 4.0.0 behaves the same.
• fail pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402: a quoted or space-before-colon top-level "trustLockfile": false, 'trustLockfile': true, trustLockfile : false, or a quoted "overrides":, is not recognised, so a duplicate key is appended (duplicated mapping key). Hosted fails on 10.34.5, 11.27.0 and 12.8.1; vendored fails on 11.27.0 and 12.8.1. Release 4.0.0 behaves the same.
• pass: hosted baseline (no workspace file) on pnpm 7.33.7 (lock 5.4), 8.15.9 (lock 6.0) and 9.15.9 (lock 9.0, trust file created). The fresh frozen install is patched.
• pass: hosted with a catalog: dependency on pnpm 9.15.9, 10.34.5, 11.27.0 and 12.8.1.
• pass: the full cycle vendor → hosted takeover → vendored takeover → bare rollback on pnpm 11.27.0. Every fresh frozen install is patched, and the lock, pnpm-workspace.yaml and a tab-indented package.json come back byte-identical.
• pass: scoped rollback <purl> after hosted only on pnpm 11.27.0 and 12.8.1 (2 runs each). The trust line is removed through whole-ledger replay.

Issues

• Filed Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400, Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401 and pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402.

False positives ruled out

• A compact single-line package.json comes back 2-space-indented after vendor + rollback. A one-line file has no indent to detect, and an indented file round-trips byte-exactly, so this wasn't filed. It's cosmetic, and JsonLayout work in PR Fix JSON writers dropping CRLF/BOM/indent (#324, #351) #357 is nearby.
• A scan --mode vendored re-run that returned status: error after a bare rollback came from the fixture: rollback garbage-collected the staged blobs, and the mock doesn't serve blob content.

Probe

• No new probe branches. git push --delete of the stale bughunt/pnpm/20260930-virtual-store was denied by the session's permission policy, so new probe branches couldn't be cleaned up either. A maintainer needs to delete bughunt/pnpm/20260930-virtual-store.

Next

1. Hosted: Rush / subspace locks (common/config/rush/pnpm-lock.yaml) and peer-suffixed instances in a workspace with the mock harness.
2. Hosted --frozen-lockfile --offline with a warm store that holds the upstream tarball, on pnpm 9–12. Confirm the documented warm-cache caveat and that vex doesn't attest unpatched bytes.
3. Agent: dependenciesMeta.injected and package-import-method=clone|copy, and pnpm 1–6 legacy layouts on Node 16.
4. Vendored on Windows / macOS autocrlf checkouts (needs a probe branch; blocked until probe-branch deletion is allowed).
5. Re-check Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400–pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402 once fixes land, including both modes and pnpm 12.

[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 pnpm version and on Linux, macOS and Windows.

Where pnpm puts global installs: pnpm add -g; discovery via pnpm root -g (PNPM_HOME). Cover pnpm 7–10 global-dir layouts, the global virtual store, and pnpm installed through corepack, standalone and npm.

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 pnpm 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 pnpm 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 × pnpm 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: pnpm bug-hunt run

Tested: main 2463257 (#277, the v5 consolidation; the CLI still reports 4.0.0), latest release 4.0.0 (npm @socketsecurity/socket-patch@4.0.0) for regression checks, and draft PR #365's head 80f4a71 for the global cells. pnpm 7.33.7, 8.15.9, 9.15.9, 10.34.5, 11.0.0, 11.27.0, 11.28.3, 12.4.2, 12.8.1 and 12.8.2, on Node 22 in the Linux sandbox. The patch API is a local Python mock (batch, by-package, view with inline blobs, package grant, hosted tarball, plus a /registry/<name>/<ver> mirror). This run focused on the maintainer's global (-g) request.

v5 harness note: hosted pins are recognised only on the named patch server, so set SOCKET_PATCH_SERVER_URL=<mock>. Rollback restores upstream from the registry, and the Rust client can't reach registry.npmjs.org from the sandbox, so set SOCKET_NPM_REGISTRY=<mock>/registry. Without these, rollback reports "Manifest not found" or cannot restore … upstream registry entry. Both are fixture artifacts.

Re-triage

• Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401: closed as fixed by v5 prerelease: scan → vex → vendor workflow, hosted by default #277. v5 keeps no redirect ledger. The hosted → vendored takeover (vendor and scan --mode vendored) on pnpm 11.27.0 and 12.8.1 now emits the documented pnpm_trust_lockfile_left advisory, and a workspace file that exactly matches the scaffold is deleted. Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401 (comment)
• Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360: still reproduces on 2463257 (pnpm 10.34.5, 2/2, through scan --mode vendored). Comment: Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360 (comment)
• Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400 and pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402 were already re-triaged on 2463257 by the triager (draft PR Fix pnpm-workspace.yaml key detection and appends (#400, #402) #414). Not repeated.

Cells (global mode, Linux)

• pass: scan -g (report only) lists globally installed direct packages on pnpm 7.33.7, 8.15.9, 9.15.9, 10.34.5, 11.27.0 and 12.8.1. -g inside a project doesn't leak project packages, and a scan without -g never reads the global dir. SOCKET_GLOBAL=1 and --global-prefix $(pnpm root -g) behave the same as -g.
• pass: scan -g --mode hosted refuses ("global installs have no project lockfile to redirect"), exits 2 and writes nothing.
• pass: scan -g --mode agent, get -g, apply -g, rollback -g (byte-exact) and vex -g --product … on direct global deps, pnpm 7.33.7–12.8.1. vex -g omits a copy that was manually reverted (not_applied).
• fail Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (commented): transitive deps of global packages are invisible on pnpm 7–10, because the default -g layout records virtualStoreDir: ../.pnpm. The same happens on pnpm 11, where -g uses the global virtual store by default. PR Fix npm crawler missing relocated dependency stores (#359, #362) #365 fixes pnpm 7–10 -g and leaves pnpm 11 out by design. Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (comment)
• fail Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 (new, regression): pnpm 12.4.2, 12.8.1 and 12.8.2, and 11.28.3 with enableGlobalVirtualStore: false. Each pnpm add -g gets its own global/v11/<hash>/node_modules/.pnpm. When two groups both hold left-pad@1.3.0, get -g / apply -g patch only one, report success, and vex -g attests not_affected while the global tool loads the unpatched copy. The result depends on listing order, and it's deterministic on tmpfs. First bad commit is b32711f (Support vlt in hosted, vendored and agent modes #269); 0b4e645 and release 4.0.0 pass. Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435
• pass: the project-mode analogue (a sharedWorkspaceLockfile: false workspace with two .pnpm stores) patches both copies on 10.34.5 and 12.8.2.
• pass: hosted → rollback on a packages/* workspace, pnpm 9.15.9 / 10.34.5 / 11.27.0 / 12.8.1. The lock is byte-exact, the trust line is kept with a pnpm_trust_lockfile_left warning, and a fresh frozen install passes.
• blocked: an unwritable global dir (item 6 of the maintainer list). The sandbox runs as root.
• blocked: macOS and Windows. There's no probe branch, because git push --delete bughunt/pnpm/20260930-virtual-store failed again ("unexpected disconnect while reading sideband packet").

Issues

• Filed Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435.
• Commented on Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 and Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360. Closed Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401.

False positives ruled out

• "rollback deletes the user's pnpm-workspace.yaml": only a user file that becomes byte-identical to hosted mode's scaffold (packages: ['.'] plus the appended trustLockfile: true) is deleted. That's documented in CLI_CONTRACT.md (upstream restore, npm family).
• get <uninstalled purl> reports success, applied: 1 when another manifest patch applies. The nested apply fails only when no entry matches. It's not pnpm-specific, so it wasn't filed; it's noted on Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362.
• A rollback -g that looked "not byte-exact" came from a fixture polluted by an earlier 4.0.0 scan in the same global dir. Clean re-runs are byte-exact.

Next

1. Global mode on macOS and Windows (corepack and standalone pnpm, PNPM_HOME with spaces or unicode), once the stale probe branch is deleted.
2. Re-run the hosted edge shapes against v5 (Rush / subspace locks, peer-suffixed workspace instances, catalogs), using the SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY harness.
3. Hosted --frozen-lockfile --offline with a warm store that holds the upstream tarball, on pnpm 9–12, plus the vex honesty check.
4. Agent mode: dependenciesMeta.injected, package-import-method=clone|copy, and pnpm 1–6 on Node 16.
5. Re-verify Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 and Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 when PR Fix npm crawler missing relocated dependency stores (#359, #362) #365 or a fix lands.

[github-actions[bot]]

[agent] 2026-10-01: pnpm bug-hunt run

Tested: main 2463257 (unchanged since run 4; the CLI reports 4.0.0), latest release 4.0.0. pnpm 9.15.9, 10.34.5, 11.28.3 and 12.8.1 on Node 22 in the Linux sandbox. The patch API is a local Python mock (batch, by-package, package grant, view, hosted tarball, /registry mirror), run with SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY pointed at it.

Re-triage

• Skipped. Main hasn't moved since run 4, which re-triaged Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401 (closed), Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 and Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 on 2463257.

Cells

• New shape: pnpm 12 two-document lock. pnpm 12.8.1 writes pnpm-lock.yaml as two YAML documents (an env document holding packageManagerDependencies / @pnpm/exe.*, then the project lock) whenever package.json has packageManager. pnpm 11.28.3 and 10.34.5 write a single document for the same input.
  • pass: hosted scan --mode hosted pins the entry in document 2. A fresh dead-registry frozen install lands the patched bytes, vex attests not_affected, and rollback restores the lock byte for byte. It needs manage-package-manager-versions=false, or a reachable registry for pnpm itself.
  • fail Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 (new): vendored on the two-doc lock refuses with vendor_lock_entry_not_found. A project vendored first and turned two-doc later breaks on every unwind. vendor --revert exits 0 with success, rollback reports vendoredKept "left untouched", and the default scan takeover exits 0 having deleted the ledger. All three leave 5 file:.socket/vendor refs, so the next frozen install fails with ERR_PNPM_OUTDATED_LOCKFILE. Root cause: section_bounds takes the first packages: / importers: header. Reproduced 2/2, and the single-doc control passes. Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466
• pass (VEX honesty): hosted followed by pnpm install --frozen-lockfile [--offline] over an existing upstream node_modules and warm store, on 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1. pnpm 9 keeps the upstream tree, and pnpm 10 and 11 --offline fail with ERR_PNPM_NO_OFFLINE_TARBALL. vex emits no statement whenever the installed bytes are unpatched, and attests not_affected only when the marker is present.
• blocked: macOS and Windows. git push --delete of the stale probe branch was denied by the session's permission policy, so no new probe branches were pushed (they couldn't be cleaned up).

Issues

• Filed Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466.

False positives ruled out

• Hosted on pnpm 9 plus an existing node_modules: the frozen install keeps the upstream bytes. That's documented in the redirect_pnpm_trust_lockfile warning ("existing node_modules or a warm pnpm store can still contain upstream files"), and VEX doesn't attest it.
• 4.0.0 vendored on the two-doc lock fails with no_local_source against the v5-shaped mock. That's a mock incompatibility, so it can't be used for a bisect.
• pnpm 12 warns The "pnpm" field in package.json is no longer read … pnpm.overrides on vendored projects. The workspace-file override is what takes effect, so this is noise only. Noted on Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466.

Next

1. Two-doc lock, part 2: pnpm 10.x / 11.x configDependencies (does an env document appear there?), and two-doc plus a packages/* workspace in hosted mode.
2. Global (-g) mode on macOS and Windows, once a maintainer deletes bughunt/pnpm/20260930-virtual-store.
3. Hosted v5: Rush / subspace locks, peer-suffixed workspace instances, catalogs.
4. Agent: dependenciesMeta.injected, package-import-method=clone|copy, pnpm 1–6 on Node 16.
5. Re-verify Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435, Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (PR Fix npm crawler missing relocated dependency stores (#359, #362) #365), Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400 and pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402 (PR Fix pnpm-workspace.yaml key detection and appends (#400, #402) #414) when they land.

[github-actions[bot]]

[agent] 2026-10-01: pnpm bug-hunt run

Tested: main 61cfb9b (adds #365, which fixes the custom-virtualStoreDir half of #362, and #414, which fixes #400 / #402), latest release 4.0.0. pnpm 8.15.9, 9.15.9, 10.34.5, 11.28.3 and 12.8.1 on Node 22 in the Linux sandbox, run against the local Python patch-API mock (SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY). Note: on v5, vendored downloads its artifact from the service (--vendor-source build was removed), so the mock's grant must use the staged manifest's UUID.

Re-triage

• Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362: the custom virtualStoreDir half is fixed on 8.15.9 / 9.15.9 (.npmrc) and on 10.34.5 / 11.28.3 / 12.8.1 (workspace file). Apply patches the transitive copy, Node loads it, and rollback restores it. The global-virtual-store half still reports package_not_installed on 11 and 12, as PR Fix npm crawler missing relocated dependency stores (#359, #362) #365 intended, so the issue stays open. Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (comment)

Cells

• fail Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 (new): hosted on a workspace with sharedWorkspaceLockfile: false reads only the root lock, ignores packages/*/pnpm-lock.yaml, and reports success, exit 0, redirected: 0. Seen on 8.15.9 / 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 (2/2 on 9 and 12). The --cwd packages/a workaround creates a nested pnpm-workspace.yaml, and the root frozen install then fails with ERR_PNPM_TARBALL_URL_MISMATCH on 12. Vendored refuses loudly (vendor_lock_entry_not_found). Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492
• fail Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 (comment): configDependencies makes pnpm 11.28.3 and 12.8.1 write a two-document lock (10.34.5 doesn't). When the target is both a config dep and a regular dep, vendor exits success with all 6 file:.socket/vendor refs in document 1, and the next frozen install fails ("Cannot update configDependencies…" / ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE). 2/2 on each version. vendor --revert restores byte for byte. Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 (comment)
• pass: hosted with configDependencies on 10.34.5 / 11.28.3 / 12.8.1. On 11 and 12 both documents are pinned and the patched bytes land in node_modules/is-number and .pnpm-config/is-number. Rollback is byte-exact (it leaves trustLockfile with pnpm_trust_lockfile_left, a known non-bug).
• pass: hosted with catalogs (catalog: in a member, plus a transitive consumer) on 9 / 10 / 11 / 12. Frozen install is patched for both, and rollback restores the lock.
• pass: hosted with peer-suffixed instances (use-sync-external-store@1.2.0 under react 17 and 18 in two members) on 9 / 11 / 12. Both instances are patched, and rollback restores the lock.
• pass: hosted with node-linker=hoisted on 9.15.9 / 12.8.1. Frozen install is patched, vex says not_affected, and rollback is byte-exact.
• pass: agent mode against a hard-linked CAS store (package-import-method=hardlink) on 9.15.9 / 12.8.1. Apply breaks the hardlink (nlink 3→1), the store and sibling projects stay pristine, and a warm-store install elsewhere gets upstream bytes.
• refused as documented: vendored with catalogs and with peer-suffixed snapshot keys (vendor_lock_entry_unsupported, loud, nothing written).
• blocked: macOS and Windows. git push --delete of bughunt/pnpm/20260930-virtual-store was denied by the permission policy again, so no probe branches were pushed.

Issues

• Filed Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492. Commented on Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 and Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362.

False positives ruled out

• pnpm 10 configDependencies copy (node_modules/.pnpm-config/<pkg>) stays unpatched under hosted mode, while vex attests not_affected for the regular copy. Config deps run only at install time (pnpmfile / config) and aren't part of the product's runtime graph, and on pnpm 10 their integrity lives in pnpm-workspace.yaml. Not filed.
• Hosted rollback keeps trustLockfile: true in a pre-existing workspace file with pnpm_trust_lockfile_left (stateless v5; known non-bug).
• Offline frozen installs of peer fixtures failed with ERR_PNPM_NO_OFFLINE_TARBALL because of an empty store (fixture error). They pass online with an empty store.

Next

1. Re-verify Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 and Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 when fixes land. For Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492, also check pnpm 7 (shared-workspace-lockfile=false with lock 5.4) and rollback / vex once member locks are pinned.
2. Global (-g) mode, and vendored on macOS and Windows, once a maintainer deletes bughunt/pnpm/20260930-virtual-store.
3. Rush / subspace hosted locks with real rush install (@microsoft/rush), including preventManualShrinkwrapChanges.
4. Agent: dependenciesMeta.injected, package-import-method=clone|copy, pnpm 1–6 on Node 16.
5. Re-verify Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361, Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 when fixed.

[github-actions[bot]]

[agent] 2026-10-02: pnpm bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; CLI 4.0.0), latest release 4.0.0. Ran on Linux with pnpm 2.25.7 (Node 10), 3.8.1 / 4.14.4 / 5.18.10 / 6.35.1 (Node 16), and 7.33.7 / 8.15.9 / 9.15.9 / 11.28.3 / 12.8.1 (Node 22), plus Rush 5.180.0 with pnpm 8.15.9 and 9.15.9. I rebuilt the local Python patch-API mock (batch, by-package, package grant, view, hosted tarball, /registry), and agent mode ran from a hand-staged manifest plus before/after blobs.

Re-triage

• Main hasn't changed since run 6, so there was nothing new to re-check. Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361, Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (GVS half), Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435, Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 and Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 are all still open.

Cells

• fail npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 (new): in a Rush repo (pnpm 9.15.9 lock 9.0, and 8.15.9 lock 6.0), the npm crawler skips common/temp (SKIP_DIRS has "temp"). Transitive deps installed in common/temp/node_modules/.pnpm therefore show as notInstalled. After scan --mode hosted pins common/config/rush/pnpm-lock.yaml, vex attests not_affected from the lockfile basis while the installed store copy is still upstream. On plain pnpm in the same state, vex correctly says not_applied. Agent apply for the same transitive dep reports package_not_installed. Direct deps pass. Reproduced 2/2. npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518
• pass: hosted on Rush. scan --mode hosted pins the Rush lock with redirect_rush_repo_state_stale. With preventManualShrinkwrapChanges: true, rush install refuses until rush update, as documented. The pin survives rush update. A cold rush install, a warm one, and rush install --purge all install the patched bytes. vex attests correctly once the tree is patched.
• fail Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 (comment): pnpm 7.33.7 with shared-workspace-lockfile=false writes no root lock at all. Hosted then exits success / redirected: 0 with only redirect_pnpm_no_lockfile, and the member lock stays unpinned. Reproduced 2/2. Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 (comment)
• pass: legacy layouts. Agent apply and rollback on a transitive dep (Node loads the patched copy), plus hosted pin → fresh frozen install with an empty store → byte-exact rollback, all pass on:
  • pnpm 2.25.7 (shrinkwrap.yaml, node_modules/.registry.npmjs.org/…)
  • pnpm 3.8.1 (lock 5.1, same layout)
  • pnpm 4.14.4 (lock 5.1, .pnpm/registry.npmjs.org/<name>/<ver>)
  • pnpm 5.18.10 (lock 5.2)
  • pnpm 6.35.1 (lock 5.3)
• pass: agent apply and rollback on peer-suffixed instances (use-sync-external-store@1.2.0 under react 17 and 18) on 9.15.9 / 12.8.1. Both copies are patched and both are restored.
• pass: npm aliases (isnum: npm:is-number@7.0.0). Agent mode passes on 9 / 12. Hosted passes on 7 (lock 5.4), 8 (6.0), 9, 11 and 12: the fresh frozen install is patched.
• pass: hosted with dependenciesMeta.injected on 8.15.9 / 12.8.1.
• blocked: hosted injected on 9.15.9. pnpm 9.15.9's own frozen install fails on the unmodified lock ("importer dependencies meta (undefined) doesn't match…"), which is an upstream pnpm bug.
• blocked: macOS and Windows. Deleting bughunt/pnpm/20260930-virtual-store was denied by the permission policy again, so no probe branches were pushed.

Issues

• Filed npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518. Commented on Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492.

False positives ruled out

• pnpm 9.15.9's frozen install failing with injected workspace deps reproduces without socket-patch, so it's upstream.
• rush update --full drops the hosted pin, because it re-resolves the lock. That's like pnpm update, and VEX then honestly reports nothing to attest.
• pnpm 3 rejects --store-dir (it wants --store), and pnpm ≤ 6 can't run on Node 22 / pnpm ≤ 2 can't run on Node 16. Those are fixture issues.
• scan --offline refusing with "requires network access" is documented (strict airgap).

Next

1. Re-verify npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 once fixed, and test Rush subspaces (common/config/subspaces/*/pnpm-lock.yaml) plus the Rush + pnpm 10 cells.
2. Global -g mode and vendored mode on macOS / Windows, once a maintainer deletes the stale probe branch.
3. Agent package-import-method=copy|clone, and agent mode on pnpm 7 / 10 / 11 with aliases and injected deps.
4. Re-verify Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 / Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 / Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360 / Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361 / Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 when fixes land.
5. Vendored mode on legacy locks (pnpm ≤ 6): expect a loud refusal or a working round-trip.

[github-actions[bot]]

[agent] 2026-10-02: pnpm bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; CLI 4.0.0), latest release 4.0.0. Ran on Linux with pnpm 5.18.10 / 6.35.1 (Node 16), and 7.33.7 / 8.15.9 / 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 (Node 22). I rebuilt the local Python patch-API mock (batch, by-package, package grant, view with inline blobs, hosted tarball, /registry mirror), run with SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY pointed at it. Agent mode ran from a hand-staged manifest plus blobs.

Re-triage

• Main hasn't changed, so there was nothing new to re-check. npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 now has a maintainer-claimed draft fix (Fix npm crawler missing configured install roots (#493, #518) #520), shared with Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493. Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361, Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (GVS half), Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435, Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466, Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 and npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 are all still open.

Cells

• fail npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (comment, not a new issue): with node-linker=hoisted, an npm alias ("isnum": "npm:is-number@7.0.0") next to a hoisted is-number@7.0.0 gives two physical copies. Agent apply reports success, applied 1, patches node_modules/is-number only, and leaves node_modules/isnum (what require('isnum') loads) unpatched. vex attests not_affected. Reproduced 2/2 on 9.15.9, 10.34.5 and 12.8.1. It's the same find_by_purls path as npm's npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356. npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (comment)
• pass: pnpm's default isolated linker with the same alias. The alias symlinks into the shared .pnpm/is-number@7.0.0, so the one copy gets patched.
• pass: patchedDependencies interplay. Two shapes: a pnpm patch on a different file (README.md), and one on the same file (index.js).
  • Agent apply / rollback on the _patch_hash= instance passes on 7.33.7 / 8.15.9 / 9.15.9 / 10.34.5. On 11.28.3 / 12.8.1 it only ran without the pnpm patch, because pnpm 11+ ignores package.json pnpm.patchedDependencies. The same-file shape overwrites pnpm's change with content_mismatch_overwritten, which is documented.
  • Hosted on 8.15.9 / 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 (workspace-file patchedDependencies on 11+) passes for both shapes: the lock pin lands, and a fresh frozen install from an empty store gets both the Socket patch and the pnpm patch.
  • vex attests not_affected for the different-file shape. For the same-file shape it declines with no_applicable_patches, because the installed file matches neither hash. That's conservative and honest.
  • Hosted rollback restores the lock.
• pass: hosted on a scoped package (@isaacs/string-locale-compare) on 7.33.7 (lock 5.4 /@s/n/v), 8.15.9 (6.0 /@s/n@v), 9.15.9 and 12.8.1 (quoted 9.0 keys). The fresh frozen install is patched.
• pass (documented): hosted on 11.28.3 / 12.8.1 with an explicit trustLockfile: false | False | no | 'false'. The setting is respected, the warning names it and gives the remedy, and the frozen install fails (or on 11, 'false' / no installs patched). This matches the CLI_CONTRACT "explicit user settings preserved" rule.
• pass: agent transitive apply / Node load / rollback, with the store kept pristine, on 7.33.7 / 10.34.5 / 11.28.3 for package-import-method=copy, package-import-method=hardlink, node-linker=hoisted, and an npm alias under the isolated linker (12 cells).
• pass (documented refusal): vendored on pnpm 5.18.10 (lock 5.2) and 6.35.1 (lock 5.3) fails loudly with vendor_lockfile_version_unsupported and writes nothing.
• pass: vendored on 7.33.7 (lock 5.4) and 8.15.9 (lock 6.0):
  • The documented vendor_pnpm_legacy_absolute_specifier warning fires.
  • Same-path frozen install is patched, and vex attests not_affected.
  • A checkout copied to a path containing a space fails --frozen-lockfile (ERR_PNPM_OUTDATED_LOCKFILE), as documented. The documented --offline --no-frozen-lockfile recovery installs the patched tarball.
  • rollback from the moved checkout restores package.json and the lock byte-exactly, and the frozen install is upstream again.
• pass (documented refusal): vendored on a 7.33.7 / 8.15.9 workspace lock (importers:) fails with vendor_lock_entry_unsupported, and the message says to upgrade to pnpm 9.
• pass: hosted on a 7.33.7 / 8.15.9 workspace lock (member dependency). The pin lands, and the fresh frozen install is patched for the member.
• blocked: macOS and Windows. Deleting bughunt/pnpm/20260930-virtual-store was denied by the permission policy again, so no probe branches were pushed.

Issues

• Commented on npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (pnpm hoisted alias cells). No new issues filed.

False positives ruled out

• Agent apply overwriting a pnpm patchedDependencies edit to the same file is the documented default mismatch policy (content_mismatch_overwritten; --strict refuses instead).
• Hosted keeping an explicit trustLockfile: false is documented, and warned.
• pnpm 9 rejects a pnpm-workspace.yaml without packages: ("packages field missing or empty"). That's a fixture issue.
• rollback emptying the staged manifest and GC-ing blobs makes a re-vendor a silent no-op (events: []). That's expected: there's nothing left to vendor.

Next

1. Re-verify npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 / Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 when Fix npm crawler missing configured install roots (#493, #518) #520 lands, then Rush subspaces and Rush + pnpm 10.
2. Global -g and vendored mode on macOS / Windows, once a maintainer deletes the stale probe branch.
3. Agent hoisted with nested duplicate copies (pnpm side of Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516), and package-import-method=clone on a reflink filesystem (needs CI).
4. Hosted on pnpm 11/12 with patchedDependencies plus catalogs and configDependencies together; pnpm patch-commit after a hosted pin.
5. Re-verify Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 / Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 / Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360 / Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361 / Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435 when fixes land.

[github-actions[bot]]

[agent] 2026-10-02: pnpm bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; CLI 4.0.0), latest release 4.0.0. Ran on Linux with pnpm 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1 on Node 22. I rebuilt the local Python patch-API mock (batch, by-package, package grant, view with inline blobs, blob, hosted tarball, /registry mirror), run with SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY pointed at it.

Re-triage

• Main hasn't changed since run 6, so there was nothing new to re-check. Vendored pnpm 10.5+ with overrides: in pnpm-workspace.yaml: the new package.json pnpm.overrides shadows the user's overrides, so frozen installs fail and a re-lock drops them #360, Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361, Agent mode ignores pnpm's virtualStoreDir: transitive dependencies are reported package_not_installed with a custom virtualStoreDir or the global virtual store #362 (GVS half), Global agent mode on pnpm 12 (and 11 without the global virtual store) patches only one of the per-install copies of a package, reports success, and VEX attests not_affected #435, Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466, Hosted scan on a pnpm workspace with sharedWorkspaceLockfile: false ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing #492 and npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 are still open, and Fix npm crawler missing configured install roots (#493, #518) #520 (the fix for npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 and Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493) is still unmerged.

Cells

• fail Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556 (new): gitBranchLockfile / git-branch-lockfile=true. Main has pnpm-lock.yaml committed, and the feature branch writes pnpm-lock.feature.yaml. Hosted scan pins the stale pnpm-lock.yaml and reports success, redirected 1. A fresh frozen install on the branch installs upstream bytes. vex honestly declines (not_applied). Reproduced 2/2 on 10.34.5 and 12.8.1, and 1/1 on 11.28.3.
  • With only the branch lock present (12.8.1), the scan gives redirected 0 and a misleading redirect_pnpm_no_lockfile ("run pnpm install").
  • pnpm 9.15.9 wrote no branch lock in this fixture, so it's n/a there.
• fail Hosted pnpm rollback drops the upstream tarball: URL from locks written with lockfileIncludeTarballUrl, so the restore isn't byte-exact #557 (new, low impact): lockfile-include-tarball-url / lockfileIncludeTarballUrl.
  • The hosted pin replaces both integrity and tarball, and the fresh frozen install is patched. That passes on 9.15.9 / 10.34.5 / 12.8.1.
  • rollback drops the upstream tarball: field, so it isn't byte-exact, and pnpm never re-adds it. Reproduced 2/2 on 9.15.9 and 12.8.1.
• pass: hosted on pnpm 12.8.1 combining a catalog: dep, workspace patchedDependencies (different file) and a workspace overrides entry that folds a transitive is-number@6 into 7.0.0.
  • The pin lands, and the fresh frozen install gets both the Socket patch and the pnpm patch on the _patch_hash instance.
  • vex attests not_affected.
  • Rollback clears the pin and warns reinstall_required and pnpm_trust_lockfile_left (documented).
• observed, not filed: hosted scan run with cwd inside a pnpm workspace member (packages/a) on 12.8.1. It doesn't look up the root pnpm-lock.yaml: success, redirected 0, warning redirect_npm_no_lockfile, and nothing is written. It's fail-safe, but the warning is misleading. The cargo analog is Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417. Before filing, check how the npm sibling's workspaces behave and whether running from the root is documented.
• blocked: macOS and Windows. Deleting bughunt/pnpm/20260930-virtual-store was denied by the permission policy again, so no probe branches were pushed.

Issues

• Filed Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556 Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556
• Filed Hosted pnpm rollback drops the upstream tarball: URL from locks written with lockfileIncludeTarballUrl, so the restore isn't byte-exact #557 Hosted pnpm rollback drops the upstream tarball: URL from locks written with lockfileIncludeTarballUrl, so the restore isn't byte-exact #557

False positives ruled out

• With a dead registry, the fresh frozen install of the combined fixture failed because the unpatched is-odd needs the registry. That's a fixture artifact; it passes against the live registry.
• pnpm_trust_lockfile_left after rollback, when trustLockfile was merged into an existing user workspace file, is documented (CLI_CONTRACT unwind; Hosted→vendored takeover leaves trustLockfile: true in pnpm-workspace.yaml, and vendor --revert never removes it #401 resolution).

Next

1. Hosted scan with pnpm gitBranchLockfile pins the stale pnpm-lock.yaml and reports success, while pnpm installs unpatched bytes from pnpm-lock.<branch>.yaml #556 follow-ups: vendored mode with gitBranchLockfile, mergeGitBranchLockfilesBranchPattern / pnpm install --merge-git-branch-lockfiles after a hosted pin, and agent-mode vex on the branch.
2. Hosted and vendored from a workspace member cwd, and pnpm lockfile-dir / lockfileDir pointing at a parent (the lock outside cwd).
3. Re-verify npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518 / Agent mode ignores yarn classic's --modules-folder: packages installed there are reported "not installed" and scan --mode agent exits 0 leaving them unpatched #493 when Fix npm crawler missing configured install roots (#493, #518) #520 lands, then Rush subspaces and Rush + pnpm 10.
4. Global -g and vendored mode on macOS / Windows, once a maintainer deletes the stale probe branch.
5. pnpm patch / patch-commit after a hosted pin, then rollback (does the pnpm patch still apply to upstream?), and agent hoisted with nested duplicate copies (pnpm side of Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516).

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

• Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361: closed 2026-10-02 16:21 UTC
• Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400: closed 2026-10-01 16:47 UTC
• pnpm-workspace.yaml edits miss quoted or space-before-colon top-level keys, append a duplicate trustLockfile/overrides key, and break every install #402: closed 2026-10-01 16:47 UTC
• npm crawler never looks in Rush's common/temp store: hosted vex attests a transitive dep not_affected while its installed copy is unpatched, and agent apply reports it package_not_installed #518: closed 2026-10-02 16:15 UTC

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

---

Generated by Claude Code