Agent mode honours the Pipfile's `[pipenv] venv_in_project = true` for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected

[mikolalysenko]

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

Summary

pipenv_venv_in_project (crates/socket-patch-core/src/crawlers/python_crawler.rs:668) reads the Pipfile's [pipenv] venv_in_project key for every Pipenv project. If the key is true and ./.venv doesn't exist, pipenv_project_site_packages returns no venv at all (python_crawler.rs:711, "An explicit 'in project' with no ./.venv means Pipenv has no venv yet").

That holds only for Pipenv 2026.2.0+, the first release that reads the key (Project._pipfile_venv_in_project). Pipenv 2018.11.26 through 2026.1.0 ignore it and put the venv at $WORKON_HOME/<name>-<hash> as usual. So when a team commits venv_in_project = true and a developer, CI image or distro still runs Pipenv ≤ 2026.1, the real venv is never found:

• agent scan falls through to the global-interpreter fallback and patches the system Python's site-packages in place (the 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 path). The project's venv stays unpatched, and the exit code is 0 with "1 of 1 targeted patch applied".
• vex then attests not_affected for the project, even though pipenv run imports the unpatched bytes.

This is the mirror image of the venv_in_project = false case, which PR #654 already treats as "only 2026.2+ reads it". The = true case with no ./.venv is unchanged in #654 (its test only covers = true with a ./.venv present, which is correct for every version). I re-ran the repro on the #654 head d8356ae and it still fails.

Impact

A silent miss with a false attestation, plus an unrequested write into the system interpreter. A team that adopts the documented Pipenv 2026.2 setting gets wrong results on every older Pipenv in its fleet.

Repro (Linux, real Pipenv)

export WORKON_HOME=/tmp/wh PIPENV_YES=1
mkdir proj && cd proj
printf '[[source]]\nurl = "https://pypi.org/simple"\nverify_ssl = true\nname = "pypi"\n\n[packages]\nsix = "==1.16.0"\n\n[pipenv]\nvenv_in_project = true\n' > Pipfile
pipenv install            # Pipenv 2025.1.3: venv at $WORKON_HOME/proj-<hash>, no ./.venv
pipenv --venv             # -> /tmp/wh/proj-qzUn2fQZ
socket-patch scan --mode agent --yes        # patch API serving a six 1.16.0 patch
pipenv run python -c "import six; print(getattr(six, 'SOCKET_PATCHED', 'UNPATCHED'))"   # UNPATCHED
sha256sum /usr/lib/python3/dist-packages/six.py                                         # changed: the system copy was patched
socket-patch vex --product pkg:pypi/demo@1.0.0 --output vex.json                        # statement: not_affected

Patch data came from a local mock patch API (batch / by-package / view / blob) serving a six 1.16.0 patch that appends SOCKET_PATCHED = True. socket-patch rollback --yes restored the system six.py byte-identically.

Expected vs actual

• Expected (docs/testing/pipenv-compatibility.md, Agent column): "patches the installed distribution in the venv Pipenv resolves for the project — … in-project .venv subject to PIPENV_VENV_IN_PROJECT and the Pipfile's [pipenv] venv_in_project, or Pipenv's default $WORKON_HOME/<dir>-<hash>[-<python>]". The installed Pipenv version can't be known without running it, so the safe reading is the one Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 / PR Fix Pipenv venv discovery settings view (#645, #546) #654 use elsewhere: with venv_in_project = true and no ./.venv, also look up the WORKON_HOME venv. A pre-2026.2 Pipenv uses it; 2026.2+ has no venv yet, so there's nothing extra to patch. Only an explicit env var (PIPENV_VENV_IN_PROJECT=1, honoured by every release) justifies "no venv yet".
• Actual: no project venv is found, the system Python is patched, the exit code is 0, and VEX attests not_affected.

Matrix (Linux, main 045d7ec, 2/2 runs each)

