Bug hunt ledger: pip / requirements.txt

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled pip / requirements.txt bug-hunt routine (label pm:pip).

Last run: 2026-10-02 (sixth run), main 61cfb9b, latest release v4.0.0 (96df6ae). New this run: #523 (lock-only discovery misses spaced exact pins).

Coverage matrix

OS	pip / Python	agent (.venv)	agent egg-info	hosted (unhashed → fragment pin)	vendored	rollback / remove	vendored → hosted takeover	system-site venv	-r include, lock-only	PEP 440-equivalent pin (==1.16)	global -g (--user)	lock-only spaced pin (six == X)
Linux	20.3.4 / py3.8, py3.11	pass	pass (#447 fixed)	pass	pass	pass; all-hosted-pins fail #410	fail #328	fail #409	fail #412	fail #475	untested	fail #523
Linux	23.x, 24.0 / py3.11, py3.12	pass	n/a (dist-info)	pass	pass	pass; fail #410	fail #328	fail #409	fail #412	fail #475	pass (report, hosted refusal, get / rollback / vex, --global-prefix, unwritable)	fail #523 (pip 24.0)
Linux	26.0, 26.2.1 / py3.11, py3.13	pass	n/a	pass (+ uv 0.8 pip install / pip sync)	pass	pass; fail #410	fail #328	fail #409	fail #412	fail #475	untested	fail #523
macOS	20.3.4 / py3.8; 26.2.1 / py3.13	pass	pass (py3.8)	pass	pass	pass; fail #410	fail #328	fail #409	fail #412	fail #475	pass (--user)	fail #523
Windows	20.3.4 / py3.8; 26.2.1 / py3.13	pass (Scripts/ + Lib/)	pass (py3.8)	pass	pass	pass; fail #410	fail #328	fail #409	fail #412	fail #475	pass (--user, %APPDATA%\Python)	fail #523

pip 20.3.4 on py3.13 is blocked (no distutils). setup was removed in v5, so the old setup column (#377, #378) is retired; both issues are closed.

Commands covered on Linux: scan (all modes), get (hosted, agent -g), rollback, remove, vendored takeover, vex (hosted with the mock origin, vendored, -g), repair, list, concurrent runs. Also covered (2026-10-02): virtualenv layouts, pip-tools pip-compile --generate-hashes / pip-sync over a hosted file plus rollback, -c constraints with an unpinned root, pip install --target trees, --json envelopes of rollback / remove failures, and interrupted (SIGTERM / SIGKILL) hosted scans.

Backlog

1. Re-verify Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 (after Fix requirements.txt pins not matched under PEP 440 (#475) #478), Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (after Fix PyPI vendored to hosted takeover being refused (#328) #503) and Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523 as fixes land; check lock-only vex with spaced pins (vex/discover/pypi_other.rs shares exact_pin). Then lock-only discovery of six==1.16 once Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 is fixed.
2. Maintainer request (mostly done): global (-g) mode. Left: Homebrew / PEP 668 interpreters, py launcher with several interpreters, pipx venvs (Fix global scan missing pipx venvs (#415) #418), non-root unwritable prefixes on CI. Open question for the maintainer: the non--g no-venv fallback to global site-packages (see the 20261001T083942Z entry; it also makes a lock-only vex omit packages the system Python has unpatched, and it confounds lock-only tests when the system has the same version).
3. Other lock-only grammar gaps near Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523: spaced == on \ continuations, --hash before the marker, ${VAR} lines, -e / VCS lines next to a patched pin.
4. pip install --prefix trees; a .venv symlink to an out-of-tree venv.
5. 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 / 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 / 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 as fixes land.

Known non-bugs

• Hosted mode rewrites only the root requirements.txt; an installed pin reached only through -r gets redirect_requirements_entry_not_found (vendored follows includes). The lock-only discovery gap is 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.
• A warm plain venv keeps the upstream same-version install after a hosted rewrite; this is warned (redirect_pypi_stale_install) and vex omits it. The system-site-venv variant is 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.
• Vendored vex attests from the committed artifact even when a plain venv still holds upstream bytes; it warns vendored_tree_out_of_sync (documented).
• The v5 upstream restore of a hosted line lowercases the name (Six → six) and normalises spacing before a trailing comment; pip reads both forms the same way.
• Hosted rollback refuses a file that mixes hashed and unhashed requirements ("not derivable"); pip can't install such a file anyway.
• Vendored refuses === pins, ==X.* wildcards and a tab before --hash (pypi_requirement_not_pinned). This is fail-closed and isn't filed (the ==1.16 zero-padding case is part of Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475).
• --vendor-source build was removed in v5; vendoring always needs a patch-service artifact.
• rollback in agent mode drops the manifest entry, so a later apply is a no-op (documented).
• A venv directory not named .venv / venv is only found through VIRTUAL_ENV.
• SOCKET_API_TOKEN format warnings and the uv pip HEAD 501 are mock artifacts. vex -o is --org, not --output. vex --json requires --output.
• scan --mode agent after a failed get (unwritable target) skips the recorded entry ("already recorded … run socket-patch apply") and exits 0. This is documented, and the failed get itself exits 1.
• Hosted vex ignores hosted URLs that aren't on patch.socket.dev. Pass --patch-server-url <mock origin> to attest mock-hosted projects locally.
• A concurrent second run in the same project exits 1 with "Another socket-patch process is operating in this directory" (by design).
• A requirements.txt that v4.0.0 (or a pre-Fix requirements.txt writers ignoring pip hash mode (#376) #383 build) hosted with --hash in an otherwise unhashed file stays in that shape on a re-scan (exit 0), so pip still fails in hash mode. This is documented in Fix requirements.txt writers ignoring pip hash mode (#376) #383; socket-patch rollback then a re-scan rewrites it to the fragment form (verified).
• Hosted decides hash mode from the root file only, while vendored checks the whole -r tree. That's harmless: in hash mode pip accepts a user-supplied direct URL's #sha256= fragment as its hash (pip 20.3.4–26.0).
• The vendored wheel path is CWD-relative; pip install -r must run from the project root (documented in CLI_CONTRACT.md).
• Hosted rollback only recognises hosted URLs of the shape /patch/pypi/<name>/<ver>/<tok>/<uuid>/<file>; a mock without that path gets "Manifest not found".
• Agent mode doesn't crawl pip install --target <dir> trees; it reports the package [NOT INSTALLED] with a skip hint (not silent). Hosted works for such projects.
• In the sandbox, the CLI can't reach pypi.org directly (NO_PROXY lists it), so hosted rollback's upstream lookup fails with "error sending request". Run with NO_PROXY=localhost,127.0.0.1.
• pip 24 refuses hashed constraints next to an unhashed root, so constraint-only hash layouts aren't a socket-patch case.
• A SIGKILLed scan can leave .socket-stage-<file>-<uuid> in the project root, and later runs don't remove it; SIGTERM leaves nothing. Not filed (inherent to SIGKILL, cross-ecosystem).

[github-actions[bot]]

[agent] 2026-09-30: pip / requirements.txt bug-hunt run

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

Tested: main f6b7fb9 (CLI 4.0.0), latest release v4.0.0; 4.0.0 and 3.3.0 from PyPI were used for first-bad checks. 3.3.0 has no hosted or vendored mode, and its setup is npm-only.

Setup: a local mock patch API (the same shape as the Pipenv, Poetry and Hatch routines) served a patched six-1.16.0 wheel. I used real pip (20.3.4, 23.3.2, 24.0 and 26.2.1) on CPython 3.10, 3.11 and 3.13 locally, and 3.8 / 3.13 on the probes.

Cells

Cell	Result
hosted, unhashed multi-line requirements.txt → pip install -r	fail → #376 (Linux, macOS, Windows × pip 20.3.4 / 23.3.2 / 26.2.1 × py3.8 / 3.13)
vendored, unhashed multi-line requirements.txt → pip install -r	fail → #376 (same matrix)
hosted, single six==1.16.0 line → fresh install PATCHED	pass (all 3 OS)
hosted, fully hashed (continuation) file → install PATCHED, rollback byte-exact	pass (Linux)
hosted, CRLF + Six capitalised; BOM; marker; extras; comment; trailing \	pass (Linux; rewrite + rollback exact)
hosted, warm .venv holding upstream six	pip keeps the same-version install (UNPATCHED); redirect_pypi_stale_install fires and vex omits it (not_applied): pass, as documented
hosted, pin only in a -r base.txt include	not rewritten, warns redirect_requirements_entry_not_found (hosted reads only the root file)
vendored, pin in a -r base.txt include	rewritten in base.txt: pass
agent, .venv / venv / VIRTUAL_ENV=env	pass; scan, idempotent re-scan and rollback all work
agent, a venv named env/ or myenv/ without VIRTUAL_ENV	not discovered; falls back to the system interpreter (package_not_installed). This is presumably documented discovery; noted, not filed
setup → socket-patch[hook] → pip install → .pth	fail → #377 (socket-patch-hook isn't on PyPI; pip backtracks to 3.3.0; Linux, macOS, Windows × py3.8 / 3.13)
setup on a hash-pinned requirements.txt	fail → #378 (all 3 OS × pip 20.3.4 / 23.3.2 / bundled)
setup --remove with a hashed continuation hook line	leaves a dangling --hash= line, which pip tolerates (noted in #378)

Issues

• Filed Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376: Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376
• Filed setup writes socket-patch[hook] into requirements.txt, but socket-patch-hook was never published to PyPI, so pip silently installs socket-patch 3.3.0 and no .pth hook #377: setup writes socket-patch[hook] into requirements.txt, but socket-patch-hook was never published to PyPI, so pip silently installs socket-patch 3.3.0 and no .pth hook #377
• Filed setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378: setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378

False positives ruled out

• vendor_fetch_failed against pypi.org is the sandbox TLS artifact; not needed here.
• The uv pip install of the hosted URL failed on my mock (501 on HEAD). That's a mock artifact, not a bug.
• six==1.16 / six==1.16.0.0 scan outcomes depend on my mock's string-matched batch endpoint, so they weren't judged.
• Lock-only discovery ignores six == 1.16.0 (spaces) and six===1.16.0, while the hosted rewriter accepts both. utils/requirements.rs tests this on purpose (exact_pin("six == 1.0") == None), so it's a design choice; it goes in the backlog, not filed.
• Probe run 36771795909's "latest" cells used setup-python's bundled pip (26.2.1 on 3.13, 23.x / 25.x on 3.8) because of a probe-script glitch. Every cell still exercised a real pip.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36771795909 (15 jobs: ubuntu / macos / windows × py3.8 / 3.13 × pip 20.3.4 / 23.3.2 / bundled)
• https://github.com/SocketDev/socket-patch/actions/runs/36772070619 (6 jobs: socket-patch-hook availability)

I couldn't delete the probe branches: the git proxy hangs up on ref-delete pushes, the same as the siblings. A maintainer should delete bughunt/pip/20260930-hash-mode and bughunt/pip/20260930-hook-dist.

Next

1. Hosted and vendored --require-hashes files with a -c constraints.txt, and -r chains in subdirectories (relative-path resolution of the vendored wheel line when pip is run from another CWD).
2. Editable (-e .) and VCS/URL lines next to a patched pin; --index-url / --extra-index-url option lines; --no-binary / sdist-only resolution after a hosted rewrite.
3. Agent mode across Windows Scripts/ + Lib/site-packages, --system-site-packages venvs, pip install --user, and virtualenv (not venv) layouts; the .pth hook on Windows once setup writes socket-patch[hook] into requirements.txt, but socket-patch-hook was never published to PyPI, so pip silently installs socket-patch 3.3.0 and no .pth hook #377 is fixed.
4. Name normalisation: zope.interface / Zope_Interface / ruamel.yaml pins in lock-only discovery and the rewriter; spaces around == (see false positives).
5. vex on a hosted requirements project after pip install --force-reinstall, and after the Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 failure (make sure it never attests an uninstallable file).

[github-actions[bot]]

[agent] 2026-10-01: pip / requirements.txt bug-hunt run

Tested: main 2463257 (#277, the v5 consolidation: hosted is now the default scan mode, rollback is an upstream restore, setup is removed; the CLI still reports 4.0.0). The latest release is v4.0.0, and 4.0.0 from PyPI was used for first-bad checks. Local mock patch API serving a patched six-1.16.0 wheel (RealApi shape). Real pip 20.3.4 / 23.3.2 / 24.0 / 24.3.1 / 26.2.1 on CPython 3.10–3.13 locally; 20.3.4 / 25.0.1 / 26.2.1 on 3.8 / 3.13 on the probes.

Re-triage

• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 still reproduces on 2463257 (six @ … --hash + idna==3.7 → pip refuses in hash mode). Commented: Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 (comment). Fix PR Fix requirements.txt writers ignoring pip hash mode (#376) #383 is still open against the old base.
• setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378 closed (not planned): setup was removed by v5 prerelease: scan → vex → vendor workflow, hosted by default #277, the same resolution as setup writes socket-patch[hook] into requirements.txt, but socket-patch-hook was never published to PyPI, so pip silently installs socket-patch 3.3.0 and no .pth hook #377. setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378 (comment)

Cells

Cell	Result
hosted, --system-site-packages venv, six in the base interpreter → pip keeps the base copy, no stale warning, vex attests not_affected	fail → #409 (Linux, macOS, Windows × py3.8 / 3.10–3.13 × pip 20.3.4 / 23.3.2 / 24.x / 25.0.1 / 26.2.1). The VEX part is a regression from #277 (v4.0.0 omitted it as package_not_found)
vendored, same layout → no vendored_tree_out_of_sync warning	fail (folded into #409)
agent, same layout → "not installed"	fail (folded into #409)
hosted, one-line six==1.16.0 (or -e . + pin, or a single hashed line) → rollback / remove / vendored takeover	fail → #410 (all 3 OS)
hosted, multi-line unhashed / --require-hashes / --index-url / VCS line / unpinned sibling → rollback	pass
hosted, pip-compile hashed (LF and CRLF) → install PATCHED → rollback	pass, byte-exact
hosted rollback with BOM + Six, or extras + marker + comment	restored and installable; name case lowered and comment spacing normalised (cosmetic, not filed)
lockfile-only checkout, pin only in -r requirements/base.txt, hosted and vendored	fail → #412 (all 3 OS × pip 20.3.4 / 25.0.1 / 26.2.1)
vendored, -r reqs/base.txt with a populated .venv → base.txt rewritten → fresh install PATCHED → rollback	pass
vendored lock-only re-scan after vendoring an include (no venv) → already vendored; vex attests from the committed artifact	pass
hosted, -c constraints.txt (unhashed and hashed constraints)	pass (pip 20.3.4 / 23.3.2 / 24.3.1 / 26.2.1, PATCHED)
agent, plain .venv	(covered last run)
unhashed multi-line hosted / vendored	still fail (#376)
pip 20.3.4 on CPython 3.13	blocked (pip 20.3.4 can't run without distutils)

Issues

• Filed 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
• Filed 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 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
• Filed 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: 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
• Commented on Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376; closed setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378.

False positives ruled out

• Vendored vex attesting while a plain venv keeps upstream bytes is documented (the committed artifact is the basis; vendored_tree_out_of_sync warns). It isn't a bug by itself; only the missing warning in the system-site case is (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).
• Rollback lowercasing Six and collapsing spaces before # comment only changes the restored hosted line; pip reads it the same way. Not filed.
• vex -o is --org, not --output. That was my mistake, not a CLI bug.
• The six == 1.16.0 (spaces) lock-only miss is still the known design choice. Not filed.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36806309982 (12 jobs: 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 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 cells)
• https://github.com/SocketDev/socket-patch/actions/runs/36806312653 (12 jobs: 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 cells)
• The first attempts (36805460155, 36805749399) died on bash -e. That was a script bug; I fixed it and re-pushed.

I couldn't delete the probe branches: the git proxy hangs up on ref-delete pushes, as in the last run. A maintainer should delete bughunt/pip/20261001-restore-include and bughunt/pip/20261001-system-site, plus last run's bughunt/pip/20260930-hash-mode and bughunt/pip/20260930-hook-dist.

Next

1. Windows agent mode (Scripts/ + Lib/), --user installs, and virtualenv (not venv) layouts, under v5.
2. VCS / URL / --no-binary sdist-only installs after a hosted rewrite; uv pip install -r of a pip-hosted file.
3. repair and list for vendored requirements; --json envelopes of rollback / remove failures.
4. Hosted rewrite + rollback when the same name is pinned twice under different markers (conditional versions).
5. Re-verify Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 / 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 / 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 / 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 once fixes land (Fix requirements.txt writers ignoring pip hash mode (#376) #383 needs a rebase onto v5).

[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 pip / requirements.txt version and on Linux, macOS and Windows.

Where pip / requirements.txt puts global installs: pip install into the system / Homebrew / python.org interpreter, pip install --user (site.USER_SITE, %APPDATA%\Python), pipx venvs, and PEP 668 externally-managed interpreters. Check which site-packages -g picks when several interpreters are on PATH (pyenv, py launcher).

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 pip / requirements.txt 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 pip / requirements.txt 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 × pip / requirements.txt 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: pip / requirements.txt bug-hunt run

Tested: main 2463257 (unchanged since the last run; CLI reports 4.0.0), latest release v4.0.0; v4.0.0 from PyPI was used for the first-bad check. Local mock of the authenticated patch API (batch / by-package / view / package) serving a marked six-1.16.0. Real pip 20.3.4 / 21.3.1 / 22.3.1 / 23.0.1 / 23.1 / 24.0 on CPython 3.10 / 3.11 locally; 20.3.4 / 22.3.1 / 23.0.1 / 23.1 on 3.8 / 3.11 on the probe.

Re-triage

Main hasn't moved since the last run, so #376, #409, #410 and #412 can't have changed. No comments.

Cells

Cell	Result
pip ≤ 23.0.1 legacy sdist install (six-1.16.0-pyX.Y.egg-info) → agent scan / get	fail → #447: skipped / package_not_installed, exit 0, unpatched (Linux, macOS, Windows × py3.8 / 3.11 × pip 20.3.4 / 22.3.1 / 23.0.1)
same, hosted rewrite + pip install -r	fail → #447: pip keeps the egg-info copy and no redirect_pypi_stale_install fires
same, scan -g / --global-prefix report	fail → #447: package missing. On Ubuntu scan -g also misses every apt egg-info package (python3-six, setuptools 68.1.2, …)
pip 23.1 / 24.0 control (dist-info)	pass in all three legs, all 3 OS
scan -g report-only (dist-info globals)	pass: 102 global purls, no venv packages leak, even with VIRTUAL_ENV set
scan -g --mode hosted, --global-prefix --mode hosted	pass: refused, exit 2, nothing written
get / rollback / apply / vex with --global-prefix "<dir with space and ü>" and SOCKET_GLOBAL_PREFIX	pass: patch applied, byte-exact rollback, vex attests only while patched (not_applied otherwise)
get --global-prefix on an unwritable (immutable) dir	pass: exit 1, Operation not permitted
scan --global-prefix --mode agent on an unwritable dir	pass: exit 1, partial_failure
non--g agent scan, requirements.txt project with no venv	patched ~/.local/lib/python3.11/site-packages/six.py (see below; not filed)

Issues

• Filed Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447: Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447

Needs a maintainer decision (not filed)

• The non--g scan touches the user/global site-packages. In a project with requirements.txt and no .venv / venv / VIRTUAL_ENV, scan --mode agent (no -g) patched ~/.local/.../six.py, and rollback restored it. python_crawler.rs:1383-1410 says this "project marker → global" fallback is deliberate, but CLI_CONTRACT.md:478 describes pypi discovery as cwd-only ($VIRTUAL_ENV, .venv / venv, Poetry venvs), and the -g checklist says "a scan without -g must never touch it". Either the contract or the code should change. Tell me if you want it filed.
• scan --mode vendored --global-prefix <dir> isn't refused (only hosted is), so it tries to vendor a global package into the cwd project. Not documented either way.

False positives ruled out

• A failed get (unwritable target, exit 1) still records the manifest entry. A later scan --mode agent prints "already recorded … run socket-patch apply" and exits 0. That's documented agent-scan behaviour, and the failure itself exited 1.
• vex doesn't recognise my mock's http://127.0.0.1 hosted URLs (it expects patch.socket.dev). That's a mock artifact, so hosted VEX wasn't judged this run.
• The SOCKET_API_TOKEN format warning is a mock artifact.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36836217323 (6 jobs, all green; per-cell results are in the logs)

I couldn't delete bughunt/pip/20261001-egg-info: the git proxy hangs up on ref-delete pushes, as before. A maintainer should delete it, along with bughunt/pip/20261001-restore-include, bughunt/pip/20261001-system-site, bughunt/pip/20260930-hash-mode and bughunt/pip/20260930-hook-dist.

Next

1. Finish the -g checklist: pip install --user on macOS (~/Library/Python/X.Y) and Windows (%APPDATA%\Python), python.org / Homebrew interpreters, a py-launcher with several interpreters, and non-root unwritable prefixes on CI runners.
2. Windows agent mode (Scripts/ + Lib/) and virtualenv (not venv) layouts under v5.
3. Legacy pip install -e . (.egg-link + project egg-info) next to a patched pin. Re-verify Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 once a fix lands.
4. VCS / URL / --no-binary installs after a hosted rewrite; uv pip install -r on a pip-hosted file.
5. repair / list for vendored requirements; --json envelopes of rollback / remove failures.

[github-actions[bot]]

[agent] 2026-10-01: pip / requirements.txt bug-hunt run

Tested: main 6e7ef74 (4 commits past 2463257: the Poetry venv-discovery reorder #330, the npm fixes #337 / #345, and Maven docs #322; the CLI still reports 4.0.0), latest release v4.0.0 (96df6ae). I used v4.0.0 from PyPI plus local builds of ade011e, ade011e~1 and f6b7fb9 for the bisect.

Setup:

• Vendored cells: the repo's own prebuilt_common artifact server, through an uncommitted local test shim.
• Hosted cells: a Python mock of batch / by-package / view / package / blob, with --patch-server-url pointed at it. This means hosted vex can now be judged locally.
• Real pip: 20.3.4 / 23.3.2 / 24.0 locally on CPython 3.10 / 3.11 / 3.12. On the probes: 20.3.4 / 21.1.1 / 23.0.1 / 24.0 / 26.2.1 on 3.8 / 3.13.

Re-triage

• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 still reproduces on 6e7ef74: idna==3.7 + hosted six @ … --hash → pip refuses in hash mode. No new information, so no comment.
• Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 still reproduces on 6e7ef74: a pip 20.3.4 --no-binary install (six-1.16.0-py3.10.egg-info) → agent get gives package_not_installed. The crawler change in Fix Poetry venv discovery to match Poetry (#327, #329) #330 touched only venv discovery order. No comment.

Cells

Cell	Result
hosted scan / get, six==1.16, six==1.16.0.0 or Six==01.16.0 with six 1.16.0 installed	fail → #475: redirect_requirements_entry_not_found, exit 0, fresh install UNPATCHED. Linux, macOS and Windows × pip 20.3.4 / 21.1.1 / 23.0.1 / 24.0 / 26.2.1 × py3.8 / 3.13. v4.0.0 passes; first bad commit is 745e8dc (#239)
vendored, same pins	refuses pypi_requirement_not_pinned (fail-closed; folded into #475)
vendored ===1.16.0, six==1.16.*, a tab before --hash	refused pypi_requirement_not_pinned (fail-closed). === / wildcards are by design; the tab case is noted, not filed
vendored SIX==1.16.0	pass
vendored, the same pin twice under different markers	both lines rewritten: pass
hosted, the same pin twice under different markers + an unhashed bystander → rewrite → install PATCHED (py3.10 and py3.12) → rollback	pass, byte-exact
hosted, six==1.16.0 ; … + six==1.15.0 ; … → rollback	pass, byte-exact
hosted, only the two marker pins (no bystander) → rollback	refused: #410 variant
hosted, --no-binary six / --no-binary :all: + pin → fresh install	PATCHED (pass)
hosted, marker on a \ continuation line	rewritten, PATCHED (pass)
vendored list --json	pass
vendored repair after deleting the wheel	rebuilt with the same sha256, requirements untouched (pass)
hosted vex (mock origin via --patch-server-url)	unpatched venv → omitted (no_applicable_patches); after pip install --force-reinstall -r → not_affected: pass
two concurrent hosted scans on one project (×3)	one wins and the other exits 1 with "Another socket-patch process is operating in this directory"; file consistent: pass
-g with pip install --user: scan -g report / scan -g --mode hosted refusal / get <uuid> -g / rollback -g	pass on Linux (local), macOS (~/Library/Python/3.8, python.org framework build, pip 20.3.4; py3.13) and Windows (%APPDATA%\Python\Python38 and Python313, pip 20.3.4 and 26.2.1). Rollback byte-exact; scan -g leaves files untouched; hosted refusal exits 2

Issues

• Filed Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475: Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475

False positives ruled out

• Hosted rollback refusing "mixes hashed and unhashed requirements": my fixture had a hashed idna next to unhashed six, which pip itself rejects. That was a fixture error.
• Local rollback -g failing with "Before blob could not be downloaded": my mock had no /patches/blob/ route. Once I added it, the cell passed.
• record_fetch_failed on probe-1 cells: that mock had no view route, so this is a mock artifact.
• --vendor-source build was removed in v5, so vendoring needs a patch-service artifact. That's expected, not a bug.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36878654662 (6 jobs: Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 matrix)
• https://github.com/SocketDev/socket-patch/actions/runs/36879025526 (6 jobs: -g with --user, all pass)

I couldn't delete bughunt/pip/20261001-pep440-pin or bughunt/pip/20261001-global-user: the git proxy hangs up on ref-delete pushes, as in earlier runs. A maintainer should delete them, along with bughunt/pip/20261001-egg-info, -restore-include, -system-site, bughunt/pip/20260930-hash-mode and -hook-dist.

Next

1. Finish -g: Homebrew python (PEP 668 externally managed), py launcher with several interpreters, a pipx venv, and a non-root unwritable prefix on a CI runner.
2. Lock-only (no venv) discovery of six==1.16 (purl six@1.16) once Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 is fixed. This needs an API mock that mirrors how the real service matches versions.
3. Windows agent mode in a project .venv (Scripts/ + Lib/) and virtualenv (not venv) layouts.
4. Legacy pip install -e . (.egg-link) next to a patched pin.
5. VCS / URL lines and uv pip install -r on a pip-hosted file; re-verify Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 / 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 / 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 / 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 / Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 / Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 as fixes land.

[github-actions[bot]]

[agent] 2026-10-01: pip / requirements.txt bug-hunt run

Tested: main 61cfb9b (16 commits past 6e7ef74, including #383, the fix for #376, and #452, the fix for #447; the CLI still reports 4.0.0). Latest release is v4.0.0, installed from PyPI for the upgrade-path check.

Setup:

• A local Python mock of batch / by-package / view / package / blob, plus a patched six-1.16.0 wheel served at /patch/pypi/six/1.16.0/<tok>/<uuid>/…. That path shape is required: hosted rollback can't find a hosted line whose URL lacks it.
• Real pip 20.3.4 / 23.3.2 / 24.0 / 26.0 on CPython 3.11 / 3.12 locally, and uv 0.8.17.
• Probe matrix: ubuntu / macos / windows × (py3.8, pip 20.3.4) and (py3.13, pip 26.2.1).

Re-triage

• Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 and Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 were closed by their fix PRs, and both are verified fixed on main (cells below).
• 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 still reproduces on 61cfb9b (six==1.16.0 alone → hosted → rollback exits 1 "not derivable"). I commented with new information: since Fix requirements.txt writers ignoring pip hash mode (#376) #383 the hosted line's shape (#sha256= fragment vs --hash) records the original mode. 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 (comment)
• 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 still reproduces on 61cfb9b (Debian system-site venv: pip keeps /usr/lib/python3/dist-packages/six.py UNPATCHED, no stale warning, vex attests not_affected). Nothing new, so no comment.
• Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 is not merged yet (Fix requirements.txt pins not matched under PEP 440 (#475) #478 is open), so I didn't re-check it.

Cells

Cell	Result
hosted unhashed file → name @ <url>#sha256=… (no --hash) → pip install -r	pass: PATCHED on Linux, macOS, Windows × pip 20.3.4 / py3.8 and 26.2.1 / py3.13, plus local 20.3.4 / 23.3.2 / 24.0 / 26.0
fragment line when an -r include turns hash mode on (hosted only checks the root file for hashes)	pass: pip 20.3.4–26.0 accept a user-supplied direct URL's fragment as its hash; a wrong fragment is rejected
fragment form with markers (;python_version>="3", and markers, a false marker), extras, six == 1.16.0, a trailing comment	pass: pip 20.3.4 and 26.0
uv pip install -r / uv pip sync on a fragment file	pass: PATCHED
hosted re-scan of a fragment file (CRLF + comment)	pass: no-op, CRLF kept
list, remove <purl> on a fragment line	pass (remove normalises spacing before the comment, a known non-bug)
hosted rollback (idna + six), all 3 OS	pass: byte-exact
hosted rollback, six==1.16.0 alone	fail → #410 (commented)
hosted, --system-site-packages venv	fail → #409
v4.0.0-hosted file (--hash in an unhashed set) → main re-scan	stays broken (exit 0, redirected 1, pip fails in hash mode). This is documented in #383 ("keeps that shape; rollback then re-scan rewrites it"); I verified that remedy works. Not filed
agent scan on a pip ≤ 23.0 --no-binary egg-info install (#447)	pass: patched, vex not_affected, rollback restores. Linux, macOS, Windows (.venv\Scripts / Lib) × py3.8 / pip 20.3.4, plus local py3.11
hosted on egg-info: redirect_pypi_stale_install and vex omits not_applied	pass
agent mode, project .venv dist-info, Windows Scripts/ + Lib/ layout	pass on all 3 OS × both combos (scan, vex, rollback)
agent mode next to a legacy pip install -e . (.egg-link + project .egg-info)	pass
vendored unhashed tree → bare wheel path, no hash; pip install -r from the project root	pass on all 3 OS × both combos; rollback byte-exact
hosted → vendored over a vendored file	pass
vendored → hosted takeover (scan --mode hosted on a vendored requirements.txt)	fail → duplicate of #328: exit 0, redirect_requirements_entry_not_found, stays vendored, on all 3 OS. The gate is scan/hosted.rs:1512 (takeover_capable admits only cargo / npm / golang). Evidence added to #328
vex with no project venv	omits six because the crawler falls back to global site-packages (Debian's unpatched six). Same open maintainer question as before

Issues

• No new issues.
• Commented on 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 (new information) and Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (requirements.txt evidence for the vendored → hosted leg): Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)

False positives ruled out

• Hosted rollback "Manifest not found": my mock's artifact URL lacked the /patch/pypi/<name>/<ver>/<tok>/<uuid>/ path, so this was a mock artifact.
• The -r include hash-mode gap in hosted (root-only requires_hashes): pip accepts the fragment hash in hash mode, so it's not a bug.
• The vendored bare path resolving against the CWD: documented ("run from the project root", CLI_CONTRACT.md).
• six==1.16.0 \ + next line: a bad fixture on my side (an invalid requirement).
• uv pip install --require-hashes failing: the unhashed bystander makes that file invalid in that mode regardless.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36922079225 (6 jobs, all cells pass except the expected Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 takeover)

I couldn't delete bughunt/pip/20261001-fragment-egg-win: the git proxy hangs up on ref-delete pushes, as before. A maintainer should delete it, along with bughunt/pip/20261001-pep440-pin, -global-user, -egg-info, -restore-include, -system-site, bughunt/pip/20260930-hash-mode and -hook-dist.

Next

1. Re-verify Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 once Fix requirements.txt pins not matched under PEP 440 (#475) #478 merges, then lock-only discovery of six==1.16 (purl six@1.16).
2. Finish -g: Homebrew / PEP 668 interpreters, py launcher with several interpreters, a pipx venv (Global scan (-g) never crawls pipx venvs, so the dependencies of a pipx-installed Hatch are never reported, patched or rolled back on any OS #415's fix landed in Fix global scan missing pipx venvs (#415) #418), and a non-root unwritable prefix on CI.
3. virtualenv (not venv) layouts, and pip install --target / --prefix trees.
4. pip-tools: pip-sync and pip-compile --generate-hashes re-runs over a hosted file.
5. --json envelopes for rollback / remove failures; interrupted runs.

[github-actions[bot]]

[agent] 2026-10-02: pip / requirements.txt bug-hunt run

Tested: main 61cfb9b (unchanged since the last run; the CLI reports 4.0.0) and latest release v4.0.0 (from PyPI, for the regression check).

Setup:

• A fresh local Python mock of batch / by-package / view / package / blob, serving patched six 1.16.0 and 1.17.0 wheels. I used 1.17.0 for the lock-only cells, because the sandbox's system Python has six 1.16.0 in global site-packages, which confounds discovery.
• Real pip 20.3.4 / 24.0 locally on CPython 3.11 / 3.12, plus virtualenv 21 and pip-tools.
• Probe matrix: ubuntu / macos / windows × (py3.8, pip 20.3.4) and (py3.13, pip 26.2.1).

Re-triage

Main hasn't moved since the last run (#478 for #475, #503 for #328 and #481 are still open PRs), so #409 / #410 / #412 / #475 have nothing new to re-check. No comments.

Cells

Cell	Result
baseline: hosted unhashed .venv → fragment pin → fresh pip install -r	pass
lock-only scan with a spaced exact pin (six == X, six ==X, six== X, six[x] == X, six (==X))	fail → #523: not discovered, exit 0 "No patches available", installs UNPATCHED. Linux, macOS, Windows × pip 20.3.4 / 26.2.1. v4.0.0 is the same (not a regression). Vendored lock-only is also blind. With a venv present the hosted rewriter handles these forms (pass)
agent scan / rollback in a virtualenv (not venv) .venv	pass
pip-tools: pip-compile --generate-hashes → hosted → pip-sync (warm, and after uninstall)	pass: pip-sync reinstalls PATCHED even over a warm venv
pip-tools hashed file → rollback	pass: restores six==1.16.0 \ plus both upstream --hash lines (needs pypi.org reachable; see the false positives)
-c constraints.txt pins, unpinned root six → hosted	pass: root line rewritten, PATCHED with the constraint satisfied
hashed constraints + unhashed root	n/a: pip 24 itself refuses that layout (constraint hashes don't satisfy hash mode)
pip install --target libs tree, agent mode	reports [NOT INSTALLED] with a skip hint, exit 0 (crawler covers venvs / site-packages only; clearly messaged). Hosted rewrite works and pip install --target from the rewritten file is PATCHED
--json envelopes: rollback / remove failure (all-hosted file, #410) and an unknown purl	pass: valid JSON, exit 1, error codes hosted_revert_failed / not_found. Rollback reports status: partial_failure with top-level failed: 0 while hosted.failed holds the entry; noted, not filed (multi-leg counter semantics)
interrupted hosted scan (SIGTERM at 20–120 ms)	pass: file is either original or fully rewritten; no litter
interrupted hosted scan (SIGKILL early)	leaves .socket-stage-requirements.txt-<uuid> (already the full rewrite) in the project root, and later runs don't sweep it. This is inherent to SIGKILL; not filed (cross-ecosystem atomic-writer behaviour)

Issues

• Filed Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523: Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523

False positives ruled out

• Hosted rollback "Cannot restore … GET https://pypi.org/pypi/six/1.16.0/json: error sending request": a sandbox artifact. pypi.org is in NO_PROXY and the CLI's direct connection fails here; with NO_PROXY=localhost,127.0.0.1 it restores correctly.
• Hosted rollback "Manifest not found" on a mock-hosted file: you need --patch-server-url <mock origin> (already known).
• Lock-only cells with six 1.16.0: confounded by Debian's global six 1.16.0 (the open no-venv fallback question). I switched to 1.17.0 locally and 1.15.0 on the probes.
• The SIGINT interruption test was invalid: a non-interactive shell's background jobs ignore SIGINT. I used SIGTERM instead.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36955168379 (6 jobs: the spaced-pin matrix; reproduces in all 6)

I couldn't delete bughunt/pip/20261002-spaced-pin: the git proxy hangs up on ref-delete pushes, as before. A maintainer should delete it, along with the older bughunt/pip/* probe branches listed in the previous entries.

Next

1. Re-verify Hosted requirements.txt rewrite skips PEP 440-equivalent pins like six==1.16 for an installed 1.16.0, so scan exits 0 and pip installs the unpatched release (regression from v4.0.0) #475 once Fix requirements.txt pins not matched under PEP 440 (#475) #478 merges, Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 once Fix PyPI vendored to hosted takeover being refused (#328) #503 merges, and Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523 when fixed. Also check lock-only vex against the spaced-pin forms (vex/discover/pypi_other.rs shares exact_pin).
2. Finish -g: Homebrew / PEP 668 interpreters, the py launcher with several interpreters, a pipx venv, and a non-root unwritable prefix on CI.
3. Other lock-only grammar gaps next to Lockfile-only requirements.txt discovery skips exact pins written with spaces (six == 1.15.0, six (==1.15.0)), so a fresh checkout reports "No patches available" and pip installs the unpatched release #523: six==1.15.0 \ continuations with a spaced ==, --hash before the marker, env-var ${VAR} lines, -e / VCS lines next to a patched pin.
4. pip install --prefix trees; a .venv symlink to an out-of-tree venv.