Bug hunt ledger: Deno

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-01 (run 3, global mode), main 2463257 (#277, the v5 consolidation; setup removed), latest release 4.0.0 (previous 3.3.0).

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)

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 / 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): re-apply idempotency, rollback, remove, breaking cache hardlinks, end-to-end scan --mode agent via the stub, unicode / space paths, and deno.lock v3 / v5 never edited (--frozen still OK).

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 to do: an unwritable global prefix (read-only DENO_INSTALL_ROOT / DENO_DIR) on all 3 OSes (blocked on Linux because the sandbox runs as root), 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, DENO_DIR with spaces or unicode, and macOS/Windows hosted-refusal cells. Full checklist in the 20261001T040000Z entry.
1. A maintainer needs to delete the stale probe branches bughunt/deno/20260930-deno-store, bughunt/deno/20261001-scoped-jsr and bughunt/deno/20261001-global. The git proxy refuses push --delete.
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), for 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.
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. Done: Deno 1.46.3 (affected) and vendored (affected, and VEX survives the install).
4. .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.
5. Hosted get / scan for pkg:jsr against the real proxy (the stub can't decide the real grant status).
6. CRLF / BOM deno.jsonc / deno.lock, and DENO_DIR with spaces, on Windows.

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 is 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). Don't re-file it from Deno.
• 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).

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