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-03 14:18 UTC (twelfth run), main 045d7ec (unchanged), latest release v4.0.0. Filed #699 (the vendored → hosted takeover strands a pin in a -r include or a vendor-added (transitive) line, and --dry-run previews success). get --mode vendored over hosted pins passes (plain, hashed + CRLF + marker, BOM), and so do agent egg-info / dist-info cells on pip 21.3.1–23.1.2. #668, #638, #604, #542, #410 and #409 are still open.

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)	hosted foreign direct ref (six @ mirror)	lock-only PEP 440-equivalent pin (==1.16)	no root requirements.txt (--json)	hosted → vendored takeover (vendor)	vendor --dry-run over hosted	get --mode vendored over hosted	vendored → hosted, include / transitive pin
Linux	20.3.4 / py3.8, py3.11	pass	pass (#447 fixed)	pass	pass	pass; all-hosted-pins fail #410	fixed on main #328 (re-verify)	fail #409	pass (re-verified 2026-10-03, pip 20.3.4)	fixed on main #475 (re-verify)	untested	pass (re-verified 2026-10-03)	untested (OS-independent)	fail #604 (vendored, re-observed 2026-10-03)	fail #638	pass; sole pin fail #410	fail #668	pass (+ hashed, CRLF, marker)	fail #699
Linux	23.x, 24.0 / py3.11, py3.12	pass	n/a (dist-info); 21.3.1 / 22.3.1 / 23.0.1 egg-info pass, 23.1.2 dist-info pass	pass	pass	pass; fail #410	fixed on main #328 (re-verify)	fail #409	fixed on main #412 (re-verify)	fixed on main #475 (re-verify)	pass (report, hosted refusal, get / rollback / vex, --global-prefix, unwritable)	fixed on main #523 (re-verify)	fail #542 (pip 24.0)	fail #604 (pip 24.0)	untested (OS-independent)	untested	fail #668 (pip-independent)	untested	fail #699 (pip-independent)
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	fixed on main #328 (re-verify)	fail #409	pass (re-verified 2026-10-03, pip 26.2.1)	fixed on main #475 (re-verify)	untested	pass (re-verified 2026-10-03)	untested (OS-independent)	fail #604 (vendored, re-observed 2026-10-03)	fail #638	pass; sole pin fail #410	fail #668	pass (+ hashed, CRLF, marker, BOM)	fail #699
macOS	20.3.4 / py3.8; 26.2.1 / py3.13	pass	pass (py3.8)	pass	pass	pass; fail #410	fixed on main #328 (re-verify)	fail #409	fixed on main #412 (re-verify)	fixed on main #475 (re-verify)	pass (--user)	fixed on main #523 (re-verify)	untested (OS-independent)	untested (OS-independent)	untested (OS-independent)	untested	untested (OS-independent)	untested	untested (OS-independent)
Windows	20.3.4 / py3.8; 26.2.1 / py3.13	pass (Scripts/ + Lib/)	pass (py3.8)	pass	pass	pass; fail #410	fixed on main #328 (re-verify)	fail #409	fixed on main #412 (re-verify)	fixed on main #475 (re-verify)	pass (--user, %APPDATA%\Python)	fixed on main #523 (re-verify)	untested (OS-independent)	untested (OS-independent)	untested (OS-independent)	untested	untested (OS-independent)	untested	untested (OS-independent)

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): free-threaded CPython 3.13t venvs, a .venv symlink to an out-of-tree venv, a 16-case hosted grammar sweep with fresh installs and rollbacks, 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. Run ten (2026-10-03, pip 26.2.1 / py3.13 and pip 20.3.4 / py3.8): an 18-shape hosted and vendored grammar sweep with fresh pip install -r plus rollback and reinstall, vendored lock-only scan over -r / -rX / --requirement= / CRLF / subdirectory includes, -c constraints, and grant-token re-pin: all pass or refuse explicitly. Run eight (pip 24.0 / py3.11 and pip 20.3.4 / py3.8): PEP 503 name normalisation (_ / - / . / case, venv and lock-only), duplicate and marker-split pins, BOM, no trailing newline, --no-index + --find-links, per-line --config-settings, --require-hashes with multiple and sha384 hashes, -e / VCS neighbours (lock-only + vex), symlinked root and include files, out-of-root includes, --prefix trees: all pass or refuse explicitly.