Pipenv	venv Pipenv uses	pipenv run six after scan	system six	vex	result
2018.11.26 (py3.8)	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail
2023.12.1	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail
2023.12.1, venv_in_project = "yes"	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail
2025.1.3	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail
2026.1.0	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail
2026.8.0	./.venv	patched	untouched	not_affected	pass
2025.1.3, no [pipenv] key (control)	$WORKON_HOME/proj-…	patched	untouched	not_affected	pass
PR #654 head d8356ae, 2023.12.1 / 2025.1.3	$WORKON_HOME/proj-…	UNPATCHED	patched	not_affected	fail

macOS and Windows weren't probed (probe branches are blocked, see the ledger). The code path doesn't depend on the OS.

First bad commit

The Pipfile key was first read in ccd43f5 (#388, "Fix Pipenv venv discovery order"), according to git log -S venv_in_project. I didn't build its parent for this shape.

Suspect code

• crates/socket-patch-core/src/crawlers/python_crawler.rs:668 (pipenv_venv_in_project): the Pipfile key is treated as authoritative, like the env var.
• crates/socket-patch-core/src/crawlers/python_crawler.rs:711: in_project == Some(true) && !dot_venv.exists() returns no venv.
• The hosted stale-install warning (crates/socket-patch-cli/src/commands/scan/hosted/python.rs:53) goes through the same find_local_venv_site_packages, so I'd expect it to miss a warm WORKON_HOME venv in this shape too. I haven't verified that in this run.

Related: #645 (the env-var form, "not in project"), #504 (the global fallback that turns this miss into a system-Python write) and PR #654.

[mikolalysenko]

[agent] Triaged as priority:p1 (Pipenv). This shares its root cause with open PR #654 (#645, #546). Pipenv venv discovery treats an explicit in-project setting from the Pipfile as true for every Pipenv version, but only Pipenv 2026.2+ reads the [pipenv] venv_in_project key. #654 already handles the = false half of this. The = true with no ./.venv branch at python_crawler.rs:711 is the remaining half: when the key comes from the Pipfile rather than PIPENV_VENV_IN_PROJECT, it should also look up the $WORKON_HOME venv. The fix belongs in #654 or a follow-up stacked on it, so this issue is left unclaimed until #654 is settled.

---

Generated by Claude Code

[mikolalysenko]

[agent] Hosted-mode shape of this bug, on main 0d302dc (Linux, real Pipenv, mock patch API, 2/2 runs each). Hosted mode has the same root cause: the Pipfile [pipenv] venv_in_project = true key hides the warm WORKON_HOME venv, so the hosted scan never prints its stale-install warning.

Repro: the Pipfile pins six = "==1.16.0" and has [pipenv]\nvenv_in_project = true. Run pipenv install, which creates $WORKON_HOME/proj-<hash> on these versions, then socket-patch scan --mode hosted --yes.

Pipenv	Venv Pipenv uses	Lock redirected	pypi_pipenv_stale_install warning	Installed six
2018.11.26	WORKON_HOME	yes	missing (exit 0)	upstream
2023.12.1	WORKON_HOME	yes	missing (exit 0)	upstream
2026.1.0	WORKON_HOME	yes	missing (exit 0)	upstream
2026.8.0	./.venv	yes	printed	upstream (expected, the remedy applies)
2023.12.1, no [pipenv] key (control)	WORKON_HOME	yes	printed	upstream

Impact: the user gets a clean exit 0 with no remedy. Their venv keeps running the unpatched release, and every later pipenv install / sync / install --deploy leaves it that way (documented warm-venv behaviour). A fresh checkout is protected.

Hosted VEX stays conservative: it fails closed and doesn't attest. With no six in the system Python it omits the package as file_not_found (2023.12.1 / 2026.1.0); with the distro's unpatched six present it omits it as not_applied. So nothing is falsely attested in hosted mode, but the file_not_found reason points the user away from the real cause.

The fix sketched in the triage comment, which also probes $WORKON_HOME when the key comes from the Pipfile, should cover this shape too. It's worth a hosted stale-warning test next to the agent one.

---

Generated by Claude Code