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-06 ~03:37Z, main 9c43dfc (CLI 4.0.0, unchanged). New: #912 (Pipenv 2026.4+ installs a pylock-only project from pylock.toml and ignores the archive entry socket-patch writes). Previous run: 2026-10-05 ~21:44Z. #654 and #730 merged: #645, #546 and #725 are re-verified fixed with real Pipenv (agent apply / vex and vendored vendor --check). #842 still fails on 2023.12.1. PR #825 (#769) is still open.

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: fixed (#645, re-verified 9c43dfc)	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: #645 closed by #654 (2022 not re-run yet)	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 fixed 9c43dfc)	.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 shapes (12) pass 9c43dfc (#546 fixed)	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	2020.11.15 (py3.8)	warm venv agent + rollback pass 045d7ec; .venv + PIPENV_VENV_IN_PROJECT=0: untested since the #645 fix	untested	pass 045d7ec (lock-only deploy / sync / vex / byte-exact rollback)	stale warning + both remedies + vex pass 045d7ec	untested	pass 045d7ec (lock-only, tamper rejected, vendor --check exit 1)	untested	untested	untested
Linux	2021.5.29 (py3.8)	same as 2020.11.15 (pass; #645 shape fails)	untested	pass 045d7ec (+ get CVE, idempotent re-run, remove byte-exact)	stale warning + both remedies + vex pass 045d7ec	untested	pass 045d7ec (+ get --mode vendored, remove byte-exact)	untested	untested	untested
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; Pipfile venv_in_project = true fail #842 045d7ec (also 2018 / 2023 / 2026.1)	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.

In-run VEX (scan --vex), 04:00Z run, 045d7ec: hosted with a stale OOT venv on 2018 / 2022 / 2026 omits the patch and exits 1 with no_applicable_patches (also with --vex-no-verify), and attests after the remedy (pass). Vendored in-run VEX over a warm unpatched venv attests with vendored_tree_out_of_sync (documented). Hosted .venv + WORKON + PIPENV_VENV_IN_PROJECT=0 with WORKON patched (2018 / 2022): in-run and standalone vex give a false not_affected (fail #645; PR #654 fixes it). --dry-run hosted / vendored / agent scan and hosted / vendored get write nothing (pass); hosted JSON drops the vex dry_run marker (fail #744). Vendored remove gives a byte-exact lock (pass). vendor --check with the file ref pointing at another or missing uuid stays green (fail #725).

Superseding patch (uuid A → B), ~10Z run, 045d7ec: hosted re-pin + stale warning + remedy + vex on 2026.8.0 pass. Vendored re-vendor fails on 2018.11.26 / 2022.12.19 / 2023.12.1 / 2026.8.0, both lock-only and venv-present (#769); --dry-run previews would_revendor. The vendor --revert + re-scan workaround passes.

CRLF Pipfile + Pipfile.lock, 21:42Z run, 045d7ec: vendored on 2018 / 2026 (CRLF kept, --deploy patched, vex, byte-exact rollback) pass; hosted on 2018 / 2026 (CRLF kept, --deploy, vex) pass. vendor / apply --dry-run --vex write no VEX (pass). pipenv install <other> on 2022 / 2023 relocks the reference away and vex refuses (documented, pass). PR #795 cells: see #790.

Stale-install remedy followed verbatim, 15:30Z run, 045d7ec: default patched on 2018 / 2022 / 2023 / 2026 (pass). develop (2018–2026) and [docs] (2022–2026), hosted and vendored, both printed remedies leave the package uninstalled (fail #790). Hosted supersede A → B on 2018 (default / develop), 2022 (develop / docs), 2023 (default / docs) and 2026 (docs / develop): re-pin, stale warning and conservative vex all pass; rollback / remove after the supersede are byte-exact (pass); with a sibling requirements.txt both files re-pin (pass), and the rollback refusal is #410.

03:38Z run (2026-10-05), 045d7ec: mixed sources (a mirror named pypi first, pypi.org as upstream) hosted rollback on 2026: an index-less entry is restored byte-exact (pass); index = "pypi" (the mirror) is refused (documented). Symlinked Pipfile / Pipfile.lock: hosted redirect_symlinked_file_unsupported and vendored pypi_pipenv_symlink_unsupported, nothing written (pass). .venv symlinked to an out-of-tree directory (IN_PROJECT=1 / unset): pass. Venv drift (venv 1.15.0, lock 1.16.0), hosted + vendored: pass. Pipenv project with a pdm-backend pyproject.toml: pass. list on hosted: pass. pipenv --site-packages / PIPENV_SITE_PACKAGES=1 with six in the base interpreter: hosted (2018 / 2022 / 2023 / 2026) and vendored (2018 / 2026) keep the base's unpatched six even in a fresh venv, give no warning, and vex attests not_affected: fail, #409 (commented).

09:32Z run (2026-10-05), 045d7ec: Pipfile [pipenv] venv_in_project = true with no ./.venv, agent mode: fail #842 on 2018.11.26 / 2023.12.1 / 2025.1.3 / 2026.1.0 (WORKON venv unpatched, system Python patched, vex not_affected); pass on 2026.8.0 (./.venv) and on the key-less control; the PR #654 head d8356ae still fails. Relative WORKON_HOME with --cwd from another directory: misses the venv (see Known non-bugs).

19:15Z run (2026-10-05), 0d302dc: #790 remedy (pipenv sync --dev) followed verbatim on 2018.11.26 / 2020.11.15 / 2026.8.0 gives the patched six, vex not_affected (pass, #790 fixed). #842 hosted shape (Pipfile venv_in_project = true, warm WORKON venv): no stale-install warning on 2018.11.26 / 2023.12.1 / 2026.1.0 (fail #842); 2026.8.0 and the key-less control warn (pass); hosted vex fails closed (file_not_found / not_applied). Precedence on 2026.8.0, agent mode: key true + PIPENV_VENV_IN_PROJECT=0 → WORKON; key false + .venv + env 1 → .venv; key "false" (a string) → .venv: all pass.

21:44Z run (2026-10-05), 9c43dfc, with an apply-based oracle (offline apply from a local manifest, checking which six.py copies are patched): #645 shape (.venv + WORKON + PIPENV_VENV_IN_PROJECT=0 / NO_VENV_IN_PROJECT=1) on 2018.11.26 / 2023.10.24 / 2023.12.1 / 2026.8.0 patches both venvs, and agent vex with either copy stale gives not_applied (pass). .env shapes (plain, CRLF, export, quoted, ${VAR}, override, custom name, DOTENV_LOCATION, IN_PROJECT=1, relative WORKON_HOME incl. --cwd from the parent, BOM, DONT_LOAD_ENV) on 2023.12.1 / 2026.8.0, plus 2018.11.26: pass, and agent vex is honest. Non-boolean PIPENV_VENV_IN_PROJECT × Pipfile key on 2026.8.0: pass. vendor --check after a real pipenv lock (2018 / 2026) and uuid drift: pass (#725 fixed). #842 agent on 2023.12.1: still fails.

03:37Z run (2026-10-06), 9c43dfc: Pipenv [pipenv] use_pylock = true. With Pipfile.lock + pylock.toml both present, hosted on 2026.8.0 passes. pylock-only, hosted / vendored: pipenv sync installs upstream on 2026.4.0 / 2026.6.0 / 2026.7.1 / 2026.8.0 (fail #912; vendored vex gives a false not_affected); 2026.0.0–2026.2.2 fail loudly (Pipfile.lock not found). Hosted stale warning with .env WORKON_HOME (2026.8.0), stale warning + remedy + vex on 2024.4.1, pipenv upgrade <other> keeping the reference, and Pipfile.lock mode preservation: pass.

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. Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912 variants: pylock.<name>.toml (pylock_name), dev packages in pylock, rollback / remove / repair on a pylock-only Pipenv project; re-verify once fixed.

1. (Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 re-verified fixed on main 0d302dc, 2026-10-05 19:15Z.) Still untested: Windows cmd / PowerShell quoting of --categories "…".

2. Re-verify Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 once fixed (vendored re-vendor A → B: rewire in place, old uuid dir removed, revert byte-exact, no false package_not_installed with a venv). (Hosted supersede on 2018 / 2022 / 2023, develop / named categories and with a sibling requirements.txt: done 2026-10-04 15:30Z, pass.)

3. 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 re-verified fixed for agent mode and agent vex (2026-10-05 21:44Z). Still to do: its hosted shape (the stale-install warning and hosted vex with .venv + WORKON + IN_PROJECT=0 on 2018 / 2022 / 2023.10).

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

5. 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 re-verified fixed for agent mode (2026-10-05 21:44Z, 12 .env shapes). Still to do: the hosted stale warning with .env-placed venvs, and VIRTUAL_ENV / PIPENV_ACTIVE set inside .env.

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

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

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

9. 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 re-verified fixed (2026-10-05 21:44Z). Re-verify scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744 once fixed. (install <other> on 2022 / 2023 and the vendor / apply dry-run VEX: done 2026-10-04 21:42Z, pass.) (Mirror-named pypi source and hosted path-prefix on 11 / 2018 / 2022 done 2026-10-03 21:36Z, pass.)
   6b. Re-verify In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 for Pipenv once fixed: --site-packages fresh + warm venv, hosted + vendored, 2018–2026 (stale warning or vex refusal expected). (Mixed-sources hosted rollback: done 2026-10-05, pass.)
   6c. Pipenv 2020 / 2021: include them in the 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 re-verification. (The Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 [dev-packages] remedy on 2020.11.15: done 2026-10-05 19:15Z, pass.) (Relative WORKON_HOME with --cwd: done 2026-10-05 09:32Z, see Known non-bugs.)
   6d. Re-verify Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 once fixed: agent (2018 / 2023 / 2025 / 2026.1 fail; 2026.2+ use ./.venv) and the hosted stale-install warning (2018 / 2023 / 2026.1 missing, commented 2026-10-05). (Pipfile key × env precedence on 2026.8: done, pass.) (The non-boolean PIPENV_VENV_IN_PROJECT × key question: done 2026-10-05 21:44Z, pass; socket-patch scans both venvs.)
   6e. Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 (rollback removing directories apply created) for a pypi agent patch that adds a file in a new directory.

10. 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: branch deletion fails through the git proxy, and as of 2026-10-05 21:44Z it is also refused by the session's permission policy.

Known non-bugs

• pipenv install / install --deploy on a pylock-only Pipenv 2026 project relocks and drops the reference (documented relock behaviour). Pipenv 2026.0–2026.2.x sync refuses a pylock-only project (Pipfile.lock not found), so that's not silent. Only 2026.4+ sync is Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912.

• Hosted scan from a monorepo root ignores services/*/Pipfile.lock: documented CLI scope (<cwd>/Pipfile.lock only, use --cwd).

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

• A vendored in-run or standalone VEX attests from the committed artifact even when a warm venv still holds the upstream bytes; it only warns vendored_tree_out_of_sync (CLI_CONTRACT, vendored evidence row). The pypi_pipenv_stale_install event beside it gives the Pipenv remedy.

• Correction: in the 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 shape (.venv + WORKON + PIPENV_VENV_IN_PROJECT=0, Pipenv ≤ 2023.10), hosted vex is NOT conservative. With the WORKON venv patched it attests a false not_affected (the 10-03 note was wrong). That's 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.

• After a stale-install remedy has removed a package (Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 shape), vex attests not_affected from the lock wiring. The package is absent, so this isn't a false attestation of unpatched bytes.

• pipenv install --system --deploy over a warm interpreter that already holds the upstream release: the hosted / vendored scan gives no stale-install warning (hosted deliberately skips global interpreters, see the stale_install_warnings comment in scan/hosted/python.rs), and the next --system --deploy keeps the upstream bytes. Hosted vex refuses (not_applied); vendored vex attests with vendored_tree_out_of_sync (documented). A fresh Docker build is unaffected. This is a maintainer question, not filed.

• pipenv install <other> on Pipenv before 2024 is a full relock and drops the reference (pipenv-compatibility.md:51). vex refuses afterwards (correct).

• A symlinked Pipfile.lock is refused in hosted (redirect_symlinked_file_unsupported) and vendored (pypi_pipenv_symlink_unsupported) mode, and nothing is written. Fail-closed by design.

• pipenv --site-packages false VEX: not Pipenv-specific; tracked in In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (pm:pip), with Pipenv evidence in a comment there. Don't re-file it.

• Mock-API notes: the blob route must return the content for the requested hash (before or after), or agent rollback fails with a hash mismatch; get CVE-… needs a /patches/by-cve/ route.

• (Superseded by Fix Pipenv venv discovery settings view (#645, #546) #654, which now joins it to the project and passes with --cwd from the parent; kept for history.) A relative WORKON_HOME (e.g. .venvs) is resolved against socket-patch's process cwd, as Python does, not against --cwd. So scan --cwd app run from the parent misses app/.venvs/…, while running inside app/ passes. Not filed: the env var means whatever the reading process's cwd makes it, and Pipenv run from a subdirectory would differ too. The system-Python write that follows is 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.

• Harness note: scan's batch purls include Pipfile.lock entries, so they can't show which venv was found. Use an apply-based oracle (local manifest + blobs, then check which copies are patched). Agent rollback needs the before blob locally, and it deletes .socket/blobs and the manifest entry.

[github-actions[bot]]

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

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

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

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

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

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

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

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

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

[github-actions[bot]]

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

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

Re-triage

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

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

Cells (Linux)

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

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

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

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Regression check of the new main

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage (closed fixes, verified on main)

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

Cells (Linux)

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

Issues

• Filed: Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504.
• Commented: scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 (the fix is incomplete in human mode).

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

• Main hasn't changed since the last run, so Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 and get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 stand. Nothing new, so no comments.

Cells (Linux)

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

Issues

• Filed: Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

• Main is unchanged, so Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 / Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 / get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 stand. Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 is claimed, with open PR Fix PyPI agent apply patching only one installed copy (#529, #501) #538. Nothing new, so no comments.

Cells (Linux)

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

Issues

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

False positives ruled out

• Hosted vex "no hosted references found": a mock artifact (the URL lacked the uuid path, and SOCKET_PATCH_SERVER_URL wasn't set).
• Hosted vex with no venv at all omits six as not_applied, because it checks the system copy (the Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 fallback). Fail-closed, so not a false attestation.
• scan -g --mode hosted --json prints a plain-text usage error with exit 2 (a clap-level refusal, documented).

Next

1. Re-verify Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 (PR Fix PyPI agent apply patching only one installed copy (#529, #501) #538) and Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 once they merge, on 2018 / 2022 / 2023 / 2026.
2. Re-verify Pipenv venv discovery ignores the project's .env, so a PIPENV_CUSTOM_VENV_NAME or WORKON_HOME set there leaves the Pipenv venv unpatched, patches the system Python instead, and VEX attests not_affected #546 once fixed: .env with PIPENV_CUSTOM_VENV_NAME, WORKON_HOME, PIPENV_VENV_IN_PROJECT=0 (+ .venv), PIPENV_IGNORE_VIRTUALENVS (+ VIRTUAL_ENV) and PIPENV_DONT_LOAD_ENV=1 exported (which must disable it).
3. A macOS / Windows probe (blocked on branch deletion).
4. --global-prefix given as an interpreter / venv root (what does pypi accept?), and -g on 2018 / 11.
5. Pipenv 2024.4.1 / 2025.1.3: the Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 .venv + WORKON shape and PIPENV_PYTHON suffix venvs.

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

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; 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, with a rebuilt local Python mock (batch / by-package / view / blob / package grant / hosted wheel, plus a /pypi/ JSON forwarder) serving a patched real six 1.16.0 wheel. PR #654 head d8356ae was also built, for re-verification.

Re-triage

Main hasn't moved, and PR #654 (#645 + #546) is still open and blocked on human review. #612 / #567 / #504 / #453 / #725 weren't re-run, since their code is unchanged.

Cells (Linux)

• scan --mode hosted --vex (in-run VEX) with a stale out-of-tree venv, 2018 / 2022 / 2026: redirect_pypi_stale_install fires, VEX leaves the patch out (vex_omitted stale_install), and the run exits 1 with no_applicable_patches. The same holds with --vex-no-verify. After the printed remedy (pipenv run pip uninstall -y six && pipenv sync), a re-scan with --vex attests not_affected. Pass.
• scan --mode vendored --vex with a warm unpatched venv (2026): pypi_pipenv_stale_install fires, yet the in-run VEX attests not_affected with a vendored_tree_out_of_sync warning. This is documented (CLI_CONTRACT, vendored evidence row: the committed artifact is the evidence). Its remedy text, "re-run your package manager's install", doesn't work for Pipenv, but the stale event beside it gives the right one. Recorded under known non-bugs.
• 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 + VEX (2018 / 2022, .venv + WORKON venv, PIPENV_VENV_IN_PROJECT=0, WORKON reinstalled patched, 2/2): in-run and standalone vex both attest a false not_affected while pipenv run loads the unpatched .venv. The 10-03 09:37Z entry's "vex is conservative (not_applied)" was wrong. PR Fix Pipenv venv discovery settings view (#645, #546) #654 fixes it (stale warning for .venv, nothing attested). Fail, 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.
• --dry-run (2018 / 2026 locks): hosted / vendored / agent scan and hosted / vendored get write nothing, and no venv files change. Pass. But hosted scan --dry-run --vex --json leaves out the documented vex: {skipped, reason: dry_run} marker, while vendored and agent emit it. Fail, filed scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744 (also reproduces on a plain requirements.txt project).
• Vendored remove pkg:pypi/six@1.16.0 (2026): vendor_reverted, the lock is byte-exact and .socket/ is gone. Pass. list on a vendored project: pass.
• Wiring drift for vendor --check (backlog 6): with the entry moved to develop, check and vex both pass (correct). With the file ref pointing at another uuid dir, whether it exists or not, check stays green while vex refuses. The missing-dir case makes pipenv install --deploy fail. Fail, 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; I commented there.
• Different six versions in [packages] / [dev-packages] on 2018: Pipenv unifies them to one version at lock time, so the shape can't happen.
• macOS / Windows: not attempted. Branch deletion through the git proxy is still the blocker.

Issues

• Filed scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744: scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744 (hosted dry-run JSON is missing the vex marker; low impact, cross-ecosystem).
• 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 (hosted false VEX, PR Fix Pipenv venv discovery settings view (#645, #546) #654 verified): 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)
• Commented on 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 (uuid-drift shapes): 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 (comment)

False positives ruled out

• Vendored in-run VEX attesting over a stale venv: documented (see above).
• The GitHub MCP issue search returns partial results; I de-duplicated against a full REST issue listing.

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 (agent, hosted warning, hosted VEX, .env shapes, 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 / scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744 once main moves.
3. -g on Pipenv 11.
4. Hosted with mixed sources (a mirror named pypi plus pypi.org under another name, on a transitive entry with no index): rollback restore source.
5. vendor --vex / apply --vex dry-run markers, and scan --vex on 2023.12.1 / 2024.4.1.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; 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, with a rebuilt Python mock that now serves two patch records for six 1.16.0 (uuid A / B, appending SOCKET_PATCHED = 'A' / 'B'). A state file switches which record discovery offers.

Re-triage

Main hasn't moved since the last run, and PR #654 (#645 + #546) is still open, so I re-ran nothing. PR #730 (fix for #725) is open.

Cells (Linux): superseding patch (new this run, prompted by #765 / #742)

• Hosted re-pin A → B (2026.8.0): re-scan rewrites the file ref + hash to B, updates[] names A → B, and redirect_pypi_stale_install fires for the warm venv. After the printed remedy, pipenv sync installs B. Vex and rollback work; rollback restores the registry entry semantically (my mock's JSON forwarder lists only the wheel hash, so it isn't byte-exact here, a mock artifact). Pass.
• Vendored re-vendor A → B (2018 / 2022 / 2023 / 2026, 2/2 each): --dry-run previews would_revendor (oldUuid A). The wet scan --mode vendored and get <B> --mode vendored exit 1. With the venv present the event is skipped package_not_installed "no installed package found on disk" (false: six is installed, at patch A). In a lock-only checkout it's failed pypi_pipenv_source_already_exists. Nothing changes, so the lock, .socket/ and the ledger stay on A. Fail, filed Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769. Workaround verified: vendor --revert → re-scan wires B, and pipenv sync gives B.
• Control: a vendored re-scan with A still offered gives already_vendored. Pass.

Issues

• Filed Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769: Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 (the Pipenv lane of Vendored requirements.txt never picks up a superseding patch: the re-vendor to a new uuid fails with pypi_requirements_already_vendored (exit 1), though --dry-run previews would_revendor and the contract says it re-vendors automatically #765; PR Fix vendored requirements.txt re-vendor to a superseding patch (#765) #766 names Pipenv as an unfiled follow-up).

False positives ruled out

• Hosted rollback not byte-exact in this run: my mock's /pypi/six/json lists only the wheel, so the upstream restore re-derives one hash. That's a mock artifact (real PyPI gives both hashes; earlier runs were byte-exact).

Next

1. Re-verify Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 once a Pipenv re-vendor fix lands (rewire in place, vendor_stale_artifact_removed, revert byte-exact back to the registry original, and a venv-present run must not say package_not_installed).
2. Hosted supersede on 2018 / 2022 / 2023 and on a develop / named-category entry, plus a superseding patch while vendored with a sibling requirements.txt (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 shape).
3. 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, and 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 Fix vendor --check passing unwired vendored entries (#725) #730 merges.
4. -g on Pipenv 11, and mixed-sources hosted rollback (backlog 6b).
5. vendor --vex / apply --vex dry-run markers.

[github-actions[bot]]

[agent] 2026-10-04 15:30Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged; 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, with a rebuilt Python mock (batch / by-package / view / blob / package grant / hosted wheel / /artifacts/ / /pypi/ JSON forwarder) serving two patched six 1.16.0 records (uuid A / B). Native locks for default, develop and [docs] (2022+) projects.

Re-triage

Main hasn't moved and PRs #654 / #730 are still open, so I re-ran nothing. Probe-branch deletion through the git proxy still fails ("unexpected disconnect"), so there were no macOS / Windows probes. bughunt/pipenv/20260930-venv-discovery and -virtualenv still need a maintainer to delete them.

Cells (Linux)

• Stale-install remedy, followed verbatim (warm venv with upstream six → scan → printed remedy pipenv run pip uninstall -y six && pipenv sync, and pipenv --rm && pipenv sync), hosted + vendored, 2/2 remedies each:
  • default on 2018 / 2022 / 2023 / 2026: patched. Pass.
  • develop on 2018 / 2022 / 2023 / 2026 and [docs] on 2022 / 2023 / 2026: six ends up uninstalled (ModuleNotFoundError), and vex still attests not_affected. Fail, filed Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790. pipenv sync --dev / --categories docs gives the patched wheel (control).
• Hosted supersede A → B: 2018 default + develop, 2022 develop + docs, 2023 default + docs, 2026 docs. The re-pin, the updates[] A → B entry and redirect_pypi_stale_install are all correct, and vex refuses (no_applicable_patches) while the venv holds A. Pass.
• Rollback / remove after a supersede (2018 develop, 2022 / 2023 / 2026 docs, 2026 develop): byte-exact to the original lock. Pass.
• Hosted supersede with a sibling pipenv requirements file (2026): both files are re-pinned to B and uv pip install -r gives B. Pass. The rollback refusal there 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 (known).

Issues

• Filed Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790: Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790

False positives ruled out

• vex not_affected after the remedy removed six: the package is absent, so this isn't a false attestation of an unpatched install. It's noted in Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 as the reason nobody notices.
• vex rc 2 on a bare Pipfile without --product: documented (product_undetected).

Next

1. Re-verify Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 once fixed (develop, named categories, a package in both default and develop, and the pre-2018 install --deploy --dev wording).
2. 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, 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 Fix vendor --check passing unwired vendored entries (#725) #730 merges, and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769.
3. Mixed sources hosted rollback (backlog 6b), and -g on Pipenv 11.
4. vendor --vex / apply --vex dry-run markers.
5. macOS / Windows probes, once branch deletion works.

[github-actions[bot]]

[agent] 2026-10-04 21:42Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged; latest release 4.0.0), plus the PR #795 head fbdfa6f. I used real Pipenv 2018.11.26 (py3.8), 2022.12.19, 2023.12.1 and 2026.8.0 (py3.11) on Linux, with a rebuilt Python mock (batch / by-package / package grant / view / blob / hosted wheel / /pypi/ JSON) serving a patched six 1.16.0.

Re-triage

• Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 → PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 (draft, opened since the last run). I followed every remedy it prints verbatim against a warm upstream venv, 2/2 runs per cell. Commented the table on Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790: Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (comment)
  • develop, hosted on 2018 / 2022 / 2023 / 2026 and vendored on 2018: pipenv sync --dev, both remedies patched. Pass.
  • [docs], hosted on 2022 / 2023 / 2026 and vendored on 2022 / 2026: --categories "docs" / "packages docs", both patched. Pass.
  • [Doc-Tools] (mixed case, hyphen), six in develop + docs (--categories "dev-packages docs"), and six in default with all three categories populated, on 2023 / 2026: both remedies patched. Pass.
  • Main control (develop, 2026): six is still uninstalled, so Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 still reproduces on main.
• 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 (PR Fix vendor --check passing unwired vendored entries (#725) #730), 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 (PR Fix Pipenv venv discovery settings view (#645, #546) #654) and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769: main unchanged, so I re-ran nothing.

Cells (Linux, main 045d7ec)

• vendor --dry-run --vex / apply --dry-run --vex / agent scan --dry-run --vex: no VEX file written; only scan --json carries the dry_run marker, which is the documented scope. Pass (backlog 6, the dry-run part).
• CRLF Pipfile.lock (and Pipfile), 2018.11.26 / 2026.8.0:
  • Vendored: CRLF kept, install --deploy patched, vex not_affected, rollback byte-exact. Pass.
  • Hosted: CRLF kept, install --deploy patched, vex not_affected. Rollback differs only by the sdist hash, because my mock's PyPI JSON lists only the wheel (a mock artifact, not a bug).
• pipenv install <other> on 2022.12.19 / 2023.12.1, hosted + vendored: the full relock drops the reference and the venv is unpatched. vex refuses (hosted: nothing to attest; vendored: vendor_unwired). Documented in pipenv-compatibility.md:51. Pass (backlog 6).
• pipenv install --system --deploy over a warm interpreter that already holds upstream six (2022 / 2026, hosted + vendored): the scan emits no stale-install warning, the next --system --deploy keeps the upstream bytes, hosted vex refuses (not_applied), and vendored vex attests with vendored_tree_out_of_sync. Hosted skips global interpreters by design (hosted/python.rs stale_install_warnings comment: avoid false warnings from unrelated Pythons), and the vendored warning is documented. Not filed; added to Known non-bugs as a maintainer question. A fresh Docker build is unaffected.

Issues

• Commented on Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 verified on real Pipenv). Nothing filed and nothing closed.

False positives ruled out

• Hosted CRLF rollback "not byte-exact": the mock's PyPI JSON lacks the sdist (a mock artifact).
• No stale warning for --system installs: deliberate (see above).

Blocked

• macOS / Windows probes: git push --delete through the git proxy still fails ("unexpected disconnect"), re-checked 21:40Z. bughunt/pipenv/20260930-venv-discovery and -virtualenv still need a maintainer to delete them.

Next

1. Re-verify Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 on main once Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 merges (same cells as the table above).
2. 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, 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 Fix vendor --check passing unwired vendored entries (#725) #730 merges, and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769.
3. Mixed sources hosted rollback (backlog 6b), and -g on Pipenv 11.
4. Windows quoting of --categories "…" (cmd / PowerShell), once probes work.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since the last run; latest release 4.0.0). Linux only. I used real Pipenv 2018.11.26, 2020.11.15 and 2021.5.29 (py3.8), plus 2023.12.1 and 2026.8.0 (py3.11), against a rebuilt Python mock (batch / by-package / by-cve / grant / view / hash-addressed blob / hosted wheel / /pypi/ JSON forwarder) serving a patched six 1.16.0.

Re-triage

• Main hasn't moved, and PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 (Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790), Fix Pipenv venv discovery settings view (#645, #546) #654 (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) and Fix vendor --check passing unwired vendored entries (#725) #730 (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) are still open, so I re-ran nothing. No human replies on the discussion.

Cells (Linux, 045d7ec)

• Pipenv 2020.11.15 and 2021.5.29 (rows that were never tested before):
  • Hosted lock-only: install --deploy / sync PATCHED, vex not_affected, rollback byte-exact. Pass.
  • Vendored lock-only: same results. A tampered committed wheel is rejected by Pipenv's hash check and vendor --check exits 1. Pass.
  • Agent over a warm venv: patched; rollback restores upstream. Pass.
  • Hosted over a warm venv: the stale warning fires, a plain sync keeps upstream (documented), both printed remedies give PATCHED, and vex refuses before the remedy and attests after it. Pass.
  • get CVE-… --mode hosted|vendored (2021): wired, --deploy PATCHED, the re-run is idempotent, and remove <purl> is byte-exact. Pass.
• Backlog 6b, mixed sources (a mirror named pypi first, pypi.org named upstream), hosted rollback on 2026:
  • Index-less entry: restored byte-exact. Pass.
  • Entry with index = "pypi" (the mirror): refused fail-closed with the git checkout remedy. Documented.
• Symlinked Pipfile + Pipfile.lock (shared-lock monorepo): hosted refuses with redirect_symlinked_file_unsupported and vendored with pypi_pipenv_symlink_unsupported; nothing is written. Pass (fail-closed by design).
• .venv symlinked to an out-of-tree directory, with PIPENV_VENV_IN_PROJECT=1 and unset (2026): agent patch + rollback and the hosted stale warning all pass.
• Venv drift (the venv holds six 1.15.0, the lock pins 1.16.0), hosted + vendored on 2026: rewired from the lock, sync PATCHED, vex not_affected. Pass.
• Pipenv project with a pdm-backend pyproject.toml ([tool.pdm.version]), agent + hosted on 2026: Pipenv's WORKON venv is still chosen. Pass.
• 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 shape on 2020.11.15 / 2021.5.29 (.venv only, PIPENV_VENV_IN_PROJECT=0): pipenv --venv is .venv, so Pipenv reads "0" as truthy. Agent skips .venv, falls back to the global interpreter and patched the sandbox's /usr/lib/python3/dist-packages/six.py, and vex attests not_affected. Fail, already covered by 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 (its "no WORKON venv" row). 2020 / 2021 sit inside the range 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 already states, so I didn't comment. The system six was restored byte-identical with rollback.
• list / list --json on hosted projects (default and named-category entries): pass.
• pipenv --site-packages / PIPENV_SITE_PACKAGES=1 with six in the base interpreter: fail, already covered by In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (pm:pip). Even a fresh venv created after the rewrite keeps the base's unpatched six (install --deploy sees it as satisfied). No stale warning fires, and vex attests not_affected. That's hosted on 2018 / 2022 / 2023 / 2026 and vendored on 2018 / 2026, 2/2 runs each. Agent mode says No patches selected and vex refuses (correct). The control without --site-packages is patched. Commented on In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409: In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (comment)

Issues

• Commented on In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (Pipenv --site-packages evidence). Nothing filed and nothing closed.

False positives ruled out

• Agent rollback "fails" with a blob hash mismatch, and get CVE-… "finds no patches": both were gaps in my mock (the blob endpoint ignored the hash; there was no by-cve route). Both pass once the mock is fixed.

Blocked

• macOS / Windows probes: git push --delete still fails ("unexpected disconnect while reading sideband packet"), re-checked 03:30Z. bughunt/pipenv/20260930-venv-discovery and -virtualenv still need a maintainer to delete them.

Next

1. Re-verify Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 once PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 merges, 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, 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 Fix vendor --check passing unwired vendored entries (#725) #730 merges, and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769.
2. Once In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 is fixed: re-run the Pipenv --site-packages cells (fresh + warm, hosted + vendored, 2018–2026).
3. Pipenv 2020 / 2021 with a [dev-packages] entry and the Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 remedy (and add them to the 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 re-verification once Fix Pipenv venv discovery settings view (#645, #546) #654 merges).
4. A relative WORKON_HOME with --cwd run from another directory (Pipenv resolves it against its own cwd).
5. Windows quoting of --categories "…", once probes work.

[github-actions[bot]]

[agent] 2026-10-05 09:32Z: Pipenv bug-hunt run

Tested: main 045d7ec (unchanged since the last run; latest release 4.0.0), plus the PR #654 head d8356ae. Linux only. I used real Pipenv 2018.11.26 (py3.8), and 2023.12.1, 2025.1.3, 2026.1.0, 2026.2.0 (source read) and 2026.8.0 (py3.11), against a rebuilt local agent-mode mock (batch / by-package / view / hash-addressed blob) serving a six 1.16.0 patch.

Re-triage

• Main hasn't moved, and none of PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795 (Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790), Fix Pipenv venv discovery settings view (#645, #546) #654 (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), Fix vendor --check passing unwired vendored entries (#725) #730 (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) or Fix vendored Pipenv re-vendor to a newer patch (#769) #825 (Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769) has merged, so I re-ran nothing. No human replies on the discussion.

Cells (Linux, 045d7ec)

• Pipfile [pipenv] venv_in_project = true, no ./.venv (new cell). Only Pipenv 2026.2.0+ read this key (source checked on 2025.1.3, 2026.1.0, 2026.2.0 and 2026.8.0). Older releases create $WORKON_HOME/<name>-<hash>, but socket-patch treats the key as authoritative and finds no venv. The agent scan then patches the system Python's six.py, pipenv run keeps the unpatched bytes, and vex attests not_affected.
  • Fail on 2018.11.26, 2023.12.1 (also with = "yes"), 2025.1.3 and 2026.1.0, 2/2 runs each. Pass on 2026.8.0 (./.venv).
  • Control without the key on 2025.1.3: pass.
  • PR Fix Pipenv venv discovery settings view (#645, #546) #654 d8356ae still fails, because it only fixes the = false direction.
  • Filed Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842. The system six was restored byte-identical with rollback after each run.
• Relative WORKON_HOME (.venvs) with --cwd app run from the parent (backlog 6c, 2026.8.0): socket-patch resolves the relative path against its own process cwd, the way Python does, so it misses app/.venvs/app-… and falls back to the system Python (patched, venv UNPATCHED). Run from inside app/: pass. Not filed. The env var is relative to whichever process reads it, so the expected answer is ambiguous, and the harmful half (the system write) is 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. Recorded under Known non-bugs.

Issues

• Filed Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842: Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842
• Nothing commented on and nothing closed.

False positives ruled out

• None this run.

Blocked

• macOS / Windows probes: branch deletion through the git proxy is still broken (see the earlier entries), so I didn't push a probe.

Next

1. Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 hosted shape: a warm WORKON_HOME venv + venv_in_project = true on Pipenv ≤ 2026.1. The stale-install warning goes through the same discovery, so it's probably missed too; verify with a hosted mock.
2. Re-verify Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795), 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 (PR Fix Pipenv venv discovery settings view (#645, #546) #654), 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 (PR Fix vendor --check passing unwired vendored entries (#725) #730) and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 (PR Fix vendored Pipenv re-vendor to a newer patch (#769) #825) once they merge, and Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 once it's fixed.
3. Pipenv 2020 / 2021 with a [dev-packages] entry and the Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 remedy.
4. Pipfile venv_in_project × PIPENV_VENV_IN_PROJECT precedence on 2026.2+ (the env var wins), and the .env form once PR Fix Pipenv venv discovery settings view (#645, #546) #654 lands.
5. Windows quoting of --categories "…", once probes work.

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger was last updated on main 045d7ec, before the 2026-10-05 11:13–13:20Z merge wave. It still cites these issues as fail, but they are now closed as completed:

• Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (fixed by PR Fix Pipenv stale-install remedy ignoring lock categories (#790) #795)

Please re-verify those cells on main 6811b4e7.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05 19:15Z: Pipenv bug-hunt run

Tested: main 0d302dc (CLI 4.0.0; latest release 4.0.0). Main's history was rewritten since the last run, so 045d7ec / d63ae5f / 61cfb9b in older entries no longer resolve. #795 (#790) has merged. Linux only. I used real Pipenv 2018.11.26 and 2020.11.15 (py3.8), plus 2023.12.1, 2026.1.0 and 2026.8.0 (py3.11), against a local Python mock patch API (batch / by-package / package grant / view / hash-addressed blob / hosted wheel) serving a six 1.16.0 patch.

Re-triage

• Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (closed by Fix Pipenv stale-install remedy ignoring lock categories (#790) #795): re-verified on main. With six in [dev-packages] and a warm WORKON venv, the hosted remedy now reads pipenv sync --dev, and following it verbatim gives the patched six on 2018.11.26, 2020.11.15 (both remedies) and 2026.8.0. vex afterwards attests not_affected, exit 0. Commented with the table.
• Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842: still open, unfixed; see the new hosted cell below.
• PRs Fix Pipenv venv discovery settings view (#645, #546) #654 (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), Fix vendor --check passing unwired vendored entries (#725) #730 (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) and Fix vendored Pipenv re-vendor to a newer patch (#769) #825 (Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769) are still open. No human replies on the discussion.

Cells (Linux, 0d302dc)

• Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 hosted shape (backlog 6d): Pipfile venv_in_project = true, warm WORKON venv, scan --mode hosted. Fail on 2018.11.26, 2023.12.1 and 2026.1.0, 2/2 runs each: the lock is redirected but there is no pypi_pipenv_stale_install warning (exit 0), and the venv keeps upstream six. Pass on 2026.8.0 (./.venv, warning printed) and on the key-less control (2023.12.1). Hosted vex stays conservative: file_not_found with no system six, not_applied with the distro's six. Commented on Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 rather than filing (same root cause).
• Pipfile key × PIPENV_VENV_IN_PROJECT precedence on 2026.8.0, agent mode (backlog 4): key true + env 0 → WORKON venv patched (pass); key false + ./.venv + env 1 → ./.venv patched (pass); key "false" (a string, which Python's bool() reads as true) → ./.venv patched (pass). The system six was untouched in every case.
• Pipenv 2020.11.15 [dev-packages] remedy (backlog 6c): pass (see Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790).

Issues

• Commented on Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790: Pipenv stale-install remedy always says pipenv sync, so for a [dev-packages] or named-category entry following it uninstalls the package instead of reinstalling it patched #790 (comment)
• Commented on Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842: Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 (comment)
• Nothing new filed, nothing closed.

False positives ruled out

• My first 2023.12.1 hosted vex gave not_applied. That came from the distro's unpatched /usr/lib/python3/dist-packages/six.py, not from the WORKON venv. With the system six moved aside it gives file_not_found. Sandbox note: the container's system Python ships six 1.16.0, so check which copy a vex verdict is about.
• Pipenv 2020.11.15's first lock failed (LegacySpecifier import error from the venv's new setuptools). That's a sandbox tooling artifact; pipenv run pip install "setuptools<60" fixes it.

Blocked

• macOS / Windows probes: branch deletion through the git proxy still fails (unexpected disconnect while reading sideband packet on git push --delete, 19:0xZ). The two bughunt/pipenv/20260930-* branches still exist, so I pushed no probe.

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 (PR Fix Pipenv venv discovery settings view (#645, #546) #654), 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 (PR Fix vendor --check passing unwired vendored entries (#725) #730) and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 (PR Fix vendored Pipenv re-vendor to a newer patch (#769) #825) once they merge, and Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 (agent + hosted stale warning) once it's fixed.
2. A non-boolean PIPENV_VENV_IN_PROJECT (e.g. enabled) + Pipfile venv_in_project = false on 2026.2+: Pipenv falls through to the Pipfile (WORKON), while socket-patch treats the env var as "yes" (.venv only). Exotic; verify with real Pipenv before deciding whether it matters.
3. The #838 rollback-created-directories fix, for a pypi agent patch that adds a new file in a new directory (needs a mock patch with a new file).
4. Windows --categories "…" quoting and the macOS / Windows probe list (backlog 7), once probes work.

[github-actions[bot]]

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

Tested: main 9c43dfc (CLI 4.0.0; latest release v4.0.0). New since the last run: #654 (Pipenv .env / .venv discovery, #645 + #546) and #730 (vendor --check wiring, #725). Linux only, with real Pipenv 2018.11.26 (py3.8), 2023.10.24, 2023.12.1, 2026.1.0 and 2026.8.0 (py3.11).

Method change: agent cells used an offline socket-patch apply from a local .socket/manifest.json + blobs (a real six 1.16.0 six.py plus a patched copy), then checked which six.py copies were patched. Vendored cells used the repo's prebuilt_common fixture server through a throwaway test file, which I deleted afterwards. Batch-purl discovery checks are NOT a valid oracle: scan also reads Pipfile.lock purls, so a lock-only purl looks like a found venv. Ignore my first round of purl-only cells.

Re-triage

• 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 (closed by Fix Pipenv venv discovery settings view (#645, #546) #654): fixed. .venv + WORKON + PIPENV_VENV_IN_PROJECT=0 / PIPENV_NO_VENV_IN_PROJECT=1 on 2018.11.26 / 2023.10.24 / 2023.12.1 / 2026.8.0: both venvs patched, system untouched. Agent vex with either copy stale gives not_applied, exit 1. Commented: 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)
• 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 (closed by Fix Pipenv venv discovery settings view (#645, #546) #654): fixed on 2023.12.1 / 2026.8.0 across 12 .env shapes, plus 2018.11.26 (whose Pipenv ignores .env placement). Commented: 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 (comment)
• 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 (closed by Fix vendor --check passing unwired vendored entries (#725) #730): fixed. A real pipenv lock after vendoring makes vendor --check exit 1 on 2026.8.0 and 2018.11.26, and the uuid-drift shape fails too. Commented: 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 (comment)
• Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842: still fails. With Pipfile venv_in_project = true, no ./.venv and a WORKON venv, apply on 2023.12.1 leaves the WORKON venv unpatched and patches the system six; 2026.8.0 (./.venv) passes. No new information, so no comment.

Cells (Linux, 9c43dfc)

• .env shapes, agent apply (2023.12.1 / 2026.8.0): plain, CRLF, export, quoted + comment, ${VAR} interpolation, .env overriding an exported WORKON_HOME, PIPENV_CUSTOM_VENV_NAME, PIPENV_DOTENV_LOCATION, PIPENV_VENV_IN_PROJECT=1, relative WORKON_HOME=.venvs (also --cwd from the parent), BOM .env, PIPENV_DONT_LOAD_ENV=1: all pass. 2018.11.26 plain / in-project .env: pass.
• Agent vex over the .env venvs (WORKON / custom / relative): not_affected when patched, not_applied after a reinstall: pass.
• Non-boolean PIPENV_VENV_IN_PROJECT (enabled, yes, 0) × Pipfile key true / false on 2026.8.0, with ./.venv and WORKON both present: socket-patch scans both, so the venv Pipenv uses is always covered: pass (backlog 6d's open question closed). This was a purl-level check, but both venvs held distinct six versions and both purls appeared.
• vendor --check after pipenv lock (2018 / 2026): pass (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).

Issues

Nothing new filed, nothing closed (all three re-verified issues were already closed by their PRs). Three verification comments, linked above.

False positives ruled out

• Purl-only discovery "passes" and "Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 fixed on 2023.12.1": scan also reports Pipfile.lock purls, so they proved nothing. The apply-based oracle shows Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 still fails.
• Agent rollback in my harness "succeeded" but left files patched, because there was no before-blob locally (the known blob-route mock gap). Rollback also deletes .socket/blobs and the manifest entry (documented), so a later apply fails with "Failed to read blob". Both are harness artifacts.

Blocked

• macOS / Windows probes: git push --delete is now refused by this session's permission policy (not only by the git proxy). No probe pushed; the two bughunt/pipenv/20260930-* branches still need a maintainer to delete them.

Next

1. Hosted cells for 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 on the new main: the stale-install warning and hosted vex with .env-placed venvs and the .venv + WORKON + IN_PROJECT=0 shape (needs the hosted mock).
2. Re-verify Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842 (agent + hosted warning) and Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 (PR Fix vendored Pipenv re-vendor to a newer patch (#769) #825) once they're fixed.
3. Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 rollback of directories that apply created, for a pypi agent patch that adds a new file in a new directory.
4. .env with VIRTUAL_ENV / PIPENV_ACTIVE set inside it, and PIPENV_DOTENV_LOCATION given as an absolute path or relative to a --cwd run from elsewhere (Pipenv resolves it against the process cwd).

[github-actions[bot]]

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

Tested: main 9c43dfc (CLI 4.0.0; latest release v4.0.0), the same commit as the last run, so there is nothing new to re-triage. Linux only, with real Pipenv 2024.4.1, 2025.0.4, 2025.1.3, 2026.0.0, 2026.1.0, 2026.2.0, 2026.2.2, 2026.4.0, 2026.6.0, 2026.7.1 and 2026.8.0 (py3.11), against a local Python mock patch API (batch / by-package / grant / view / blob / hosted wheel) serving a patched six 1.16.0 wheel.

Re-triage

• Main is unchanged (9c43dfc), so Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842, Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769, scan --mode hosted --dry-run --vex <path> --json drops the documented vex: {skipped: true, reason: "dry_run"} marker (agent and vendored scans emit it) #744, 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 and get <uuid> overrides socket.yml without the documented policy_bypassed warning (purl/CVE/GHSA forms do warn) #453 can't have moved. Nothing to comment or close.

Cells (Linux, 9c43dfc)

• New: Pipenv 2026 pylock.toml ([pipenv] use_pylock = true)
  • Pipfile.lock + pylock.toml both present, hosted on 2026.8.0: both files rewritten; sync / install --deploy / verify / requirements all give PATCHED (pass).
  • pylock-only (no Pipfile.lock), hosted: the scan rewrites pylock.toml to an archive entry and reports success with no warning. Then pipenv sync installs the upstream six on 2026.4.0 / 2026.6.0 / 2026.7.1 / 2026.8.0, exit 0 (fail, Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912). On 2026.0.0–2026.2.2, sync fails loudly with Pipfile.lock not found; 2025.x has no pylock support. Hosted vex refuses (no_applicable_patches, correct).
  • pylock-only, vendored on 2026.8.0: archive = { path = … }, pipenv sync gives upstream, and vex attests not_affected (fail, Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912, 2/2).
  • Root cause: Pipenv's PylockFile.convert_to_pipenv_lockfile reads only wheels / sdist hashes and ignores archive.
• Hosted stale warning with WORKON_HOME set in .env (2026.8.0): the warning names the .env-placed venv (pass; backlog 2, partly).
• Hosted stale warning + verbatim remedy + vex on 2024.4.1: PATCHED, not_affected (pass).
• pipenv upgrade idna on 2026.8.0 keeps the hosted six reference, and install --deploy gives PATCHED (pass).
• Pipfile.lock mode 0640 is kept across the hosted rewrite after the Write every utils::fs atomic file through one stage-and-rename core (#728) #858 atomic-write refactor (pass).
• Hosted scan from a monorepo root with services/api/Pipfile.lock: nothing rewritten (documented CLI scope: <cwd>/Pipfile.lock only).

Issues

• Filed Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912: Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912
• Nothing commented on or closed.

False positives ruled out

• My first 2026.0.0 / 2026.1.0 runs showed "six ABSENT, vex not_affected". pipenv sync had failed loudly there (exit 1, Pipfile.lock not found), and the script had hidden it. That's not a silent failure.
• pipenv install / install --deploy on a pylock-only project relocks (Pipenv writes a new Pipfile.lock and pylock.toml) and drops the reference. That's the documented relock behaviour.
• Hosted rollback in the sandbox failed with a pypi.org fetch error: the known rustls vs proxy-CA artifact.

Blocked

• macOS / Windows probes: git push --delete is still refused by the session's permission policy, so I pushed no probe. The two bughunt/pipenv/20260930-* branches still need a maintainer to delete them.

Next

1. Hosted and vendored scans rewrite a Pipenv project's pylock.toml to an archive entry that Pipenv 2026.4+ ignores, so pipenv sync silently installs the unpatched release from PyPI #912 variants: pylock.<name>.toml ([pipenv] pylock_name), [dev-packages] in pylock (Pipenv's dev heuristic), and rollback / remove / repair on the pylock-only shape.
2. Re-verify Agent mode honours the Pipfile's [pipenv] venv_in_project = true for every Pipenv, but only 2026.2+ read it, so on Pipenv 2018–2026.1 the WORKON_HOME venv stays unpatched, the system Python is patched instead, and VEX attests not_affected #842, Vendored Pipenv never picks up a superseding patch: re-vendor to a new uuid fails with pypi_pipenv_source_already_exists (lock-only) or a false package_not_installed (venv present), exit 1 #769 and the other open issues once main moves.
3. Hosted .env shapes beyond WORKON_HOME (custom name, IN_PROJECT) and the 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 hosted shape on 2018 / 2022 / 2023.10.
4. .env with VIRTUAL_ENV / PIPENV_ACTIVE set inside it.