Bug hunt ledger: Pipenv #313

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

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