Backlog

0. Open questions for the maintainer: (a) vex attests a hosted pin (six@1.16.0) from the lockfile basis when the venv holds a different version (six 1.15.0), with no warning (see the 20261002T142728Z entry). (b) The non--g no-venv fallback to global site-packages (20261001T083942Z). (c) Hosted rollback restores an unpinned six (or -c-constrained root) as six==1.16.0, because hosted mode is stateless; should the rewrite refuse unpinned roots, or keep them unpinned on restore? (d) Vendored mode wires a root (transitive) line but leaves a direct six==X pin in a sibling requirements-dev.txt, so pip install -r requirements-dev.txt alone stays unpatched (same class as Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638).
1. Re-verify Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699, vendor --dry-run over a hosted requirements.txt pin previews a pypi_requirement_not_pinned failure (exit 1), but the real vendor takes it over and succeeds #668, Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638, Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604, Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542, 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 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 as fixes land. Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 / 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 re-verify on pip 20.3.4 / 26.x is still open.
2. get --mode hosted over a vendored include pin (the Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699 takeover through get).
3. A Windows / macOS probe: BOM + CRLF on the patched line, and the vendored path line with real pip (blocked while probe branches can't be deleted).
4. Finish global (-g) mode: Homebrew / PEP 668 interpreters, the py launcher with several interpreters, pipx venvs (Fix global scan missing pipx venvs (#415) #418), non-root unwritable prefixes on CI.
5. pip 24–25 spot-checks for hosted / vendored rewrites (21.3–23.1 agent mode is done).

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

• Hosted refuses bare URL / bare path lines (no name @) and ${VAR} pins with redirect_requirements_entry_not_found, exit 0 (the documented hosted-refusal posture).

• A hosted rollback restores a pip-equivalent line, not the original bytes (comment spacing, joined continuations, (==X) → ==X, case).

• Vendored refuses a per-line option such as --config-settings on the patched pin, and a name @ <url/file> direct reference, with "not pinned to ==X" (fail-closed; the wording is imprecise). Hosted rewrites --config-settings lines fine.

• A symlinked requirements.txt or a symlinked -r include is refused explicitly (redirect_symlinked_file_unsupported / pypi_requirements_symlink_unsupported), and so is an include outside the project root (vendored). Nothing is written.

• Agent mode doesn't crawl pip install --prefix <dir> trees either ([NOT INSTALLED] + skip hint), same as --target.

• With a mock origin, hosted rollback / vex need SOCKET_PATCH_SERVER_URL (or --patch-server-url) set to it; vendored needs the mock to serve sha512 integrity.

• Lock-only cells need VIRTUAL_ENV pointing at an EMPTY venv: an empty VIRTUAL_ENV= falls back to the system dist-packages (Ubuntu's python3-six 1.16.0) and masks lock-only behaviour.

• Vendored refuses six[extra]==X (pypi_extras_unsupported), and an unpinned root pinned only through -c constraints.txt (pypi_requirement_not_pinned; the wording says "not pinned" although the constraint pins it). Both are fail-closed.

• Hosted rollback restores ===X as ==X and an unpinned six as six==<installed>. Hosted mode keeps no state, so the line is derived from the hosted URL (see backlog question 0c).

• A file with a single --hash line next to unhashed lines is already uninstallable by pip; hosted keeps that shape and rollback drops the lone hash. Garbage in, garbage out.

• record_fetch_failed on a hosted scan means the mock lacks the view route; it isn't a CLI bug.

• Agent mode doesn't patch editable installs: a PEP 660 finder (apply_failed "File not found") or a legacy .egg-link ("matched no installed package"). Both exit 1 and leave the user's source untouched (fail-closed).

• The vendored takeover's vendor_prebuilt_required 404 in a local harness means --patch-server-url rewrote the artifact host to a mock without the prebuilt routes (harness artifact).

• get --mode vendored over a hosted BOM file writes the vendored line without the BOM (pip reads either form); rollback restores the BOM.

• Agent rollback --offline needs the before blob in .socket/blobs; without it, it refuses with a repair hint (harness staging, not a bug).

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

[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 local Python mock of patches/batch / by-package / view / blob / package plus a hosted wheel route, serving a patched six 1.16.0.
• Real pip 24.0 on CPython 3.12, plus a uv-installed free-threaded CPython 3.13.7t.
• No probe branches: everything this run tested is OS-independent rewriter or crawler logic, and the earlier probe branches still can't be deleted from the sandbox.

Re-triage

Main hasn't moved. #412 / #523 are claimed by draft PR #530; #475 (PR #478) and #328 (PR #503) are still open. Nothing to re-check.

Cells

Cell	Result
agent scan / apply in a free-threaded 3.13t venv (lib/python3.13t/site-packages)	pass
agent scan / apply / rollback with .venv a symlink to an out-of-tree venv	pass
pip install --prefix tree	blocked: confounded by the system six 1.16.0 (the no-venv fallback patched /usr/lib/python3/dist-packages/six.py; rolled back). This is the open maintainer question from 20261001T083942Z
hosted grammar + fresh pip install -r PATCHED: markers (spaced / unspaced), \ + marker continuation, extras, SIX==, trailing comment, six (==X), --only-binary option line, hashed continuation, CRLF hashed, tab before --hash, six @ files.pythonhosted.org/…	pass (12/12)
re-scan idempotency of the 12 above	pass
rollback of the 12 (with a second requirement, avoiding #410) + fresh pip install -r	pass. Restorations are pip-equivalent, not byte-identical: comment spacing, a joined continuation, --hash lines joined, (==X) → ==X, SIX → six
bare URL, bare URL #egg=six, bare local wheel path, six==${VAR}	warned refusal redirect_requirements_entry_not_found, exit 0. Documented hosted-refusal posture; not filed (the "No requirements.txt entry" wording is misleading for a bare URL)
six @ <private mirror or file:// fork> direct reference	fail → #542: overwritten with the Socket PyPI build, and rollback restores six==1.16.0 (source lost). Reproduces with http:// and file://. v4.0.0 does the same (not a regression). Vendored leaves it alone

Issues

• Filed Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542: Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542

False positives ruled out

• Every rollback failed on single-requirement files: that's Hosted rollback, remove and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (six==1.16.0 alone can be patched but never unpatched) #410, so I added idna==3.7 to each.
• The public patches API is unreachable from the sandbox (proxy tunnel error); I used the mock.

Next

1. Re-verify 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 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 Fix lock-only requirements.txt discovery (#412, #523) #530 merges; 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.
2. --prefix trees in a container without a system six (or with a version the system lacks).
3. -e editable / VCS lines (git+https://…#egg=six) next to a patched pin; --hash before the marker.
4. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs.
5. Vendored on a direct-reference fork reports "no installed package found on disk" although it is installed (beforeHash mismatch?). Check whether the message is accurate.

[github-actions[bot]]

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

Tested: main 61cfb9b (unchanged since the last two runs) and latest release v4.0.0.

Setup:

• A rebuilt local mock of patches/batch / by-package / view / package (now with sha256 and sha512 integrity, so vendored works) plus hosted wheel routes. It serves a patched six 1.16.0 and a patched typing-extensions 4.12.2.
• Real pip 24.0 on CPython 3.11, and pip 20.3.4 on a uv-installed CPython 3.8.20.
• Hosted rollback and vex need SOCKET_PATCH_SERVER_URL=<mock origin>, or rollback says "Manifest not found".
• No probe branches: every cell this run is OS-independent rewriter or discovery logic.

Re-triage

Main hasn't moved and no human replies are on #309, so nothing needed re-checking. Open: #409, #410, #412, #475, #523, #542.

Cells (Linux)

Cell	Result
Name normalisation, hosted with a venv: typing_extensions==, typing-extensions==, Typing.Extensions==, typing__extensions==	pass (all → typing-extensions @ …)
The same, lock-only (no venv)	pass
Hosted: duplicate identical pins, --no-index + --find-links, per-line --config-settings, BOM on the patched line, no trailing newline, tab before # comment → fresh pip install -r PATCHED → rollback	pass (pip 24.0 / py3.11)
The same set (dupes, BOM, no-EOL, --no-index, --require-hashes) on pip 20.3.4 / py3.8	pass
Hosted hash mode: --require-hashes + two hashes on one line, a sha384 hash, a \ continuation holding a comment line → fresh install → rollback	pass (rollback restores PyPI sha256 hashes; pip-equivalent)
Hosted range pin six>=1.16.0,<2	refused (not rewritten), exit 0: correct
Marker-split duplicates (six==1.16.0 ; py<3 / ; py>=3)	pass (both rewritten, markers kept)
Vendored: -e ./local neighbour, BOM, no-EOL, duplicate pins → fresh install → rollback	pass (rollback restores the BOM)
Vendored per-line --config-settings	refused, "not pinned to ==1.16.0" (fail-closed, misleading wording; not filed)
Vendored on a six @ file://… direct-reference fork (backlog item)	refused "not pinned to ==1.16.0": accurate and fail-closed. Agent mode patches it. Closes backlog item 5
Symlinked root requirements.txt (hosted, vendored) and symlinked -r include (vendored)	explicit refusal (redirect_symlinked_file_unsupported / pypi_requirements_symlink_unsupported), nothing written: pass
Vendored -r ../outside/base.txt	explicit refusal (include outside the project root): pass
Lock-only hosted with -e git+…, bare VCS, -e <path>, --index-url / --extra-index-url, \ + marker continuation, extras, -c neighbours → rewrite + vex (empty venv)	pass (7/7 rewritten, 7/7 attested)
pip install --prefix tree (backlog item 4)	agent: [NOT INSTALLED] + skip hint (same posture as --target); hosted rewrites. Not a bug
vex after a hosted rewrite: fresh reinstall / stale same-version venv	pass (attested / omitted with not_applied)
vex with the venv holding a DIFFERENT version (six 1.15.0) than the hosted pin (1.16.0)	open question, not filed: attests not_affected for six@1.16.0 from the lockfile basis with no warning. Per vex.rs:582 only "no installed tree" is excused, but the copy lookup is keyed by name@version, so a different installed version reads as "not installed". The statement names 1.16.0, not the installed 1.15.0, so it doesn't suppress the real component. Likely cross-ecosystem; for the maintainer

Sandbox hazard (again): agent scan in a dir without a venv patched the system /usr/lib/python3/dist-packages/six.py (the no-venv fallback). I rolled it back and verified the file is clean.

Issues

None filed, commented on or closed.

False positives ruled out

• Hosted rollback "Manifest not found": a mock-origin artifact without SOCKET_PATCH_SERVER_URL. Works once that's set.
• Vendored "tarball artifact has no sha512 integrity": a mock artifact without sha512.

Next

1. Maintainer input on the version-drift vex attestation (above) and the no-venv global fallback.
2. Re-verify 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 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 Fix lock-only requirements.txt discovery (#412, #523) #530 merges; 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; Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542.
3. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs (Fix global scan missing pipx venvs (#415) #418).
4. pip 26.x on the new grammar sweep (dupes / BOM / --no-index / --config-settings), and a Windows probe for BOM + CRLF together.
5. Lock-only vex with spaced pins once 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 lands.

[github-actions[bot]]

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

• 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: closed 2026-10-02 14:28 UTC
• 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: closed 2026-10-02 16:23 UTC
• 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: closed 2026-10-02 14:28 UTC

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

---

Generated by Claude Code

[github-actions[bot]]

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

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

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

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 045d7ec (moved since 61cfb9b: #478 PEP 440 pins, #530 lock-only discovery, #503 PyPI takeover, #572 shared hosted grammar) and latest release v4.0.0.

Setup:

• A rebuilt Python mock of patches/batch / by-package / package plus the hosted wheel route, matching purls exactly. It has no view / blob routes, so vendored can't run against it this time.
• Real pip 24.0 on CPython 3.11.
• VIRTUAL_ENV points at an empty venv for lock-only cells, so the system python3-six isn't touched.
• No probe branches: everything this run covered is OS-independent.

Re-triage

Issue	Result on 045d7ec
#410 (rollback when every requirement is a hosted pin)	still reproduces (the "not derivable" refusal). No comment, no new info
#542 (direct reference six @ file://… overwritten)	still reproduces (#572 didn't change it). No comment
#475, #412, #523, #328	closed by #478 / #530 / #503. mode_migration_pypi requirements lanes pass locally

Cells (Linux, pip 24.0 / py3.11)

Cell	Result
Lock-only hosted, six==1.16.0	pass
Lock-only hosted, six==1.16 / six == 1.16 / six==1.16.0.0 / six==01.16.0	fail → #604: purl sent verbatim (six@1.16), "No patches available", exit 0, and pip installs unpatched 1.16.0 (2/2 runs)
Lock-only vendored, six==1.16	fail (#604)
The same six==1.16 file with a venv holding 1.16.0	pass (the #475 fix)
Lock-only six==v1.16.0	not inventoried (exact_pin requires a leading digit); covered by #604
Vendored → hosted takeover with a real venv	hosted side passes, and a fresh pip install -r is PATCHED. Vendored side blocked (mock has no view)

Issues

• Filed Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604: Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604. This is the lock-only follow-up the Fix requirements.txt pins not matched under PEP 440 (#475) #478 author noted on 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; nothing tracked it before.

False positives ruled out

• VIRTUAL_ENV= (empty) makes the crawler fall back to the system dist-packages, which hold six 1.16.0. That hides lock-only behaviour. Use an empty venv instead.
• A loose mock (substring purl match) made six==1.16.0.0 look patched. The real API keys on the exact purl, so the mock now matches exactly.

Next

1. Re-verify Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604, Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542, 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 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 as fixes land.
2. Rebuild the mock with view / blob routes, then vendored lock-only PEP 440 pins and takeover with real pip.
3. pip 26.x and pip 20.3.4 on the run-eight grammar sweep against 045d7ec (new shared grammar from Recognize hosted Pipenv references through one shared grammar (#563) #572).
4. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs (Fix global scan missing pipx venvs (#415) #418).
5. Maintainer question still open: version-drift vex attestation and the no-venv global fallback.

[github-actions[bot]]

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

Tested: main 045d7ec, unchanged since the previous run, and latest release v4.0.0 (PyPI socket-patch==4.0.0, used for the regression check).

Setup:

• Real pip 26.2.1 on CPython 3.13 and pip 20.3.4 on CPython 3.8 (uv-managed 3.8.20).
• A Python mock of batch, by-package, package and the hosted wheel, plus the view route this time (backlog item 2), so scan --mode vendored runs discovery end to end.
• Vendored artifacts come from the repo's own prebuilt_common fixture server, run through a throwaway #[ignore] test (not committed).
• No probe branches: every cell this run is OS-independent text or JSON handling.

Re-triage

main hasn't moved, so #604, #542, #410 and #409 stand as last run. I didn't comment. #604 was re-observed (vendored lock-only six==1.16 → vendor.events: [], unpatched install, on pip 20.3.4 and 26.2.1). So was #410 (sole hosted pin → rollback exit 1).

Cells (Linux)

Cell	pip 26.2.1 / py3.13	pip 20.3.4 / py3.8
Hosted grammar sweep, 18 shapes × (scan → fresh pip install -r → rollback → reinstall): base, BOM, CRLF, marker, continuation marker, extras, Six== + comment, tab comment, --index-url, hashed continuations, marker split, spaced, ===, unpinned, editable neighbour	pass	pass
Hosted ~= / range	refused redirect_requirements_version_ambiguous (documented)	same
Hosted single --hash in an otherwise unhashed file	pip fails both before and after (input already broken for pip); rollback drops the lone hash	same
Vendored grammar sweep (vendor with staged manifest), same 18 shapes	pass; extras → pypi_extras_unsupported; unpinned, range, ~=, === → explicit refusals (fail-closed)	same
Vendored scan (discovery), lock-only: -r base.txt, -rbase.txt, --requirement=base.txt, CRLF include, -r sub/base.txt	pass (include rewired, PATCHED, rollback restores)	pass
Lock-only hosted six == 1.16.0, six (==1.16.0) (#523 re-verify)	pass	pass
Lock-only hosted -r base.txt (#412 re-verify)	discovered; redirect_requirements_entry_not_found (documented root-only)	same
-c constraints.txt (vendored and hosted; root six, six>=1.10 or six==1.16.0)	hosted pass / ambiguous refusal; vendored pypi_requirement_not_pinned for unpinned root (fail-closed)	—
Hosted re-run idempotency and re-pin after grant-token rotation	pass	—
Hosted with no root requirements.txt (requirements-dev.txt only, requirements/base.txt only, none)	fail → #638	fail → #638

Issues

• Filed Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638: Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638. Hosted --json reports success with empty skipped and warnings when a PyPI project has no root requirements.txt. Human output names the package, but no redirect_pypi_no_lockfile-style code is emitted, unlike npm, pnpm, vlt, composer, gem, maven and go. Same on v4.0.0, so not a regression.

False positives and limits ruled out

• record_fetch_failed in the first sweep was a mock artifact (no view route); it was gone once the route was added.
• Rollback rewrites an unpinned hosted six back as six==1.16.0 (and === as ==). Hosted mode is stateless, so the restore derives the line from the hosted URL by design. Not filed; added to the maintainer questions below. It matters most with -c constraints.txt workflows, where a later constraint bump then conflicts with the new root pin.
• The vendored -c refusal says "six is not pinned to ==1.16.0" even though the constraint pins it. The wording is imprecise but the behaviour is fail-closed.

Next

1. Re-verify Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638, Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604, Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542, 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 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 as fixes land.
2. Windows / macOS probe: CRLF + BOM on the patched line, vendored path line with real pip (backlog 5).
3. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs (Fix global scan missing pipx venvs (#415) #418).
4. Vendored takeover (vendored → hosted and hosted → vendored) with the now-complete mock and real pip 20.3.4 / 26.2.1.
5. Maintainer questions: version-drift vex, the no-venv global fallback, and whether rollback should keep an unpinned root unpinned.

[github-actions[bot]]

[agent] 2026-10-03 (08:23 UTC): pip / requirements.txt bug-hunt run

Tested: main 045d7ec, unchanged since the previous run. Latest release v4.0.0.

Setup:

• Real pip 26.2.1 on CPython 3.13.7 and pip 20.3.4 on CPython 3.8.20 (uv-managed).
• Hosted API: the mode_migration_pypi.rs wiremock. Vendored artifact: prebuilt_common::mount_project mounted on the same mock, with --vendor-url and --patch-server-url both pointing at it.
• The probe test was a throwaway and was not committed.
• No probe branches: every cell this run is OS-independent.

Re-triage

main hasn't moved, so #638, #604, #542, #410 and #409 stand as last run. I didn't comment. The #410 sole-pin refusal was re-observed on the hosted → vendored takeover (redirect_revert_failed, "every requirement … is a hosted pin").

Cells (Linux)

Cell	pip 26.2.1 / py3.13	pip 20.3.4 / py3.8
Hosted → vendored takeover via vendor (idna + six; hashed with sdist + wheel hashes; CRLF + marker + comment), then fresh pip install -r	pass (patched six installed)	pass
The same takeover with six as the sole pin	refused #410 (known)	same
Takeover re-run (idempotency)	pass (already_vendored, bytes identical)	—
vendor --revert after the takeover	pass: lands on the upstream line. Hashed restore carries the real PyPI wheel and sdist hashes; CRLF kept	—
vendor --dry-run over the hosted project	fail → #668 (pypi_requirement_not_pinned, exit 1; the wet run succeeds)	OS/pip-independent
scan --mode vendored --dry-run over the hosted project	pass (would_vendor)	—
rollback / remove --dry-run vs wet over a hosted marker line	pass (parity, dry leaves the bytes alone)	—
Agent apply over a PEP 660 editable six (pip 26, setuptools finder .pth)	fails closed: apply_failed "six.py - File not found", exit 1, user source untouched	—
Agent apply over a legacy develop editable (six.egg-link, pip 20.3.4)	—	fails closed: "matched no installed package", exit 1, user source untouched

Issues

• Filed vendor --dry-run over a hosted requirements.txt pin previews a pypi_requirement_not_pinned failure (exit 1), but the real vendor takes it over and succeeds #668: vendor --dry-run over a hosted requirements.txt pin previews a pypi_requirement_not_pinned failure (exit 1), but the real vendor takes it over and succeeds #668. vendor --dry-run over a hosted requirements.txt previews a pypi_requirement_not_pinned failure with exit 1, but the wet vendor takes the pin over and succeeds. The backend preview reads the still-hosted line. Bun already has the skip at vendor.rs ~2505; requirements.txt doesn't. The other Python flavors weren't checked (sibling routines own them).

False positives and limits ruled out

• vendor_prebuilt_required "serve returned 404/410" in the first takeover run was a harness artifact: --patch-server-url rewrites the artifact host, so the prebuilt routes must live on that same mock.
• Without SOCKET_PATCH_SERVER_URL / --patch-server-url, a mock-hosted line looks like a user direct reference, and vendor refuses it pypi_requirement_not_pinned (fail-closed, mock artifact).
• Editable installs aren't patched in agent mode. Both shapes fail loudly (exit 1) and never write into the user's source checkout. Added to known non-bugs.

Next

1. Re-verify vendor --dry-run over a hosted requirements.txt pin previews a pypi_requirement_not_pinned failure (exit 1), but the real vendor takes it over and succeeds #668, Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638, Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604, Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542, 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 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 as fixes land.
2. A Windows / macOS probe: BOM + CRLF on the patched line, with real pip on the vendored path line.
3. get --mode vendored over a hosted pin (the same takeover through get), and its --dry-run.
4. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs (Fix global scan missing pipx venvs (#415) #418).
5. pip 21.3–23.x boundary spot-checks: agent mode on egg-info, --use-pep517 builds.

[github-actions[bot]]

[agent] 2026-10-03 (14:18 UTC): pip / requirements.txt bug-hunt run

Tested: main 045d7ec, unchanged since the previous run. Latest release v4.0.0.

Setup:

• Real pip 26.2.1 on CPython 3.13 and pip 20.3.4 on CPython 3.8. For the agent boundary cells: pip 21.3.1 / py3.10, 22.3.1 / py3.11, 23.0.1 / py3.11 and 23.1.2 / py3.12.
• Hosted API: the mode_migration_pypi.rs wiremock. Vendored artifacts: prebuilt_common::mount_view on the same mock (plus a view route), with --vendor-url and --patch-server-url pointing at it. The harness was a throwaway and was not committed.
• No probe branches: every cell this run is OS-independent text logic, and earlier probe branches still can't be deleted from the sandbox.

Re-triage

main hasn't moved and no fix PR touches the open pip issues, so #668, #638, #604, #542, #410 and #409 stand. I didn't comment.

Cells (Linux)

Cell	pip 26.2.1 / py3.13	pip 20.3.4 / py3.8
get <uuid> --mode vendored over a hosted pin (fragment form), then fresh pip install -r	pass (patched)	pass
get --mode vendored --dry-run over the hosted pin	pass (would_vendor; unlike vendor --dry-run, #668)	—
get --mode vendored re-run	pass (already_vendored)	—
The same over a hashed file (CRLF, marker, wheel + sdist hashes), then pip in hash mode	pass	pass
The same over a BOM + CRLF file, then rollback	pass (the vendored line drops the BOM, pip doesn't care; rollback restores BOM + CRLF)	—
Wet scan --mode vendored over a hosted pin, plus a re-run	pass (vendor_takeover_reverted_redirect, then already_vendored)	—
Vendored → hosted takeover, pin in a -r base.txt include	fail → #699: dry run says redirected: 1; the wet run reverts and strands six unpatched (exit 1, redirect_takeover_unpatched); pip installs unpatched six	same
Vendored → hosted takeover, vendor-added (transitive) line (six only in requirements-dev.txt)	fail → #699 (same shape)	—
Vendored (transitive) line: pip install -r requirements.txt -r requirements-dev.txt	pass (patched)	pass
Vendored (transitive) line appended to a hash-pinned root (gets its own --hash), pip in hash mode	pass	pass
Agent apply / re-apply / rollback on egg-info (setup.py install)	pip 21.3.1, 22.3.1, 23.0.1: pass	—
Agent apply / rollback on dist-info	pip 23.1.2: pass. pip uninstall after apply works on all four	—

Issues

• Filed Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699: Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699. The vendored → hosted takeover reverts a vendored pin that hosted can't reach (a -r include or a vendor-added (transitive) line), so the project ends up unpatched. --dry-run previews a clean takeover because hosted.rs:1018 counts every preview as confirmed. First bad: 0ac5b91a (Fix PyPI vendored to hosted takeover being refused (#328) #503).

False positives and limits ruled out

• Agent rollback --offline "Before blob not found": my staging had no before blob. It passes once the blob is present.
• A hashed-case "hash mismatch" was my wrong idna hash in the fixture.
• pip install -r requirements-dev.txt alone still installs upstream six when vendored mode wired the root (transitive) line. That's the same class as Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 (Pipenv) and Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638 (hosted). Not re-filed; it's a backlog question.

Next

1. Re-verify Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699, vendor --dry-run over a hosted requirements.txt pin previews a pypi_requirement_not_pinned failure (exit 1), but the real vendor takes it over and succeeds #668, Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638, Lock-only requirements.txt discovery sends PEP 440-equivalent pins verbatim (six==1.16 → pkg:pypi/six@1.16), so a fresh checkout reports "No patches available" while the same file with a venv is patched #604, Hosted requirements.txt rewrite replaces a user's own direct reference (six @ https://mirror/…/six-1.16.0-….whl, file:// fork) with the Socket PyPI build, and rollback then restores six==1.16.0 from PyPI, losing the original source #542, 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 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 as fixes land.
2. get --mode hosted over a vendored include pin (the same takeover through get), once Vendored → hosted takeover strands a requirements.txt pin that lives in a -r include or a vendored "(transitive)" line: the wet run reverts it to the unpatched release, while --dry-run previews a clean takeover #699 is triaged.
3. Vendored (transitive) line semantics: should vendored also rewrite (or warn about) a sibling requirements-*.txt that pins the patched package directly?
4. Finish -g: Homebrew / PEP 668, the py launcher, pipx venvs (Fix global scan missing pipx venvs (#415) #418).
5. A Windows / macOS probe for the vendored path line with BOM + CRLF, once probe branches can be deleted.