Merge origin/main to resolve CHANGELOG conflict

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKwBoKTsqpGR3ZcCAcEyCA

Author: claude

.github/workflows/ci.yml

@@ -261,24 +261,47 @@ jobs:
           cache: false
 
       - name: Install vexctl
-        # `go install` puts the binary in $(go env GOPATH)/bin; surface
-        # that path to subsequent steps so `Command::new("vexctl")` in
-        # the test resolves. Pinned to a tagged release rather than
-        # @latest for reproducibility.
+        # Linux / Windows: the v0.3.0 release binary, checked against the
+        # sha256 pinned here (from the release's vexctl_checksums.txt).
+        # Compiling it took ~80s on ubuntu and ~180s on windows, the
+        # slowest job in this workflow.
         #
-        # Retried: the install compiles sigstore/cosign, whose module
-        # verification reads dozens of sum.golang.org checksum tiles, and
-        # transient INTERNAL_ERROR stream resets there have failed this
-        # step on otherwise-green runs. The backoff rides out short
-        # resets; a persistent outage still fails loudly on the last
-        # attempt. Follow-up option if this recurs: install the pinned
-        # release BINARY (sha256-pinned) instead of compiling, which
-        # sidesteps module verification and drops ~100s of compile time per
-        # leg.
+        # macOS still compiles: the release's darwin binaries are built
+        # with go1.22.7 and have no LC_UUID, so the runner's dyld refuses
+        # them (see the Go step above). The compile is retried: it builds
+        # sigstore/cosign, whose module verification reads dozens of
+        # sum.golang.org checksum tiles, and transient INTERNAL_ERROR
+        # stream resets there have failed this step on otherwise-green
+        # runs. The backoff rides out short resets; a persistent outage
+        # still fails loudly on the last attempt.
+        #
+        # Either way the binary's directory goes on PATH so
+        # `Command::new("vexctl")` in the tests resolves.
         shell: bash
+        env:
+          VEXCTL_VERSION: v0.3.0
+          VEXCTL_SHA256_LINUX_AMD64: cd7f8b57d20642166ed4eb3dd1fd849bbb30bbd7c5b9f5b0316b6003b57ceaba
+          VEXCTL_SHA256_WINDOWS_AMD64: 346fb3104b656fe1a407cbae88ea29a636b36f4569ec58a5a8dadca7343993ed
         run: |
+          set -euo pipefail
+          case "$RUNNER_OS" in
+            Linux) asset=vexctl-linux-amd64 bin=vexctl sha="$VEXCTL_SHA256_LINUX_AMD64" ;;
+            Windows) asset=vexctl-windows-amd64.exe bin=vexctl.exe sha="$VEXCTL_SHA256_WINDOWS_AMD64" ;;
+            *) asset='' ;;
+          esac
+          if [ -n "$asset" ]; then
+            dir="$RUNNER_TEMP/vexctl-bin"
+            mkdir -p "$dir"
+            curl -fsSL --retry 5 --retry-all-errors -o "$dir/$bin" \
+              "https://github.com/openvex/vexctl/releases/download/$VEXCTL_VERSION/$asset"
+            echo "$sha  $dir/$bin" | sha256sum -c -
+            chmod +x "$dir/$bin"
+            "$dir/$bin" version
+            echo "$dir" >> "$GITHUB_PATH"
+            exit 0
+          fi
           for attempt in 1 2 3 4 5; do
-            if go install github.com/openvex/vexctl@v0.3.0; then
+            if go install "github.com/openvex/vexctl@$VEXCTL_VERSION"; then
               break
             fi
             if [ "$attempt" = 5 ]; then

CHANGELOG.md

@@ -108,6 +108,11 @@ limits, and required install commands.
   scanned project, so a Yarn Berry project's `global` script can't run or pick
   the directory treated as the global install. Composer's global home also
   falls back to `%APPDATA%\Composer` and `$XDG_CONFIG_HOME/composer`.
+- Agent-mode PyPI `apply` patches every installed copy of a release, not just
+  the first one found. A Pipenv project with both a WORKON_HOME venv and a
+  `./.venv`, or a global install with the same release in the user site and a
+  system dir, no longer keeps the copy Python imports unpatched while `vex`
+  attests it (#529, #501).
 - Gem hosted and vendored modes wire only the manifest Bundler loads. A `gems.rb`
   twin or a `BUNDLE_GEMFILE` setting (environment or `.bundle/config`) no longer
   leads to an edit of an ignored `Gemfile` that reports success and attests an
@@ -175,6 +180,11 @@ limits, and required install commands.
 - Transient apply locks are removed on normal command exit; no-op scans and full
   reversal avoid leaving unused `.socket/` state. Terminal output, telemetry
   timeouts, and update-check handling are more consistent.
+- Agent mode finds transitive npm packages in npm's linked store
+  (`install-strategy=linked`, `node_modules/.store`) and in a relocated pnpm
+  `virtualStoreDir`, instead of reporting them `package_not_installed` (#359,
+  #362). A store outside the project, such as pnpm's global virtual store, is
+  shared with other projects and is still not patched in place.
 - npm locks keep their own layout when edited. `scan --mode hosted`,
   `scan --mode vendored`, `rollback` and `vendor --revert`
   re-serialized `package-lock.json` / `npm-shrinkwrap.json` with LF line
@@ -184,6 +194,13 @@ limits, and required install commands.
   unparseable (hosted) or refused as `vendor_lockfile_version_unsupported`
   (vendored). The lock now keeps its BOM, indent and line endings, and the
   undo is byte-exact (#324).
+- `vendor` under `--global` / `--global-prefix` (or `SOCKET_GLOBAL` /
+  `SOCKET_GLOBAL_PREFIX`) is now a usage error (exit 2,
+  `global_scope_unsupported`), like `scan` and `get` with `--mode vendored`.
+  Run inside a project, `vendor -g` vendored the manifest's records into that
+  project and rewired its lockfile, and `vendor --revert -g` unwound the
+  project's vendoring, so its next frozen install was silently unpatched.
+  Global installs have no project lockfile to vendor into (#498).
 
 ### Maintenance