Bug hunt ledger: vlt

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-01 (run 4), main 5678b76, latest release 4.0.0 (no vlt support; previous 3.3.0). Newest vlt: 1.3.3 (2026-10-01).

Method: real vlt installs (scripts/install-vlt.sh) against a local Node mock of the npm registry plus the patch API. It's a pure-JS tar writer, so it runs on every OS. The registry is on :18555 and the patch server on :18556 via SOCKET_PATCH_SERVER_URL; set SOCKET_NPM_REGISTRY to the registry for v5 rollback. The oracle is require('left-pad') printing patched / pristine. The 3-OS probe scripts are in the run-2 workflow (run 36803186961), the run-3 global-mode workflow (run 36834317384) and the run-4 bundled-copy workflow (run 36871535059, whose mock adds a bundler@1.0.0 that bundles left-pad). The mock's /patches/batch must answer only for purls in the request body, or scan -g shows false hits. CI already runs the capstones and the native backtest on 57 releases × 3 OS.

Coverage matrix

OS	vlt	Hosted (scan / rollback / remove)	Vendored (+ takeover, rollback)	Agent	Notes
Linux	1.0.0-rc.14	pass (rollback byte-exact, era B 3-tuple)	untested (CI)	untested (CI)	CI native leg flaked once (warmOrdinary, PR #277 run), root cause blocked
Linux	1.0.0-rc.32	untested (resolves from npmjs; mock can't serve it)	untested (CI)	untested (CI)
Linux	1.0.10	pass (incl. config.registry 3-tuple)	untested (CI)	untested (CI)
Linux	1.2.0	pass	pass	pass	brotli: flag stays 0
Linux	1.3.0	untested	untested	untested	vlt itself fails install against tar.br registries
Linux	1.3.1	fail #372 (brotli registries)	fail #372	untested
Linux	1.3.2	pass on npm-style registries; fail #372 with tar.br alternates	pass (workspaces incl. 4-deep, space/unicode dirs; takeover; repair; re-run idempotent); fail #372 with tar.br	pass (hardlinked store is copy-on-write)
macOS	1.2.0 / 1.3.2	pass (probe run 2)	pass (probe run 2)	pass (probe run 2)	brotli untested
Windows	1.2.0 / 1.3.2	pass (probe run 2)	pass (probe run 2)	pass (probe run 2)	brotli untested
Linux / macOS / Windows	1.3.3	scan → vlt ci patched (probe run 3); rollback via -g path only (#445); fail #372 with tar.br (Linux)	scan → vlt ci patched (probe run 3); frozen / vex / workspaces untested	untested	new release, 2026-10-01

Bundled copies (a package bundling the patched name@version; vlt-lock.json never records the bundled copy)

OS	vlt 1.0.10	vlt 1.2.0	vlt 1.3.3
Linux / macOS / Windows	fail #471 (hosted + vendored: vex attests, bundled copy pristine)	fail #471	fail #471

Global mode (-g; vlt has no global install, so this is an npm global prefix with a vlt project in the cwd)

OS	vlt	scan -g report	-g / SOCKET_GLOBAL / --global-prefix × --mode hosted refusal	agent apply / vex / rollback (-g, get -g, env)	--global-prefix with space + unicode	unwritable prefix	rollback -g / remove -g leave the project alone
Linux	1.0.10 / 1.2.0 / 1.3.3	pass	pass	pass	pass	pass (scan); get re-run → npm handover	fail #445
macOS	1.0.10 / 1.2.0 / 1.3.3	pass	pass	pass	pass	pass (scan)	fail #445
Windows	1.0.10 / 1.2.0 / 1.3.3	fail #434 (default prefix)	pass	fail #434 (default prefix)	pass	untested	fail #445

Backlog

1. Maintainer -g request (20261001T040000Z): covered in run 3, except Windows with the default prefix (blocked on 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 / PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442) and the Windows unwritable prefix (Program Files). Re-probe once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands.
2. rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 follow-ups once PR Fix -g touching the cwd project's state (#436, #445) #446 lands: a patched global plus a hosted project (only the global is restored), and repair -g / vendor -g in a vlt project.
3. vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471 follow-ups once fixed: a bundled copy at a different version (must not contest), a bundle nested in a bundle, and agent mode on the bundled store copy.
4. v5 upstream restore against a registry with non-conventional dist.tarball (Artifactory scoped /-/@scope/name-ver.tgz).
5. Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 follow-ups once fixed: a mixed brotli / non-brotli lock, a brotli dev node (flag 6) heal, the restore putting bit 4 back, and VEX on brotli nodes.
6. Peer-extras DepIDs (two instances of one name@version) through hosted scan → remove.
7. Concurrent or interrupted scan / rollback on vlt projects.
8. vlt 1.3.3 frozen / workspaces cells on macOS and Windows.
9. Root-cause the intermittent CI native (ubuntu, rc.14) hosted-direct warmOrdinary failure if it recurs.

Known non-bugs

• Hosted pins are recognized only on patch.socket.dev or SOCKET_PATCH_SERVER_URL. Against a mock without it, rollback says "Manifest not found" (documented).
• If the patch server shares the project registry's config.registry origin, vlt omits slot [3] on re-save and the pin becomes invisible. That's a mock artifact only.
• vlt re-saves CRLF locks as LF on any install (documented). socket-patch itself keeps \r through scan and rollback.
• scan <member-dir> in hosted mode scans the member as its own project (contract: "as if it were --cwd"), so a workspace member with no lock redirects nothing (redirect_npm_no_lockfile, rc 0; the human output says "Switched 0").
• Vendored refuses a package entirely when any instance is on a named non-default registry (vendor_lock_entry_unsupported). That's loud and fail-closed.
• vlt 1.0.0-rc.14 / rc.32 resolve from public npmjs despite registries.npm.
• The nightly canary failure "vlt 1.3.x is published but neither supported nor excluded" is the docs Releases table lagging new vlt releases.
• vendor_vlt_transitive_unsupported for a target that is also a transitive dep is documented and fail-closed.
• vlt 1.3.0 fails vlt install with "Integrity check failure" against registries advertising tar.br alternates (a vlt bug, fixed in 1.3.1).
• Sandbox: the Rust binaries can't reach npmjs through the TLS proxy (serve version docs locally), vlt's cold-cache "security data" fetch fails, vlt's machine cache must be isolated per mock change (XDG/HOME), the Actions artifact/log blob host is blocked, and the git proxy drops branch deletions.
• Release 4.0.0 reports redirect_npm_no_lockfile on vlt projects: it predates vlt support.
• vlt has no global install surface (no vlt install -g, as of 1.0.10 … 1.3.3). -g only covers npm/pnpm/yarn/bun globals.
• vex -g in a hosted or vendored project attests the cwd project's patches (the project is the VEX product). That's deliberate per commands/vex.rs:1013 (cwd ledgers gate discovery under --global).
• A -g "unwritable prefix" test needs files the user doesn't own: socket-patch may chmod files it owns.
• vlt-lock.json has no node for a bundled copy (1.0.10 … 1.3.3). That's vlt's format, not a socket-patch parse bug. The bug is vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471 (not detecting it).

[github-actions[bot]]

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

Tested: main f6b7fb9 (CLI 4.0.0 workspace version). The latest published release is 4.0.0 (previous 3.3.0), but it predates vlt hosted support: on a vlt project it reports redirect_npm_no_lockfile, so it can't be compared. vlt 1.0.0-rc.14, 1.0.10, 1.2.0, 1.3.0, 1.3.1 and 1.3.2 (the current latest), installed through scripts/install-vlt.sh, on Node 22.22.2 on Linux. Patch data came from a local Node mock of the npm registry plus the patch API (mock.mjs, below), and from a hand-staged .socket/ for agent mode. No secrets.

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

CI status found

• The nightly vlt-compatibility.yml fails on main (runs 36522277204 and 36669570554), but only in canary (ubuntu-latest). The cause is "vlt 1.3.0 / 1.3.1 is published but neither supported nor excluded" in docs/testing/vlt-compatibility.md (Releases). All 5 capstone suites pass on 1.3.1 in that job, and push-triggered runs and ci.yml's 35 vlt e2e rows plus hosted-e2e are green. So this is a doc/matrix gap, not a code failure, and nothing was filed for it. vlt 1.3.2 is also out now.

Cells

• fail Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372: vlt ≥ 1.3.0 brotli tarballs. With a registry that advertises dist.alternates tar.br, vlt writes node flag bit 4. vlt_lock_text.rs:673 only accepts 0–3, so hosted refuses the lock (redirect_vlt_lock_unsupported, rc 0, stays unpatched) and vendored fails with vendor_lockfile_version_unsupported. Reproduced on 1.3.1 and 1.3.2. The control with no alternates passes. I verified by hand that a fix must also clear bit 4, otherwise vlt ci rewrites the lock.
• pass, Linux, vlt 1.3.2: all five real-vlt capstones (e2e_redirect_vlt_build 37 ran / 1 skip, e2e_vendor_vlt_build 30/2, mode_migration_vlt 12/2, e2e_safety_vlt 7/3, e2e_vlt 14/1), and every check-vlt-legs manifest is clean. 1.3.2 behaves as 1.2.0 on npmjs bytes.
• pass, vlt 1.3.2 against the mock: hosted scan → vlt install / vlt ci patched; vendored scan → vlt ci patched, lock byte-stable through --frozen-lockfile, vendor --revert byte-exact; vendored workspace members, including the dirs packages/my pkg and packages/café (DepIDs my_spkg, café); transitive-only target refused with vendor_vlt_transitive_unsupported; a direct+transitive target also refused, lock untouched; hosted direct+transitive both patched; agent apply / rollback on a brotli (flag 4) store; vex attests hosted and vendored-workspace projects and emits nothing for the refused project.
• vlt 1.3.0 itself fails vlt install ("Integrity check failure") against a registry advertising alternates. That's a vlt bug (fixed in 1.3.1), not ours.

Issues

• Filed Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372).

False positives ruled out

• scan --mode vendored giving no_local_source against my first mock: vendored needs blobContent in the patch view and the /patches/blob/<hash> route. It was a mock gap.
• Capstones failing "could not fetch … from npmjs" in the sandbox: the test harness's reqwest::Client doesn't trust the sandbox TLS proxy CA. Prefill /tmp/socket-patch-test-caches/vlt-e2e-registry/v1/<name+scope>@<ver>.{json,tgz} with curl (the version manifest JSON plus the tarball).

Probe

• No probe branch this run. Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 is in a pure text parser, so it's expected to be OS-independent, and macOS/Windows remain untested for it.

Next

1. Update the docs matrix (maintainer side) for 1.3.0–1.3.2 and re-check Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 once the fix lands. Hosted on a mixed lock (some brotli nodes, some not): the lock-level check passes, the brotli target is refused per-dep. Confirm redirect_vlt_lock_entry_unsupported wording.
2. Probe branch: vlt 1.3.2 capstones on macOS and Windows (not in CI yet), plus store-linker hardlink/copy on 1.3.2.
3. Heal after a hosted rewrite on a brotli dev node (flag 6): reinstalls_after_removal keeps the stale copy.
4. Workspaces nested ≥ 3 deep and a workspace member depending on another member that depends on the target (member-transitive refusal).
5. vlt install --lockfile-only checkouts → hosted/vendored → vlt ci.

mock.mjs (registry + patch API; PORT, NO_ALT=1 turns off the tar.br alternates)

import http from 'node:http';
import zlib from 'node:zlib';
import crypto from 'node:crypto';
import { execSync } from 'node:child_process';
import fs from 'node:fs';
const PORT = +process.env.PORT || 18555;
const R = `http://127.0.0.1:${PORT}`;
const NAME='left-pad', VER='1.3.0', UUID='aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa', TOKEN='bbbbbbbb-bbbb-4bbb-8bbb-bbbbbbbbbbbb', ORG='test-org';
const PURL=`pkg:npm/${NAME}@${VER}`;
const ALT = process.env.NO_ALT ? false : true;
function tarOf(content){
  const d=fs.mkdtempSync('/tmp/bt/t'); fs.mkdirSync(d+'/package');
  fs.writeFileSync(d+'/package/package.json', JSON.stringify({name:NAME,version:VER,main:'index.js'})+'\n');
  fs.writeFileSync(d+'/package/index.js', content);
  const tar = execSync(`tar -C ${d} --owner=0 --group=0 --mtime=@0 -cf - package`);
  return tar;
}
const sri = b => 'sha512-'+crypto.createHash('sha512').update(b).digest('base64');
const git = b => crypto.createHash('sha256').update(Buffer.concat([Buffer.from(`blob ${b.length}\0`), b])).digest('hex');
const PRIST = Buffer.from("module.exports = 'pristine'\n"), PATCH = Buffer.from("module.exports = 'patched'\n");
const tgz = zlib.gzipSync(tarOf(PRIST)), br = zlib.brotliCompressSync(tarOf(PRIST)), ptgz = zlib.gzipSync(tarOf(PATCH));
function wrapTar(){ const d=fs.mkdtempSync('/tmp/bt/w'); fs.mkdirSync(d+'/package'); fs.writeFileSync(d+'/package/package.json', JSON.stringify({name:'wrapper',version:'1.0.0',main:'index.js',dependencies:{'left-pad':'1.3.0'}})+'\n'); fs.writeFileSync(d+'/package/index.js', "module.exports = require('left-pad')\n"); return zlib.gzipSync(execSync(`tar -C ${d} --owner=0 --group=0 --mtime=@0 -cf - package`)); }
const wtgz = wrapTar();
const artPath = `/patch/npm/${NAME}/${VER}/${TOKEN}/${UUID}/${NAME}-${VER}.tgz`;
const log = [];
http.createServer((req,res)=>{
  let body=''; req.on('data',c=>body+=c); req.on('end',()=>{
  const u = req.url.split('?')[0]; log.push(req.method+' '+u); fs.appendFileSync('/tmp/bt/mock.log', req.method+' '+u+'\n');
  const j = o => { res.writeHead(200,{'content-type':'application/json'}); res.end(JSON.stringify(o)); };
  const b = x => { res.writeHead(200,{'content-type':'application/octet-stream'}); res.end(x); };
  if (u===`/${NAME}`) {
    const dist = {tarball:`${R}/${NAME}/-/${NAME}-${VER}.tgz`, integrity: sri(tgz)};
    if (ALT) dist.alternates=[{kind:'tar.br', tarball:`${R}/${NAME}/-/${NAME}-${VER}.tar.br`, integrity: sri(br)}];
    return j({name:NAME, 'dist-tags':{latest:VER}, versions:{[VER]:{name:NAME,version:VER,main:'index.js',dist}}});
  }
  if (u==='/wrapper') return j({name:'wrapper','dist-tags':{latest:'1.0.0'},versions:{'1.0.0':{name:'wrapper',version:'1.0.0',main:'index.js',dependencies:{'left-pad':'1.3.0'},dist:{tarball:`${R}/wrapper/-/wrapper-1.0.0.tgz`,integrity:sri(wtgz)}}}});
  if (u==='/wrapper/-/wrapper-1.0.0.tgz') return b(wtgz);
  if (u===`/${NAME}/-/${NAME}-${VER}.tgz`) return b(tgz);
  if (u===`/${NAME}/-/${NAME}-${VER}.tar.br`) return b(br);
  if (u===artPath) return b(ptgz);
  if (u.startsWith(`/v0/orgs/${ORG}/patches/blob/`)) { const h=u.split('/').pop(); for (const x of [PRIST,PATCH]) if (git(x)===h) return b(x); }
  if (u===`/v0/orgs/${ORG}/patches/batch`) return j({packages:[{purl:PURL,patches:[{uuid:UUID,purl:PURL,tier:'free',cveIds:[],ghsaIds:[],severity:'high',title:'fx'}]}],canAccessPaidPatches:false});
  if (u.startsWith(`/v0/orgs/${ORG}/patches/by-package/`)) return j({patches:[{uuid:UUID,purl:PURL,publishedAt:'2024-01-01T00:00:00Z',description:'x',license:'MIT',tier:'free',vulnerabilities:{}}],canAccessPaidPatches:false});
  if (u===`/v0/orgs/${ORG}/patches/package`) return j({results:{[UUID]:{status:'granted',url:R+artPath,purl:PURL,artifacts:[{kind:'tarball',url:R+artPath,integrity:{sha512:sri(ptgz)}}],registryOverride:null}}});
  if (u===`/v0/orgs/${ORG}/patches/view/${UUID}`) return j({uuid:UUID,purl:PURL,publishedAt:'2024-01-01T00:00:00Z',files:{'package/index.js':{beforeHash:git(PRIST),afterHash:git(PATCH),blobContent:PATCH.toString('base64'),beforeBlobContent:PRIST.toString('base64')}},vulnerabilities:{'GHSA-vlth-aaaa-bbbb':{cves:['CVE-2026-4242'],summary:'s',severity:'high',description:'d'}},description:'x',license:'MIT',tier:'free'});
  res.writeHead(404); res.end('nf');
  });
}).listen(PORT, '127.0.0.1', ()=>console.log('listening', PORT));

[github-actions[bot]]

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

Tested: main 2463257 ("feat!: consolidate the v5 patching workflow", #277; CLI still reports 4.0.0). Latest release is still 4.0.0 (previous 3.3.0); neither has vlt support, so v5 can't be bisected against a release. vlt 1.3.2 (still latest, no new release since run 1), 1.2.0, 1.0.10, 1.0.0-rc.32, 1.0.0-rc.14, on Node 22.22.2 (Linux) and Node 24.21.0 (probe). Patch data comes from the run-1 mock, now with a pure-JS tar writer (so it runs on Windows) and the /<name>/<version> version doc that v5's upstream restore fetches. It runs on two ports: the registry on :18555 and the patch API/artifacts on :18556 with SOCKET_PATCH_SERVER_URL, because a shared origin is a mock artifact, see below.

Focus this run: v5 regressions. #277 replaced v4's hosted ledger with the upstream restore (patch/redirect/upstream/vlt.rs) for rollback / remove / the hosted→vendored takeover, and made hosted the default for a bare scan.

Re-triage

• Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (brotli flag bit 4) still reproduces on 2463257: bare scan gives rc 0, redirected: 0, redirect_vlt_lock_unsupported; --mode vendored gives partial_failure with vendor_lockfile_version_unsupported. Commented: Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (comment) (v5 now hits it with no flags, and the new upstream restore shares the parser).

Cells (all pass unless noted)

• Linux, vlt 1.3.2 / 1.2.0 / 1.0.10, hosted: bare scan → warm vlt install patched → vlt ci patched, lock byte-stable → rollback gives a byte-exact lock and a pristine warm install. Also checked: config.registry 3-tuple locks (no slot [3] written back); CRLF lock (rollback is byte-exact and keeps \r); re-scan idempotent; rollback --dry-run writes nothing; remove <purl> is byte-exact; get <purl>; rollback after vlt install wrapper added a second dependent; lockfile-only checkout with a sibling package-lock.json (redirect_vlt_sibling_lockfiles; both restored byte-exact; npm_allow_remote_left as documented).
• Linux, rc.14 (era B, ·npm· 3-tuple, lockfileVersion 0): hosted scan → rollback byte-exact (restore against a local copy of the real npmjs version doc).
• Linux, 1.3.2 / 1.2.0, hosted→vendored takeover → vlt ci patched → frozen install byte-stable → rollback byte-exact, .socket/ removed.
• Linux, 1.3.2, vendored workspaces: members packages/a → packages/b → left-pad and a 4-deep member apps/x/y/z (edge file:../../../../.socket/...). vlt ci patched, frozen stable, vex attests, rollback byte-exact.
• Linux, 1.3.2, default + named-registry copies of the same left-pad@1.3.0 (corp: alias in a member): hosted redirects only the default node (redirect_vlt_custom_registry_skipped), and vex refuses to attest. Vendored refuses the whole package with vendor_lock_entry_unsupported (loud, partial_failure).
• Linux, 1.3.2, agent on the hardlinked global store: patching project A breaks the hardlink (link count 9 → 1 on A's copy), and projects B and C stay pristine. Path-scoped agent rollback 'apps/**' restores all 3 copies and emits out_of_scope_copies_restored.
• Linux, 1.3.2, vendored re-run idempotent (lock + .socket files stable), repair after deleting a payload file, remove byte-exact.
• Probe: ubuntu / macos / windows × vlt 1.2.0 / 1.3.2, all 6 green, 22/22 checks each (hosted scan/warm/ci/rollback, CRLF, takeover + vendored ci/frozen/vex/rollback, a vendored workspace with dirs packages/my pkg and packages/café, agent apply/rollback/other-project isolation). Run: https://github.com/SocketDev/socket-patch/actions/runs/36803186961. This is the first macOS/Windows coverage of vlt 1.3.x, which CI's matrix still doesn't list.
• CI install-proof legs: on main's push run (36798098098) every vlt-compatibility job is green. On PR v5 prerelease: scan → vex → vendor workflow, hosted by default #277's run (36797999817), one cell failed: native (ubuntu-latest, 1.0.0-rc.14) hosted-direct: unsafe, failing=['warmOrdinary'] (35/36). The same cell passed on main 13 minutes later, and it passes 5/5 locally against the mock. Blocked: the result artifact (11134182795) is on the Actions blob host, which the sandbox proxy refuses (403), so I couldn't root-cause it. It's an intermittent production-service leg; nothing filed.

Issues

• Commented on Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (still reproduces on v5 main). No new issues: nothing met the filing bar.

False positives ruled out

• rollback printed "Manifest not found" after a hosted scan against the mock. The contract only recognizes hosted pins on patch.socket.dev or SOCKET_PATCH_SERVER_URL; with that set, rollback works.
• config.registry project left patched after rollback: my patch server shared the registry's origin, so vlt re-saved the hosted node without slot [3] (its registry prefix rule), and the pin became invisible. That's a mock artifact; with the patch server on a separate origin it passes on 1.0.10, 1.2.0 and 1.3.2.
• Rollback lock "differ" in the first probe draft: vlt's machine-wide cache still held tarballs from the old mock at the same URL (stale integrity). The probe now isolates XDG/HOME per run.
• CRLF rollback "differ" after a vlt install: vlt re-saves locks as LF (documented). This was my probe's fault.
• vlt ci "Failed to fetch security data" on a cold cache (1.0.10, 1.2.0): the sandbox network blocks it. It passes on the GitHub runners.
• rc.32 / rc.14 rollback "differ" in the probe: those releases resolved left-pad from public npmjs despite registries.npm, while the probe's SOCKET_NPM_REGISTRY pointed at the mock. The integrity mismatch came from my probe. Restoring rc.14 against the real npmjs doc is byte-exact.
• scan packages/b (hosted) in a vlt workspace finds the patch but redirects nothing (redirect_npm_no_lockfile, rc 0). The contract defines each PATH as its own project "exactly as if it were --cwd (its own lockfiles)", and the human output says "Switched 0 packages". So this is documented. The warning names npm locks rather than the root vlt-lock.json: cosmetic, not filed.

Infra

• Probe-branch delete is blocked: git push origin --delete bughunt/vlt/20261001-v5-rollback-3os prints "Everything up-to-date" and the ref stays (4 attempts, plus one try with an explicit :refs/heads/... refspec). Sibling routines' bughunt/<pm>/* branches are stuck the same way. A maintainer needs to delete them; the session git proxy seems to drop ref deletions.

Next

1. Upstream restore against a registry whose dist.tarball isn't the conventional {base}/{name}/-/{leaf}-{ver}.tgz (Artifactory scoped /-/@scope/name-ver.tgz). The restore rebuilds slot [3] conventionally from the project registry and takes integrity from SOCKET_NPM_REGISTRY (npmjs), not the project registry. Check whether vlt ci still installs after rollback on such a registry.
2. Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 follow-ups once fixed: a mixed brotli / non-brotli lock, a brotli dev node (flag 6) in the heal, and the upstream restore putting bit 4 back.
3. Peer-extras DepIDs (~npm~x@1~peer.<hex>, two instances of one name@version) through hosted scan → remove (all-or-nothing per pin).
4. Concurrent scan + rollback (apply.lock) on a vlt project, and a rollback interrupted mid-run.
5. vlt 1.3.x in the docs Releases table / CI matrix (maintainer side), then drop the probe.

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

Where vlt puts global installs: Whatever vlt's global install surface is on each vlt version (none, or vlt install -g). If vlt has none, -g must not pick up the project's vlt store, and must still report the other Node globals.

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

Tested: main 2463257 (unchanged since run 2), latest release 4.0.0 (previous 3.3.0). New vlt release: 1.3.3 (2026-10-01T02:36Z, now latest), covered this run. Also covered vlt 1.2.0 and 1.0.10. Node 22.22.0 in the sandbox, 24.21.0 on the probes. Focus: the maintainer's global-mode (-g) checklist (20261001T040000Z entry).

vlt has no global install surface: none of 1.0.10, 1.2.0 or 1.3.3 has vlt install -g or a global prefix. So -g reaches only npm/pnpm/yarn/bun globals, and must never pick up a vlt project or its store. The global cells below use an npm global prefix (NPM_CONFIG_PREFIX), plus a vlt project in the cwd as the thing that must stay untouched.

Re-triage

• Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (brotli flag): still reproduces on main and on vlt 1.3.3: slot [0] = 4, redirect_vlt_lock_unsupported, 2/2 runs. Commented: Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (comment)

Cells: probe run https://github.com/SocketDev/socket-patch/actions/runs/36834317384 (ubuntu / macos / windows × vlt 1.0.10 / 1.2.0 / 1.3.3) plus the Linux sandbox

• scan -g --json (report-only) inside and outside a vlt project: finds exactly the global left-pad, with no project leakage. The project lock and .socket are untouched, and the global copy is unchanged. pass on Linux and macOS (all 3 vlt). On Windows, fail (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): bare npm root -g finds nothing (fix in PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442).
• scan -g --mode hosted, scan --global-prefix <dir> --mode hosted and SOCKET_GLOBAL=1 scan --mode hosted: exit 2, nothing written. pass, all 9 cells.
• scan -g --mode agent → global patched, project pristine → vex -g rc 0 → rollback -g byte-exact. get <purl> -g (agent default) and SOCKET_GLOBAL=1 the same. pass on Linux and macOS. On Windows 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 (exit 0, nothing patched).
• --global-prefix "<dir>/my prefix café/node_modules": apply and rollback byte-exact, the default global untouched. pass, all 9 cells, Windows included.
• A local (non--g) agent scan never touches the global copy. pass, 9/9.
• Unwritable (root-owned) global prefix, probe run https://github.com/SocketDev/socket-patch/actions/runs/36835560958 (ubuntu, macos) plus the sandbox as a non-root user: scan -g --mode agent, --global-prefix and SOCKET_GLOBAL=1 all give rc 1 partial_failure, global unchanged (pass). But a re-run of get -g after a failed one exits 0 success ("already in manifest") with the global copy unpatched. That's npm global, not vlt: handed over to npm (entries/npm/20261001T083036Z-from-vlt.md).
• FAIL → rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445: rollback -g and remove <purl> -g run inside a hosted or vendored vlt project also unwind the project: lock restored or unwired, .socket/vendor deleted, node_modules/left-pad deleted, rc 0. This happens even with an empty global prefix. 9/9 probe cells plus the sandbox, and npm projects too. Bisected to d5e1815 (feat!: scan↔rollback duality — full-state rollback default, --preserve-state, path targeting #231, full-state rollback). 4.0.0 and 3a2b06d are clean. Same root cause: in a vendored project, scan -g --mode agent skips the global copy (vendored_ownership_retained, rc 0).

Issues

• Filed rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445: rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445
• Commented on Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (vlt 1.3.3).
• Handover to npm (Bug hunt ledger: npm #302): failed get -g re-run reports success.

False positives ruled out

• scan -g "found" the project's left-pad with an empty global prefix. My mock's /patches/batch answered left-pad for any query. With the mock filtering on the request body, scan -g reports 0. Not a bug.
• vex -g in a hosted or vendored project emits a statement for the project's patched left-pad, with the project as the VEX product. vex.rs:1013 documents that the cwd ledgers and pins are consulted under --global on purpose. Not filed; noted under Known non-bugs.
• The probe's first read-only cell (chmod -R a-w on runner-owned files) "patched anyway": the owner can chmod its own files. Re-done with a root-owned prefix, which fails loudly.
• 1.2.0 / 1.0.10 vlt ci leaving left-pad missing in the sandbox: "Failed to fetch security data" (known sandbox network block). It passes on runners.

Infra

• The probe-branch deletes are still dropped by the git proxy ("Everything up-to-date", ref stays). Stuck: bughunt/vlt/20261001-v5-rollback-3os, bughunt/vlt/20261001-global-3os, bughunt/vlt/20261001-global-ro. A maintainer needs to delete them.

Next

1. Global-mode on Windows once PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 (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) lands: re-run the run-36834317384 probe on windows-latest with the default prefix.
2. rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 follow-up once fixed: rollback -g with a patched global AND a hosted project (only the global is restored), and repair -g / vendor -g in a vlt project.
3. v5 upstream restore against a non-conventional dist.tarball registry (Artifactory scoped path).
4. Peer-extras DepIDs (two instances of one name@version) through hosted scan → remove.
5. Concurrent / interrupted scan + rollback on a vlt project.

[github-actions[bot]]

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

Tested: main 5678b76 (3 commits past 2463257: #330 Poetry, #337 npm bundled-copy VEX fix for #325, #322 Maven docs). Latest release is still 4.0.0 (previous 3.3.0). vlt 1.0.10 / 1.2.0 / 1.3.3 (1.3.3 is still the newest). Node 22.22.0 in the sandbox, 24.21.0 on the probes. Focus: does the new #337 bundled-copy contest reach vlt?

Re-triage

• rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 (rollback -g unwinds the cwd project): still reproduces on 5678b76 (Linux, vlt 1.3.3, empty npm global prefix; hosted pin removed from vlt-lock.json, rc 0). The fix is open in PR Fix -g touching the cwd project's state (#436, #445) #446. No comment, nothing new to add.
• Hosted and vendored modes refuse vlt 1.3 locks whose nodes carry the new brotli flag (slot [0] = 4) #372 (brotli flag): no parser change on main (vlt_lock_text.rs untouched by the 3 new commits), and already re-triaged on 1.3.3 last run. No comment.

Cells: probe run https://github.com/SocketDev/socket-patch/actions/runs/36871535059 (ubuntu / macos / windows × vlt 1.0.10 / 1.2.0 / 1.3.3) plus the Linux sandbox

• Bundled copy (bundler@1.0.0 with bundleDependencies: ["left-pad"], plus a direct left-pad@1.3.0), hosted: scan rc 0 with no bundled warning → vlt ci → direct copy patched, bundled copy pristine → vex attests not_affected. FAIL vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471, 9/9 cells plus sandbox 3/3.
• The same in vendored mode: FAIL vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471, 9/9.
• npm control (same mock, npm install): warns redirect_npm_bundled_instance_skipped, and vex refuses to attest. That's the Fix npm VEX attesting packages with an unpatched bundled copy (#325) #337 behaviour, so it passes.
• Bundled-only (no direct dep), hosted: rc 0 with redirect_vlt_entry_not_found "run vlt install first", which is misleading. Folded into vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471.
• vlt-lock.json never records bundled copies (1.0.10 … 1.3.3), so a lock-only fix can't work. The contest must come from the store or from manifest bundleDependencies.

Issues

• Filed vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471: vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471
• No comments or closes.

False positives ruled out

• vlt 1.2.0 vlt ci rc 1 in the sandbox: the known "security data" fetch block. It passes on all runners.

Infra

• The probe reused my existing branch bughunt/vlt/20261001-global-3os (merged origin/main, so the diff is still the single workflow file), so no new branch was added. The delete is still dropped by the git proxy ("remote end hung up" / "Everything up-to-date"). Still stuck: bughunt/vlt/20261001-global-3os, bughunt/vlt/20261001-global-ro, bughunt/vlt/20261001-v5-rollback-3os. A maintainer needs to delete them.

Next

1. Global-mode on Windows once PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 (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) lands (default prefix).
2. rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 follow-ups once PR Fix -g touching the cwd project's state (#436, #445) #446 lands: rollback -g with a patched global AND a hosted project, and repair -g / vendor -g in a vlt project.
3. vlt hosted and vendored vex attests not_affected while a bundled copy of the same name@version in node_modules/.vlt stays unpatched (the #325 fix covers npm locks only) #471 follow-ups once fixed: a bundled copy at a different version (must not contest), a nested bundle (a bundle inside a bundle), and agent mode on the bundled store copy.
4. v5 upstream restore against a non-conventional dist.tarball registry (Artifactory scoped path).
5. Peer-extras DepIDs (two instances of one name@version) through hosted scan → remove.