Bug hunt ledger: Pipenv

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Pipenv bug-hunt routine (label pm:pipenv).

The routine runs every 6 hours. Each run adds one comment here with the socket-patch commit it tested, the OS × Pipenv-version × mode cells it covered, the issues it filed, updated or closed, and what it plans to probe next. The routine treats this thread as its only memory.

Last run: 2026-10-02 09:41Z, main 61cfb9b (unchanged; CLI 4.0.0). Filed #546: Pipenv settings in the project's .env (PIPENV_CUSTOM_VENV_NAME, WORKON_HOME) are ignored by venv discovery, so agent mode patches the system Python and VEX attests not_affected (Pipenv 2022–2026; not a regression).

Coverage matrix

Cells marked v5 were re-run on 2463257 (v5: no hosted ledger, upstream-restore rollback, service-artifact vendoring).

OS	Pipenv	agent (OOT venv)	agent (stray venv/ or .venv+IN_PROJECT=0)	hosted (all categories, sync, --deploy, rollback)	hosted + OOT venv stale warning / VEX	hosted live-lock conflict + requirements.txt	vendored (lock-only, repair, revert)	hosted → vendored	vendored → hosted	VIRTUAL_ENV w/ IGNORE_VIRTUALENVS / PIPENV_ACTIVE
Linux	2018.11.26	pass 61cfb9b (unicode/space/paren names, nested PIPENV_PYTHON chain)	.venv + WORKON venv, nothing explicit: fail #529	pass v5 (+CRLF)	untested	fail #333	pass v5	untested	untested	fail #384
Linux	2022.12.19	untested	.venv + WORKON venv, nothing explicit: fail #529	pass v5 (+relock); [docs]-only + rollback pass 61cfb9b	untested	fail #333	untested	untested	untested	untested
Linux	2023.12.1	pass	.venv + WORKON venv, nothing explicit: fail #529	pass v5 (+relock); verify / requirements / deploy pass 61cfb9b	pass; fail #334/#384 shapes (false VEX)	fail #333	untested	untested	untested	fail #384 (agent + hosted VEX)
Linux	2026.8.0	pass 61cfb9b	pass 61cfb9b (#334 fixed); no-Pipenv-venv shapes patch the system Python, fail #504	pass v5 (+CRLF); verify / requirements / deploy pass 61cfb9b	pass; #334/#384 shapes untested since the fix	pass 61cfb9b (#333 fixed)	pass v5	pass v5	fail #328 v5	pass 61cfb9b (#384 fixed)
Linux	2024.4.1	pass 61cfb9b	untested	pass 61cfb9b (default + [docs], verify / requirements / sync / --deploy / vex / byte-exact rollback)	untested	untested	pass 61cfb9b (both categories, sync / --deploy / vex / repair / rollback)	untested	untested	untested
Linux	2025.1.3	untested	untested	pass 61cfb9b (same as 2024.4.1)	untested	untested	pass 61cfb9b (same as 2024.4.1)	untested	untested	untested
macOS	2023.12.1	pass	fail #334	untested	untested	fail #333	untested	untested	untested	fail #384
macOS	2026.8.0	pass	fail #334	untested	untested	fail #333	untested	untested	untested	fail #384
Windows	2023.12.1	pass	fail #334	untested	untested	fail #333	untested	untested	untested	fail #384
Windows	2026.8.0	pass	fail #334	untested	untested	fail #333	untested	untested	untested	fail #384
Linux	2022.12.19 -g (install --system --deploy, py3.10)	-g --global-prefix <site-packages> --apply / rollback -g pass, lock untouched; hosted refused exit 2 pass (61cfb9b)
Linux	2018.11.26 -g (install --system)	scan -g report pass; -g --mode hosted refused exit 2 pass; -g --apply / vex / rollback pass
Linux	2023.12.1 -g (install --system)	scan -g report (in/out of project), hosted refused exit 2, -g --apply / vex / rollback, SOCKET_GLOBAL, --global-prefix pass; rollback -g / remove -g / get -g --mode hosted|vendored unwind or rewire the cwd project's Pipfile.lock (#445 / #436)
Linux	2026.8.0 -g (install --system)	scan -g report (in/out of project), SOCKET_GLOBAL, --global-prefix pass; hosted refused exit 2 pass; -g --apply / get -g / vex / rollback pass	no--g agent scan in a venv-less project patches the global interpreter (needs a maintainer decision, see Known non-bugs)
Linux	9.1.0 / 11.10.4 (py3.8)	pass on 11 61cfb9b (unicode/space/paren names, PIPENV_PYTHON suffix)	untested	pass v5 (path ref, --deploy, rollback; 11 byte-exact)	pass on 11 (stale warning, VEX not_applied)	untested	refused (documented)	n/a	n/a	untested
macOS / Windows	7–11	untested	untested	untested	untested	untested	refused (documented)	n/a	n/a	untested
any	0–6	untested	n/a	refused (documented)	n/a	n/a	refused (documented)	n/a	n/a	untested

.env-borne Pipenv settings (agent + hosted stale warning): PIPENV_CUSTOM_VENV_NAME in .env fails #546 on 2022.12.19 / 2023.12.1 / 2024.4.1 / 2025.1.3 / 2026.8.0 (the exported control passes); WORKON_HOME in .env fails #546 on 2023 / 2026. --global-prefix with spaces and unicode (site-packages path, 2026.8.0): pass.

Agent rerun after a reinstall (2026.8.0, 61cfb9b): --json pass; human-mode scan --apply / --mode agent / --sync fail, #454 incomplete (commented). PIPENV_PIPFILE spellings with --cwd: pass.

Policy (socket.yml) cells, Linux 2026.8.0 hosted monorepo: every filter passes; get <uuid> skips the policy_bypassed warning (fail #453, re-checked on 6e7ef74). socket.yml × --package / --min-severity / --max-new-patches intersections: pass (6e7ef74). Concurrent hosted scans: pass. SIGKILL mid hosted / vendored run: pass. Mirror / env-var source rollback refusal: pass (documented).

Named category on 2026.8.0 (61cfb9b): pipenv requirements --categories docs / --dev, verify, sync --categories docs and install --deploy --categories "packages docs" all give the patched wheel (pass). Named category ([docs]) hosted + sync --categories / install --deploy --categories / vex / rollback: pass on 2022.12.19, 2023.12.1 and 2026.8.0; vendored: pass on 2022.12.19 and 2023.12.1 (6e7ef74). Non-registry entries (path, file URL, git): hosted refuses with redirect_pipenv_refused, vendored with pypi_pipenv_source_already_exists, vex attests nothing: pass on 2026.8.0.

-g / agent on an unwritable prefix or a root-owned .venv, as a non-root user (2026.8.0): human mode fails loudly (pass); the --json envelope drops the failure (#424); a rerun exits 0 unpatched (#454).

macOS/Windows rows are from the 2026-09-30 probes on f6b7fb9. No probe ran on v5 because branch deletion through the git proxy still fails (re-checked 2026-10-01 09:30Z); bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Backlog

1. Re-verify 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 PyPI agent apply patching only one installed copy (#529, #501) #538) once it merges (.venv + WORKON_HOME, nothing explicit) on 2018 / 2022 / 2023 / 2024 / 2025 / 2026, plus the PIPENV_PYTHON-suffix twin-venv shape.
2. Re-verify Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546 once it's fixed: .env with PIPENV_CUSTOM_VENV_NAME, WORKON_HOME, PIPENV_VENV_IN_PROJECT=0 + .venv, PIPENV_IGNORE_VIRTUALENVS + VIRTUAL_ENV, and an exported PIPENV_DONT_LOAD_ENV=1 (which must disable it).
3. Re-verify 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 (a no-Pipenv-venv agent scan patches the system Python) and the scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 human-mode gap once they're fixed.
4. Maintainer request (global -g mode): still to do: macOS / Windows (blocked: no probe), -g on 2018 / 11, and --global-prefix given as a venv / interpreter root (scans 0 today; the semantics are undocumented). Full checklist in the 20261001T040000Z entry.
5. A macOS/Windows probe re-verifying Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 / Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 / Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 / 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 / Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546, and hosted / vendored on 2018 / 2022 there (CRLF on Windows). Blocked until branch deletion through the git proxy works.

Known non-bugs

• Pipfile.lock with pipfile-spec < 6 (Pipenv 0–6): hosted is refused (redirect_pipenv_skipped) and vendored is refused (pypi_pipenv_spec_unsupported). Documented.
• Vendored on Pipenv 7–11 is refused (pypi_pipenv_installer_unsupported). Documented.
• A warm venv is never reinstalled by pipenv install / sync / --deploy; the stale-install warning is the designed remedy. Documented.
• pipenv lock / update drops the redirected reference (silent unpatch until re-scan). Documented.
• Pipenv 2023+ don't hash-check local wheels, so vendored carries vendor_integrity_unverified. Documented.
• The CLI doesn't walk up to a parent Pipfile or follow PIPENV_PIPFILE. Documented.
• rollback drops manifest entries, so a later apply is a no-op. Documented.
• Pipenv 2026.8.0 crashes on $VAR inside WORKON_HOME. That's Pipenv's bug.
• vendor_fetch_failed against pypi.org in the sandbox is rustls vs the proxy CA; use a SOCKET_PYPI_JSON_API forwarder.
• VIRTUAL_ENV set with no PIPENV_IGNORE_VIRTUALENVS / PIPENV_ACTIVE: Pipenv uses the activated venv too, so socket-patch patching it is correct.
• .venv file pointer: a relative path is joined to the project directory and an empty file means the default placement. Matches Pipenv 2026.8.0.
• v5 rollback on a project with no manifest, ledger or hosted pin exits 1 "Manifest not found". Documented (CLI_CONTRACT, truly-empty project).
• v5 hosted rollback refuses when the entry's index isn't PyPI, or when offline. Documented (the upstream-restore refusals).
• Vendored drops the Pipfile.lock entry's index key. Harmless for a local wheel, and rollback restores it.
• rollback <path> targets select installed copies, not hosted project directories; use --cwd. Documented, and cross-PM anyway.
• Mock-API note: a hosted artifact URL must have the /patch/pypi/<name>/<ver>/<token>/<uuid>/<wheel> shape, and SOCKET_PATCH_SERVER_URL must name the mock origin, or vex / rollback see no hosted reference.
• scan -g --mode hosted --json prints a plain-text usage error with exit 2 (a clap-level refusal, documented).
• Mock-API notes: vendoring needs integrity.sha512 on the tarball artifact; the view needs files; agent mode needs /patches/blob/<afterHash>.
• Filed as 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 (2026-10-01), formerly an open question: with no venv found and a Python project marker present, the crawler deliberately falls back to the global interpreter (python_crawler.rs get_site_packages_paths). So an agent-mode scan without -g, in a Pipenv project whose venv isn't created yet (or is install --system), patches the global site-packages in place. That's right for Docker --system, but it contradicts the -g checklist ("a scan without -g must never touch it"). Filing waits on a maintainer decision.
• A Pipenv 9.1.0 lock written with "hashes": [] (seen in the sandbox) comes back from hosted rollback with PyPI's full hash list: not byte-exact, but a valid and stricter registry entry. The upstream restore re-derives hashes by design.
• Hosted rollback refuses a _meta.sources URL written as ${PIP_INDEX_URL}, even when the variable points at pypi.org; env vars aren't expanded. Documented and fail-closed, with the git checkout remedy.
• scan -g counts every ecosystem plus the well-known system Python paths (/usr/lib/python3*, /usr/local/lib/python3*, ~/.local). That's by design; Pipenv's WORKON_HOME venvs aren't included.
• --prune warns that it has no effect with --mode hosted. Documented.
• Non-registry Pipfile.lock entries (path, file URL, git) are refused in hosted (warning, exit 0) and vendored (pypi_pipenv_source_already_exists, exit 1). By design; the "no Pipfile beside the lock" wording in the hosted detail is Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333.
• Mock-API note: the batch mock must filter by the requested purls, and by-package must carry vulnerabilities[*].severity, or --package / --min-severity cells give false failures.
• A non-UTF-8 Pipfile makes hosted treat the lock as abandoned, but Pipenv itself refuses that Pipfile (UnicodeDecodeError). Not a real-world shape.
• PIPENV_PIPFILE naming a Pipfile outside --cwd finds no venv: documented CLI scope.
• Pipenv refuses different versions of one package across [packages] and a named category (categories are constrained by the default packages), so per-category version splits can't happen.
• vex gives product_undetected on a bare Pipfile project (no name or version); --product is the documented remedy.
• Pipenv 11.x / 2018.x with virtualenv<20 can't create venvs from uv's standalone CPython (missing libpython): a sandbox tooling artifact, so use virtualenv 20.x. Pipenv 11.x also breaks on ( in a project name (an unsanitized shebang): Pipenv's bug.

[github-actions[bot]]

[agent] 2026-09-30: Pipenv bug-hunt run

This is the first run, so the ledger started empty and there were no pm:pipenv issues to re-triage.

Tested: main f6b7fb9 (CLI 4.0.0), latest release 4.0.0. The previous release, 3.3.0 (from PyPI), was used for first-bad checks: it has no hosted mode and no Pipenv out-of-tree venv discovery.

Setup: patch.socket.dev is blocked by the sandbox proxy (403), so a local mock patch API served a real patched six-1.16.0 wheel (the same recipe as the Poetry routine). A local HTTP forwarder for pypi.org / files.pythonhosted.org, via SOCKET_PYPI_JSON_API, stood in for rustls vs the proxy CA. Every cell ran a real Pipenv release (2018.11.26 and 2022.12.19 on py3.8; 2023.12.1 and 2026.8.0 on py3.12): install / sync / install --deploy / lock, then a byte check through pipenv run python.

Cells

• Agent, default out-of-tree venv (plus PIPENV_CUSTOM_VENV_NAME, a literal WORKON_HOME, and a project path with a space and unicode): pass on Linux 2026.8.0, and on macOS and Windows 2023.12.1 / 2026.8.0 (probe).
• Agent, stray venv/ directory: fail on every OS and version → Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334.
• Agent, .venv + PIPENV_VENV_IN_PROJECT=0: fail on 2023.12.1 and 2026.8.0 on every OS → Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334. Correct on 2018 and 2022, which read "0" as truthy.
• Agent lifecycle, Linux 2026.8.0 (scan, rollback, apply after rollback, remove): pass. Rollback dropping the manifest entry is documented.
• Hosted, Linux 2026.8.0: default + develop + named category tests all rewritten; pipenv sync --categories "packages tests" into a fresh venv gives PATCHED; install --deploy exits 0; the stale-install warning fires with in-project and out-of-tree venvs; rollback is byte-exact. All pass.
• Hosted, live-lock conflict (file dep) + sibling requirements.txt: fail on Linux 2018 / 2022 / 2023 / 2026 and on macOS and Windows 2023 / 2026 → Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333.
• Hosted, stray venv/: stale-install warning suppressed (part of Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334).
• Mode switch, hosted ⇄ vendored, installed and lock-only: fail (same root cause as Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328). Commented there with the Pipenv evidence.
• Vendored, Linux 2026.8.0: vendor from a lock-only checkout (pristine wheel fetched by lock digest), pipenv sync gives PATCHED; repair after deleting the committed wheel, both with the venv and lock-only, rebuilds a byte-identical wheel. Pass. The Poetry lock-only repair bug does not reproduce on Pipenv, because Pipfile.lock keeps every release digest.

Issues

• Filed Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333: Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 (hosted: Pipfile isn't among the redirect candidate files, so the live-lock conflict veto is dead code).
• Filed Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334: Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 (agent: a stray venv/, or a .venv ignored by PIPENV_VENV_IN_PROJECT=0, shadows Pipenv's venv).
• Commented on Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328: Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment) (the Pipenv side of hosted ⇄ vendored).

False positives ruled out

• Pipenv 2026.8.0 crashes ('str' object has no attribute 'expanduser') when WORKON_HOME contains $HOME. That's Pipenv's own bug, not socket-patch's.
• vendor_fetch_failed against pypi.org is a sandbox TLS artifact; use a local forwarder via SOCKET_PYPI_JSON_API.
• rollback removing manifest entries is documented (README rollback).
• vex correctly refuses (no_applicable_patches) in the Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 half-redirect case, so there is no false attestation.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36739663342 (6 jobs: ubuntu / macos / windows × 2023.12.1 / 2026.8.0)

I couldn't delete the probe branch: git push --delete gets cut off by the git proxy. A maintainer needs to delete bughunt/pipenv/20260930-venv-discovery.

Next

1. Pipenv 7–11 (path refs, py3.6 via Docker if a daemon is available) hosted, plus the SOCKET_PIPENV_MAJOR override when pipenv isn't on PATH.
2. Windows hosted and vendored on 2018.11.26 / 2022.12.19 (py3.8), and CRLF locks on Windows.
3. Agent mode with VIRTUAL_ENV pointing at an unrelated activated venv (e.g. the one socket-patch was pip-installed into) while Pipenv uses its own.
4. The .venv file pointer with a relative path containing a separator, and PIPENV_PIPFILE / PIPENV_MAX_DEPTH from a subdirectory (a documented limitation; check the refusal message).
5. pipenv install <other> on 2022 (full relock) after hosted: confirm the rollback and re-scan path, and VEX after a relock.

[github-actions[bot]]

[agent] 2026-09-30: Pipenv bug-hunt run

Tested: main f6b7fb9 (CLI 4.0.0; unchanged since the previous run), latest release 4.0.0. Real Pipenv 2018.11.26 (py3.8), 2023.12.1, 2026.1.0 and 2026.8.0 (py3.12) on Linux; 2023.12.1 / 2026.8.0 on macOS and Windows via a probe. Patch data: a local .socket/manifest.json for six 1.16.0 (apply --offline), and the probe's mock patch API (scan --mode agent). The Docker daemon isn't available in this sandbox, so Pipenv 7–11 (py3.6) stayed blocked.

Re-triage: #333 and #334 are still open. Main hasn't moved since they were filed, so there's no fix to check and I didn't comment. #334 has a new-info comment (below).

Cells

• Agent, VIRTUAL_ENV = unrelated venv + PIPENV_IGNORE_VIRTUALENVS=1: fail on Linux 2018 / 2023 / 2026 and on macOS and Windows 2023 / 2026 → Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384.
• Agent, VIRTUAL_ENV = another project's venv + PIPENV_ACTIVE=1 (pipenv shell, then cd): fail, same cells → Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384.
• Agent, VIRTUAL_ENV set, no opt-out: pass on 2023 / 2026 on every OS (Pipenv uses the activated venv too). Ambiguous on 2018: pipenv --venv names VIRTUAL_ENV, but pipenv run imports from WORKON_HOME.
• Agent, auto-detected .venv dir + an existing WORKON_HOME venv, Pipenv 2026.2.0+: fail on Linux 2026.8.0 (Pipenv now prefers the WORKON_HOME venv). Pass on 2026.1.0. → commented on Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334.
• Agent, Pipfile [pipenv] venv_in_project = false + .venv dir, 2026.2.0+: fail on Linux 2026.8.0 → commented on Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334.
• Agent, no VIRTUAL_ENV (control): pass on every OS and version tested.

Issues

• Filed Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384: Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384
• Commented on Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334: Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 (comment) (the 2026.2.0 .venv precedence changes)

False positives ruled out

• I read the .venv file pointer semantics against Pipenv 2026.8.0 source: relative paths resolve against the project directory, and an empty file means the default placement. socket-patch matches both, so there's no bug.
• The VIRTUAL_ENV-only case isn't a bug: Pipenv honours an activated venv by default.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36779636041 (6 jobs, all reproduce)

I couldn't delete either probe branch: git push --delete is cut off by the git proxy. A maintainer needs to delete bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv.

Next

1. Pipenv 7–11 hosted path refs, and the SOCKET_PIPENV_MAJOR override. This needs py3.6; try uv python install 3.7 with Pipenv 11.10.4 if Docker stays unavailable.
2. Windows and macOS hosted and vendored on 2018.11.26 / 2022.12.19, and CRLF locks on Windows.
3. Relock on 2022 (install <other>) after hosted or vendored, then rollback, re-scan and VEX.
4. Hosted stale-install warning under Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 / Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 conditions (whether it's suppressed or shows the wrong venv) and on a 2026.2+ auto-.venv.
5. Concurrent or interrupted scans on a Pipfile.lock.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Pipenv version and on Linux, macOS and Windows.

Where Pipenv puts global installs: pipenv install --system puts packages in the global interpreter. Check that -g sees them, and never scans the Pipenv venv (PIPENV_VENV_IN_PROJECT, WORKON_HOME).

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Pipenv package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Pipenv project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Pipenv version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Pipenv bug-hunt run

Tested: main 2463257 (#277, the v5 consolidation: hosted mode keeps no ledger, rollback re-derives upstream entries from PyPI, and vendoring uses service artifacts). The CLI still reports 4.0.0, and the latest release is 4.0.0. Real Pipenv 2018.11.26 and 2022.12.19 (py3.8), and 2023.12.1 and 2026.8.0 (py3.12), all on Linux. I used a local mock patch API (SOCKET_API_URL + SOCKET_PATCH_SERVER_URL) serving a patched six 1.16.0 wheel plus pyyaml 6.0.2 and urllib3 1.26.18. It also proxied PyPI's JSON API for SOCKET_PYPI_JSON_API.

Re-triage

• Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333: still reproduces on v5. New: rollback now refuses to undo the stray requirements.txt redirect (git is the only remedy). Commented: Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 (comment)
• Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334: still reproduces (agent). New: in hosted mode the same discovery bug suppresses the stale-install warning, and vex emits a false not_affected while Pipenv's venv holds upstream bytes (stray venv/, and .venv + PIPENV_VENV_IN_PROJECT=0; 2023.12.1 and 2026.8.0, each run twice). Commented: Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 (comment)
• Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384: same hosted false-VEX consequence with VIRTUAL_ENV + PIPENV_IGNORE_VIRTUALENVS=1. Commented: Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 (comment)
• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (pm:poetry): on Pipenv, hosted → vendored is fixed by the v5 takeover; vendored → hosted is still refused with exit 0. Commented: Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)

I didn't file a separate issue for the false VEX. It comes from the same crawlers/python_crawler.rs venv selection as #334 and #384, so per filing bar (d) it went into comments there.

Cells (Linux)

• Hosted v5 round trip, all four versions (default, develop, a named tests category on 2022+, an extras entry, and a 53-file pyyaml release on py3.12): scan → pipenv sync --dev into an empty venv gives PATCHED → install --deploy exits 0 → rollback re-derives hashes from PyPI byte-exact. Pass.
• Hosted, CRLF lock on 2018 and 2026: byte-exact. Pass.
• Vendored v5, lock-only (service artifact) on 2018 and 2026: sync gives PATCHED, --deploy passes, rollback is byte-exact. repair after deleting the wheel redownloads an identical wheel. vendor --revert is byte-exact and removes .socket/. remove <purl> restores one package. Pass.
• hosted → vendored takeover (installed and lock-only): pass (new in v5). vendored → hosted: fail (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328).
• Hosted dry-run: no write. Pass.
• Hosted, out-of-tree venv: stale warning fires, and vex omits the patch as not_applied. Pass. Under the Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 and Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 shapes: fail (false VEX, above).
• Relock after hosted (2022 / 2023 install idna): Pipenv drops the reference (documented). Rollback is then a no-op, re-scan, sync and VEX all work. Pass.
• scan apps/a apps/b (hosted, monorepo): both locks are rewritten. --json with 2 directories is refused (documented). rollback apps/a apps/b / 'apps/**' says "Manifest not found" and leaves both hosted (path targets select installed copies). rollback --cwd apps/a works. This is cross-PM, not Pipenv-specific, so I didn't file it.
• macOS and Windows: blocked. I pushed no probe because git push --delete is still cut off by the git proxy, and two old probe branches are still waiting on a maintainer: bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv.

Maintainer request: global (-g) mode (Linux)

The global interpreter was a standalone CPython (3.12 for Pipenv 2026.8.0, 3.8 for 2018.11.26) first on PATH, filled with pipenv install --system --deploy.

• scan -g / --json, run inside and outside the project, reports exactly the global six 1.16.0. Pass. SOCKET_GLOBAL=1 behaves the same, and --global-prefix <site-packages> scans only that prefix. Pass.
• scan -g --mode hosted and scan --global-prefix … --mode hosted exit 2 ("global installs have no project lockfile to redirect") and write nothing. Pass.
• scan -g --apply and get <purl> -g patch the global copy (import shows it). vex -g emits not_affected; after rollback -g the file is byte-exact again and vex -g has nothing to attest. --global-prefix apply / rollback match. Pass on both versions. apply -g after a rollback is a no-op (documented: rollback drops manifest entries).
• Open question, not filed: an agent-mode scan without -g in a Pipenv project with no venv (not yet pipenv installed, or --system) falls back to the global interpreter by design (python_crawler.rs get_site_packages_paths, the project-marker fallback) and patched the global six in place. That contradicts check 2 of the request ("a scan without -g must never touch it"), but the code documents it as intentional, so I need a maintainer decision before filing.
• Not covered: macOS and Windows (no probe this run); a non-writable prefix (the sandbox runs as root, so a permission check is meaningless here).

False positives ruled out

• rollback on a project with nothing patched exits 1 "Manifest not found". That's documented (CLI_CONTRACT "truly-empty project").
• Vendored drops the entry's "index" key: harmless for a local file, and rollback restores it.
• vendor_prebuilt_required / "patch has no applicable files" were mock-API shape gaps (the artifact needs sha512, and the view needs files), not CLI bugs.

Next

1. Pipenv 7–11 hosted path refs on v5 (py3.6/3.7), and rollback of a path ref.
2. A macOS/Windows probe for hosted VEX under the Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334/Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 shapes (once branch deletion works).
3. v5 socket.yml policy and --package / --min-severity filters on a Pipenv project.
4. Hosted rollback when _meta.sources names a mirror or env-var URL: check that the refusal message names the source.
5. Concurrent or interrupted scans on a Pipfile.lock.

[github-actions[bot]]

[agent] 2026-10-01: Pipenv bug-hunt run

Tested: main 2463257 (unchanged since the previous run; the CLI reports 4.0.0, and the latest release is v4.0.0 from 2026-08-21, which predates v5 and socket.yml). Real Pipenv 9.1.0, 11.10.4 and 2018.11.26 on py3.8, and 2023.12.1 and 2026.8.0 on py3.12, all on Linux. Pipenv 7–11 run on py3.8 when a stdlib venv with pip 18.1 is created at the expected location first; old virtualenv can't copy uv's standalone CPython, and uv has no 3.7 build. Patch data came from a local mock patch API serving a real patched six 1.16.0 wheel (batch / by-package / package / view / blob endpoints), with a PyPI JSON forwarder for SOCKET_PYPI_JSON_API.

Re-triage

• Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333, Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 and Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384: main hasn't changed since the 03:37 re-triage, and their fixes (Fix hosted scan not reading the Pipfile (#333) #425, Fix Pipenv venv discovery order (#334, #384) #388) are still open drafts. Nothing new to add, so I left no comments.

Cells (Linux)

• Pipenv 11.10.4, hosted, out-of-tree venv: scan --mode hosted writes a path reference (probe found pipenv, version 11.10.4 on PATH). pipenv install --deploy into an emptied venv gives the PATCHED six, and vex --product gives not_affected. Rollback re-derives the entry from PyPI byte-exact. Over a warm venv, redirect_pypi_stale_install fires and vex omits the patch as not_applied. Pass.
• SOCKET_PIPENV_MAJOR=11 / 11.10.4 with no pipenv on PATH: path, no warning. With neither set: file + redirect_pipenv_installer_unknown. Pass (documented).
• Pipenv 9.1.0, hosted, in-project .venv: path ref, install --deploy gives PATCHED, rollback succeeds. Pass. Here the 9.1.0 lock had "hashes": [], most likely because its old resolver couldn't fetch hashes through the sandbox proxy. Rollback restores the full PyPI hash list instead of [], so it isn't byte-exact, but the restored lock reinstalls upstream fine. Not filed (see Known non-bugs).
• socket.yml policy, hosted, two-root Pipenv monorepo (2026 shape): ignorePaths (glob and /apps/b/Pipfile.lock marker), includePaths, projectIgnorePaths, ignorePackages (purl and bare name, case-insensitive), ecosystems: [npm], enabled: false, minSeverity: critical, maxNewPatches: 0 / 1 (a purl admitted in apps/a is free in apps/b, as documented): all pass. A patch that's already hosted is retained when policy later excludes it. --prune is a documented no-op in hosted mode.
• get vs socket.yml: get <purl> warns policy_bypassed, but get <uuid> doesn't, in agent, hosted or vendored mode → filed get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453.
• Hosted rollback with a mirror / ${PIP_INDEX_URL} source: refused, partial_failure exit 1, and the error names the source and the git checkout -- Pipfile.lock remedy. https://pypi.org/simple/, PyPI.org and pypi.python.org restore byte-exact. Pass (documented). ${PIP_INDEX_URL} is refused even when the variable is exported as pypi.org: the check doesn't expand env vars. That's conservative and documented ("names a PyPI source in _meta.sources"), so I didn't file it.
• Concurrent hosted scans (6 parallel, 3 rounds): one or more exit 0, the rest lock_held exit 1, the lock is always valid and redirected, and no .socket/ residue. Pass.
• Global -g on 2023.12.1 (pipenv install --system --deploy into a standalone CPython 3.12): scan -g / --json inside and outside the project reports only six. scan -g --mode hosted and --global-prefix … --mode hosted exit 2 and write nothing. scan -g --apply patches the global copy, the lock is untouched, vex -g gives not_affected, rollback -g is byte-exact, and vex afterwards has nothing to attest. SOCKET_GLOBAL=1 get <uuid> and --global-prefix rollback also pass. Pipenv's WORKON_HOME venv isn't scanned. The 114 pypi packages -g counts come from the system interpreter paths (/usr/lib/python3*, /usr/local/lib/python3*), which is by design.
• -g from inside a hosted / vendored Pipenv project: rollback -g and remove <purl> -g unwind the project's Pipfile.lock (and the vendored artifact), and get <uuid> -g --mode hosted|vendored rewires the project's lock, all with exit 0. This is the cross-PM root cause of get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 (fix PR Fix -g touching the cwd project's state (#436, #445) #446 open), so I commented there with the Pipenv evidence instead of filing: rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 (comment) and get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (comment)
• macOS / Windows: blocked. git push --delete is still cut off by the git proxy ("unexpected disconnect while reading sideband packet"), so I pushed no probe. bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Issues

• Filed: get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 (get <uuid> skips policy_bypassed).
• Commented: rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 and get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 (they reproduce on Pipenv).

False positives ruled out

• The Pipenv 9.1.0 "hashes": [] rollback difference: likely a sandbox artifact of the lock, and the restore is a valid, stricter lock.
• The ${PIP_INDEX_URL} rollback refusal is documented and fail-closed.
• The large scan -g counts: by design, -g covers every ecosystem and the system Python paths.

Next

1. A macOS/Windows probe for -g and hosted VEX under the Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 / Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 shapes, once branch deletion works.
2. -g on 2022.12.19 (py3.8), and an unwritable global prefix as a non-root user (useradd, then run as that user).
3. Pipenv 2022+ named categories combined with socket.yml ignorePackages, and --package / --min-severity CLI flags intersecting the file.
4. Interrupted hosted / vendored runs (SIGKILL between the lock acquire and the write) on a Pipfile.lock.
5. A PIPENV_PIPFILE / subdirectory refusal message check.

[github-actions[bot]]

[agent] 2026-10-01 15:41Z: Pipenv bug-hunt run

Tested: main 6e7ef74 (new since the last run: #345 npm non-registry entries, #330 Poetry venv discovery, #337 npm bundled VEX, #322 Maven; the CLI reports 4.0.0, and the latest release is still v4.0.0). Real Pipenv 2022.12.19 (py3.10), 2023.12.1 (py3.11) and 2026.8.0 (py3.12), all on Linux. Patch data came from a local mock patch API serving a real patched six 1.16.0 wheel. It now filters the batch by the requested purls and returns advisory severities from by-package; without both, the mock produced false --package / --min-severity "failures". PyPI was reached through a SOCKET_PYPI_JSON_API forwarder.

Regression check of the new main

• Fix Poetry venv discovery to match Poetry (#327, #329) #330 reorders find_local_venv_site_packages (Poetry first, then .venv, then venv, then Pipenv) and moves the \\?\ stripping into strip_windows_verbatim_prefix. Pipenv's own placement logic is unchanged. Agent mode with an out-of-tree venv still passes, and the Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 shape (stray venv/) still fails the same way.

Re-triage

• Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334: still reproduces on 6e7ef74 (skipped / package_not_installed, exit 0, with the out-of-tree venv untouched). I left no comment because nothing is new.
• get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453: still reproduces (get <uuid> --mode hosted gives 0 policy_bypassed, the purl form gives 1). I left no comment.

Cells (Linux)

• Named category [docs], hosted on 2022.12.19, 2023.12.1 and 2026.8.0: the redirect lands in docs. pipenv sync --categories docs and install --deploy --categories "packages docs" into a fresh venv give the PATCHED six, vex gives not_affected, and rollback is byte-exact (git clean). Pass.
• Named category, vendored on 2022.12.19 and 2023.12.1: applied, sync and deploy give PATCHED, vex gives not_affected, and rollback is clean. Pass. (2022.12.19 also carries vendor_integrity_unverified, which is conservative, so I didn't file it.)
• socket.yml × CLI flags, hosted, 2026.8.0: --package six|SIX|pkg:pypi/six@1.16.0|idna, --min-severity critical|high|medium|none against a high advisory, --max-new-patches 0, ignorePackages with and without --package, packages: [idna] with --package six, and file minSeverity: critical overridden by --min-severity none|high: every case matches CLI_CONTRACT (deny wins, flags narrow, scalars go flag > file). Pass.
• SIGKILL mid-run (hosted ×9 delays, vendored ×25 delays from 0.05 to 1.2 s): the Pipfile.lock is always valid JSON and either original or fully rewired. A vendored ref always matches the wheel's sha256. The leftover .socket/apply.lock is reclaimed by the next run, which succeeds. After a vendored rerun, pipenv sync gives PATCHED. Pass.
• Non-registry lock entries (the Pipenv analogue of npm hosted and vendored modes rewire git-sourced lock entries, so npm ci silently installs the unpatched git bytes while scan and VEX report success #326): path = "./vendor/six-1.16.0", file = <pypi wheel URL> and git = …, ref = "1.16.0". Lock-only, nothing is discovered (no version in the lock). With a warm venv, hosted refuses with redirect_pipenv_refused (exit 0, lock untouched), vendored refuses with pypi_pipenv_source_already_exists (exit 1), and vex attests nothing. Pass. Two minor wording issues, not filed: the hosted detail says "no Pipfile beside the lock", which is the Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 root cause, and the vendored message calls a path entry a "file reference". A registry pin in [packages] plus a file-URL in [docs]: Pipenv 2026 resolves both to the registry pin, and both get redirected. Pass.
• Subdirectory run (--cwd src/ under a Pipenv project): "No packages found", exit 0, nothing written. This is the documented CLI scope.
• -g item 6, unwritable prefix, non-root user (a root-owned standalone CPython 3.12 with pipenv install --system --deploy, and a root-owned in-project .venv):
  • Human mode fails loudly (Permission denied (os error 13), exit 1). Pass.
  • scan --apply --json / --global-prefix … --apply --json / scan --mode agent --json exit 1 with partial_failure, but report failed: 0, action: "added" and no error text. That's scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424, so I commented there with the project-venv shape: scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 (comment)
  • A rerun prints [skip] … already recorded and exits 0 while the file is still unpatched. That's scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454, so I commented there with the "first apply failed" trigger: scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 (comment)
  • vex omits the patch as not_applied. Pass.
• macOS / Windows: blocked. git push --delete is still cut off by the git proxy ("unexpected disconnect while reading sideband packet"), so I pushed no probe. bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Issues

• Filed: none.
• Commented: scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 and scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454.

False positives ruled out

• --package idna still redirecting six, and --min-severity high filtering a high patch as unknown < high: both were mock artifacts. The mock ignored the batch body and served vulnerabilities: {} on by-package.
• The Pipenv 2022.12.19 pkgutil.ImpImporter crash: Pipenv 2022 with PIPENV_PYTHON built a py3.12 venv under a -python3.10 name. Use pipenv --python <3.10> instead. That's a sandbox and old-Pipenv issue.

Next

1. A macOS/Windows probe for -g and the Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 / Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 shapes, once branch deletion works.
2. -g on 2022.12.19 (py3.10 via pipenv --python), plus SOCKET_GLOBAL=1 with a space- or unicode-containing --global-prefix.
3. Pipenv 7–11 agent mode with an out-of-tree venv (py3.8), and the PIPENV_PYTHON venv-name suffix on 11.
4. PIPENV_PIPFILE with a non-normalized value (./Pipfile, sub/../Pipfile). Pipenv hashes os.path.abspath (lexically normalized), while the crawler hashes cwd.join(raw) (python_crawler.rs:990). The canonical-cwd fallback currently hides the mismatch, but it would miss when PIPENV_PIPFILE names another directory.
5. Hosted mode with pipenv requirements export and pipenv verify after a redirect, on 2023.12.1 and 2026.8.0.

[github-actions[bot]]

[agent] 2026-10-01 21:44Z: Pipenv bug-hunt run

Tested: main 61cfb9b. That's new since the last run: #388 (Pipenv venv discovery, fixes #334 / #384), #425 (hosted reads the Pipfile, fixes #333), #456 (#454 re-apply), #446 (-g vs the cwd project, #436 / #445), #452 (egg-info discovery, #447) and #419. The CLI reports 4.0.0, and the latest release is still v4.0.0. I tested real Pipenv 2022.12.19 (py3.10), 2023.12.1 (py3.11) and 2026.8.0 (py3.12) on Linux. Patch data came from a local mock API (batch / by-package / package / view / blob, serving a real patched six 1.16.0 wheel). The mock must serve the before blob too, or rollback fails with "Blob not found". For bisecting I also built bae5d3a (the parent of #388).

Re-triage (closed fixes, verified on main)

• Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 fixed: a stray venv/ plus the WORKON_HOME venv: the Pipenv venv gets patched and venv/ doesn't. Pass.
• Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 fixed: VIRTUAL_ENV=<other> with PIPENV_IGNORE_VIRTUALENVS=1, or with PIPENV_ACTIVE=1: the Pipenv venv gets patched and the other one doesn't. With neither variable set, the activated venv gets patched, which is correct. Pass.
• Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 fixed: a file-wheel lock plus a sibling requirements.txt: redirected: 0, requirements.txt untouched, and the warning no longer has the "no Pipfile" clause. Pass.
• get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453: still reproduces (get <uuid> --mode hosted gives no policy_bypassed, the purl form does, 2/2). I left no comment because nothing is new.

Cells (Linux)

• Hosted + pipenv verify / pipenv requirements / install --deploy into a fresh venv / pip install -r of the exported requirements on 2023.12.1 and 2026.8.0: verify says up to date, the export carries the hosted URL with #sha256=, and every install gives the PATCHED six. Pass.
• PIPENV_PIPFILE spellings (./deploy/Pipfile, deploy/../deploy/Pipfile, an absolute path, ./Pipfile, sub/../Pipfile) with --cwd deploy or cwd=deploy: the WORKON_HOME venv is found every time. Pass. With the Pipfile outside the cwd (no Pipfile in the cwd), nothing is found, which is the documented CLI scope.
• Non-UTF-8 Pipfile (a latin-1 comment): hosted treats the lock as abandoned again, but Pipenv itself crashes on that Pipfile (UnicodeDecodeError), so it isn't a real-world shape. Not filed.
• Agent mode, Pipfile + lock with no Pipenv venv: the system Python's /usr/lib/python3/dist-packages/six.py gets patched, exit 0, vex gives not_affected, and the project's venv/ is ignored. Before Fix Pipenv venv discovery order (#334, #384) #388 (bae5d3a), venv/ was patched. As non-root, the run gets Permission denied on the system path. → filed 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.
• scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 re-check: scan --apply --json re-applies after a reinstall (fixed). Human mode (scan --apply, scan --mode agent, scan --sync without --json) still prints [skip] … already recorded, exits 0, and leaves the package unpatched (2/2 each, real Pipenv venv). The early return is at scan/mod.rs:2700-2737. → commented on scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454: scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 (comment)
• macOS / Windows: blocked. git push --delete still fails ("unexpected disconnect while reading sideband packet"). bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Issues

• Filed: 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.
• Commented: scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 (the fix is incomplete in human mode).

False positives ruled out

• An apparent "main patches venv/": that was my own mistake. I built bae5d3a into the shared target/, which overwrote the main binary. Keep copies of each binary outside target/.
• The rollback "Blob not found": a mock artifact (no before blob was served).

Next

1. After 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 lands: Pipenv projects with venv/ and no Pipenv venv, plus a fresh checkout before pipenv install, on 2018 / 2023 / 2026.
2. After scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 is fully fixed: human-mode rerun after a reinstall and after a failed first apply.
3. macOS/Windows probe (once branch deletion works) for Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 / Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 / Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 verification and the -g checklist.
4. Pipenv 7–11 agent mode with an out-of-tree venv (py3.8), and the PIPENV_PYTHON suffix on 11.
5. Hosted on Pipenv 2022.12.19 with pipenv requirements --categories, and -g on 2022.12.19.

[github-actions[bot]]

[agent] 2026-10-02 03:42Z: Pipenv bug-hunt run

Tested: main 61cfb9b, the same commit as the last run (CLI 4.0.0; the latest release is still v4.0.0). I used real Pipenv 11.10.4 and 2018.11.26 (py3.8, uv-managed, with virtualenv 20.16.7), 2022.12.19 (py3.10), 2023.12.1 (py3.11) and 2026.8.0 (py3.12) on Linux. Patch data came from a local Python mock of the API (batch / by-package / package / view / blob, serving a real patched six 1.16.0 wheel) plus a PyPI JSON forwarder for SOCKET_PYPI_JSON_API. For bisecting I built ccd43f58~1 (the parent of #388).

Re-triage

• Main hasn't changed since the last run, so 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 and get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 stand. Nothing new, so no comments.

Cells (Linux)

• Hosted, six in both default and a named [docs] category (2026.8.0): both entries were redirected. pipenv verify says up to date. pipenv requirements (plain, --categories docs, --categories=docs, --dev) emits the hosted URL with #sha256=. sync --categories docs and install --deploy --categories "packages docs" into a fresh .venv both install the PATCHED six. Pass.
• Hosted, six only in [docs] on 2022.12.19 and 2026.8.0: redirect, requirements --categories docs, vex (--product) not_affected and rollback (byte-exact, via the forwarder) all pass.
• Agent with an out-of-tree venv, Pipenv 11.10.4 and 2018.11.26 (py3.8): project names plain, sp ace é and sp ace é(x) (11.x doesn't sanitize parens) are all found and patched. Pass.
• Agent with the PIPENV_PYTHON suffix, 11.10.4 / 2018.11.26 (an absolute interpreter path gives the nested <name>-<hash>-/abs/path/... chain, 3.8 gives -3.8): the nested chain is discovered. With both venvs present, only the sorted-first one gets patched (same mechanism as below). On 2026.8.0 with PIPENV_PYTHON=python3.11 plus an unsuffixed venv, the unsuffixed venv is patched while pipenv --venv reports -python3.11. I couldn't confirm what pipenv run imports there, so that part is noted on 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 as unverified.
• Agent, ./.venv dir + existing WORKON_HOME venv, nothing explicit (the Fix Pipenv venv discovery order (#334, #384) #388 "patch both" case): only the WORKON_HOME venv is patched (purl dedup in crawl_all). Pipenv 2018.11.26, 2022.12.19 and 2023.12.1 run ./.venv, so it stays unpatched: exit 0, a re-apply says "already match", and vex attests not_affected. 2/2 on each. 2026.8.0 passes. Before Fix Pipenv venv discovery order (#334, #384) #388, 2018/2023 passed and 2026 failed (Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334). → filed 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 (regression from ccd43f58).
• Hosted, same shape (2023.12.1, WORKON copy patched, .venv pristine): redirect_pypi_stale_install fires and hosted vex omits the patch. Pass.
• macOS / Windows: not attempted. Branch deletion through the git proxy has been failing since 2026-09-30, and bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still exist on the remote (re-checked with git ls-remote).

Issues

• Filed: 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 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

False positives ruled out

• Pipenv refuses different versions of one package across [packages] and a named category (it constrains categories by default), so a "per-category version mismatch" shape can't happen.
• vex exits product_undetected on a bare Pipfile project: a Pipfile has no name or version, and --product is the documented remedy.
• Hosted rollback "error sending request" against pypi.org: the known rustls-vs-proxy-CA sandbox artifact. It passes through a SOCKET_PYPI_JSON_API forwarder.
• Old Pipenv + virtualenv<20 can't copy uv's standalone CPython (libpython3.8.so missing): a sandbox/tooling artifact; use virtualenv 20.x.

Next

1. Re-verify 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 once it's fixed, on 2018 / 2022 / 2023 / 2026 (and the PIPENV_PYTHON-suffix twin venv).
2. After 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 and the scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 human-mode gap are fixed: venv-less Pipenv projects and the human-mode rerun after a reinstall.
3. A macOS / Windows probe (once branch deletion works) for Agent-mode scan skips Pipenv's out-of-tree venv when the project has a stray venv/ directory or a .venv with PIPENV_VENV_IN_PROJECT=0, and still exits 0 #334 / Agent-mode scan patches the activated VIRTUAL_ENV even when PIPENV_IGNORE_VIRTUALENVS or PIPENV_ACTIVE tells Pipenv to ignore it, leaving the Pipenv venv unpatched with exit 0 #384 / Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333 and the -g checklist.
4. Pipenv 2024.4.1 / 2025.1.3 spot-checks of the .venv + WORKON shape and hosted named categories.
5. -g on 2022.12.19, and a --global-prefix containing spaces or unicode.

[github-actions[bot]]

[agent] 2026-10-02 09:41Z: Pipenv bug-hunt run

Tested: main 61cfb9b, unchanged since the last run (CLI 4.0.0; the latest release is still v4.0.0, installed from PyPI for comparison). I used real Pipenv 2022.12.19 (py3.10), 2023.12.1 (py3.11), 2024.4.1 and 2025.1.3 (py3.12) and 2026.8.0 (py3.12) on Linux. Patch data came from a local Python mock of the public proxy (SOCKET_PROXY_URL: batch / by-package / package / view / blob), serving a real patched six 1.16.0 wheel, plus a PyPI JSON forwarder for SOCKET_PYPI_JSON_API.

Mock note: the hosted artifact URL must have the /patch/pypi/<name>/<ver>/<token>/<uuid>/<wheel> shape, and SOCKET_PATCH_SERVER_URL must name the mock origin. Otherwise vex / rollback don't recognize the reference ("no hosted … references were found").

Re-triage

• Main is unchanged, so 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 / 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 / get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 stand. 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 is claimed, with open PR Fix PyPI agent apply patching only one installed copy (#529, #501) #538. Nothing new, so no comments.

Cells (Linux)

• Agent, out-of-tree venv, 2024.4.1: patched, pipenv run imports the patched six. Pass.
• Hosted, six in default + [docs], 2024.4.1 and 2025.1.3: both categories redirected. verify up to date; requirements --categories docs emits the hosted URL with #sha256=; sync, sync --categories docs and install --deploy into a fresh .venv all give the PATCHED six; vex not_affected; rollback byte-exact. Pass.
• Vendored, same shape, 2024.4.1 and 2025.1.3: both categories point at the committed wheel and vendor_integrity_unverified is emitted; verify, sync, sync --categories docs and --deploy give PATCHED; vex not_affected; repair is a no-op; rollback is byte-exact and removes .socket/vendor. Pass.
• .env-borne Pipenv settings (new): Pipenv 2022.12.19–2026.8.0 all honor PIPENV_CUSTOM_VENV_NAME, PIPENV_VENV_IN_PROJECT and WORKON_HOME from the project's .env. With PIPENV_CUSTOM_VENV_NAME=myenv in .env, an agent scan --apply misses $WORKON_HOME/myenv, falls back to the global interpreter (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) and patches /usr/lib/python3/dist-packages/six.py; vex then says not_affected. That's 1/1 on 2022/2024/2025 and 2/2 on 2023/2026. Exporting the variable instead passes on every version. WORKON_HOME in .env fails the same way (2023 / 2026). Hosted misses redirect_pypi_stale_install for the warm .env venv (2023 / 2026). v4.0.0 also misses the venv, so it's not a regression. → filed Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546.
• -g --global-prefix with spaces and unicode (dir sp é/sysenv/lib/python3.12/site-packages, 2026.8.0 install --system): apply + rollback pass. A venv-ROOT prefix scans 0 packages: the semantics are undocumented, so not filed.
• -g on 2022.12.19 (install --system --deploy into a py3.10 env, --global-prefix = its site-packages): scan -g --apply patches, rollback -g restores, the Pipfile.lock is untouched, and -g --mode hosted is refused with exit 2. Pass.
• macOS / Windows: not attempted. git push --delete still fails ("unexpected disconnect while reading sideband packet"). bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Issues

• Filed: Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546 Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546

False positives ruled out

• Hosted vex "no hosted references found": a mock artifact (the URL lacked the uuid path, and SOCKET_PATCH_SERVER_URL wasn't set).
• Hosted vex with no venv at all omits six as not_applied, because it checks the system copy (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 fallback). Fail-closed, so not a false attestation.
• scan -g --mode hosted --json prints a plain-text usage error with exit 2 (a clap-level refusal, documented).

Next

1. Re-verify 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 PyPI agent apply patching only one installed copy (#529, #501) #538) and 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 once they merge, on 2018 / 2022 / 2023 / 2026.
2. Re-verify Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546 once fixed: .env with PIPENV_CUSTOM_VENV_NAME, WORKON_HOME, PIPENV_VENV_IN_PROJECT=0 (+ .venv), PIPENV_IGNORE_VIRTUALENVS (+ VIRTUAL_ENV) and PIPENV_DONT_LOAD_ENV=1 exported (which must disable it).
3. A macOS / Windows probe (blocked on branch deletion).
4. --global-prefix given as an interpreter / venv root (what does pypi accept?), and -g on 2018 / 11.
5. Pipenv 2024.4.1 / 2025.1.3: the 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 .venv + WORKON shape and PIPENV_PYTHON suffix venvs.