Bug hunt ledger: Deno

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-02 (run 7), main 61cfb9b, latest release 4.0.0 (previous 3.3.0). Newest Deno is 2.9.7. Fix PR #496 for #373 passes against real layouts. Fix PR #517 for #516 misses Deno _1 copies even with #496 (commented on #516).

Method: real Deno binaries (GitHub release zips; denoland/setup-deno in probes), a per-project DENO_DIR, and a local manifest plus blobs driven by apply --offline. The patched bytes record themselves in globalThis.__SP, so deno run shows which patched modules actually loaded. For scan / get / hosted / vendored there's a local stub of the public proxy (SOCKET_PROXY_URL + SOCKET_PATCH_SERVER_URL) serving batch, by-package, view (real blobs), package grants and a patched tarball at /patch/npm/<uuid>/<name>-<ver>.tgz. Deno's npm packages are pkg:npm (npm crawler), and the Deno ecosystem proper is JSR (pkg:jsr).

Coverage matrix

OS	Deno	Agent: direct npm dep (incl. scoped, alias, workspace member)	Agent: transitive npm dep (node_modules/.deno)	Agent: nodeModulesDir none	Agent: JSR (vendor: true)	JSR via --global-prefix vendor/jsr.io	vendored refusal	hosted / vendored (npm deps via package-lock.json)	VEX
Linux	1.46.3	pass	fail #373	known limitation	fail #374	pass	untested	hosted fail #406	pass (agent), fail #406 (hosted)
Linux	2.0.6	pass (run 1)	fail #373	known limitation	fail #374	untested	untested	untested	untested
Linux	2.2.15	pass	fail #373	known limitation	fail #374	pass	untested	hosted + vendored fail #406 (package-lock + deno.lock)	fail #406
Linux	2.9.6	pass	fail #373 (also --prune drops records)	known limitation	fail #374	pass (scan + apply; unsafe with npm deps, see #374)	pass for pkg:jsr (vendor_unsupported_ecosystem)	hosted + vendored fail #406	pass (agent), fail #406 (hosted)
macOS	1.46.3 / 2.2.15 / 2.9.6	pass (scoped; apply / vex / rollback)	fail #373	untested	fail #374	pass	untested	untested	pass (agent)
Windows	1.46.3 / 2.2.15 / 2.9.6	pass (scoped via junctions; apply / vex / rollback)	fail #373	untested	fail #374	pass	untested	untested	pass (agent)
Linux	2.9.7	pass (also links)	fail #373 (re-checked on 61cfb9b)	untested	untested	untested	pass for pkg:npm in a deno.lock-only project (vendor_lockfile_missing, exit 1, files untouched)	fail #406 (lockfile-only vex)	pass (agent)

Isolated .deno store edge cases (agent mode, Linux)

Deno	copy-index peer variant <name>@<ver>_1 of a direct dep	hashed mixed-case name _<base32>@<ver>	scoped transitive @scope+name@ver	isolated workspace (deno.json + package.json members)
1.46.3	n/a (single copy)	untested	fail #373	untested
2.0.6 / 2.2.15	fail #373 (_1 left unpatched, apply success, VEX not_affected); pass with #496	untested	fail #373	untested
2.9.7	fail #373 (same); pass with #496; VEX partial-revert hits #516, still fails with #517 + #496 (find_by_purls skips peer variants)	fail #373 when transitive (direct passes); pass with #496	fail #373; pass with #496	pass

nodeModulesLinker: "hoisted" (Deno ≥ 2.8, needs nodeModulesDir: manual), agent mode

OS	Deno	direct	nested transitive	DENO_DIR cache untouched	re-apply	vex	rollback	scan discovery
Linux / macOS / Windows	2.8.3, 2.9.7	pass	pass	pass	pass	pass	pass	pass (Linux 2.9.7)
Linux	2.9.7, workspace members	pass (doubly nested too)	pass	—	—	pass	pass	—
Linux	2.9.7, duplicate copies of one name@version	pass (both patched)	—	—	—	fail (only the first copy is hashed; handed over to npm)	—	—
Linux	2.9.7, deno install after apply, then rollback	—	—	—	—	—	pass (alreadyOriginal, rc 0, manifest emptied)	—

Global mode (-g / --global-prefix / SOCKET_GLOBAL), deno install -g of a tool with an npm: dep

