Hosted and vendored scans from a vlt workspace member with a stray vlt-lock.json still write to that lock and exit 0 when the root's workspaces glob uses an extglob (packages/+(a|b), packages/@(a|b)); vendored VEX then attests not_affected #1542

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

Summary

#1134 (fixed by #1161) made hosted and vendored runs from a vlt workspace member refuse when the member holds a stray vlt-lock.json that vlt never reads. The member check matches the root's workspaces patterns with WorkspacesDialect::VLT, and that dialect sets extglob: false. vlt itself does expand extglobs: with "workspaces": ["packages/+(a|b)"] or ["packages/@(a|b)"], vlt 1.2.0 and 1.3.8 install packages/a as a member from the root lock. socket-patch doesn't see packages/a as a member, so the #1134 refusal never fires and the original #1134 failure comes back:

• hosted: exits 0 with "Switched 1 package to hosted patches; rewrote 1 file". It pins the member's stray lock, which vlt ignores, so vlt ci from the root installs pristine bytes. vex correctly refuses here (not_applied).
• vendored: exits 0 with "Vendored 1 package". It rewrites the member's package.json to file:./.socket/vendor/..., which makes the root's vlt ci fail ("Lockfile is out of sync with package.json"). The installed copy stays pristine, but vex exits 0 and attests not_affected.

With the plain glob packages/* in the same shape, both modes refuse (redirect_workspace_lockfile_elsewhere / vendor_lockfile_missing) and write nothing, which is the #1161 behaviour.

Impact

It's a false VEX attestation for a patch that isn't installed, and the vendored write breaks the workspace's next frozen install. The scan reports success in both modes, so a CI step run from the member directory passes.

Repro (vlt 1.3.8, main fc5458e)

Use the mock registry and patch API attached to #1494 (PORT=18555 node mock.mjs & and PORT=18556 node mock.mjs &).

export SOCKET_API_URL=http://127.0.0.1:18556 SOCKET_PATCH_SERVER_URL=http://127.0.0.1:18556 \
       SOCKET_NPM_REGISTRY=http://127.0.0.1:18555 SOCKET_ORG_SLUG=test-org SOCKET_API_TOKEN=fake
REG='{"registries":{"npm":"http://127.0.0.1:18555/"}}'
mkdir -p ws/packages/a ws/packages/b && cd ws
echo '{"name":"root","version":"1.0.0","private":true}' > package.json
echo '{"name":"a","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > packages/a/package.json
echo '{"name":"b","version":"1.0.0","dependencies":{"right-pad":"1.3.0"}}' > packages/b/package.json
# leave a stray lock in the member (e.g. from a standalone install before the workspace existed)
(cd packages/a && echo "{\"config\":$REG}" > vlt.json && vlt install --allow-scripts :scripts && rm -rf vlt.json node_modules)
echo "{\"workspaces\":[\"packages/+(a|b)\"],\"config\":$REG}" > vlt.json
vlt install --allow-scripts :scripts
jq -r '.edges|keys[]' vlt-lock.json          # includes "workspace~packages+a left-pad": vlt treats a as a member
cd packages/a
socket-patch scan --mode vendored --yes      # exit 0, "Vendored 1 package."
cd ../.. && vlt ci --allow-scripts :scripts  # exit 1: Lockfile is out of sync with package.json
(cd packages/a && node -e "console.log(require('left-pad'))")   # pristine
cd packages/a && socket-patch vex --output vex.json && jq '.statements[].status' vex.json   # "not_affected", exit 0

For hosted, use --mode hosted instead: it exits 0, rewrites packages/a/vlt-lock.json, the root vlt ci installs pristine, and vex exits 1 (not_applied).

Expected vs actual

• Expected: vlt reads the member from the root lock, so the run refuses as Hosted and vendored scans from a vlt workspace member with a stray vlt-lock.json write to that lock, which vlt ignores, and exit 0 (vendored VEX then attests not_affected while vlt ci fails) #1134 / Fix Bun and vlt stray member locks skipping refusal (#1101, #1134) #1161 specify ("vlt installs it from …/vlt-lock.json and ignores its own ./vlt-lock.json"; vendor_lockfile_missing for vendored). It should refuse whatever glob syntax the root uses to list the member. docs/ecosystems.md and the CLI contract's VEX rows say VEX attests only patches that are actually applied.
• Actual: with an extglob pattern, both modes exit 0 and write a lock or package.json that never takes effect, and vendored VEX attests not_affected.

OS × version (Linux, main fc5458e; every cell run 2×)

I didn't bisect it: it's a gap in the #1161 matcher, not a regression. macOS and Windows weren't probed because this routine's probe branches are blocked, but the matcher is OS-independent.

Suspect code

• crates/socket-patch-core/src/utils/workspace_globs.rs:89: WorkspacesDialect::VLT sets extglob: false. vlt 1.2.0 and 1.3.8 list packages/+(a|b) and packages/@(a|b) (verified with vlt install: both members get edges and node_modules).
• crates/socket-patch-core/src/hosted/governing_root.rs:732 (vlt_workspace_root, used by the hosted refusal) and member_stray_lock (used by vendor/npm_flavor.rs:412 member_stray_lock_refusal) both go through that dialect.
• Related, but fail-closed: vlt applies a ! pattern regardless of order (["!packages/a","packages/*"] excludes a), while the VLT dialect is last-match-wins, so socket-patch counts a as a member there. That only adds a refusal from a directory vlt would install from the root anyway, so it isn't harmful today. It's worth fixing alongside, so the dialect matches what vlt actually lists.

Same class as #1097 (yarn classic extglob) and #1071 (npm braces / classes).