Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched

[mikolalysenko]

[agent] Found by the scheduled Deno bug-hunt routine (ledger #308).

Summary

When a Deno project materialises npm packages into a local node_modules ("nodeModulesDir": "auto" / "manual" on Deno 2, "nodeModulesDir": true on Deno 1.x), Deno uses a pnpm-like store. Every package physically lives at node_modules/.deno/<name>@<version>/node_modules/<name>, and only direct dependencies get a top-level symlink (node_modules/is-odd -> .deno/is-odd@3.0.1/node_modules/is-odd). The npm crawler knows the .pnpm, .vlt and legacy .<registry-host> stores, but it drops .deno in its generic hidden-entry skip. As a result:

• apply reports a transitive-only dependency as skipped / package_not_installed, yet the run's overall status is success with exit code 0.
• scan never discovers the transitive packages at all. The batch query sent to the API contains only the direct deps ({"components":[{"purl":"pkg:npm/is-odd@3.0.1"}]} for the repro below), and lockfileOnlyPackages is 0. So a patch for a transitive package is never even offered.

Deno loads the transitive package from exactly that .deno path at runtime, so the vulnerable code keeps running while socket-patch reports success.

Impact

In Deno projects that use a local node_modules (the documented agent-mode path for Deno npm deps, and the layout tests/docker_e2e_deno.rs exercises), only direct dependencies are patchable. Transitive dependencies, usually most of the tree, are silently left vulnerable, and the exit code gives CI nothing to fail on. This is the Deno counterpart of #359 (npm .store) and #366 (bun .bun), but it is a separate store directory with its own code path.

Repro (Linux; Deno 2.9.6; no API needed)

set -eu
SP=/path/to/socket-patch          # built from main f6b7fb9
mkdir deno-store && cd deno-store
export DENO_DIR=$PWD/.denodir
echo '{"nodeModulesDir":"auto","imports":{"is-odd":"npm:is-odd@3.0.1"}}' > deno.json
echo 'import isOdd from "is-odd"; isOdd(3); console.log("loaded-patched=" + JSON.stringify((globalThis as any).__SP || []));' > probe.ts
deno cache probe.ts
ls -l node_modules            # only: is-odd -> .deno/is-odd@3.0.1/node_modules/is-odd
S=node_modules/.deno
# Local manifest + blobs for two patches (direct is-odd, transitive is-number). Each patch
# prepends: globalThis.__SP=(globalThis.__SP||[]).concat(["<name>"]);
python3 mkman.py . "pkg:npm/is-odd@3.0.1=$S/is-odd@3.0.1/node_modules/is-odd" \
                   "pkg:npm/is-number@6.0.0=$S/is-number@6.0.0/node_modules/is-number"
$SP apply --offline --json; echo "rc=$?"
deno run -A probe.ts

mkman.py is a ~25-line helper that writes .socket/manifest.json and before/after blobs with git-sha256 hashes. It's inlined verbatim in the probe workflow linked below.

Output:

"status": "success"
  pkg:npm/is-odd@3.0.1    applied
  pkg:npm/is-number@6.0.0 skipped  errorCode=package_not_installed
rc=0
loaded-patched=["is-odd"]        # is-number is loaded (is-odd requires it) but unpatched

node_modules/.deno/is-number@6.0.0/node_modules/is-number/index.js exists and is the file Deno resolves (createRequire(...).resolve("is-number") points at it).

Expected vs actual

• Expected: docs/ecosystems.md lists npm agent mode as "✅ any install layout", and the Deno row lists agent mode as supported. Every installed copy Deno can load should be found and patched, the way the .pnpm / .vlt stores are (npm_crawler.rs comments: "the store is the ONLY physical home of transitive dependencies"). If a patch can't be applied, the run shouldn't report success / exit 0 (CLI_CONTRACT.md status semantics).
• Actual: transitive packages are invisible to scan and apply, and the run exits 0.

Matrix

Every cell was run with the real Deno install plus a runtime check (deno run) of which patched modules actually loaded.

OS	Deno	nodeModulesDir auto (deno.json imports)	manual (package.json + deno install)
Linux (sandbox)	1.46.3 (true)	fail	n/a ("manual" is 2.x-only)
Linux (sandbox)	2.0.6 / 2.2.15 / 2.9.6	fail	fail
ubuntu-latest	1.46.3 / 2.2.15 / 2.9.6	fail	fail
macos-latest	1.46.3 / 2.2.15 / 2.9.6	fail	fail
windows-latest	1.46.3 / 2.2.15 / 2.9.6	fail	fail

Direct dependencies pass in every cell. Each cell was reproduced at least twice on Linux.

Not a regression: releases 3.3.0 and 4.0.0 (npm @socketsecurity/socket-patch) behave identically.

Suspect code

• crates/socket-patch-core/src/crawlers/npm_crawler.rs:1069: nested_node_modules_of special-cases .pnpm, .vlt and legacy pnpm stores, then name_str.starts_with('.') drops .deno.
• crates/socket-patch-core/src/crawlers/npm_crawler.rs:1392: the same skip in the crawl_all / scan walker.
• crates/socket-patch-core/src/crawlers/npm_crawler.rs:1926: find_store_peer_variant_copies only knows .pnpm / .vlt, so peer-variant copies in .deno/<name>@<ver>_<peer>@<ver> would also be missed. That part is code-read only, not reproduced.

The .deno layout is <name>@<version>[_peer...]/node_modules/<name>, the same shape as pnpm's store entries (scoped packages use @scope+name@ver).

Probe run

https://github.com/SocketDev/socket-patch/actions/runs/36769893940 (3 OS × Deno 1.46.3 / 2.2.15 / 2.9.6 × auto/manual, all 18 cells reproduce)

[mikolalysenko]

[agent] Triaged: priority:p1 (npm packages installed by Deno into node_modules). Not a duplicate.

Shares root cause with #359, #362 and #366: the npm crawler recognizes dependency stores only by hard-coded directory names (.pnpm, .vlt, legacy .<registry>). .deno falls into the generic hidden-entry skip in gather_node_modules (scan), nested_node_modules_of (apply/rollback) and find_store_peer_variant_copies. Will be fixed together.

#359 and #362 are being fixed in the in-flight agent PR #365, which touches exactly those walks. .deno, which uses a pnpm-shaped <name>@<ver>[_peer]/node_modules/<name> with @scope+name, isn't in that PR's scope yet. It should be added there or right after it lands.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triage from the scheduled Deno bug-hunt routine (ledger #308): still reproduces on main 2463257 (after the v5 consolidation in #277). crawlers/npm_crawler.rs still drops .deno in its hidden-entry skip (lines 1066 and 1389 on this commit).

Re-checked on Linux with the repro in the description: Deno 1.46.3 (nodeModulesDir: true), 2.2.15 and 2.9.6 (auto) all give status: success, rc 0, is-number skipped / package_not_installed, and deno run shows only ["is-odd"] patched.

One more consequence (new information): scan --mode agent --prune treats the transitive package as uninstalled and would delete its manifest record. In the same project, scan --mode agent --prune --dry-run --json (with a local mock API) reports gc.prunableManifestEntries: ["pkg:npm/is-number@6.0.0"], even though node_modules/.deno/is-number@6.0.0/node_modules/is-number exists and Deno loads it. So a CI job that runs scan --prune would silently drop valid transitive patch records from .socket/manifest.json.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triage from the scheduled Deno bug-hunt routine (ledger #308): still reproduces on main 6e7ef74 with Deno 2.9.7 (the newest release). The 4 commits since 2463257 don't touch the npm crawler. apply gives success, rc 0, pkg:npm/is-number@6.0.0 skipped / package_not_installed, and deno run loads only ["is-odd"] patched.

New information: the bug only affects Deno's default isolated linker. Deno 2.8 added "nodeModulesLinker": "hoisted" / --node-modules-linker (absent in 2.7.14, present in 2.8.3; it requires "nodeModulesDir": "manual"). That linker writes an npm-style tree (real dirs at node_modules/<name>, conflicts nested under node_modules/<parent>/node_modules/<name>, and only a .deno/.deno.lock marker under .deno). With it, socket-patch handles transitive deps correctly. Probe run https://github.com/SocketDev/socket-patch/actions/runs/36873031389, with is-odd@3.0.1 + is-number@7.0.0 at the root, so is-number@6.0.0 is nested:

OS	Deno	apply (direct + nested transitive)	runtime loads patched	$DENO_DIR cache unchanged (hardlinks broken)	re-apply	vex	rollback
ubuntu / macos / windows	2.8.3, 2.9.7	applied ×2	["is-odd","is-number"]	yes, and a sibling project on the same DENO_DIR stays unpatched	already_patched	verified ×2	2 restored, runtime unpatched

scan --mode agent in a hoisted project also queries all 3 PURLs (Linux, 2.9.7). So {"nodeModulesDir":"manual","nodeModulesLinker":"hoisted"} + deno install is a working user workaround on Deno ≥ 2.8 until .deno is crawled. A regression test for the fix could use the hoisted layout as a control.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triaged after the Deno 2.9.7 comment: still priority:p1, still in the dependency-store cluster with #359 / #362 / #366 / #405 (.deno dropped by the npm crawler's hidden-entry skip). The hoisted-linker result is consistent with that: the hoisted layout never goes through .deno. PR #365 covers #359 / #362 only, so .deno still needs adding there or as a follow-up.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #366, #405, #495; shared root cause: the npm crawler only recognizes isolated stores by hard-coded names/shapes, so .bun, .deno and Yarn 4's .store are skipped). Branch: agent/fix-npm-crawler-isolated-stores. Claim-ID: 2026-10-01T19:20:55Z-253dcb

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft fix PR: #496

---

Generated by Claude Code

[mikolalysenko]

[agent] Deno bug-hunt routine (ledger #308), main 61cfb9b vs PR #496 head 7f41839, real Deno 2.9.7 on Linux, reproduced 2/2.

New on main: a direct dep can also be left half-patched, and nothing says so. Deno names a second peer resolution of the same name@version with a copy index: node_modules/.deno/<name>@<ver>_1, not a pnpm-style (peer) suffix. Repro (deno.json):

{ "nodeModulesDir": "auto", "imports": { "ajv": "npm:ajv@6.12.0", "ak": "npm:ajv-keywords@3.5.2", "su": "npm:schema-utils@2.7.1" } }

deno install gives .deno/ajv-keywords@3.5.2 (peer → ajv 6.12.0) and .deno/ajv-keywords@3.5.2_1 (peer → ajv 6.15.0, linked from schema-utils@2.7.1/node_modules/ajv-keywords). With an offline patch to pkg:npm/ajv-keywords@3.5.2 index.js, main gives:

• apply: success, applied, exit 0. Only the root-linked @3.5.2 copy is written, and @3.5.2_1 keeps the original bytes.
• At runtime (import "ak"; import "su") the marker fires once, so schema-utils loads the unpatched _1 copy.
• vex --product …: exit 0, not_affected.

So this case doesn't show package_not_installed. The fan-out (find_store_peer_variant_copies) never looks in .deno.

PR #496 checked against real Deno layouts (all pass):

Layout (Deno 2.9.7, isolated)	main	#496
copy-index variant ajv-keywords@3.5.2_1	_1 left unpatched, success	both copies patched, runtime loads both patched, rollback restores both
mixed-case name, which Deno hashes (JSONStream → .deno/_jjju6tstorzgkyln@1.3.5), transitive via conventional-commits-parser	package_not_installed	applied, $DENO_DIR copy untouched (link count 1)
scoped transitive @babel+highlight@7.25.9, plus through@2.3.8 under JSONStream	package_not_installed	applied, runtime loads patched, VEX not_affected ×N, rollback empties the manifest

Deno 1.46.3 (nodeModulesDir: true) resolves the same graph to a single ajv-keywords@3.5.2, with no _1, so 1.x isn't affected by the copy-index case.

One leftover with #496: after a correct apply, reverting only the _1 copy still gets not_affected from vex, while reverting the primary gets exit 1. That's #516 (vex.rs collapse_to_first), not this issue. I've noted it there.

---

Generated by Claude Code