Description

Mikola Lysenko (mikolalysenko)

opened on Oct 5, 2026

Issue body actions

[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/[email protected] --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.

Activity

1. Mikola Lysenko (mikolalysenko)

   added

   bugSomething isn't workingSomething isn't working

   bughuntFound by a scheduled package-manager bug-hunt agentFound by a scheduled package-manager bug-hunt agent

   pm:pipenvPipenvPipenv

   on Oct 5, 2026
2. Mikola Lysenko (mikolalysenko)

   added a commit that references this issue on Oct 5, 2026

   pipenv: run ledger 2026-10-05 09:32Z (#842)

   e4f9b93
3. Mikola Lysenko (mikolalysenko)

   added

   agent:triaged

   priority:p1

   on Oct 5, 2026
4. mikolalysenko commented on Oct 5, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 5, 2026

   CollaboratorAuthor

   More actions

   [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
5. mikolalysenko commented on Oct 5, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 5, 2026

   CollaboratorAuthor

   More actions

   [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
6. Mikola Lysenko (mikolalysenko)

   added a commit that references this issue on Oct 5, 2026

   pipenv: 2026-10-05 19:15Z ledger (#790 verified, #842 hosted shape)

   310da16
7. mikolalysenko commented on Oct 9, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 9, 2026

   CollaboratorAuthor

   More actions

   [agent] Still reproduces on main f3c6313, but the agent-mode symptom has changed (Linux, Pipenv 2023.12.1, real pipenv sync, mock patch API, 2/2).

   Since #950 / #504, agent mode no longer falls back to the system Python. With the Pipfile's [pipenv] venv_in_project = true key, the WORKON_HOME venv Pipenv 2023 actually uses ($WORKON_HOME/a1-<hash>-python3.11, six 1.16.0 installed) is still missed, so now:

   $ socket-patch scan --mode agent
     [skip] pkg:pypi/[email protected] (not installed; run your package manager's install first, or `socket-patch scan --mode vendored` to vendor it from the lockfile)
   No patches selected.                              # exit 0, no .socket/manifest.json written
   $ pipenv run python -c 'import six; print(open(six.__file__).readline())'
   # Copyright (c) 2010-2020 Benjamin Peterson      # upstream bytes
   

   Deleting the [pipenv] key (control) on the same venv gives # PATCHED by socket. So the system-Python write and the false not_affected in the title no longer happen. The user gets exit 0 and a "not installed" remedy for a package that is installed, and since no manifest is recorded, apply --check says "nothing to apply" (exit 0) and vex has nothing to attest. Nothing is falsely attested now; the venv just stays silently unpatched. The root cause in the triage comment (python_crawler.rs honouring the Pipfile key on Pipenv < 2026.2) is unchanged.

   ---

   Generated by Claude Code
8. Mikola Lysenko (mikolalysenko)

   added

   priority:p2

   and removed

   priority:p1

   on Oct 9, 2026
9. mikolalysenko commented on Oct 9, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 9, 2026

   CollaboratorAuthor

   More actions

   v5 triage: P2, not a release blocker. Retain old-Pipenv interpretation of a newer configuration key at P2. Recent comments confirm the system-Python mutation has already been fixed.

   This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.
10. mikolalysenko commented on Oct 26, 2026

    

    Mikola Lysenko (mikolalysenko)

    on Oct 26, 2026

    CollaboratorAuthor

    More actions

    [agent] Claiming this issue (shared root cause: Pipenv venv discovery treats the Pipfile's [pipenv] venv_in_project = true as authoritative when no ./.venv exists, though Pipenv < 2026.2 ignores the key and uses WORKON_HOME). Branch: agent/fix-pipenv-pipfile-in-project-workon. Claim-ID: 2026-10-26T12:34:53Z-2f499c

    ---

    Generated by Claude Code
11. Mikola Lysenko (mikolalysenko)

    added

    agent:claimed

    on Oct 26, 2026
12. mikolalysenko commented on Oct 26, 2026

    

    Mikola Lysenko (mikolalysenko)

    on Oct 26, 2026

    CollaboratorAuthor

    More actions

    [agent] Draft PR: #1729

    ---

    Generated by Claude Code
13. Mikola Lysenko (mikolalysenko)

    added 2 commits that reference this issue on Oct 26, 2026

    Find old Pipenv venv with Pipfile in-project key

    This issue will close once commit 5aab282 is merged into the 'main' branch.

    5aab282

    Keep old Pipenv's WORKON venv for NO_ variable

    This issue will close once commit 4136270 is merged into the 'main' branch.

    4136270
14. Mikola Lysenko (mikolalysenko)

    closed this as completedin #1729on Oct 26, 2026
15. Mikola Lysenko (mikolalysenko)

    removed

    agent:claimed

    on Oct 27, 2026

Issue actions