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

Summary

uv lets a project put its environment somewhere other than ./.venv with UV_PROJECT_ENVIRONMENT (an absolute path, or a path relative to the project root). uv's own Docker and CI guides use it (UV_PROJECT_ENVIRONMENT=/opt/venv, .venv-ci, and so on), and uv sync / uv run then install into and run from that directory. socket-patch never reads the variable. find_local_venv_site_packages only probes VIRTUAL_ENV, Pipenv, Poetry, ./.venv and ./venv. So it finds no venv, and get_site_packages_paths falls through to get_global_python_site_packages() (the fallback #504 describes).

In agent mode, a plain socket-patch scan --mode agent (no -g) in such a project:

• leaves the real uv env unpatched (uv run imports the vulnerable bytes);
• patches six in the PATH interpreter's site-packages, plus every other global copy with a patch. In my run that included backports.tarfile inside an unrelated uv tool environment (~/.local/share/uv/tools/poetry), which the project doesn't depend on;
• exits 0 with status: success, and socket-patch vex then attests pkg:pypi/[email protected] as not_affected for the project's product.

In hosted mode, the redirect_pypi_stale_install guard checks the wrong interpreter. A project whose real env still holds the upstream six gets no stale-install warning, while the same project with a plain .venv gets it. VEX was only saved from a false attestation because the system Python happened to have an unpatched six.

Impact

• The environment the app actually runs in stays vulnerable, while the exit code and the VEX document both say it's fixed. That's a false attestation.
• A project-scoped command modifies files outside the project, including other tools' uv tool envs and, as root in Docker, the OS Python.

Repro (Linux, uv 0.8.17; the variable is honored the same way by uv 0.5.31; main 61cfb9b)

# stand-in "global" interpreter on PATH with six 1.16.0
uv venv G && uv pip install --python G/bin/python six==1.16.0
mkdir app && cd app
cat > pyproject.toml <<'EOF'
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["six==1.16.0", "idna==3.7"]
EOF
uv lock
export UV_PROJECT_ENVIRONMENT=.venv-ci      # or an absolute path such as /opt/venv
uv sync                                      # env lands in ./.venv-ci; there is no ./.venv
PATH=../G/bin:$PATH socket-patch scan --mode agent --yes $API   # exit 0, status success, scannedPackages 118
.venv-ci/bin/python -c "import six; print(getattr(six,'SOCKET_PATCHED',0))"   # 0  <- real env unpatched
../G/bin/python   -c "import six; print(getattr(six,'SOCKET_PATCHED',0))"     # 1  <- PATH interpreter patched
uv run --frozen python -c "import six; print(getattr(six,'SOCKET_PATCHED',0))" # 0
PATH=../G/bin:$PATH socket-patch vex $API -O vex.json             # exit 0: six not_affected for pkg:pypi/[email protected]

The patch API was a local mock serving a free six 1.16.0 patch (the patched six.py appends SOCKET_PATCHED = 1). The absolute-path form (UV_PROJECT_ENVIRONMENT=$TMP/envs/app) gave the same result: real env 0, PATH Python 1, vex not_affected. Each form ran on a fresh project, so it reproduced twice.

Expected vs actual

• Expected: CLI_CONTRACT.md, "cwd-only (single project)": the crawler inspects only the project rooted at --cwd. For a uv project, that's the environment uv uses for it, which uv sync / uv run take from UV_PROJECT_ENVIRONMENT when it's set (relative paths resolve against the project root). Global installs are the -g / --global-prefix surface only. VEX must not attest a patch that isn't applied in the project's env.
• Actual: the uv project env is ignored, global and uv-tool copies are patched, and VEX attests.

Cells (Linux)

Untested: macOS and Windows (the probe order is the same code path), and a stray ./.venv next to a UV_PROJECT_ENVIRONMENT env. I'd expect the wrong one to be patched there too.

Related

• Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 (Pipenv), Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476 (Poetry) and Agent and hosted mode ignore the interpreter PDM records in .pdm-python (venv.in_project = false, pdm use <venv>), so the real env is skipped or a stray .venv / the PATH python is patched, and VEX attests an unpatched install #502 (PDM) are the same class: a project env the tool uses but socket-patch doesn't probe, plus the non--g global fallback. This issue is the uv-specific missing probe. Fixing Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504's fallback alone would turn the uv case into "nothing patched, exit 0", and the real env would still be missed.

Suspect code

• crates/socket-patch-core/src/crawlers/python_crawler.rs:381-385: the generic probe only tries <cwd>/.venv and <cwd>/venv. There's no UV_PROJECT_ENVIRONMENT arm, which needs to be resolved relative to the uv project root.
• crates/socket-patch-core/src/crawlers/python_crawler.rs:1719-1724: the is_python_project → global fallback (see Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504).