OS	Deno	scan -g report	apply -g	--global-prefix on $DENO_DIR layouts	2.9 per-tool bin/.<tool>/node_modules	rollback -g	vex -g	hosted refusal
Linux	1.46.3 / 2.2.15	fail #444	fail #444	fail #444	n/a	untested (blocked by #444)	fail #444 (no_applicable_patches)	pass (2.9.6)
Linux	2.9.6	fail #444	fail #444	fail #444	fail #444 (false applied + VEX for local/JSR tools; pass for npm: tools)	untested	fail #444	pass
Linux	2.7.0 → 2.9.7 (layout only)	—	—	—	per-tool dir from 2.7.0; decoy node_modules for local tools by 2.7.14 (#444 comment)	—	—	—
Linux / macOS / Windows	1.46.3, 2.0.6, 2.2.15, 2.4.5, 2.9.6 (probe)	Windows also #434	fail #444	fail #444	2.9.6 only: fail #444	untested	2.9.6 decoy: false not_affected	untested

Other passes (Linux): an immutable (chattr +i) target fails loudly (apply_failed, exit 1), list --json, re-apply idempotency, rollback, remove, breaking cache hardlinks, end-to-end scan --mode agent via the stub, unicode / space paths, and deno.lock v3 / v4 (2.2.15) / v5 never edited (--frozen still OK, patched copy loads).

Backlog

0. Maintainer request (global mode), partly covered. Filed Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 (still open on 61cfb9b, no fix PR). Still to do: an unwritable global prefix (read-only DENO_INSTALL_ROOT / DENO_DIR) on macOS / Windows, rollback -g after Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 is fixed, and DENO_DIR with spaces or unicode.
1. A maintainer needs to delete the stale probe branches bughunt/deno/20260930-deno-store, bughunt/deno/20261001-scoped-jsr, bughunt/deno/20261001-global and bughunt/deno/20261001-hoisted. The git proxy and the session permission policy both refuse push --delete.
2. When Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 merges, re-test Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 on main: copy-index _1, hashed _<base32> names, scoped transitive, scan discovery and scan --prune. Close it if everything passes.
3. When Fix agent vex checking only one installed copy (#516) #517 merges, re-test the .deno/<name>@<ver>_1 partial-revert VEX case. As of 0f45d24 + Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 it still attests not_affected (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 comment).
4. Probe macOS / Windows for the .deno _1 / _<base32> folders (case-insensitive FS) once Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 lands.
5. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
6. Interrupted / concurrent apply on a hardlinked .deno store. Hoisted + vendor: true JSR is low value (it's just Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374).

Known non-bugs

• patches-api.socket.dev and dl.deno.land / deno.land are proxy-denied in the sandbox. Use GitHub release zips and a local stub.
• nodeModulesDir: "none" (the Deno 2 default without package.json) keeps npm packages only in the shared DENO_DIR/npm/registry.npmjs.org/<name>/<ver>. Agent apply fails loudly (package_not_installed, partialFailure). scan says "No packages found" because deno.lock isn't a documented lockfile-supplement source.
• setup was removed in v5 (v5 prerelease: scan → vex → vendor workflow, hosted by default #277). The earlier "package.json postinstall hook Deno never runs" GAP and the setup.manual VEX gating no longer apply; v5 VEX attests agent patches from the installed bytes without any setup.
• vex --no-verify trusts agent records without hashing, by documented design.
• Hosted scan in a deno.json-only project warns redirect_npm_no_lockfile and exits 0 / success. Hosted refusals don't change exit status (CLI_CONTRACT).
• Hosted get pkg:jsr/... gives redirected: 0 with only a human "no lockfile entry" line (no JSON code). Unverified against the real proxy; revisit (backlog 3).
• nodeModulesDir: "auto" / "manual" are Deno 2 values; on 1.x, use true.
• setup.manual: ["deno"] (legacy) covered only pkg:jsr; npm: deps are the npm ecosystem.
• get -g --mode hosted|vendored not refusing was get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (generic), fixed by Fix -g touching the cwd project's state (#436, #445) #446. It now refuses on 61cfb9b.
• scan -g --mode hosted / --global-prefix --mode hosted exit 2 with the documented refusal. That's correct.
• A Deno 2.9 npm:-entrypoint global tool gets "nodeModulesDir": "manual" and really loads bin/.<tool>/node_modules. Only local/JSR-entrypoint tools load the DENO_DIR copy (Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444).
• nodeModulesLinker: "hoisted": every deno install (including --frozen) re-links from DENO_DIR and drops agent patches. Agent mode needs apply after each install (documented), and vex then says not_applied.
• repair --offline GCs before-blobs, so a later rollback --offline fails with missing_blob and a repair remedy. Offline design, not Deno-specific.
• list --json files[].verified is always false (hardcoded). Generic, cosmetic.
• vex without --product in a deno.json-only project fails with "Could not auto-detect a top-level product PURL". deno.json isn't in the documented auto-detect list.
• Deno "links" copies the linked package into node_modules/.deno/<name>@<ver>. An agent patch only touches that copy, never the linked source.
• Agent-mode VEX checking only the first of several copies of a name@version is a generic npm-family defect (commands/vex.rs:556), handed over to npm. Don't re-file it from Deno; comment on the npm issue instead.
• Deno names a second peer resolution .deno/<name>@<ver>_N (copy index) and a mixed-case package .deno/_<base32 hash>@<ver> (in $DENO_DIR too). Those are real installs, not junk; Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 decodes both.
• The duplicate applied + already_patched events for one PURL in an isolated Deno workspace come from the member node_modules/<dep> symlink reaching the same file. Cosmetic.

[github-actions[bot]]

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

Tested: main f6b7fb9 (CLI 4.0.0 workspace version). For regression checks, the latest release 4.0.0 and the previous release 3.3.0 from npm @socketsecurity/socket-patch. Deno 1.46.3, 2.0.6, 2.2.15 (LTS) and 2.9.6 (latest), from GitHub release zips in the sandbox (dl.deno.land is proxy-denied) and denoland/setup-deno in the probe. The probe covered ubuntu, macOS and Windows.

Method: real deno cache / deno install into a per-project DENO_DIR, then a local .socket/manifest.json plus before/after blobs (git-sha256), driven by apply --offline. The patched bytes prepend globalThis.__SP=(…).concat(["<name>"]), so deno run of a probe that imports the direct dependency prints which patched modules actually loaded. That's the oracle. scan discovery was checked with a tiny local mock (SOCKET_PROXY_URL=http://127.0.0.1:8765, which returns empty batches and logs the queried PURLs). patches-api.socket.dev is proxy-denied.

This is the first run: there was no earlier ledger and no pm:deno issues to re-triage.

Cells

• fail Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373: agent mode with a node_modules dir. Transitive npm deps live only in node_modules/.deno/<name>@<ver>/node_modules/<name>. apply reports them as package_not_installed but finishes success with rc 0, and scan never queries them. Deno loads the unpatched copy. Reproduced with nodeModulesDir auto and manual (package.json + deno install) on Deno 2.0.6 / 2.2.15 / 2.9.6, and with true on 1.46.3. Linux, macOS and Windows (18/18 probe cells). Releases 3.3.0 and 4.0.0 behave the same.
• fail Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374: JSR. The crawler probes only $DENO_DIR/npm/jsr.io, which no Deno creates (1.46.3 and 2.9.6 checked; JSR goes to remote/https/jsr.io/<hash>). A "vendor": true project has the matching ./vendor/jsr.io/@scope/name/ver/ layout, but local apply gives package_not_installed, while --global-prefix vendor/jsr.io applies and the patched code runs. Deno 1.46.3 / 2.0.6 / 2.2.15 / 2.9.6, Linux.
• pass: direct npm deps (the top-level .deno symlink target) in every cell above.
• pass: agent re-apply is idempotent (already_patched), and rollback restores the original bytes (2.9.6 auto).
• pass: agent writes break Deno's cache hardlinks. deno cache hardlinks DENO_DIR/npm/registry.npmjs.org/... into node_modules/.deno, and after apply the node_modules copy has a new inode while the cache stays clean.
• pass: VEX never attests an unapplied patch. With setup.manual: ["npm"], only is-odd gets not_affected and is-number is package_not_found.
• pass: vendor with a pkg:jsr patch gives vendor_unsupported_ecosystem. npm-in-Deno vendoring fails closed with vendor_lockfile_missing (deno.lock is not a supported lock), and deno.lock / package.json are untouched.
• pass: setup gives no_files in deno.json-only projects (auto / none).
• expected failure (not filed): nodeModulesDir none, the Deno 2 default for deno.json-only projects. npm packages exist only in the global DENO_DIR/npm/registry.npmjs.org/<name>/<ver>, so apply reports package_not_installed with partialFailure (rc 1). The failure is loud, and patching a shared global cache would be a design change. Recorded as a known limitation below.

Issues

• Filed Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373: Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373
• Filed Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374: Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374

False positives ruled out

• A Deno + package.json project gets setup → success, packageManager: npm, a postinstall hook, and setup --check → configured, but Deno never runs root lifecycle scripts. Measured: 2.0.6 and 2.2.15 never run them; 2.9.6 runs them only with deno install --allow-scripts and otherwise prints "Ignored build scripts … deno approve-scripts". A fresh deno install therefore reinstalls unpatched bytes. This is already tracked as a baseline GAP in crates/socket-patch-cli/tests/setup_matrix_deno.rs, so not filed. VEX correctly reports not_applied afterwards.
• setup.manual: ["deno"] doesn't cover npm: packages in a Deno project (they are pkg:npm, so ecosystem npm), and VEX reports ecosystem_not_setup. Declaring "npm" works. That's by design: the Deno ecosystem is JSR only.
• My first runtime probe used createRequire(import.meta.resolve("npm:…")), which fails on Deno ≤ 2.2 (not a file URL). That's a harness artifact, replaced by the globalThis marker oracle.

Probe

• bughunt/deno/20260930-deno-store, 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 Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373).
• The branch could not be deleted. git push --delete failed through the git proxy ("remote end hung up", tried 4 times), so a maintainer needs to delete it.

Next

1. .deno peer-variant entries (<name>@<ver>_<peer>@<ver>), scoped @scope+name@ver entries, and a Deno workspace ("workspace": [...]) with per-member imports, all under Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 once it's fixed.
2. JSR on macOS / Windows with "vendor": true, plus the vendor dir in a workspace member, for Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374.
3. deno.lock v3 (Deno 1.x) vs v4 / v5: confirm scan / VEX ignore Socket-looking urls in remote (manifest-less VEX gives manifest_not_found), and that apply never edits deno.lock.
4. scan --mode vendored|hosted refusal codes for pkg:jsr patches via the mock (needs patches/view + by-package routes in the mock).
5. Deno 2.9.6 --allow-scripts / deno approve-scripts: does the npm postinstall hook setup writes then actually re-apply after a fresh install (npx availability)?

[github-actions[bot]]

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

Tested: main 2463257, which is #277, the v5 consolidation: 793 files, setup removed, manifest-less hosted VEX. The CLI version string is still 4.0.0. Latest release 4.0.0, previous 3.3.0. Deno 1.46.3, 2.2.15 and 2.9.6 (GitHub release zips in the sandbox; denoland/setup-deno in the probe). npm 10.9 for the mixed-lock case.

Method: same as run 1. A real deno cache / deno install into a per-project DENO_DIR, then a local manifest plus git-sha256 blobs driven by apply --offline. The runtime oracle is a globalThis.__SP marker. New this run: a richer local stub of the public proxy (SOCKET_PROXY_URL, plus SOCKET_PATCH_SERVER_URL for VEX). It serves /patch/batch, /patch/by-package, /patch/view/<uuid> (with real before/after blobs), /patch/package grants, and a patched tarball at /patch/npm/<uuid>/<name>-<ver>.tgz, so agent, hosted and vendored scan / get run end to end.

Re-triage

• Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 still reproduces on 2463257 (Deno 1.46.3 / 2.2.15 / 2.9.6, Linux): success, rc 0, transitive package_not_installed. New symptom: scan --mode agent --prune lists the transitive record in gc.prunableManifestEntries, so a prune run would delete it. Commented: Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 (comment)
• Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 still reproduces on 2463257. Confirmed on macOS and Windows too (9/9 probe cells), and the --global-prefix vendor/jsr.io apply / vex / rollback lifecycle passes everywhere. Commented: Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 (comment) and Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 (comment)

Cells

• fail Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 (new): a Deno 2 project with package.json, package-lock.json and deno.lock. scan --mode hosted rewrites only package-lock.json and reports redirected: 1 / success with no deno warning. deno install --frozen keeps loading the unpatched registry copy. In-run scan --vex and fresh-clone vex both attest not_affected. Standalone vex after deno install correctly gives not_applied. Deno 2.2.15 and 2.9.6, Linux, reproduced 3× on 2.9.6. The contested-lock rule doesn't read deno.lock. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406
• pass (probe, ubuntu/macos/windows × 1.46.3/2.2.15/2.9.6): a scoped direct npm dep through node_modules/.deno/@scope+name@ver (junctions on Windows): apply → patched code runs, vex verified, rollback restores. https://github.com/SocketDev/socket-patch/actions/runs/36804433321
• pass (Linux 2.9.6): agent scan --mode agent end to end via the stub (download → apply → patched code runs).
• pass (Linux 2.9.6): npm alias ("odd": "npm:is-odd@3.0.1", nodeModulesDir: manual + deno install): apply plus remove <purl>.
• pass (Linux 2.9.6): a Deno workspace ("workspace": ["./a","./b"]) with a deno.json member and a package.json member; both members' direct deps are patched (root node_modules plus b/node_modules).
• pass (Linux 2.9.6): a project path and DENO_DIR containing spaces and ü, with --cwd.
• pass: deno.lock v3 (1.46.3) and v5 (2.9.6) are byte-unchanged by apply / hosted scan / vex / rollback, and deno cache --frozen still succeeds.
• pass: vex omits the unapplied transitive patch (package_not_found). There is no setup.manual any more, and VEX needs none in v5.
• pass: vendored refusal. get pkg:jsr/... --mode vendored gives vendor_unsupported_ecosystem (skipped, nothing written). npm-in-Deno vendored scan fails closed (rc 1).
• pass: Deno "vendor": true creates ./vendor/, and the composer crawler doesn't misdetect it.

False positives ruled out / not filed

• vex --no-verify attests the transitive record that was never applied. That's documented: --no-verify "trust[s] the patch records" for agent mode.
• scan in nodeModulesDir: none prints "No packages found" with exit 0. deno.lock isn't in the documented lockfile-supplement list (CLI_CONTRACT "Lockfile supplement"), so this is a documented gap. It's in the backlog as a possible enhancement.
• Hosted get pkg:jsr/... gives success, redirected: 0, no JSON skip code, and a human "no lockfile entry pinning it could be rewritten". The CLI asks the server for a grant; my stub granted it. The real proxy's answer for pkg:jsr can't be checked from the sandbox, so this isn't filed. Recorded under Known non-bugs, to revisit.
• scan --mode vendored → "patch has no applicable files" was a stub artifact (empty files).
• vex didn't recognise the stub's first hosted URL (/t.tgz, no uuid segment). Harness artifact; fixed in the stub.
• The first probe run (36803957571) aborted on GitHub's bash -e -o pipefail. A harness bug, fixed in the second push.

Probe

• bughunt/deno/20261001-scoped-jsr, runs 36803957571 (harness failure) and 36804433321 (9/9 green, results above).
• Branch deletion failed again. git push --delete / :refs/heads/… gives "remote end hung up" through the git proxy. A maintainer needs to delete bughunt/deno/20260930-deno-store and bughunt/deno/20261001-scoped-jsr.

Next

1. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: Deno 1.46.3 with package.json; vendored takeover of a Deno + package-lock project; pnpm-lock / yarn.lock / bun.lock beside deno.lock.
2. .deno peer-variant entries and scoped transitive entries, once Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 is fixed.
3. Hosted get / scan for pkg:jsr against the real proxy, if a run ever gets network access to patches-api.socket.dev.
4. nodeModulesDir: none: should scan read deno.lock's npm section as a lockfile supplement (lockfileOnlyPackages)? Enhancement, not a bug.
5. CRLF / BOM deno.jsonc and deno.lock on Windows (is_deno_project only checks existence today).

[github-actions[bot]]

[agent] 2026-10-01: Deno bug-hunt run (addendum to 20261001T021734Z; same main 2463257)

Same session, extended. No new issues were filed; all new findings went onto existing issues.

Cells

• fail Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 (vendored, new information): in the mixed project (package.json + package-lock.json + deno.lock), scan --mode vendored rewires package-lock.json to file:.socket/vendor/..., reports applied / success, and leaves deno.lock untouched. deno install --frozen loads the unpatched copy. vex keeps attesting not_affected after the Deno install, warning only vendored_tree_out_of_sync with a "re-run your package manager's install" remedy that can't work under Deno. Deno 2.2.15 and 2.9.6. This also contradicts the ecosystems.md Deno row ("vendored ❌ refused"). Comment: Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 (comment)
• fail Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 (Deno 1.46.3, deno.lock v3): hosted is the same. Comment: Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 (comment)
• pass: scan --mode agent --global-prefix vendor/jsr.io discovers, downloads and applies a JSR patch, and the patched code runs.
• caveat (Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374): --global-prefix re-roots every crawler, so in a mixed JSR + npm project the npm deps vanish. apply gives success with package_not_installed, and --prune would delete npm records. Documented semantics, so not a separate bug. Comment: Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 (comment)

Harness note

The stub's vendored path needs the served tarball to carry the same after-bytes as the patch view. A mismatch gives apply_failed ("prebuilt tarball … does not carry the patched files"), which is a harness artifact, not a bug.

Next

1. pnpm-lock.yaml / yarn.lock / bun.lock beside deno.lock (expected to be the same Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 class; confirm before commenting).
2. .deno peer-variant and scoped transitive entries, once Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 is fixed.
3. Hosted pkg:jsr against the real proxy.
4. CRLF / BOM deno.jsonc on Windows.

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

Where Deno puts global installs: deno install -g and the npm cache under $DENO_DIR (~/.cache/deno, ~/Library/Caches/deno, %LOCALAPPDATA%\deno). The crawler docs say users run scan --global --ecosystems deno --global-prefix <path>; verify that and the bare -g path.

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

Tested: main 2463257 (unchanged since the last run), latest release 4.0.0, previous 3.3.0 (npm @socketsecurity/socket-patch). Deno 1.46.3, 2.2.15 and 2.9.6 in the sandbox (GitHub release zips). The probe covered 1.46.3, 2.0.6, 2.2.15, 2.4.5 and 2.9.6 on ubuntu, macos and windows.

Focus: the maintainer's global (-g) mode request (20261001T040000Z entry). The method is a real deno install -g of a local entrypoint that imports npm:is-odd@3.0.1, in a per-run DENO_DIR + DENO_INSTALL_ROOT. The oracle is a patched console.log('SP-PATCHED') and running the installed shim. DENO_LOG=debug shows the package folder Deno resolves. There's a local batch-API stub for scan, and an offline manifest for apply / vex / rollback.

Filed

• Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444. Deno global installs keep npm deps in $DENO_DIR/npm/registry.npmjs.org/<name>/<ver>. scan -g gives success and never lists them, apply -g gives package_not_installed, and no --global-prefix ($DENO_DIR, npm, registry.npmjs.org) reaches that layout. On Deno 2.9.6, deno install -g also writes bin/.<tool>/node_modules/.deno, which is a decoy for local/JSR-entrypoint tools (Deno still loads the DENO_DIR copy). --global-prefix on it reports applied and vex attests not_affected while the tool runs unpatched. 15/15 probe cells reproduce. Not a regression (3.3.0 and 4.0.0 are the same).

Cells (global mode)

• fail Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: scan -g / SOCKET_GLOBAL=1 report (finds no Deno-global npm package). Linux 1.46.3 / 2.2.15 / 2.9.6. -g -e deno gives scannedPackages: 0 / success.
• fail Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: apply -g and --global-prefix × 3 on ubuntu, macos and windows × 1.46.3 / 2.0.6 / 2.2.15 / 2.4.5 / 2.9.6 (probe https://github.com/SocketDev/socket-patch/actions/runs/36833777679).
• fail Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: 2.9.6 per-tool decoy gives apply applied, tool unpatched, vex verified / not_affected (ubuntu, macos, windows).
• pass: scan -g --mode hosted and scan --global-prefix … --mode hosted exit 2 with "global installs have no project lockfile to redirect" and write nothing (Linux 2.9.6, inside a git Deno project).
• pass: scan -g from inside a Deno project lists no project packages, and a plain project scan never queries the global copies.
• pass: SOCKET_GLOBAL_PREFIX=<dir> matches --global-prefix <dir>, and SOCKET_GLOBAL=1 matches -g.
• pass: apply -g exits 1 (partialFailure) and vex -g exits 1 (no_applicable_patches) when nothing is found. They're loud, not silent.
• pass (2.9.6, npm: entrypoint tool): the per-tool dir gets "nodeModulesDir": "manual" and Deno loads it, so --global-prefix bin/.<tool>/node_modules patches the running copy for direct deps (transitive is Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373).
• known, not re-filed: get -g --mode hosted exits 0 with redirected: 0 instead of refusing. That's get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (generic, not Deno-specific).
• blocked: unwritable global prefix. The sandbox runs as root, so permission bits don't bite. Needs a probe with a read-only dir (backlog).
• known: on Windows, scan -g -e npm scans 0 packages (On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434).

Re-triage

Main is unchanged since the last re-check (same SHA), so #373, #374 and #406 still stand as recorded in the earlier entries.

Housekeeping

• Probe branch bughunt/deno/20261001-global: git push --delete still gives "remote end hung up" through the git proxy. A maintainer needs to delete it, along with bughunt/deno/20260930-deno-store and bughunt/deno/20261001-scoped-jsr.

Next

1. Global mode, continued: the unwritable prefix (read-only DENO_INSTALL_ROOT / DENO_DIR) on all 3 OSes, rollback -g once Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 lands, and paths with spaces or unicode in DENO_DIR.
2. Find the first Deno 2.x that writes the per-tool bin/.<tool> dir (absent in 2.4.5, present in 2.9.6).
3. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
4. CRLF / BOM deno.jsonc / deno.lock on Windows.

[github-actions[bot]]

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

Tested: main 6e7ef74 (4 commits since 2463257: #337 npm VEX bundled copies, #345 npm git/URL/file lock entries, Poetry, Maven). No crawler, deno or redirect-for-deno code changed. Workspace version 4.0.0 (latest release 4.0.0, previous 3.3.0). Deno 1.46.3, 2.4.5–2.9.7 (newest release is now 2.9.7) from GitHub release zips in the sandbox, and 2.8.3 / 2.9.7 on ubuntu, macos and windows in the probe.

Re-triage

• Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406: still reproduces on 6e7ef74. A lockfile-only checkout (package-lock.json hosted ref for is-odd@3.0.1 + a real Deno 2.9.7 deno.lock v5 resolving it from the registry) still treats the ref as live: vex --offline goes to record_unavailable instead of dropping it with patched_ref_unattributable. vex/discover/deno.rs is still "deliberately always empty", so the new npm VEX attests not_affected while a bundled (inBundle) copy of the same package@version stays unpatched #325 cross-lock contest doesn't see deno.lock. No comment posted (no new information).
• Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373: still reproduces on 6e7ef74 with Deno 2.9.7. Commented with new information: the hoisted linker is unaffected and works as a workaround (below). Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 (comment)
• Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: commented with the version boundary. Deno 2.7.0 is the first to write bin/.<tool>/ (only deno.json there for local tools). The decoy node_modules for local tools appears by 2.7.14 and is present through 2.9.7. 2.4.5–2.6.10 write no per-tool dir. Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 (comment)

Cells

• pass (new): nodeModulesLinker: "hoisted" (Deno ≥ 2.8; absent in 2.7.14; requires nodeModulesDir: manual). Direct + nested transitive (node_modules/is-odd/node_modules/is-number@6) apply, runtime loads both patched, $DENO_DIR cache bytes unchanged (hoisted files are hardlinks into the cache and apply breaks them), a sibling project on the same DENO_DIR stays unpatched, re-apply already_patched, vex verified ×2, rollback restores. ubuntu / macos / windows × 2.8.3 / 2.9.7, probe https://github.com/SocketDev/socket-patch/actions/runs/36873031389 (6/6 cells).
• pass: scan --mode agent in a hoisted project queries all 3 PURLs, including the nested one (Linux 2.9.7, local stub).
• pass: hoisted deno install / deno install --frozen re-links from the cache and drops the patch. Agent mode needs apply after each install (documented). vex then reports not_applied. Switching hoisted → isolated puts the transitive copy back under .deno (package_not_found = Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373).
• pass: Deno 2.9.7 isolated / manual direct dep: apply, list --json, vex verified, deno install --reload → vex not_applied, re-apply.
• pass: an immutable target (chattr +i on the file or on the package dir, standing in for a read-only install since the sandbox runs as root) gives apply_failed "Operation not permitted", partialFailure, exit 1, leaves no stray files, and vex gives not_applied.
• not a bug (generic): repair --offline GCs the before-blob, so a later rollback --offline fails loudly with missing_blob and a "Run socket-patch repair" remedy. That's the offline design (before-blobs are fetched on demand), not Deno-specific.
• note: list --json prints files[].verified: false hardcoded (commands/list.rs:174) even for an applied patch. Cosmetic, and generic, not Deno.

Filed

None. Every finding was already covered (#373 / #406 / #444) or passed.

Housekeeping

• Probe branch bughunt/deno/20261001-hoisted: git push --delete and push :refs/heads/… both give "remote end hung up" through the git proxy again. A maintainer needs to delete it, along with bughunt/deno/20260930-deno-store, bughunt/deno/20261001-scoped-jsr and bughunt/deno/20261001-global.

Next

1. Isolated-linker peer variants (<name>@<ver>_<peer>) and scoped .deno entries, once Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 is fixed. Use hoisted as the control.
2. Hoisted linker + Deno workspace ("workspace": [...]) members, and hoisted + vendor: true JSR.
3. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
4. A read-only DENO_DIR / DENO_INSTALL_ROOT on macOS / Windows (the sandbox runs as root), and DENO_DIR with spaces / unicode on Windows.
5. CRLF / BOM deno.jsonc / deno.lock on Windows.

[github-actions[bot]]

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

Tested: main 61cfb9b (16 commits since 6e7ef74, including #365 npm .store / pnpm virtualStoreDir walks, #446 -g keeping off project state, #456 agent scan/get re-apply, #357 JSON writers CRLF/BOM). No deno_crawler.rs or vex/discover/deno.rs change. Workspace version 4.0.0 (latest release 4.0.0, previous 3.3.0). Deno 2.9.7 is still the newest release (2.9.8 and 2.10.0 are 404). Linux only this run, with real release binaries. No probe branches.

Re-triage

• Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373: still reproduces on 61cfb9b (Deno 2.9.7, nodeModulesDir: auto). is-number@6.0.0 under node_modules/.deno gives package_not_installed, status: success, exit 0, and only is-odd loads patched. Fix npm crawler missing relocated dependency stores (#359, #362) #365 added .store / .modules.yaml walks, but not .deno. Draft fix PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 is open (claimed). No comment, since there's no new information.
• Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: unchanged on 61cfb9b. No crawler for $DENO_DIR/npm/registry.npmjs.org and no fix PR. Fix -g touching the cwd project's state (#436, #445) #446 fixed the related get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (get -g --mode hosted now refuses: "global installs have no project lockfile to redirect").
• Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 / Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406: the relevant code is unchanged since the last re-check, so not re-run.

Cells

• pass (new): hoisted linker + Deno workspace (2.9.7, nodeModulesDir: manual, nodeModulesLinker: hoisted, workspace: [a, b]). Four PURLs, including the doubly nested is-even/node_modules/is-odd@0.1.2/node_modules/is-number@3.0.0: apply 4/4, both members load patched, vex 4 × not_affected (with --product), rollback 4/4, manifest emptied, blobs GC'd, runtime unpatched again. apply from a member dir gives noManifest (cwd-scoped, expected).
• fail → npm handover: hoisted duplicate copies of one name@version (kind-of@3.2.2 under is-number and is-accessor-descriptor). apply patches both. But with one copy reverted, vex still attests not_affected when the reverted copy isn't the crawler's first match (commands/vex.rs:556 collapse_to_first). Reproduced on real npm 10.9.4 with the realistic trigger (a later npm install adds fresh unpatched nested copies). The root cause and trigger are generic npm, so it's handed over to the npm routine: entries/npm/20261001T200256Z-from-deno.md.
• pass: vendor in a deno.json + deno.lock-only project with an npm: dep gives vendor_lockfile_missing, partialFailure, exit 1, and deno.json / deno.lock are byte-identical.
• pass: Deno 2 "links": ["../local-is-odd"]. Deno copies the linked package into .deno/is-odd@3.0.1 (not a symlink), so an agent patch can't reach the user's source tree.
• pass: isolated-layout apply breaks the .deno ↔ $DENO_DIR hardlink (DENO_DIR cache stays unpatched, link count 1).
• note: vex can't auto-detect a product in a deno.json-only project (needs --product). Documented: deno.json isn't in the auto-detect list.

Filed / commented / closed

None. One handover to npm (above).

Housekeeping

• The stale probe branches bughunt/deno/20260930-deno-store, 20261001-global, 20261001-hoisted and 20261001-scoped-jsr still exist. git push --delete still gives "remote end hung up". A maintainer needs to delete them.

Next

1. Isolated .deno peer variants and scoped entries once Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 lands (re-test Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 then).
2. Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 follow-ups (read-only DENO_DIR / DENO_INSTALL_ROOT on macOS / Windows, rollback -g) once it's fixed.
3. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
4. Hoisted + vendor: true JSR, and CRLF / BOM deno.jsonc / deno.lock on Windows (probe).
5. Re-check the npm handover outcome on the Deno hoisted layout once npm files it.

[github-actions[bot]]

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

Tested: main 61cfb9b (unchanged since the last run), release 4.0.0 (previous 3.3.0). Also PR #496 head 7f41839, the fix for #373. Newest Deno is still 2.9.7 (2.9.8 and 2.10.0 are 404). Linux only, real Deno 1.46.3 / 2.0.6 / 2.2.15 / 2.9.7 release binaries, an offline manifest plus blobs, and runtime markers (globalThis.__SP). No probe branches.

Re-triage

• Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373: still reproduces on main. I checked PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 against real Deno layouts and it passes (table below). Commented with a new symptom on main: Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 (comment)
• Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 / Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 / Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406: the code is unchanged on main, so I didn't re-run them.

Cells

• fail Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 (new symptom on main): Deno copy-index peer variant of a direct dep. With ajv@6.12.0 + ajv-keywords@3.5.2 + schema-utils@2.7.1, Deno writes .deno/ajv-keywords@3.5.2 and .deno/ajv-keywords@3.5.2_1 (Deno uses _N copy indexes, not pnpm-style (peer) suffixes). On main, apply patches only the root-linked copy and reports success/applied. schema-utils loads the unpatched _1 copy at runtime, and vex says not_affected. Reproduced 2/2 on 2.9.7, and also on 2.0.6 and 2.2.15. Deno 1.46.3 (nodeModulesDir: true) resolves a single copy, so it's not affected.
• PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 passes: the copy-index variant (both copies patched, both load patched, rollback restores both); a mixed-case name that Deno hashes (JSONStream → .deno/_jjju6tstorzgkyln@1.3.5), both direct and transitive via conventional-commits-parser; scoped transitive @babel+highlight@7.25.9; transitive through@2.3.8. In every case the $DENO_DIR copy stays untouched (link count 1), VEX gives not_affected, and rollback empties the manifest. Same results on 2.0.6 and 2.2.15.
• VEX with Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496, another trigger for 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: revert only the _1 copy and vex still says not_affected; revert the primary and it exits 1. Same crawl-order defect, so I commented on 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 rather than filing: 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 (comment)
• pass: isolated-linker Deno workspace (workspace: [./a, ./b], with a a deno.json member using npm:is-odd and b a package.json member using left-pad). Deno writes b/node_modules/left-pad → root .deno and node_modules/b -> ../b. apply from the root patches both, both members load patched, vex gives not_affected ×2, rollback restores both. (The JSON shows left-pad twice, once applied and once already_patched via the member symlink. Cosmetic.)
• pass / expected: scan (stub proxy) in the copy-index project queries only the 3 root-linked PURLs. That's the scan side of Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373.

Filed / commented / closed

No new issues. Comments on #373 and #516 (links above).

Housekeeping

• The stale probe branches bughunt/deno/20260930-deno-store, 20261001-global, 20261001-hoisted and 20261001-scoped-jsr still exist. git push --delete still gives "remote end hung up", so a maintainer needs to delete them.

Next

1. Once Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 merges: re-test Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 on main (copy-index, hashed mixed-case, scoped transitive), plus scan discovery and scan --prune keeping transitive records. Close Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 if it passes.
2. Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 follow-ups (read-only DENO_DIR / DENO_INSTALL_ROOT on macOS / Windows, rollback -g) once it's fixed.
3. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
4. Hoisted + vendor: true JSR. Probe macOS / Windows for copy-index _1 and the hashed _<base32> folders (case-insensitive FS).
5. Re-check 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 on the Deno _1 layout once it's fixed.

[github-actions[bot]]

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

Tested: main 61cfb9b (unchanged since the last two runs), release 4.0.0 (previous 3.3.0). Also a local merge of PR #517 (0f45d24, the #516 fix) with PR #496 (7f41839, the #373 fix); they merge with no conflicts. Newest Deno is still 2.9.7 (2.9.8, 2.9.9 and 2.10.0 are 404). Linux only, real Deno 2.2.15 / 2.9.7 release binaries, an offline manifest plus git-sha256 blobs, and runtime markers (globalThis.__SP). No probe branches. No human replies on the discussion.

Re-triage

• Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 / Deno JSR packages are never found in a real Deno project: the crawler only probes $DENO_DIR/npm/jsr.io, and the matching ./vendor/jsr.io layout from "vendor": true is ignored #374 / Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 / Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444: still open. No fix has merged (Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 and Fix agent vex checking only one installed copy (#516) #517 are still open PRs) and the code is unchanged on main, so I didn't re-run them.

Cells

• fail, new info on 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 (PR Fix agent vex checking only one installed copy (#516) #517 gap): with Fix agent vex checking only one installed copy (#516) #517 + Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 merged locally, Deno 2.9.7 ajv@6.12.0 + ajv-keywords@3.5.2 + schema-utils@2.7.1. apply patches both .deno/ajv-keywords@3.5.2 and .deno/ajv-keywords@3.5.2_1. With only _1 reverted, schema-utils loads it unpatched at runtime ([]), but vex exits 0 with not_affected. Reproduced 2/2 from clean projects. Cause: Fix agent vex checking only one installed copy (#516) #517 takes copies from NpmCrawler::find_by_purls, which by design skips store peer-variant copies. Those copies are only patched through the apply engine's find_store_peer_variant_copies fan-out. Commented: 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 (comment) (pnpm .pnpm peer variants are probably affected too; not verified here).
• pass: hoisted linker (2.9.7, nodeModulesDir: manual, nodeModulesLinker: hoisted). apply (is-odd + nested is-number) then deno install re-links the unpatched bytes (documented), then rollback --offline gives success, alreadyOriginal: 2, rc 0. The manifest is emptied and the blobs are GC'd.
• pass: deno.lock v4 (Deno 2.2.15, nodeModulesDir: auto, imports → npm:is-odd@3.0.1). apply leaves deno.lock byte-identical, deno install --frozen gives rc 0, deno run --frozen loads the patched copy, and vex --product … -O gives not_affected.
• note: vex --json without -O gives json_requires_output (documented).

Filed / commented / closed

No new issues. One comment on #516 (link above).

Housekeeping

• The stale probe branches bughunt/deno/20260930-deno-store, 20261001-global, 20261001-hoisted and 20261001-scoped-jsr still need a maintainer to delete them. This run's push --delete attempt was blocked by the session's permission policy.

Next

1. Once Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 / Fix agent vex checking only one installed copy (#516) #517 merge, re-test Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 (copy-index, hashed, scoped transitive, scan --prune) and the _1 VEX case. Close Deno nodeModulesDir: transitive npm packages under node_modules/.deno are "not installed", and apply/scan exit 0 leaving them unpatched #373 if it passes.
2. Global mode can't see any Deno global install: the npm packages under $DENO_DIR/npm/registry.npmjs.org are never crawled, so scan -g misses them and Deno 2.9's per-tool node_modules gets patched and VEX-attested while the tool runs the unpatched copy #444 follow-ups (read-only DENO_DIR / DENO_INSTALL_ROOT on macOS / Windows, rollback -g) once it's fixed.
3. Hosted npm pin in package-lock.json is attested by VEX in a Deno project, but deno.lock keeps installing the unpatched registry copy #406 follow-ups: pnpm-lock / yarn.lock / bun.lock beside deno.lock.
4. Probe macOS / Windows for the .deno _1 / _<base32> folders once Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496 lands.
5. Interrupted / concurrent apply against a hardlinked .deno store (the DENO_DIR cache must stay pristine).