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-01 15:41Z, main 6e7ef74 (v5 + #330 Poetry venv reorder; CLI 4.0.0).

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	untested	fail #334 (venv/)	pass v5 (+CRLF)	untested	fail #333	pass v5	untested	untested	fail #384
Linux	2022.12.19	untested	untested	pass v5 (+relock)	untested	fail #333	untested	untested	untested	untested
Linux	2023.12.1	pass	fail #334	pass v5 (+relock)	pass; fail #334/#384 shapes (false VEX)	fail #333	untested	untested	untested	fail #384 (agent + hosted VEX)
Linux	2026.8.0	pass v5	fail #334 v5	pass v5 (+CRLF)	pass; fail #334/#384 shapes (false VEX)	fail #333 v5	pass v5	pass v5	fail #328 v5	fail #384 (agent + hosted VEX)
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	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)	untested	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

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 ([docs]) hosted + sync --categories / install --deploy --categories / vex / rollback: pass on 2022.12.19, 2023.12.1 and 2026.8.0; vendored: pass on 2022.12.19 and 2023.12.1 (6e7ef74). Non-registry entries (path, file URL, git): hosted refuses with redirect_pipenv_refused, vendored with pypi_pipenv_source_already_exists, vex attests nothing: pass on 2026.8.0.

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

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

Backlog

1. Maintainer request (global -g mode): Linux is covered on 2018.11.26, 2023.12.1 and 2026.8.0, and the unwritable prefix as a non-root user is done (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 / 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). Still to do: macOS and Windows (blocked: no probe), 2022.12.19 (use pipenv --python <py3.10>, not PIPENV_PYTHON), and a --global-prefix with spaces or unicode. Full checklist in the 20261001T040000Z entry.
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, and hosted / vendored on 2018 / 2022 there (CRLF on Windows).
3. Pipenv 7–11 agent mode with an out-of-tree venv (py3.8), and the PIPENV_PYTHON venv-name suffix on 11.
4. A non-normalized PIPENV_PIPFILE (./Pipfile, sub/../Pipfile, another directory): Pipenv hashes os.path.abspath, while the crawler hashes cwd.join(raw) (python_crawler.rs:990).
5. pipenv requirements / pipenv verify after a hosted redirect, on 2023.12.1 and 2026.8.0.

Known non-bugs

• Pipfile.lock with pipfile-spec < 6 (Pipenv 0–6): hosted is refused (redirect_pipenv_skipped) and vendored is refused (pypi_pipenv_spec_unsupported). Documented.
• Vendored on Pipenv 7–11 is refused (pypi_pipenv_installer_unsupported). Documented.
• A warm venv is never reinstalled by pipenv install / sync / --deploy; the stale-install warning is the designed remedy. Documented.
• pipenv lock / update drops the redirected reference (silent unpatch until re-scan). Documented.
• Pipenv 2023+ don't hash-check local wheels, so vendored carries vendor_integrity_unverified. Documented.
• The CLI doesn't walk up to a parent Pipfile or follow PIPENV_PIPFILE. Documented.
• rollback drops manifest entries, so a later apply is a no-op. Documented.
• Pipenv 2026.8.0 crashes on $VAR inside WORKON_HOME. That's Pipenv's bug.
• vendor_fetch_failed against pypi.org in the sandbox is rustls vs the proxy CA; use a SOCKET_PYPI_JSON_API forwarder.
• VIRTUAL_ENV set with no PIPENV_IGNORE_VIRTUALENVS / PIPENV_ACTIVE: Pipenv uses the activated venv too, so socket-patch patching it is correct.
• .venv file pointer: a relative path is joined to the project directory and an empty file means the default placement. Matches Pipenv 2026.8.0.
• v5 rollback on a project with no manifest, ledger or hosted pin exits 1 "Manifest not found". Documented (CLI_CONTRACT, truly-empty project).
• v5 hosted rollback refuses when the entry's index isn't PyPI, or when offline. Documented (the upstream-restore refusals).
• Vendored drops the Pipfile.lock entry's index key. Harmless for a local wheel, and rollback restores it.
• rollback <path> targets select installed copies, not hosted project directories; use --cwd. Documented, and cross-PM anyway.
• Mock-API notes: vendoring needs integrity.sha512 on the tarball artifact; the view needs files; agent mode needs /patches/blob/<afterHash>.
• Open question for maintainers (not filed): 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.

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