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-03 21:36Z, main 045d7ec (CLI 4.0.0, unchanged). Filed #725 (vendor --check reports wiring verified after pipenv lock drops the vendored reference). Passing: a pypi-named mirror source (hosted / vendored on 2018 / 2026, rollback refusal documented); a hosted path-prefixed server on Pipenv 11 / 2018 / 2022; a transitive entry with markers. PR #654 (d8356ae, #645 + #546) is still unmerged.

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: pass d63ae5f (#529 fixed); .venv + PIPENV_VENV_IN_PROJECT=0 / NO_VENV_IN_PROJECT=1: fail #645 045d7ec	pass v5 (+CRLF); Six casing pass 045d7ec	stale warning + remedy pass 045d7ec	fail #333	pass v5; + sibling requirements.txt fail #612	pass 045d7ec (default + develop)	pass 045d7ec (default + develop)	fail #384
Linux	2022.12.19	multi-copy (.venv + WORKON) + rollback w/ modified copy pass 045d7ec	.venv + WORKON venv, nothing explicit: pass (#529 fixed); .venv + PIPENV_VENV_IN_PROJECT=0 / NO_VENV_IN_PROJECT=1: fail #645 045d7ec	pass v5 (+relock); [docs]-only + rollback pass 61cfb9b; --hash requirements.txt pass 045d7ec	stale warning + remedy pass 045d7ec	fail #333	pass 045d7ec (lock-only, sync / --deploy, tamper rejected, repair, revert byte-exact)	pass 045d7ec (default + develop)	untested	untested
Linux	2023.12.1	pass; PIPENV_VENV_IN_PROJECT=0 + .venv + WORKON pass 045d7ec (2023.11.14 too; 2023.10.24 fails #645)	.venv + WORKON venv: pass d63ae5f (#529 fixed); .venv reset to pristine → vex not_applied pass 045d7ec (#516 fixed)	pass v5 (+relock); verify / requirements / deploy pass 61cfb9b	pass; fail #334/#384 shapes (false VEX)	fail #333	+ sibling requirements.txt fail #612	pass 045d7ec (prefix)	pass 045d7ec (+ requirements.txt)	fail #384 (agent + hosted VEX)
Linux	2026.8.0	pass 61cfb9b; NO_VENV_IN_PROJECT=1 / VENV_IN_PROJECT=0 + .venv pass 045d7ec; PIPENV_PYTHON-suffixed twin venv pass d63ae5f; .env WORKON_HOME still fails #546 045d7ec	pass 61cfb9b (#334 fixed); .venv + WORKON pass d63ae5f; #504 still fails d63ae5f; 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; + sibling requirements.txt fail #612	pass v5; prefixed server pass 045d7ec; requirements.txt unpatched fail #612	pass 045d7ec (#328 fixed; default + develop + [docs], requirements.txt)	pass 61cfb9b (#384 fixed)
Linux	2024.4.1	pass 61cfb9b; multi-copy + rollback w/ modified copy pass 045d7ec	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	multi-copy + rollback w/ modified copy pass 045d7ec	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

Dotted / underscored distribution names (jaraco.context, typing_extensions), 09:37Z run, 045d7ec: hosted lock-only (2023), vendored (2018 / 2023 / 2026), agent + stale-warning remedy (2018 / 2026) all pass. Lock entries with extras: hosted (file) and vendored (path) on 2022 / 2023 / 2026 pass; a tampered path + extras wheel is rejected on 2018 / 2022 (pass). Pipenv 2026 install <other> keeps the hosted or vendored reference (pass). Hosted stale warning with .venv + WORKON + PIPENV_VENV_IN_PROJECT=0 on 2018 / 2022 names only WORKON: fail, #645 (vex stays conservative, not_applied).

Non-default index (six = {version, index = "private"}, second http [[source]]), 15:32Z run, 045d7ec: hosted lock-only on 2018.11.26 / 2022.12.19 / 2023.12.1 / 2026.8.0 keeps index, and sync / --deploy give PATCHED (pass). 2026 vex / verify / requirements → pip pass. Vendored on 2018 / 2026: sync / --deploy / check / byte-exact rollback pass. Hosted → vendored is refused fail-closed (redirect_revert_failed), and vendored → hosted restores index (pass). Hosted rollback refusal: documented.

Hosted with a path-prefixed --patch-server-url, a rotated grant token, or an sdist hosted artifact (2026.8.0, 045d7ec, #572): rotate, sync / --deploy, verify, vex and byte-exact rollback all pass.

Hosted + requirements.txt with -r req/base.txt pinning the package (Pipenv 2018 / 2023 / 2026 locks, d63ae5f and 8eec03a): fail #567. Hosted lock-only default + develop + root requirements.txt (2023 / 2026, d63ae5f): pass, except rollback refuses the all-hosted requirements.txt (#410).

.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).

Hosted pipenv requirements --hash sibling (2022 / 2026, 045d7ec): hash mode kept, pip install --require-hashes PATCHED (pass); rollback refusal there is #410. Vendored + hashed sibling requirements.txt: vendor --revert / rollback byte-exact on both files (2026, pass).

pypi-named [[source]] on a mirror (no pypi.org in _meta.sources), 21:36Z run, 045d7ec: hosted lock-only on 2018.11.26 / 2026.8.0 (sync / --deploy PATCHED, vex not_affected) pass; hosted rollback refused (documented); vendored on 2018 / 2026 (sync / --deploy / check / vex / byte-exact rollback) pass. Hosted path-prefixed server (/cdn/v2), lock-only: Pipenv 11.10.4 (path), 2018.11.26 and 2022.12.19 (--deploy, vex, idempotent re-scan, byte-exact rollback) pass. A transitive entry with markers and no index (hosted, 2026): pass. Vendored, then pipenv lock (ref dropped) on 2018 / 2022 / 2023 / 2026: vex vendor_unwired (correct), but vendor --check stays green: fail #725.

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-03 03:30Z); bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv still need a maintainer to delete them.

Backlog

0. Re-verify Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 once it's fixed (PR Fix Pipenv venv discovery settings view (#645, #546) #654 d8356ae already passes the agent + hosted-warning repros on 2018 / 2022) (2018 / 2022 / 2023.10.24 with PIPENV_VENV_IN_PROJECT=0, =false, PIPENV_NO_VENV_IN_PROJECT=1; 2023.11.14+ must keep using WORKON). Also check its hosted shape: the stale warning and vex look at WORKON while Pipenv ≤ 2023.10 installs into .venv.
1. Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 variants still open: -r includes in vendored mode. Re-verify once fixed. (Revert / rollback on the half-wired project pass.)
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 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. Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 variants: vendored mode with an -r include, remove, -c constraints; re-verify once fixed.
5. Maintainer request (global -g mode): still to do: macOS / Windows, -g on 2018 / 11, and --global-prefix as a venv root (scans 0; undocumented). Checklist in the 20261001T040000Z entry.
6. Re-verify vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725 once fixed, plus other wiring-drift shapes: a hand-edited file ref to a different uuid, the entry moved to develop, and pipenv install <other> on 2023. (Mirror-named pypi source and hosted path-prefix on 11 / 2018 / 2022 done 2026-10-03 21:36Z, pass.)
   6b. Mixed sources (a mirror named pypi plus pypi.org under another name) with a transitive, index-less entry: hosted rollback restore.
7. 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 / Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645, and hosted / vendored on 2018 / 2022 there (CRLF on Windows). Blocked until branch deletion through the git proxy works (still denied 2026-10-03 15:20Z).

Known non-bugs

• Hosted vex with .venv + WORKON venv under PIPENV_VENV_IN_PROJECT=0 checks both copies, so it gives not_applied when either is stale. That's correct; only the stale warning is Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645.

• Vendored over a hosted pin from a path-prefixed patch server, with no --patch-server-url / SOCKET_PATCH_SERVER_URL naming that origin: pypi_pipenv_source_already_exists. Since Recognize hosted Pipenv references through one shared grammar (#563) #572 a foreign origin isn't ours, so this fails closed by design.

• 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.

• A hosted requirements.txt rewrite touches only the root file; an included pin gets redirect_requirements_entry_not_found (documented). The Pipenv-project consequence is Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567.

• Pipenv 2026.8.0 recreates a PIPENV_PYTHON-suffixed venv on pipenv run when PIPENV_PYTHON names a PATH symlink ("Python version differs"). That's Pipenv's quirk.

• Pipenv 2018.11.26 reads PIPENV_VENV_IN_PROJECT with bool(os.environ.get(...)), so "0" means in project, and Pipenv ≤ 2023.10.24 always uses an existing .venv directory. That's Pipenv's behaviour, and the reason Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 is a socket-patch bug.

• v5 scan defaults to hosted mode; agent cells need --mode agent.

• A hand-reformatted Pipfile.lock (2-space indent or minified) gets the hosted entry in Pipenv's 4-space style, so rollback is semantically exact but not byte-exact. Cosmetic: Pipenv re-serializes on any pipenv lock.

• Pipenv 11.x crashes on PIP_NO_CACHE_DIR=1 (its vendored pip9 _build_session TypeError): a sandbox env artifact, so unset it.

• repair after a relock leaves an unwired vendored entry unwired (success, 0 events): documented as artifact-only. get --mode vendored re-wires it. (Only vendor --check staying green is a bug, vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725.)

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

[github-actions[bot]]

[agent] 2026-10-02 15:39Z: Pipenv bug-hunt run

Tested: main d63ae5f. That's new since the last run: #538 (multi-copy PyPI agent apply), #530 (lock-only requirements.txt -r includes) and #527 / #522 / #499 landed. The CLI is still 4.0.0, and the latest release is still v4.0.0 (installed from PyPI for comparison). I also built the parent 8eec03a to bisect. I used real Pipenv 2018.11.26 (py3.8), 2023.12.1 (py3.11) and 2026.8.0 (py3.12) on Linux. Patch data came from a local Python mock (batch / by-package / view / blob / package grant + hosted wheel, /pypi/ JSON forwarder for SOCKET_PYPI_JSON_API), serving a real patched six 1.16.0.

Re-triage

• 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 (already closed by Fix PyPI agent apply patching only one installed copy (#529, #501) #538): verified fixed. On 2018 / 2023 / 2026, .venv + WORKON_HOME patches both copies, pipenv run imports the patched six, vex not_affected, rollback restores both. Commented: 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 (comment)
• 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: still reproduces on d63ae5f. Pipfile + Pipfile.lock with no Pipenv venv and a stray venv/: agent scan patches /usr/lib/python3/dist-packages/six.py, venv/ stays unpatched, and rollback restores. No comment (nothing new).

Cells (Linux)

• Agent, partial multi-copy state (new, after Fix PyPI agent apply patching only one installed copy (#529, #501) #538): both copies patched, then one copy reset to pristine (.venv recreated). apply re-patches it: pass. But vex hashes only the first copy (WORKON_HOME), so with .venv (the venv Pipenv 2018–2025 runs) pristine it attests not_affected. That's 2018 1/1, 2023 2/2, 2026 shape n/a (Pipenv uses WORKON there, and that order is right). Same root cause as Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (collapse_to_first in vex.rs). PR Fix agent vex checking only one installed copy (#516) #517 is generic, so I commented on Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 instead of filing: Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (comment)
• Agent, PIPENV_PYTHON=python3.11 suffixed twin venv (2026.8.0, proj-<hash> + proj-<hash>-python3.11): both patched. Pass. (Pipenv 2026.8.0 itself recreates the suffixed venv on pipenv run when PIPENV_PYTHON names a PATH symlink: that's Pipenv's quirk.)
• Hosted, lock-only, default + develop, root requirements.txt from pipenv requirements (2023 / 2026): both files rewired; sync --dev, install --deploy PATCHED; verify up to date; vex not_affected. Pass. Rollback refuses (an all-hosted requirements.txt, so the hash mode isn't derivable). That's existing Hosted rollback, remove and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (six==1.16.0 alone can be patched but never unpatched) #410.
• Hosted, Pipenv project + requirements.txt = -r req/base.txt (new, Fix lock-only requirements.txt discovery (#412, #523) #530 area): only Pipfile.lock is rewired (redirect_requirements_entry_not_found in redirect.warnings), status success. Then vex exits 2 (patched_ref_unattributable), rollback exits 1, and a rescan changes nothing; pip install -r gets unpatched six. Fails on d63ae5f (3/3, plus 2018 / 2023 with Pipenv on PATH) and on 8eec03a, so it's not a Fix lock-only requirements.txt discovery (#412, #523) #530 regression. → filed Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567.
• macOS / Windows: not attempted. The two old probe branches still need a maintainer to delete them.

Issues

• Filed: Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567
• Commented: Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (Pipenv evidence), 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 (fix verified)

False positives ruled out

• Hosted rollback "error sending request … pypi.org": rustls vs the proxy CA (known); fixed with the forwarder.
• Rollback refusal on an all-hosted root requirements.txt: Hosted rollback, remove and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (six==1.16.0 alone can be patched but never unpatched) #410, already filed.
• Pure pip -r include in hosted mode: root-only rewrite + redirect_requirements_entry_not_found is the documented hosted behavior (Lockfile-only scan ignores pins in requirements.txt -r includes, so a fresh checkout reports "No patches available" and installs unpatched (hosted and vendored) #412 body). Not handed over.

Next

1. 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 (.env venv settings) 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 fixed.
2. Re-verify the Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 Pipenv shape once PR Fix agent vex checking only one installed copy (#516) #517 merges (.venv pristine on 2018 / 2023 / 2025).
3. Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 variants: vendored mode with an -r include in a Pipenv project, remove, and -c constraints files.
4. Agent multi-copy on 2022 / 2024 / 2025, including rollback with one copy user-modified (third hash).
5. A macOS / Windows probe (blocked on branch deletion).

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

• 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: closed 2026-10-01 16:48 UTC
• 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: closed 2026-10-01 16:46 UTC
• 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: closed 2026-10-01 16:46 UTC
• 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: closed 2026-10-02 14:26 UTC

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger still lists these issues as failing, but they are now closed:

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (vendored ⇄ hosted takeover refused): closed as completed by PR Fix PyPI vendored to hosted takeover being refused (#328) #503, merge 0ac5b91a on main

Please re-check them and update the matrix on your next run.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-02 21:36Z: Pipenv bug-hunt run

Tested: main 045d7ec. Main was force-updated since the last run (d63ae5f is no longer on it). New since then: #572 (one shared hosted-Pipenv URL grammar, #563), #503 (PyPI vendored → hosted takeover, #328) and #517 (agent vex checks every copy, #516). The CLI and the latest release are both still 4.0.0. I used real Pipenv 2018.11.26 (py3.8), 2023.12.1 and 2026.8.0 (py3.12) on Linux. Patch data came from a local Python mock (batch / by-package / view / blob / package grant with an optional path prefix, rotating grant token, wheel or sdist artifact, and a /pypi/ JSON forwarder), serving a real patched six 1.16.0.

Re-triage

• Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (closed by Fix agent vex checking only one installed copy (#516) #517): the Pipenv shape is verified fixed. On 2023.12.1, .venv + WORKON venv, with .venv reset to pristine, vex now gives not_applied, not not_affected (2/2). Commented: Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (comment)
• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (closed by Fix PyPI vendored to hosted takeover being refused (#328) #503, pm:poetry): the Pipenv vendored → hosted takeover passes (see cells).
• 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: still reproduces on 045d7ec (2026.8.0, WORKON_HOME in .env). The Pipenv venv stays unpatched and the system six is patched instead; rollback restores it. No comment (nothing new).

Cells (Linux)

• Hosted, path-prefixed --patch-server-url (/socket-proxy/v1), plus a rescan with a rotated grant token (2026): rotated in place, sync PATCHED, vex not_affected, rollback byte-exact. Pass (Recognize hosted Pipenv references through one shared grammar (#563) #572).
• Hosted sdist artifact (six-1.16.0.tar.gz), plus a token rotation (2026): install --deploy PATCHED, verify passes, vex not_affected, rollback byte-exact. Pass (Recognize hosted Pipenv references through one shared grammar (#563) #572).
• Hosted (prefix) → vendored takeover (2023): vendor_takeover_reverted_redirect, vendored, exit 0. Pass. Without SOCKET_PATCH_SERVER_URL the prefixed pin is a foreign source, so pypi_pipenv_source_already_exists (exit 1, fail-closed, by design).
• Vendored → hosted takeover (Fix PyPI vendored to hosted takeover being refused (#328) #503): 2026 default-only, 2018 default + develop, and 2026 default + develop + [docs]. All categories are redirected, .socket/ is reclaimed, sync / --deploy PATCHED, vex not_affected, rollback byte-exact. Pass.
• Vendored → hosted with a pipenv requirements sibling requirements.txt (2023): both files are redirected. Pass.
• Vendored with a pipenv requirements sibling requirements.txt (2018 / 2023 / 2026, 2/2 each): only Pipfile.lock is wired, with no pypi_multiple_lockfiles warning. vendor --check is green, pip install -r gets UNPATCHED six, and vex refuses with a remedy that a re-run doesn't satisfy. The hosted → vendored takeover (2026) reverts the hosted requirements.txt pin to PyPI. Fail, filed Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612.
• macOS / Windows: not attempted. Probe-branch deletion was still broken, and the new cells are pure lock logic.

Issues

• Filed: Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612
• Commented: Agent-mode npm vex hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched #516 (Pipenv shape verified fixed)

False positives ruled out

• vex with no --product on a bare Pipfile: product_undetected, documented.
• Vendored over a path-prefixed hosted pin without SOCKET_PATCH_SERVER_URL: the origin isn't ours, so the refusal is correct.
• v4.0.0 vendored against the mock gives vendor_fetch_unverifiable (the old flow needs the PyPI wheel by hash), so it couldn't serve as a bisect baseline.

Next

1. Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 variants: vendor --revert / rollback on the half-wired project; requirements.txt with --hash lines (pipenv requirements --hash); -r includes (overlaps Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567).
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 / 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 / Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 once fixed.
3. Agent multi-copy on 2022 / 2024 / 2025, plus rollback with one copy user-modified.
4. Hosted path-prefix on Pipenv 9 / 11 (path references) and on lock-only checkouts.
5. A macOS / Windows probe, if branch deletion works.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since the last run; CLI and latest release 4.0.0). I used real Pipenv 2018.11.26 (py3.8), 2022.12.19, 2023.10.24, 2023.11.14, 2023.12.1, 2024.4.1, 2025.1.3 and 2026.8.0 (py3.11) on Linux. Patch data came from a local Python mock (batch / by-package / view / blob / package grant / /pypi/ JSON forwarder) serving a real patched six 1.16.0. Published v4.0.0 (npm) was the bisect baseline.

Re-triage

Main hasn't moved since the last run, so I didn't re-check the open issues (#612 / #567 / #546 / #504 / #453). Nothing could have changed.

Cells (Linux)

• Hosted stale-install warning + its printed remedy (pipenv run pip uninstall -y six && pipenv sync) on 2018.11.26 / 2022.12.19 / 2023.12.1 / 2026.8.0: the warning fires, the remedy gives PATCHED, and vex gives not_affected. Pass.
• Hosted + pipenv requirements --hash sibling (2022.12.19, 2026.8.0): both files are rewritten; requirements.txt keeps hash-checking mode (--hash=sha256:<patched>) and markers. A fresh pip install --require-hashes -r gives PATCHED. Pass. Rollback refuses the all-hosted requirements.txt, which is Hosted rollback, remove and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (six==1.16.0 alone can be patched but never unpatched) #410 (pm:pip), already filed.
• Vendored on 2022.12.19 (previously untested row): scan, warm warning, sync, --rm + install --deploy, lock-only fresh checkout sync, tampered wheel (Pipenv 2022 rejects it on the hash, vendor --check exit 1), repair, vendor --revert byte-exact, .socket/ removed. Pass.
• Hosted → vendored takeover, default + develop, on 2018.11.26 and 2022.12.19: takeover note, both categories vendored, sync --dev PATCHED, vendor --check green, vex not_affected, rollback byte-exact. Pass.
• Pipfile name casing (Six = "==1.16.0", requirements.txt Six==1.16.0) on 2018 / 2026, hosted: both files rewritten, install --deploy PATCHED. Pass.
• Agent multi-copy (WORKON venv + .venv) on 2022.12.19 / 2024.4.1 / 2025.1.3: both copies patched, lock untouched, vex not_affected. Rollback with the .venv copy user-modified refuses that copy ("modified after patching"), rolls back the other, and exits non-zero. Pass.
• Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 variants (2026.8.0): vendor --revert and rollback on a vendored project with a hashed sibling requirements.txt are both byte-exact on both files. Pass. The Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 gap itself is unchanged.
• Explicit "not in project" + ./.venv, agent: PIPENV_VENV_IN_PROJECT=0 / false, PIPENV_NO_VENV_IN_PROJECT=1. Pipenv ≤ 2023.10.24 always uses an existing .venv directory (2018 even reads "0" as truthy), but since Fix Pipenv venv discovery order (#334, #384) #388 socket-patch patches only the WORKON venv. pipenv run stays unpatched and vex says not_affected. Failing: 2018.11.26, 2022.12.19, 2023.10.24 (2/2 on 2018 / 2022). With no WORKON venv, the global Python gets patched instead (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 shape). Passing: 2023.11.14, 2023.12.1, 2026.8.0. v4.0.0 passes on 2022. Fail, filed Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645. The Pipenv boundary (2023.10.24 → 2023.11.14) comes from the upstream wheels.
• macOS / Windows: not attempted. git push origin --delete through the proxy still fails ("unexpected disconnect while reading sideband packet", re-checked 03:30Z), so bughunt/pipenv/20260930-venv-discovery and bughunt/pipenv/20260930-virtualenv remain.

Issues

• Filed: Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645

False positives ruled out

• An all-hosted hashed requirements.txt refused by rollback: that's Hosted rollback, remove and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (six==1.16.0 alone can be patched but never unpatched) #410, and its suggested --hash vs #sha256= signal is already there.
• PIPENV_VENV_IN_PROJECT=0 "ignored" by Pipenv 2022: that's how Pipenv itself behaves (an existing .venv dir wins), not a sandbox artifact. That's the basis of Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645.
• In v5 the default scan mode is hosted; agent cells need --mode agent.

Next

1. Re-verify Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 / 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 / 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 / Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 / Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 once main moves.
2. Hosted-mode shape of Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645: the stale warning and vex look at the WORKON venv while Pipenv ≤ 2023.10 installs into .venv. Check whether vex gives a false not_affected once WORKON is reinstalled.
3. -g on 2018 / 11, and --global-prefix as a venv root (maintainer checklist).
4. Hosted path-prefix on Pipenv 9 / 11 (path references) and on lock-only checkouts.
5. A macOS / Windows probe, once branch deletion works.

[github-actions[bot]]

[agent] 2026-10-03 09:37Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged; CLI and latest release 4.0.0). I used real Pipenv 2018.11.26 (py3.8), 2022.12.19, 2023.12.1 and 2026.8.0 on Linux. Patch data came from a rebuilt local Python mock (batch / by-package / view / blob / package grant / hosted artifact / /pypi/ JSON forwarder) serving real patched wheels of jaraco.context 4.3.0, typing_extensions 4.7.1 and six 1.16.0.

Re-triage

Main hasn't moved, so open issues #645 / #612 / #567 / #546 / #504 / #453 weren't re-checked on main. I built PR #654 (d8356ae, claims #645 + #546) and ran the #645 repros against it. See Issues.

Cells (Linux)

• Dotted / underscored distribution names (jaraco.context, lock key jaraco.context, purl jaraco-context; typing_extensions, lock key typing-extensions):
  • Hosted lock-only on 2023.12.1: both entries rewritten, sync / install --deploy PATCHED, vex not_affected, rollback byte-exact.
  • Vendored on 2018.11.26 / 2023.12.1 / 2026.8.0: sync PATCHED, vendor --check green, rollback byte-exact with .socket/ removed.
  • Agent on 2018 / 2026: patched, rollback restores.
  • Hosted stale warning on 2018 / 2026, and its remedy pip uninstall -y jaraco-context on 2018: works.
  • Pass.
• Lock entry with extras, hosted and vendored on 2022.12.19 / 2023.12.1 / 2026.8.0. Vendored writes path and hosted writes file, with extras / markers kept. sync and --rm + install --deploy give PATCHED; rollback is byte-exact. Pass.
• Tampered vendored wheel on a path (extras) entry, 2018.11.26 / 2022.12.19: Pipenv rejects it on the hash and vendor --check exits 1. Same with the file entry. Pass.
• Pipenv 2026.8.0 pipenv install <other> after hosted or vendored: the six reference survives, stays PATCHED, and vex gives not_affected. This matches the docs (only releases before 2024 do a full relock). Pass.
• Hosted shape of Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 (2018 / 2022, .venv + WORKON venv, PIPENV_VENV_IN_PROJECT=0, 2/2): the stale-install warning names only the WORKON venv. After that venv is reinstalled, a rescan is silent while pipenv run still loads the unpatched .venv. vex is conservative (not_applied, since hosted vex also checks .venv). Fail, same root cause as Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645. I commented there instead of filing.
• macOS / Windows: not attempted. Probe-branch deletion through the proxy was still broken at the last check.

Issues

• Commented on Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 with the hosted shape and the PR Fix Pipenv venv discovery settings view (#645, #546) #654 verification: Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 (comment). On Fix Pipenv venv discovery settings view (#645, #546) #654 the hosted scan warns for both copies, the rescan still warns for .venv, and agent patches both copies on 2018 and 2022.
• No new issues filed.

False positives ruled out

• Hosted vex with .venv stale and the WORKON venv patched gives not_applied, which is correct. There's no false attestation, so the hosted shape isn't a separate VEX bug.
• An extras test with extras = ["testing"] failed on 2022 because of the extra's own dependency tree (py3.8). That's a test artifact, so I re-ran with a placeholder extra.

Next

1. Re-verify Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 / 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 Fix Pipenv venv discovery settings view (#645, #546) #654 merges, including the .env shapes and PIPENV_DONT_LOAD_ENV=1.
2. Re-verify Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 / 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 main moves.
3. -g on 2018 / 11, and --global-prefix as a venv root (maintainer checklist).
4. Hosted path-prefix on Pipenv 9 / 11 (path references) and on lock-only checkouts.
5. Lock entries with a non-default index (second [[source]]) in hosted and vendored, on 2018 and 2026.
6. A macOS / Windows probe, once branch deletion works.

[github-actions[bot]]

[agent] 2026-10-03 15:32Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged; CLI and latest release 4.0.0). I used real Pipenv 2018.11.26 (py3.8), 2022.12.19, 2023.12.1 and 2026.8.0 (py3.11) on Linux. Patch data came from a rebuilt local Python mock (batch / by-package / package grant / view / blob / hosted wheel / /pypi/ JSON forwarder), plus a PEP 503 private simple index serving the upstream six 1.16.0 wheel. The mock served a real patched six 1.16.0 wheel.

Re-triage

Main hasn't moved and PR #654 is still unmerged (blocked on human review), so #645 / #612 / #567 / #546 / #504 / #453 weren't re-checked.

Cells (Linux), backlog item 6: lock entries with a non-default index

The Pipfile has two [[source]] entries, pypi (pypi.org) and private (http, verify_ssl = false), and six = {version = "==1.16.0", index = "private"}. Each release's pipenv lock writes "index": "private". Pipenv 2018 also merges the PyPI sdist hash into hashes.

• Hosted, lock-only, on 2018.11.26 / 2022.12.19 / 2023.12.1 / 2026.8.0: the entry is rewritten to file + #sha256 with index: "private" kept. sync and --rm + install --deploy give PATCHED on all four. On 2026, vex gives not_affected, pipenv verify passes, and pipenv requirements → pip install -r gives PATCHED. Pass.
• Hosted rollback with the private index: refused, exit 1, with the git checkout remedy and the lock left untouched. This is the documented upstream-restore refusal. Pass.
• Vendored, lock-only, on 2018.11.26 / 2026.8.0: index is dropped (a known non-bug). sync / install --deploy give PATCHED, vendor --check is green, and rollback is byte-exact with .socket/ removed. Pass.
• Hosted → vendored takeover over the private-index pin (2026): redirect_revert_failed "cannot vendor over the live hosted pin … not PyPI", partial_failure exit 1, lock byte-identical, no .socket/vendor. This fails closed with the remedy. Pass.
• Vendored → hosted takeover (2026): migrated, index: "private" restored from the ledger, --deploy PATCHED, .socket/vendor removed. Pass.

Other cells

• A re-formatted Pipfile.lock (2-space indent, or minified to one line), hosted on 2026.8.0: the rewrite is valid JSON, --deploy gives PATCHED, vex gives not_affected, and rollback succeeds and is semantically identical. Pass. The rewritten entry uses Pipenv's 4-space style, so rollback isn't byte-exact on a non-Pipenv layout. This is cosmetic; any pipenv lock re-serializes it anyway (added to Known non-bugs).
• macOS / Windows: not attempted. Deleting probe branches through the git proxy is still denied (re-checked 15:20Z), so no probe was pushed.

Issues

None filed, commented on or closed.

False positives ruled out

• uv pip install -r against the mock failed on HEAD (501). That's a gap in the mock; pip gives PATCHED.

Next

1. Re-verify Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 / 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 Fix Pipenv venv discovery settings view (#645, #546) #654 merges, including the .env shapes and PIPENV_DONT_LOAD_ENV=1.
2. Re-verify Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 / 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 main moves.
3. Hosted path-prefix on Pipenv 9 / 11 (path references) and on lock-only checkouts.
4. A pypi-named source pointing at a mirror (no pypi.org in _meta.sources): hosted, vendored and rollback, on 2018 / 2026.
5. -g on Pipenv 11.

[github-actions[bot]]

[agent] 2026-10-03 21:36Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged; CLI and latest release 4.0.0). I used real Pipenv 11.10.4 / 2018.11.26 (py3.8) and 2022.12.19 / 2023.12.1 / 2026.8.0 (py3.11) on Linux. Patch data came from a rebuilt local Python mock (batch / by-package / package grant / view / blob / hosted wheel, a /pypi/ JSON forwarder and a PEP 503 simple index), serving a patched real six 1.16.0 wheel. A second instance served the hosted wheel under a /cdn/v2 path prefix.

Re-triage

Main hasn't moved, and PR #654 (#645 + #546) is still open and blocked on human review. So #645 / #612 / #567 / #546 / #504 / #453 weren't re-checked. #612 gained a uv-routine comment (same root cause in uv); no action needed.

Cells (Linux)

• Backlog 4: a pypi-named [[source]] pointing at a mirror (_meta.sources has no pypi.org, and the entry has index: "pypi"):
  • Hosted lock-only on 2018.11.26 / 2026.8.0: rewritten to file, with index kept. sync and install --deploy give PATCHED, and vex gives not_affected. Pass.
  • Hosted rollback: refused, exit 1, partial_failure, with the git checkout remedy and the lock untouched. Documented upstream-restore refusal. Pass.
  • Vendored lock-only on 2018 / 2026: sync / --deploy give PATCHED, vendor --check is green, vex gives not_affected, and rollback is byte-exact with .socket/ removed. Pass.
• Backlog 6b: hosted path-prefixed patch server (/cdn/v2), lock-only:
  • Pipenv 11.10.4 (path reference): install --deploy gives PATCHED, vex gives not_affected, the re-scan is idempotent, and rollback is byte-exact. Pass.
  • 2018.11.26 / 2022.12.19 (file): --deploy gives PATCHED, vex gives not_affected, and rollback is byte-exact. Pass.
• Transitive entry with markers and no index (six under python-dateutil, hosted, 2026.8.0): markers kept, --deploy gives PATCHED, pipenv verify passes, vex gives not_affected, and rollback is byte-exact. Pass.
• Vendored, then pipenv lock (relock drops the .socket/vendor ref) on 2018 / 2022 / 2023 / 2026: a fresh install --deploy gives UNPATCHED, as documented. vex refuses with vendor_unwired (correct). But vendor --check says "committed artifact and wiring verified" and exits 0. Fail, filed vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725. repair is a no-op there (documented as artifact-only), and get --mode vendored re-wires it.
• macOS / Windows: not attempted. Branch deletion through the git proxy is still the blocker.

Issues

• Filed vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725: vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725. run_check verifies wiring only for JVM entries (vendor.rs:955). This is probably cross-PM (uv / poetry / pdm relocks), but I only reproduced it on Pipenv.

False positives ruled out

• PIP_NO_CACHE_DIR=1 crashes Pipenv 11's vendored pip9 (TypeError in _build_session): a sandbox env artifact, so unset it for Pipenv ≤ 11.
• vex without SOCKET_PATCH_SERVER_URL on a path-prefixed hosted pin gives "nothing to attest", exit 2. That's the documented foreign-origin rule (already in the mock notes).

Next

1. Re-verify Agent mode skips ./.venv when PIPENV_VENV_IN_PROJECT=0 or PIPENV_NO_VENV_IN_PROJECT=1 is set, but Pipenv 2018 through 2023.10.24 still use that .venv, so it stays unpatched and VEX attests not_affected (regression from #388) #645 / 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 Fix Pipenv venv discovery settings view (#645, #546) #654 merges, including the .env shapes and PIPENV_DONT_LOAD_ENV=1.
2. Re-verify Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 / 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 / vendor --check says "committed artifact and wiring verified" (exit 0) after pipenv lock drops the vendored reference, so a fresh pipenv install --deploy installs the unpatched wheel while vex says vendor_unwired #725 once main moves.
3. Other wiring-drift shapes for vendor --check / vex: a hand-edited file ref pointing at a different uuid, the entry moved to develop, and pipenv install <other> on 2023.
4. -g on Pipenv 11.
5. Hosted with mixed sources (a mirror named pypi plus pypi.org under another name, on a transitive entry with no index): rollback restore source.