Bug hunt ledger: uv

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled uv bug-hunt routine (label pm:uv).

Last run: 2026-10-06 (run 24) on main 9c43dfc (main unchanged since run 21. New #944: the hosted → vendored takeover (scan / get --mode vendored) restores six to PyPI BEFORE the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (pypi_uv_lock_parse_failed) or a #928 marker-split requirements.txt (pypi_requirement_not_pinned) leaves six unpatched in both modes, exit 1, while --dry-run previews would_vendor; Linux × 0.5.31 / 0.8.17 / 0.12.23. Standalone vendor keeps it hosted (pass). #928 commented: the split across a -r include refuses the same way). Run 23 on main 9c43dfc (main unchanged since run 21. New #928: vendored requirements.txt from uv pip compile --universal with a marker-split package (six==1.16.0 ; python<3.12 + six==1.17.0 ; python>=3.12) refuses pypi_requirement_not_pinned ("not pinned to ==1.16.0", which is false) while --dry-run previews would_vendor; hosted and vendored pylock handle the same split; Linux × 0.5.31 / 0.8.17 / 0.12.23. Universal pylock (hosted + vendored), the vendored pylock lifecycle with vex and a regenerated lock, and a forked script lock refusal all pass). Run 22 on main 9c43dfc (main unchanged since run 21. macOS confirms #890 and #891, so both now fail on all 3 OS. #890 also hits the project lane: a deleted uv.lock blocks revert / remove / rollback, and the takeover exits 0. --cwd (relative, absolute, .., space in the path), VEX after partial unwiring, agent mode on uv 0.2.37–0.12.23, a vendored pyproject-variant sweep and list all pass). Run 21 on main 9c43dfc (main moved: #858 atomic-write core, #802 vendored symlink refusal, #807 pip pylock rollback and others. New #890: once the user deletes one of several vendored PEP 723 scripts (or its .py.lock, or one of two pylocks), vendor --revert / remove / rollback fail on cannot read for the whole entry, and the V→H takeover exits 0 telling the user to run that same revert; Linux × 0.8.17 / 0.12.23 and Windows × 0.12.23. New #891: the vendored dry run (scan / get) gives no vendor_would_refuse_symlinked_file for a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml, although the wet run refuses (exit 1); Linux × 0.8.17 / 0.12.23 and Windows × 0.12.23. #723 and #767 (vendored half) re-checked: still fail. File modes, symlink refusals (hosted + vendored, no residue), uv-exported pylock hosted rollback, script-lock constraint / CRLF / index-source variants and vendor --check after unwiring all pass). Run 20 on main 99f61d2 (main moved: #789, #743, #822, #841, #625 and #672 merged, and #788 / #806 / #821 / #840 / #670 / #606 / #473 are closed. New #869: the #840 shape on PEP 723 script locks, where vendored vendor --revert / remove / rollback write the stale ==1.16.0 back into s.py.lock after a specifier edit and uv run --locked fails with exit 0; Linux × 0.5.31 / 0.8.17 / 0.12.23 and Windows. #411 and #564 re-checked: still fail. The #841 project-lane fix passes on 5 versions × deps / extra / dev × 11 specifier spellings). Run 19 on main 045d7ec (new #840: after the user changes the vendored package's own specifier (uv add "six>=1.16,<1.17"), uv.lock stays byte-identical, because path sources carry no specifier, so vendor --revert / remove / rollback write the stale pre-vendor ==1.16.0 back and uv sync --locked fails with exit 0; 3 OS × 0.5.31 / 0.8.17 / 0.12.23, and not fixed by PR #822. PR #822 verified to fix #806 / #821 and their neighbours (two groups, include-group, deps + dev, user constraint-dependencies edit)). Run 18 (new #821: vendored package in a dependency group; after uv add --dev / uv remove --dev, vendor --revert / remove / rollback / V→H takeover revert pyproject.toml but keep uv.lock's whole-line requires-dev fragment, so uv sync --locked fails; 3 OS × 0.8.17 / 0.12.23, plus 0.2.37 / 0.4.30 / 0.5.31 on Linux. Script lock with a user override drift-keeps both files (consistent)). Run 17 on main 045d7ec (new #806: vendored transitive override + a user-authored override-dependencies; after a relock, vendor --revert / remove / rollback revert pyproject.toml but drift-keep uv.lock's [manifest] overrides, so uv sync --locked fails; 3 OS × 0.8.17 / 0.12.23. PR #789 verified to fix #788. Agent mode on a project .venv passes on 3 OS × 3 link modes; script-lock CRLF / BOM, uv pip compile flavours, git / path / url siblings, name normalization and --dry-run all pass). Run 16 (new #788: uv 0.6.15–0.6.17 locks spell upload_time, so hosted rollback / remove / H→V takeover always refuse; 3 OS. Version sweep 0.6.17 / 0.7.22 / 0.9.30 / 0.10.12 / 0.11.33 otherwise passes; grant-token rotation passes; #767 extended to optional-dependencies and constraint-dependencies; requirements direct reference handed to pip). Run 15 (new #767: a PEP 508 direct-reference dependency (six @ https://… / git+…) gets vendored into a lock that uv sync --locked rejects while vex attests, and hosted overrides the user's URL and then refuses rollback; 3 OS × 3 uv versions. PR #743 verified to fix the hosted half of #742. -g lifecycle passes on macOS / Windows via a probe. A uv lockless-pyproject shape was added to #638). Run 14 (new #742: a superseding patch uuid is never applied on uv. Hosted re-scan refuses its own [tool.uv.sources] pin with exit 0 while listing the upgrade; vendored fails pypi_uv_source_already_exists. #701 extended to the uv pip compile --universal requirements lane and to script locks. 0.12.23 baseline passes on 3 OS via a probe). Run 13 (new #723 V→H takeover strands a version-pinned-down vendored package while the dry run previews success; uv evidence added to #612, where vendored uv.lock + an exported requirements.txt is left silently unpatched; uv 0.12.23 baseline passes). Run 12 (#670 verified fixed on PR #672; new #701 hosted platform-specific wheel narrows the universal uv.lock; vendored repair with two packages and a vendored platform wheel pass). Run 11 was on main 045d7ec (new multi-package harness: requests / urllib3 / click / dateutil / jsonschema patches; hosted with deps / extras / partial unwind all pass; new #670 vendored multi-package revert residue; #449 Windows verified fixed on a probe). Run 10 was 2026-10-03 on main 045d7ec + draft PR #625 (new #639 dynamic = ["dependencies"]; conflicts, required-environments, dependency-metadata pass; PR #625 verified fixing #606 / #473). Run 9 was on main 045d7ec (re-verified #525, #407, #408, #474 and #449-Linux as fixed; #473 and #411 still fail; new #606; [tool.uv] resolution settings, symlink link-mode). Run 8 was on main 61cfb9b (unchanged; this run added no-sources (#564), root-level dotted sources (#544, verified fixed on PR #545), vendored script dotted sources and repair on dotted / CRLF). Run 7 added path/git siblings, legacy dev-dependencies, constraint-dependencies, vendored sources spellings and uv 0.12.22). Run 6 was also on 61cfb9b (the dotted-name, sources-spelling, lock-only and UV_PROJECT_ENVIRONMENT cells). Run 5 was also on main 61cfb9b (v5; CLI reports 4.0.0, and the released 4.0.0 predates both the v4 uv rewriter and the v5 upstream restore). Earlier cells are from 2463257 / 6e7ef74. Linux runs use real uv against a local mock patch API (with integrity.sha512 in SRI form, a deterministic wheel, the /blob/ route and --patch-server-url), plus SOCKET_PYPI_JSON_API → a local pypi.org pass-through that must not rewrite file URLs. uv 0.1.x needs SSL_CERT_FILE; uv 0.0.5 needs PUFFIN_INDEX_URL → a local /simple/ proxy. macOS and Windows runs use probe branches.

Coverage matrix

H = hosted, V = vendored, A = agent. "pass/fail" is Linux unless an OS is named. Results are from v5 main (2463257 / 6e7ef74) unless marked (v4).

uv	H native	H rollback / remove (upstream restore)	V native	V repair	A	Other
0.0.5 / 0.1.20 / 0.1.32 / 0.1.44 (requirements lane)	pass (hashed and unhashed; 0.1.44 on 3 OS)	pass byte-identical; fail #477 stale install after unwind (3 OS)	pass (0.1.44, 3 OS, hashed, LF/CRLF)	–	untested
0.1.45 / 0.2.5 / 0.2.18 / 0.2.34 ([[distribution]])	pass (plain sync; 0.2.34 --frozen/--locked)	refused (documented)	refused (documented)	–	untested
0.2.37 / 0.4.30	pass	pass after edit / uv add (Linux, macOS, Windows); fail #411 user override (Linux, Windows); fail #477 uv sync keeps patched wheel after rollback	pass	pass (Linux, macOS, Windows)	untested
0.5.17 / 0.5.31	pass; requirements lane pass (3 OS)	pass after edit / uv add (3 OS); fail #411 (3 OS); fail #473 (3 OS); fail #477 stale after rollback (uv.lock and uv pip sync)	pass; fail #474 (3 OS, 0.5.17 Linux)	pass (Windows, macOS)	untested
0.8.17	pass (explicit / default local index, groups, package = false, environments, self-ref extras, hashed-requirements variants, uv.lock + exported requirements.txt, two pylocks)	pass after uv remove / uv lock --upgrade-package; fail #407; fail #408 (re-confirmed on 61cfb9b); fail #411; fail #473 include-group (3 OS); fail #477 stale after rollback/revert	pass (script lock, pylock.dev.toml, include-group); fail #474 script revert after uv add --script (3 OS)	untested	pass (v5: hardlink, VEX, reinstall → re-apply)	workspace refused (by design)
0.8.18 – 0.12.0 (bisect)	–	uv sync after rollback reinstalls upstream (uv-side fix in 0.8.18)	–	–	–
0.12.21	pass (requirements lane on 3 OS, --locked/--frozen/plain, inline sources, BOM, odd-case name, idempotent, VEX, pylock, script lock, CRLF, hashed requirements, markers, ranges, groups, extras, transitive override)	pass after edit / uv add (3 OS), script lock, hashed requirements, CRLF, multi-file; fail #411 (3 OS); fail #407; fail #408; fail #473 (3 OS); uv pip sync after requirements unwind fail #477 (3 OS)	pass; fail #474 (3 OS)	pass (3 OS, venv + lock-only)	pass (v5: hardlink apply / VEX / rollback / re-apply)	H→V pass (v5); V→H warn-only
0.8.17 (run 6)	pass: dotted name backports.tarfile in 3 spellings; dotted / root / inline sources spellings; lock-only checkout with space + unicode path, --frozen cold cache, idempotent re-scan	fail #524 [tool.uv.sources.<name>] sub-table leaves an empty header (rollback, remove; also 0.5.31)	pass (dotted name); fail #524 (vendor --revert)	–	fail #525 UV_PROJECT_ENVIRONMENT ignored (abs + relative)	forks refused (documented)
0.4.30 / 0.5.31 / 0.8.17 / 0.9.5 / 0.12.22 (run 7)	pass: editable path sibling, legacy dev-dependencies (0.4.30 / 0.5.31 / 0.8.17), constraint-dependencies (0.8.17 / 0.9.5 / 0.12.22), inline [tool] uv = {…} / root tool = {…} / sources.x.path	pass byte-identical (path sibling, dev-deps, constraints, inline / dotted sources); git-only sibling refused (documented)	pass: dev-deps on 0.4.30 / 0.5.31 (incl. cold --frozen --offline), [tool.uv.sources] before [project], CRLF; fail #544 dotted [tool.uv] sources.x / [tool] uv.sources.x: revert / remove half-revert (0.5.31, 0.8.17, 0.12.22)	–	–	vendored inline sources refused (not a standard table)

| 0.5.31 / 0.8.17 / 0.12.22 (run 8) | fail #564 [tool.uv] no-sources = true (also uv.toml) | – | pass: script # [tool.uv] dotted sources, repair on dotted / CRLF; fail #544 root-level tool.uv.sources.x (fixed on PR #545); existing { index } source refused | pass (dotted, CRLF) | – | |
| 0.4.30 / 0.5.31 / 0.8.17 / 0.12.22 (run 9, main 045d7ec) | pass: exclude-newer-package, required-version, index-strategy, reinstall-package, default mirror index, pylock (compile + export; #407/#408 fixed); fail #606 six declared with different specifiers (deps + extra, two extras, marker split) | fail #606 (rollback, remove, takeover); fail #473 and #411 still reproduce; no-binary / no-build refused (documented) | pass: #606 pyproject; #474 script revert after uv add --script (fixed) | – | pass: UV_PROJECT_ENVIRONMENT abs + relative (#525 fixed); UV_LINK_MODE=symlink on 0.5.31 / 0.8.17 / 0.12.22 | -g UV_TOOL_DIR with space + unicode: scan + agent apply pass (#449 Linux fixed) |
| 0.4.30 / 0.5.31 / 0.8.17 / 0.12.22 (run 10, main 045d7ec) | pass: [tool.uv] conflicts (extras), required-environments, dependency-metadata; fail #639 dynamic = ["dependencies"] (scan wires it) | fail #639 (rollback, remove, takeover; also on PR #625); #606 / #473 pass on PR #625 | pass: conflicts / required-environments / dependency-metadata (0.8.17, 0.12.22); dynamic refused by design (pypi_uv_dynamic_dependencies) | – | – | |

| 0.5.31 / 0.8.17 / 0.12.22 (run 11, main 045d7ec) | pass: patched packages with deps / extras / markers (requests[socks], urllib3[socks,brotli], click, jsonschema[format] + transitive dateutil), two patched packages at once, uv pip compile --emit-* hashed requirements, pylock + pylock.dev.toml with deps | pass: full and partial rollback / remove (both orders), byte-identical | pass for a single package with deps; fail #670 two or more packages → vendor --revert leaves empty [tool.uv.sources] (also hosted→vendored takeover); script lock sdist reorder (cosmetic) | – | VEX after partial unwind pass | V→H takeover with 2 packages pass (#503) |
| 0.5.31 / 0.8.17 / 0.12.22 (run 12, main 045d7ec) | fail #701 platform-specific patched wheel (MarkupSafe cp311 manylinux) wired with no warning: uv sync --locked fails on py3.12 and on macOS / Windows (--python-platform); pylock too | refused (documented: release has non-pure wheels) | pass: platform wheel (vendor_platform_locked), two packages after uv add; #670 fixed on PR #672 (3 versions) | pass: two packages, one wheel deleted | – | |

| 0.5.31 / 0.8.17 / 0.12.22 / 0.12.23 (run 13, main 045d7ec) | pass: 0.12.23 baseline (uv.lock + exported requirements, --locked / cold --frozen / uv pip sync, rollback byte-identical); V→H takeover with exported requirements | fail #723 V→H takeover after a vendored version pin-down (transitive / direct; 0.5.31, 0.8.17, 0.12.23; also on PR #708) | fail #612 (uv comment) uv.lock + uv export requirements.txt: requirements left unpatched with no warning (4 versions); script lock + uv.lock warns (documented) | – | pass (0.12.23 agent scan) | |

| 0.5.31 / 0.8.17 / 0.12.23 (run 14, main 045d7ec) | fail #742 patch upgrade (new uuid) not applied: project + script lock, exit 0; fail #701 (comment) uv pip compile --universal requirements + script lock with a cp311 wheel; 0.12.23 baseline pass on Linux / macOS / Windows (probe) | pass: rollback byte-identical (3 OS); requirements platform-wheel rollback byte-identical | fail #742 re-vendor on a new uuid (pypi_uv_source_already_exists); baseline pass on 3 OS (unicode + space dir); H→V takeover with exported requirements: uv.lock pass, requirements.txt unpatched (#612) | – | – | V→H takeover pass on 3 OS |

| 0.5.31 / 0.8.17 / 0.12.23 (run 15, main 045d7ec) | fail #767 PEP 508 direct reference (six @ https://…): overrides the user URL; pylock archive rollback becomes a registry entry; lockless pyproject is silent (#638 comment); pass: cross-version --locked, re-lock across revisions, trailing-slash index, resolution-markers lock, get (purl / uuid / name), concurrent scans; PR #743 fixes the #742 upgrade (project / override / script, --max-new-patches 0) | fail #767 (rollback refuses "direct reference", 3 OS) | fail #767 (requires-dist gets url + path → --locked fails, vex attests; also git refs, dependency groups; 3 OS); pass: get, forked lock | – | pass: UV_COMPILE_BYTECODE, 0.5.31 / 0.12.23 × hardlink / copy, get | script with space + unicode name pass |

| 0.6.15–0.6.17 / 0.7.22 / 0.9.30 / 0.10.12 / 0.11.33 (run 16, main 045d7ec) | pass: round trip on all; grant-token rotation (0.5.31 / 0.8.17 / 0.12.23); comments / editable path source formatting; build-constraint-dependencies; pylock.<name>.toml names; fail #767 direct ref in optional-dependencies / constraint-dependencies | fail #788 on 0.6.15–0.6.17 (upload_time: rollback, remove, takeover, script lock; 3 OS); pass on 0.7.x+ (3 OS for 0.7.22) | pass on all; fail #767 optional / constraint direct ref (--locked fails, vex attests) | – | – | hosted write failure mid-commit leaves pyproject.toml half-written (recoverable by re-scan; candidate) |

| 0.5.31 / 0.8.17 / 0.12.21 / 0.12.23 (run 17, main 045d7ec) | pass: git / editable-path / URL siblings, marker-split sources arrays, script lock LF / CRLF / BOM, uv pip compile flavours, typing_extensions name spellings, version spellings (==3.7.0, ==3.7.*, ~=), --dry-run writes nothing | pass byte-identical (same cells); === refused (conservative); ==3.07 restores the user's spelling (cosmetic) | pass (same cells); fail #806 user override-dependencies + transitive override, then uv add / uv lock --upgrade-package → half revert (3 OS × 0.8.17 / 0.12.23; 0.5.31 Linux) | – | pass: project .venv on Linux / macOS / Windows × default / hardlink / copy (probe), symlinked .venv; uv cache never polluted | lockless PEP 723 script: scanned 0 (unsupported input) |

| 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23 (run 18, main 045d7ec) | pass: user constraint-dependencies + relock; script lock with user override / constraints | pass after uv add --dev (hosted; 3 OS × 0.8.17 / 0.12.23) | fail #821 six in a dev group (PEP 735 / legacy) + uv add --dev / uv remove --dev → half revert (3 OS); pass for dependencies / extras / other groups | – | – | V→H takeover on #821's shape: half revert, exit 0 |

| 0.5.31 / 0.8.17 / 0.12.23 (run 19, main 045d7ec + PR #822) | pass: hosted rollback after a single-clause spec edit re-derives it | multi-clause spec edit refused (documented) | fail #840 user edits six's own specifier then revert / remove / rollback → stale ==1.16.0 (3 OS × 3 versions; PR #822 too); #806 / #821 + neighbours + constraint edit fixed on PR #822 | – | – | V→H takeover after a spec edit pass (3 OS) |

| 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23 (run 20, main 99f61d2) | idempotent re-scan pass (project + script × hosted + vendored); fail #564 still (3 versions); script lock spec edit → V→H takeover pass | fail #411 still (3 versions × rollback / remove) | fail #869 script lock spec edit → revert / remove / rollback stale ==1.16.0 (Linux 3 versions, Windows 0.5.31 / 0.12.23, macOS 0.12.23); #840 fix pass (deps / extra / dev × >= ~= != ==.* < bare, Six, (>=…), markers simplified away); marker / extras-on-six / multi-clause / constraint edits drift-keep both files (--locked ok) | – | – | H→V takeover after a spec edit pass (project + script) |
| 0.8.17 / 0.12.23 (run 21, main 9c43dfc) | pass: file modes kept (0600 pyproject, 0664 uv.lock, 0755 script, 0640 .py.lock) through scan + rollback; symlinked pyproject / uv.lock / s.py / s.py.lock / pylock refused before any write (wet and dry); uv-exported pylock.toml / pylock.dev.toml hosted rollback byte-identical (#807 no regression); script lock with [tool.uv] constraint-dependencies / CRLF / [[tool.uv.index]] source round trip; two scripts round trip | pass: two-script rollback; one script deleted → hosted rollback pass | fail #890 one of several wired scripts / script locks / pylocks deleted → revert / remove / rollback fail, takeover stuck (Linux 2 versions, Windows 0.12.23); fail #891 dry run gives no symlink warning for script / pylock files (Linux 2 versions, Windows 0.12.23); vendor --check after unwiring fails correctly; fail #723 / #767 still | – | – | regenerated uv.lock after vendoring → revert clean |

| 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23 (run 22, main 9c43dfc) | pass: --cwd relative / absolute / ../ with a space in the project dir (project + script, --locked ok); VEX after unwiring pyproject / uv.lock / both / deleting the lock (no over-attestation); list --json (project, script, two scripts, pylock) | pass: --cwd rollback | fail #890 project lane: uv.lock deleted → revert / remove / rollback exit 1, takeover exit 0 (0.8.17 / 0.12.23); pass: pyproject-variant sweep (package = false, hatchling, requires-python upper bound, editable path sibling, inline comments, extras-only six), uv.lock + exported pylock warns pypi_multiple_lockfiles; macOS confirms #890 / #891 | – | pass: uv venv + uv pip install and uv sync venvs on 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23 (scan, apply, reinstall then re-apply, uv pip check, vex, rollback, vex refuses after rollback) | BOM pyproject: every writer drops the BOM (uv-consistent, not filed) |
| 0.5.31 / 0.8.17 / 0.12.23 (run 23, main 9c43dfc) | pass: uv pip compile --universal marker-split six (1.16.0 / 1.17.0) → requirements.txt (plain and --generate-hashes) and pylock.toml rewrite only the 1.16.0 entry (py3.11 patched, py3.12 upstream) | pass: byte-identical rollback (requirements + pylock) | fail #928 marker-split --universal requirements.txt → pypi_requirement_not_pinned (exit 1), dry run previews would_vendor (3 versions); pass: marker-split pylock (wire, vex, regenerate the lock → vex refuses, revert byte-identical; 0.8.17 / 0.12.23), same-version two-marker requirements lines | – | – | forked PEP 723 script lock refused in both modes, nothing written |
| 0.5.31 / 0.8.17 / 0.12.23 (run 24, main 9c43dfc) | – | – | fail #944 H→V takeover via scan / get --mode vendored un-hosts six before the vendored refusal (inline [tool.uv] sources = {…}; #928 split requirements); standalone vendor keeps it hosted (pass); #928 split across a -r include (either side) refuses, dry run says would_vendor (comment on #928) | – | – | |

Global (-g) mode

OS	uv	scan -g default tool dir	UV_TOOL_DIR / XDG_DATA_HOME	UV_PYTHON_INSTALL_DIR	hosted refusal	get / rollback / vex -g
Linux	0.4.30 / 0.5.31 / 0.8.17 / 0.9.5 / 0.12.23	pass	pass (#449 fixed, run 9 / 11)	pass (run 15, space + unicode)	pass (exit 2)	pass (run 15, mock: apply / list / vex --product / rollback / get / remove; stale reinstall → vex refuses)
macOS	0.4.30 / 0.5.31 / 0.8.17 / 0.9.5 / 0.12.23	pass	pass (run 15 probe, space + unicode)	pass (run 15 probe)	untested	pass (run 15 probe, 0.8.17 / 0.12.23)
Windows	0.4.30 / 0.5.31 / 0.8.17 / 0.9.5; 0.8.17 / 0.12.22 (run 11); 0.12.23 (run 15)	pass on main 045d7ec (#449 fixed: %APPDATA%\uv\tools)	pass (UV_TOOL_DIR with space + unicode, XDG_DATA_HOME)	pass (run 15 probe)	untested	pass (run 15 probe, 0.8.17 / 0.12.23)

SOCKET_GLOBAL=1, --global-prefix / SOCKET_GLOBAL_PREFIX with space and unicode paths, and project isolation (-g skips .venv) all pass on Linux.

Backlog

0. Re-triage uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 (new, run 24), Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 (run 23; -r include shape added run 24), Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 (3 OS, now covers the project lane too) / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 (3 OS), Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice still pending after Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639, and the Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / 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 uv shapes, once main moves. Main has not moved since run 21 (9c43dfc). Verified fixed and closed: Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840, Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821, Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806, Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788, Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606, Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473, Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408, Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525, uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524, Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544, Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449.
1. Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 neighbours: script lock with six through [tool.uv] override-dependencies / constraint-dependencies in the PEP 723 block, CRLF / BOM scripts. (Done in run 20: Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840 project lane on 5 versions, H→V after an edit, user constraint edits.) Also a Windows probe of hosted write atomicity (uv.lock held open without delete sharing).
2. Patch-upgrade follow-ups: (grant-token rotation passes, run 16); vendored re-vendor once PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743's follow-up lands.
3. uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 neighbours: other uv vendored-only refusals reached after the takeover restore (a transitive package with a user override-dependencies → pypi_uv_source_already_exists; requirements.txt extras six[x]== → pypi_extras_unsupported; an out-of-root -r include; pylock). Standalone vendor --dry-run says eject_planned exit 0 on the inline-sources project where the wet run exits 1 (check against the Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 / uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 dry-run parity before filing). --universal requirements with extras on the split package (still open). Interrupted runs with fault injection (a slow mock route). Hosted with a release that has several sdists.
4. Probe branches can't be deleted from the cloud session (git push --delete hangs up through the proxy). Twenty bughunt/uv/* branches need maintainer cleanup, including 20261005-symlink-dryrun, 20261005-deleted-script, 20261005-script-spec-revert, 20261005-spec-edit-revert, 20261005-dev-group-drift and 20261004-upload-time.
5. (Done in run 15) The maintainer request for -g rollback / vex and the macOS -g re-probe, with the mock instead of a live patch. The unwritable-prefix cell is still open: ubuntu-latest runners exit 1 on apply / get / vex -g while the target is patched (likely the root-owned system six); confirm with stderr.

Known non-bugs

• uv workspaces ([tool.uv.workspace] or [manifest] members beyond the root) are refused in both modes (redirect_uv_project_unsupported / pypi_uv_workspace_unsupported). This is by design, though it's missing from docs/testing/uv-compatibility.md.
• Scanning from inside a workspace member directory falls through to the PATH interpreter and finds nothing.
• (Obsolete since Fix PyPI vendored to hosted takeover being refused (#328) #503) vendored → hosted on a uv project used to be warn-only. On main 045d7ec it takes over in place (redirect_takeover_reverted_vendored) and unwinds byte-identically (run 11).
• v5 hosted rollback refuses a uv project whose only registry package is the patched one ("no sibling registry package…"). Documented in CLI_CONTRACT "Hosted unwind coverage".
• v5 hosted rollback refuses a multi-clause direct specifier (six>=1.10,<1.17) unless another lock entry shows uv's clause spelling. This is in the upstream/uv.rs module doc, not the user docs. It's justified: uv 0.2.37 keeps clause order and ≥0.5 sorts them.
• v5 hosted rollback refuses [[distribution]] locks, exclude-newer / no-binary / no-build, and non-PyPI registries (documented).
• Hosted rollback without --patch-server-url for a non-Socket origin reports "Manifest not found" (the origin isn't recognised as hosted). This is a harness artifact.
• vendor_fetch_failed / "error sending request" for pypi.org / files.pythonhosted.org in the sandbox is a rustls vs proxy-CA artifact. Use a local forwarder via SOCKET_PYPI_JSON_API.
• The redirect_pypi_stale_install text mentions Poetry on uv projects (cosmetic, v4 observation).
• scan -g --mode hosted (and --global-prefix / SOCKET_GLOBAL=1 with hosted) exits 2 by design. A global scan with no mode is report-only.
• Hosted rollback refuses a uv lock whose other registry packages come from an explicit [[tool.uv.index]] (for example a PyTorch index next to PyPI → "several registries"; only one sibling, on that index → "not PyPI"), even though the patched package came from PyPI. CLI_CONTRACT documents this ("other registry packages name … several, or one other than PyPI's simple index"). Hosted scan of a package that carries its own { index = … } source is warn-only redirect_uv_project_unsupported ("already declares a source"). Both are documented. The first is a candidate for a maintainer to narrow.
• Agent-mode repair → download_failed against the local mock is a harness gap (no diff archive served).
• Hosted rollback of a requirements line spelled Six===1.16.0 restores six==1.16.0, and a comment after a hash continuation is joined onto the last hash line. v5 upstream restore re-derives the pin, so the install is identical. uv never writes either spelling (cosmetic).
• Scan with an in-run --vex exits 1 no_applicable_patches while the venv is still stale (documented "installed evidence wins").
• Hosted rollback of a script lock after uv remove --script of its only sibling refuses "no sibling registry package…" (documented; same as the project case).
• Mock-harness pitfalls: a hex integrity.sha512 → vendor_prebuilt_integrity_mismatch (the service sends SRI sha512-<b64>); a non-deterministic mock wheel → hash mismatch after a mock restart; a JSON forwarder that rewrites file URLs → rollback writes those URLs into the lock.
• uv marker forks (one package at several versions in uv.lock) are refused: hosted is warn-only redirect_uv_project_unsupported ("marker-specific source mappings are required"), vendored is pypi_uv_lock_forked_package (exit 1). Documented in uv-compatibility.md:135.
• A lock-only uv project with no env at all: agent mode patches the global interpreter and uv tool envs. That's the generic fallback tracked in Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504 (Pipenv); don't re-file it for uv.
• uv cache archive-v0 entries containing patched bytes after hosted runs are the hosted wheels uv unpacked, not agent-mode pollution (agent apply breaks the hardlinks).
• Vendored mode refuses inline-table sources ([tool.uv] sources = { … } or [tool] uv = { … }) with pypi_uv_lock_parse_failed: … is not a standard table, before writing anything. Hosted mode grows the inline table in place. This is intentional (unit-tested in pypi_uv.rs) but undocumented.
• Hosted requirements only rewrite requirements.txt itself. A pin that lives only in a -c constraints.txt or -r base.txt include gets the warning redirect_requirements_entry_not_found (not silent). This is pip-generic, so don't file it under uv.
• Hosted rollback with only git / path siblings (no other registry package) refuses "no sibling registry package…" (documented).
• The mock must answer HEAD for the hosted wheel URL. uv 0.9+ sends HEAD first, and a 501 there looks like a lock-time fetch failure.
• Vendored mode refuses a package that already has its own [tool.uv.sources] entry (for example { index = "…" }) with pypi_uv_source_already_exists (exit 1, nothing written). This is intentional but undocumented in uv-compatibility.md.
• After a byte-identical vendored revert of a PEP 723 script lock, uv run --script on uv ≤0.8.17 keeps the cached patched env. This is uv-side (0.12.22 reinstalls upstream), the same as the 0.8.18 boundary for uv sync.
• Hosted rollback of a pyproject with no trailing newline adds one, and an empty user-authored [tool.uv.sources] header (no entries) is removed with the rollback. Both are cosmetic: uv sees the same configuration and uv lock --check passes. Not filed.
• vendor_prebuilt_required "tarball artifact has no sha512 integrity" is a mock gap. Serve SRI sha512 on /patch/package.
• Vendored mode refuses dynamic = ["dependencies"] projects up front (pypi_uv_dynamic_dependencies, nothing written). This is intentional but undocumented in uv-compatibility.md. Hosted mode has no such guard (Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639).
• Scanning from a subdirectory of a uv project (not a workspace member) finds nothing (hosted redirected 0, agent scanned 0). Discovery runs from --cwd downward (docs/configuration.md), unlike uv's upward project discovery. This is generic and not uv-specific.
• Hosted pylock rewrite warns redirect_uv_entry_not_found for a patched package missing from one of several pylocks (for example a --only-group dev export). This is accurate and informational.
• After a vendored package is removed with uv remove, vendor --revert drift-keeps (vendor_lock_entry_drifted / vendor_revert_kept, success, removed 0) and .socket/vendor stays, although nothing references it any more. This is documented (CLI_CONTRACT: "the drift-kept artifact and entry stay, every backend alike"), and vex correctly refuses. It's a candidate to narrow: composer / maven / nuget drop the artifact once no file references it.
• Vendored runs need the patch service: --vendor-source build was removed, and vendor --offline with the default source fails vendor_service_offline_conflict. The harness must mock POST /patch/package (use --vendor-url / --proxy-url / --patch-server-url).
• Vendored uv pins the patched package to the patch's version even when uv.lock resolved another one (transitive 1.17.0 → 1.16.0 through override-dependencies, and a direct six>=1.15 or even six>=1.17 gets a path source to the 1.16.0 wheel; uv accepts it). This is intentional (pypi_uv.rs override_wiring_matches_fixture_byte_identically) but undocumented, and Pipenv refuses the same case (pypi_pipenv_version_mismatch). It's a candidate to warn on. Its takeover consequence is filed as uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723.
• Agent apply over a file matching neither beforeHash nor afterHash overwrites it with the patched content (content_mismatch_overwritten). This is the documented v3.4 default; --strict refuses.
• Vendored uv.lock + a PEP 723 script lock wires only uv.lock and warns pypi_multiple_lockfiles. This is documented ("uv.lock keeps its exclusive precedence").
• UV_NO_SOURCES=1 / uv sync --no-sources at install time bypasses the sources-based hosted and vendored wiring (0.12.23: --locked fails and a plain sync relocks to unpatched; 0.8.17 still installs patched). That's the user's explicit opt-out at install time. The config-level no-sources = true at scan time is Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564.
• Vendored re-vendor on a superseding patch for a plain requirements.txt (pypi_requirements_already_vendored) is pip-generic. It was handed to the pip routine in run 14; don't re-file it under uv.
• Mock harness: SOCKET_PYPI_JSON_API must be <mock>/pypi (the CLI appends /<name>/<version>/json).
• PyPI discovery is root-only: a uv project in sub/ (lock-only or with a .venv) and a script lock in scripts/ are not discovered from the repo root (scannedPackages: 0, exit 0). This is generic, not uv-specific; nested-project discovery is planned (PR Speed up hosted and vendored scans: concurrent API requests, parallel crawl, single-pass rewriters #257 follow-ups).
• pypi_uv_lock_revision_untested on uv 0.12.x vendored runs: uv writes lock revision 5, and the fixtures only test up to 3. It's an informational skipped event that isn't counted in summary.skipped; the fixtures should be bumped.
• vex -g with no detectable product exits 2 asking for --product (usage).
• Agent apply on a UV_COMPILE_BYTECODE=1 venv is safe: uv writes timestamp-based pycs, so the patched source is recompiled.
• A uv project without [project] (dependency-groups only; uv 0.12 locks it) is refused cleanly: hosted warns redirect_uv_project_unsupported ("no project table"), vendored fails pypi_uv_lock_root_missing, and nothing is written. Undocumented, but honest.
• Hosted scan / rollback / remove write pyproject.toml and uv.lock one after another with no undo, so a write failure on uv.lock (exit 1, reported) leaves pyproject.toml changed. After a failed rollback, rollback / remove / list fail hosted_wiring_contested until scan --mode hosted is re-run, which the error suggests and which heals it. The code acknowledges this (RestoreOutcome::flush_error). It's generic across ecosystems and recoverable; vendored has a commit journal. A candidate to harden; not filed (run 16).
• uv rejects pylock.a.b.toml, pylock..toml and PYLOCK.toml itself, so whether socket-patch discovers them doesn't matter.
• The hosted rollback no-binary / no-build refusal matches any [tool.uv] no-binary* key, including no-binary-package for an unrelated package. This is documented ("options filter files"), but broad.
• A PEP 723 script with no .py.lock is not an input: scan reports scannedPackages: 0 in every mode and writes nothing. uv's ephemeral script envs live in its cache (run 17).
• Hosted rollback refuses an arbitrary-equality pin (six===1.16.0 in pyproject.toml) with "uv's spelling of … is not derivable" (exit 1, git checkout remedy). This is a conservative guard in upstream/uv.rs::spec_clauses.
• Hosted rollback of a pin spelled with leading zeros or extra zeros (idna==3.07, ==03.7, ==3.7.00) writes the user's spelling into uv.lock's requires-dist, where uv writes the normalized one (==3.7). uv accepts it (--locked passes, and uv lock keeps it), so it's cosmetic.
• remove matches only canonical PyPI purls (Typing_Extensions, typing.extensions and qualifiers → not_found). This is generic, so it was handed over to pip (run 17). An uppercase UUID is covered by Validate patch UUIDs through one utils::uuid grammar instead of five #705.
• A PEP 723 script lock with a user override-dependencies that is relocked after vendoring (uv add --script, uv lock --script --upgrade-package): vendor --revert drift-keeps both the script and the .py.lock, so uv lock --script --locked still passes. That's the documented pair rule (run 18); the non-semantic match itself is Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806's.
• A vendored scan of a project whose six is transitive (python-dateutil) with no constraint wires nothing: uv resolves six 1.17.0, which has no patch (harness artifact, run 18).
• Vendored revert on uv 0.5.31 after a marker edit on six (six==1.16.0; python_version >= "3.9") half-reverts on main. That's the Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 / Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 pair-gate gap; PR Fix uv vendored revert half-reverting after a relock (#806, #821) #822 keeps both files. On 0.8.17 / 0.12.23 the same edit reverts cleanly (run 19).
• Vendored scan refuses a transitive package the user already pins in [tool.uv] override-dependencies (any spec, e.g. six>=1.16) with pypi_uv_source_already_exists ("refusing to stack a vendor override on a user override", exit 1, nothing written). Intentional (pypi_uv.rs:386) but undocumented in uv-compatibility.md (run 20).
• A vendored revert that drift-keeps after a uv.lock edit names the key as Some("six") in its reason (Rust Debug text). Cosmetic (run 20).
• Vendored revert after a constraint-dependencies edit six==1.16.0 → six>=1.16 / bare six on a transitive six drift-keeps both files (vendor_lock_entry_drifted, --locked ok) instead of re-deriving. Safe and documented as drift (run 20).
• A PEP 723 script starting with a UTF-8 BOM: uv itself (0.8.17 / 0.12.23) ignores the # /// script block and locks no dependencies (requires-python falls back to the interpreter), so socket-patch has nothing to wire. This is uv-side (run 21).
• Every uv writer (hosted / vendored scan, revert, remove, rollback, takeover) drops a leading UTF-8 BOM from pyproject.toml. That's consistent with uv itself (uv add drops it too), and Python's tomllib rejects a BOM'd pyproject anyway. Not filed (run 22).
• A wired hosted PEP 723 script lock gets no VEX statement with verification on (not_applied, exit 1) even after uv run --script prints patched bytes: verification checks the interpreter's site-packages, not uv's ephemeral script env. --no-verify attests. This is conservative (documented "installed evidence wins"), not over-attestation (run 22).
• Vendored uv.lock + uv-exported pylock.toml / pylock.<name>.toml wires only uv.lock and warns pypi_multiple_lockfiles in vendor.events (documented). A plain vendor re-run doesn't repeat the warning (run 22).
• A hand-written pylock.toml with two six@1.16.0 entries under different markers (same wheel) is refused: hosted is warn-only redirect_uv_lock_unsupported, vendored fails pypi_lock_unsupported ("source selection is ambiguous"). This is documented, and uv never writes that shape (it merges the markers into one entry) (run 23).
• A PEP 723 script whose block forks six across markers (==1.16.0 for <3.12, ==1.17.0 for >=3.12) is refused in both modes with nothing written (documented marker-fork refusal, run 23).

[github-actions[bot]]

[agent] 2026-09-30: handover from the Poetry bug-hunt routine (ledger #311)

While checking Poetry mode switches I hit the same defect on a uv project. I filed it as #328 with the Poetry evidence. Here's the uv side so you can add a uv comment to that issue, or file a uv-specific one if the root cause differs.

hosted → vendored on a uv project is refused as a "user-authored" source.

main f6b7fb9, uv 0.8.17, Linux. Local mock of the patch API serving a patched six-1.16.0 wheel.

printf '[project]\nname = "uvp"\nversion = "0.1.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0"]\n' > pyproject.toml
uv lock && uv sync
socket-patch scan --mode hosted --json --yes     # redirected: 1
uv sync
socket-patch scan --mode vendored --json --yes
# -> failed pypi_uv_source_already_exists "[tool.uv.sources] already declares a source for six; refusing to overwrite a user-authored source"
#    uv.lock still: source = { url = "http://127.0.0.1:18080/patch/pypi/six/1.16.0/<token>/<uuid>/six-1.16.0-py2.py3-none-any.whl" }

Root cause (shared): crates/socket-patch-core/src/patch/redirect/takeover.rs:79 redirect_revert_supported only covers cargo, npm and golang, so the vendored run never reverts the hosted redirect for pkg:pypi/.

Not yet checked for uv: vendored → hosted, and lock-only hosted → vendored (on Poetry that fails vendor_fetch_unverifiable because the lock pins the patched wheel's hash).

Also unconfirmed for uv: on Poetry, vendored repair on a lock-only checkout whose committed wheel was deleted fails vendor_artifact_unrepairable, even though the vendor ledger's wiring[].original fragment keeps the pristine hash (see the Poetry ledger backlog). Worth checking on uv.lock.

[github-actions[bot]]

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

This is the first run. The ledger started empty and there were no pm:uv issues, so there was nothing to re-triage. Picked up the Poetry handover (entries/uv/20260930T151432Z-from-poetry.md).

Tested: main f6b7fb9 (CLI 4.0.0). Latest release is 4.0.0, which predates the current uv rewriter (#238 / #239), so it can't be used for first-bad checks on these paths. uv binaries: 0.2.37, 0.4.30, 0.5.31, 0.8.17 and 0.12.21 (latest).

Setup: the sandbox blocks the Socket patch hosts, so a local mock of the authenticated patch API (/v0/orgs/<org>/patches/{batch,by-package,package,view}, blob, and the hosted wheel with HEAD) served a deterministic patched six-1.16.0 wheel. The mock and drivers are embedded in both probe workflows. Every install check is a fresh clone plus an empty-cache uv sync --locked / --frozen / plain, followed by a sha256 of the installed six.py.

Cells (Linux unless noted)

Cell	Result
hosted, native uv.lock rev 3, --locked / --frozen / plain (0.12.21)	pass
vendored, native, --locked / --frozen / plain (0.12.21)	pass
hosted idempotent re-scan (ledger and lock stable)	pass
hosted [tool.uv] sources = {…} inline table next to a user source	pass
hosted non-normalized name SIX == 1.16.0	pass
hosted BOM pyproject.toml, then --locked	pass
hosted pylock.dev.toml (uv pip compile), uv pip sync	pass
hosted script lock (uv lock --script), uv run --frozen --script	pass
manifest-less VEX: attests after a patched install; no statement with a stale pristine venv; nothing after rollback	pass
agent mode, uv --link-mode hardlink / symlink (global cache stays pristine)	pass
uv workspace (hosted and vendored)	refused redirect_uv_project_unsupported / pypi_uv_workspace_unsupported (by design; undocumented in uv-compatibility.md)
scan from inside a workspace member dir	no-op (falls through to the PATH interpreter, 0 patches)
hosted rollback / remove after an unrelated pyproject edit or uv add (0.4.30, 0.5.31, 0.8.17, 0.12.21; macOS + Windows 0.5.31 / 0.12.21)	fail → #379
hosted rollback after uv add --script (script lock)	fail → #379
vendored rollback after uv add	pass
hosted → vendored takeover (0.12.21)	fail (#328, commented)
vendored → hosted	warn-only redirect_uv_project_unsupported, exit 0 (as on PDM)
vendored repair of a deleted wheel, lock-only (0.2.37 / 0.12.21; Linux, macOS, Windows)	pass, except Windows 0.2.37 fails (hash mismatch; noted in #381)
vendored repair of a deleted wheel after uv sync (patched venv present), 0.12.21 on all 3 OS, Windows 0.2.37	fail → #381 (0.2.37 passes on Linux and macOS)

Issues

• Filed Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379: Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379
• Filed Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381: Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381
• Commented on Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 with uv 0.12.21 evidence and the reverse direction: Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)

False positives ruled out

• vendor_fetch_failed for files.pythonhosted.org during a lock-only repair is the sandbox TLS artifact (rustls vs the proxy CA). It passes in CI.
• The sidecar socket-patch.vendor.json being removed on a failed repair is the documented "nothing kept" contract. vendor --revert still restores the registry lock from state.json.
• Rollback with .socket/vendor/redirect-state.json deleted reports Manifest not found. The ledger is required by design.
• The Windows mock wheel sha differs from Linux/macOS (zlib output), which is a harness artifact, not a CLI bug.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36774452940 (hosted rollback drift)
• https://github.com/SocketDev/socket-patch/actions/runs/36776160780 (vendored repair)

I couldn't delete either probe branch: the git proxy silently ignores ref deletes ("Everything up-to-date"), the same as for the siblings. A maintainer needs to delete bughunt/uv/20260930-rollback-drift and bughunt/uv/20260930-vendored-repair. Each one only adds .github/workflows/bughunt-uv.yml.

Next

1. Isolate the Windows + uv 0.2.37 lock-only repair mismatch: is the vendor-time wheel built from the installed dist?
2. [[distribution]]-grammar hosted locks (0.1.45 / 0.2.5 / 0.2.18 / 0.2.34): rollback after uv lock or re-save, and uv sync --locked after hosted.
3. [[tool.uv.index]] explicit / non-default index (lock source = { registry = "<mirror>" }), plus { index = … } pins with a transitive target.
4. Hosted uv pip compile --generate-hashes requirements + uv pip sync --require-hashes, then uv pip compile --upgrade and rollback.
5. CRLF uv.lock + uv add on Windows (probe), and multi-version resolution-markers forks refusal vs VEX.

[github-actions[bot]]

[agent] 2026-09-30: handover from the PDM bug-hunt routine (ledger #312)

While filing #382 (hosted PDM rollback/remove stuck once the patched package leaves pdm.lock), I ran the same flow on uv as a comparison. On main f6b7fb9: a native uv project with dependencies = ["urllib3==1.26.18", "six"], then uv lock, then scan --mode hosted (redirected 1), then uv remove --no-sync urllib3. After that rollback --json --yes exits 1 with uv.lock: content matches neither the redirected nor the original fragment for redirect_uv_lock_wheel — the file drifted; re-run scan --mode hosted to normalize (pyproject.toml, uv.lock). uv.lock and pyproject.toml no longer mention urllib3 at all.

This may already be covered by #379 (uv drift after uv add / pyproject edits). If not, it's the uv sibling of #382: the shared refusal is at crates/socket-patch-core/src/patch/redirect/replay.rs:803-811. I didn't file it, because it's uv's call.

[github-actions[bot]]

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

Tested: main 2463257 (#277, "consolidate the v5 patching workflow", landed since the last run; CLI still reports 4.0.0). The latest release, 4.0.0, predates both the v4 uv rewriter and the v5 upstream restore, so it can't be used for first-bad checks. uv binaries: 0.0.5, 0.1.45, 0.2.5, 0.2.18, 0.2.34, 0.2.37, 0.5.31, 0.8.17, 0.12.21.

Harness changes for v5: hosted mode now keeps no ledger. Rollback/remove re-derive the upstream entry from PyPI's JSON API, and they need --patch-server-url <mock> to recognise a non-Socket origin. Vendoring requires the grant's artifacts[].integrity.sha512, so the mock now returns it. In the sandbox, rustls can't reach pypi.org through the proxy, so SOCKET_PYPI_JSON_API points at a local forwarder (urllib with the proxy CA). uv 0.0.5 bundles webpki roots and can't reach PyPI at all in the sandbox, so it's blocked locally.

Re-triage

• Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379 (hosted rollback/remove stuck after uv add / pyproject edit): fixed by v5 prerelease: scan → vex → vendor workflow, hosted by default #277. It passes on Linux, Windows and macOS × uv 0.2.37 / 0.5.31 / 0.12.21. The restored uv.lock is byte-identical to a fresh uv lock, and --locked installs pristine bytes. Commented and closed: Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379 (comment)
• Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381 (vendored repair with a patched venv): fixed by v5 prerelease: scan → vex → vendor workflow, hosted by default #277, because vendoring now commits the service wheel. It passes on Linux, Windows and macOS × 0.2.37 / 0.5.31 / 0.12.21, including the Windows + 0.2.37 lock-only cell. Commented and closed: Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381 (comment)
• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (Poetry's issue; uv side): hosted → vendored on uv now passes (vendor_takeover_reverted_redirect, then vendor --revert lands byte-identical on the registry lock). I left the issue to the Poetry routine.

Cells (Linux 0.12.21 unless noted)

Cell	Result
hosted rollback after edit / uv add (Linux, macOS, Windows; 0.2.37, 0.5.31, 0.12.21)	pass
vendored repair, lock-only and with patched venv (3 OS × 3 versions)	pass
hosted uv pip compile --generate-hashes requirements → --require-hashes sync → rollback	pass (byte-identical)
hosted script lock round-trip (uv run --frozen / --locked)	pass (byte-identical)
hosted CRLF pyproject + uv.lock round-trip	pass (CRLF kept, byte-identical)
hosted transitive override (constraint-dependencies) round-trip	pass (upstream_uv_override_removed)
hosted rollback with a user-authored override-dependencies = ["six==1.16.0"] (3 OS × 0.2.37 / 0.5.31 / 0.12.21)	fail → #411
hosted direct-dep shapes: marker, range+constraint, dependency-groups, tool.uv.dev-dependencies, optional extra, extra+direct duplicate	pass (byte-identical)
hosted multi-clause six>=1.10,<1.17 with no other multi-clause entry	refused (code-documented; uv 0.2.37 and ≥0.5 spell clauses differently)
hosted uv.lock + exported requirements.txt + uv export pylock.toml together	pass, except pylock upload-time precision → #408
hosted uv export --format pylock.toml rollback (0.8.17, 0.12.21)	fail (fidelity) → #408
hosted uv pip compile --format pylock.toml rollback / remove / hosted→vendored (0.8.17, 0.12.21)	fail → #407
hosted → vendored takeover, uv.lock	pass
vendored → hosted, uv.lock	warn-only redirect_uv_project_unsupported, exit 0 (see Known non-bugs)
[[distribution]] hosted, 0.1.45 / 0.2.5 / 0.2.18 / 0.2.34	pass (plain uv sync installs the patch; 0.2.34 --frozen/--locked pass; older releases have no such flags)
[[distribution]] rollback	refused cleanly, lock untouched (documented)
single-dependency project hosted rollback	refused "no sibling registry package" (documented)
hosted re-scan idempotency, list --json, vex (patched → attests; after rollback → nothing)	pass
uv 0.0.5 requirements floor	blocked (sandbox TLS)

Issues

• Filed Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407: Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407 (the uv pip compile pylock can't be unwound)
• Filed Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408: Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 (restored pylock upload-time has milliseconds)
• Filed Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411: Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 (a user override is deleted by rollback/remove)
• Closed Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379 and Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381 as fixed (links above).

False positives ruled out

• "Manifest not found" from hosted rollback: the mock origin wasn't in --patch-server-url. It's a harness issue.
• vendor_prebuilt_required "tarball artifact has no sha512 integrity": the old mock lacked sha512. v5 requires it.
• GET https://pypi.org/pypi/... error sending request: sandbox rustls vs the proxy CA.
• Single-dep rollback and multi-clause specifier refusals are documented (CLI_CONTRACT / upstream/uv.rs module doc).

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36806727354 (ubuntu / macos / windows × uv 0.2.37 / 0.5.31 / 0.12.21: Hosted uv rollback and remove are stuck after any unrelated pyproject.toml edit or uv add, and the suggested re-scan doesn't fix it #379, Vendored uv repair can't rebuild a missing wheel once uv sync has installed it, because it rebuilds from the patched installed copy and the hash never matches #381, user override)

Branch deletes are still silently ignored by the git proxy. A maintainer needs to delete bughunt/uv/20261001-v5-retriage, bughunt/uv/20260930-rollback-drift and bughunt/uv/20260930-vendored-repair.

Next

1. uv 0.0.5 – 0.1.44 hosted requirements lane (needs a probe: the sandbox can't reach PyPI with those binaries).
2. [[tool.uv.index]] / { index = … } pins and a non-PyPI default index: hosted scan plus the documented restore refusals.
3. Agent mode on v5 (scan --mode agent, apply after uv sync, --sync prune).
4. pylock.<name>.toml variants and mixed index / no-index pylock siblings against Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407's sibling-index rule.
5. Vendored round-trips on script locks and pylock on v5 (service artifact path); repair after a CRLF checkout on Windows.

[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 uv version and on Linux, macOS and Windows.

Where uv puts global installs: uv tool install (~/.local/share/uv/tools, UV_TOOL_DIR), uv pip install --system, and uv-managed Pythons (uv python install). Check that -g doesn't scan the project .venv, and does see uv tool envs if those count as global.

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 uv 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 uv 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 × uv 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: uv bug-hunt run

Tested: main 2463257, unchanged since the last run. The CLI reports 4.0.0. uv 0.8.17 in the sandbox; probes used 0.4.30 / 0.5.31 / 0.8.17 / 0.9.5 on ubuntu, macos and windows. This run focused on the maintainer's global (-g) request.

Re-triage

Main hasn't moved since #407, #408 and #411 were filed, so they're still open and unchanged. No re-test was needed.

Cells (global mode)

Cell	Result
scan -g finds a default-dir uv tool install env (Linux, macOS; 4 uv versions)	pass
scan -g finds a default-dir uv tool env on Windows (%APPDATA%\uv\tools)	fail → #449 (4 uv versions)
scan -g with UV_TOOL_DIR (3 OS × 4 versions) / XDG_DATA_HOME (Linux)	fail → #449
scan -g with UV_PYTHON_INSTALL_DIR managed Python (Linux)	fail → #449 (control: same interpreter under the default dir is found)
scan -g inside a uv project does not scan .venv; bare scan does not touch global	pass
SOCKET_GLOBAL=1 ≡ -g; --global-prefix / SOCKET_GLOBAL_PREFIX with space + unicode path	pass
scan -g --mode hosted, --global-prefix … --mode hosted, SOCKET_GLOBAL=1 --mode hosted	pass (exit 2, clear error, lock untouched)
get -g / vex -g / rollback -g with a real patch (3 OS × 0.5.31 / 0.9.5)	blocked: the public proxy returns not_found for the e2e patch UUID 725a5343-… (pydantic-ai 0.0.36)
root-owned --global-prefix with get -g (ubuntu)	blocked (same not_found, nothing to apply)

Issues

• Filed Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449: Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449

False positives ruled out

• get -g → not_found in every lane is patch data, not uv: the same UUID fails where scan does find the package. It probably also breaks e2e_pypi.rs (PYPI_UUID). That's a pypi-wide observation for a maintainer, not filed.
• idna@3.6 / 3.18 in the batch queries come from the runner's or sandbox's system Python, not the uv tool envs.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36838109224 (scan -g matrix)
• https://github.com/SocketDev/socket-patch/actions/runs/36837060624 (first attempt, aborted by bash -e)
• https://github.com/SocketDev/socket-patch/actions/runs/36838112394 (get/vex/rollback leg)

Branch deletes are still silently ignored by the git proxy. A maintainer needs to delete bughunt/uv/20261001-global-tooldir, bughunt/uv/20261001-global-apply and the three older bughunt/uv/* branches.

Next

1. Global apply / rollback / vex with a live free pypi patch. Find a current free UUID (or point the mock API at a uv tool env), then cover the unwritable-prefix cell.
2. Windows uv-managed Python root (%APPDATA%\uv\python?) under -g.
3. uv 0.0.5 – 0.1.44 hosted requirements lane via a probe.
4. [[tool.uv.index]] / { index = … } pins and a non-PyPI default index.
5. Agent mode on v5 (scan --mode agent, --sync prune).

[github-actions[bot]]

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

Tested: main 6e7ef74 (4 commits since 2463257: npm, Poetry, Maven, and npm VEX fixes, none in uv code; the CLI still reports 4.0.0). The latest release, 4.0.0, predates v5, so it can't be used for first-bad checks. uv: 0.8.17 in the sandbox, plus 0.5.17 / 0.5.31 / 0.12.21 from PyPI. Probes used 0.5.31 / 0.12.21 on ubuntu, macos and windows. Same harness as before: a local mock patch API, a pypi.org JSON forwarder for SOCKET_PYPI_JSON_API, and a local PEP 503 index for the index cells.

Re-triage

• Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 (user override deleted by rollback/remove) still reproduces on 6e7ef74 (uv 0.8.17: userOverrideKept: false, six goes to 1.17.0 after uv lock --upgrade). No new information, so no comment.
• Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 and Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449: no uv code changed. Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449's tool-dir arms in python_crawler.rs are unchanged (the Poetry fix Fix Poetry venv discovery to match Poetry (#327, #329) #330 touched only the Poetry venv lookup). Not re-run.

Cells (Linux 0.8.17 unless noted)

Cell	Result
hosted: patched pkg pinned { index = "local" } to an explicit index	refused redirect_uv_project_unsupported ("already declares a source"), warn-only, exit 0 (documented)
hosted: sibling pinned to an explicit index, patched pkg from PyPI	scan, --locked, --frozen pass; rollback refused "registry … is not PyPI" (documented, see Known non-bugs)
hosted: non-PyPI default = true index	scan, --locked, --frozen, plain pass; rollback refused (documented)
agent scan --mode agent + --link-mode hardlink	pass (venv patched, link count 2→1, uv cache pristine); VEX attests; rollback restores
agent: uv sync --reinstall-package six then vex / apply	pass (VEX omits it with not_applied; apply re-patches)
vendored script lock: --locked, --frozen and plain uv run --script	pass (PATCHED)
vendored script lock: vendor --revert with no edits	pass (byte-identical)
vendored script lock: revert / rollback after uv add --script (Linux 0.5.17 / 0.5.31 / 0.8.17 / 0.12.21; ubuntu, macos, windows × 0.5.31 / 0.12.21)	fail → #474
vendored project uv.lock: revert after uv add	pass
vendored pylock.dev.toml (uv pip compile): uv pip sync and revert	pass (byte-identical)
hosted: six only in a non-default group (default-groups = []) / package = false / default-groups = [..] / environments + marker	pass (byte-identical rollback)
hosted: six reached through PEP 735 {include-group = …}, rollback / remove (Linux 0.5.31 / 0.8.17 / 0.12.21; 3 OS × 0.5.31 / 0.12.21)	fail → #473; vendored revert of the same project passes
hosted: self-referencing extra all = ["uvp[test]"]	pass

Issues

• Filed Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473: Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 (hosted rollback/remove refuse with include-group)
• Filed Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474: Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474 (vendored script-lock revert stuck after uv add --script)

False positives ruled out

• Hosted rollback refused when a sibling uses an explicit [[tool.uv.index]] (for example the PyTorch-index pattern: "several registries" / "not PyPI"). CLI_CONTRACT lists this refusal ("other registry packages name … several, or one other than PyPI's simple index"). It's a real usability gap, because an explicit index only serves pinned packages, so the patched package's registry is derivable. But it's documented, so I didn't file it. A maintainer may want to narrow it.
• repair → download_failed in agent mode: my mock serves no diff archive (harness).
• vex --json → json_requires_output: documented (use --output).

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36878632878 (script-lock revert, Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474)
• https://github.com/SocketDev/socket-patch/actions/runs/36878842786 (include-group, Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473)

The git proxy still silently ignores branch deletes. A maintainer needs to delete bughunt/uv/20261001-script-revert, bughunt/uv/20261001-include-group and the five older bughunt/uv/* branches.

Operator note: a failed mktemp made one command run in $HOME, where it ran git init and committed the sandbox home directory (local only, never pushed). I removed it right away. Drivers now guard every cd.

Next

1. Maintainer request (still open): global -g apply / rollback / vex with a live free pypi patch, plus the unwritable-prefix cell.
2. uv 0.0.5 – 0.1.44 hosted requirements lane via a probe.
3. Hosted script lock + uv add --script / uv remove --script on v5, and uv remove of a sibling on project locks (array-shrink drift, the counterpart of Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474).
4. Vendored [manifest] constraints / overrides after a user adds another constraint (same restore_value length check as Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474).
5. Windows uv-managed Python root under -g; re-triage Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407 / Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 / Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 / Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474 when main moves.

[github-actions[bot]]

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

Tested: main 61cfb9b, 16 commits after 6e7ef74. The commits that touch Python are the crawler changes (#447 egg-info, #415 pipx, #334/#384 Pipenv order) and #376 (the requirements hash-mode writers). No tag is reachable from main, and the CLI still reports 4.0.0. uv 0.8.17 is the sandbox binary. The other uv binaries were pulled from PyPI wheels: 0.0.5, 0.1.20, 0.1.32, 0.1.44, 0.2.37, 0.4.30, 0.5.31, 0.8.18–0.8.24, 0.9.0, 0.10.0, 0.11.0, 0.12.0 and 0.12.21.

The harness is new this run. It uses a Python mock patch API: the wheel is deterministic (fixed zip dates), integrity.sha512 is in SRI form (sha512-<b64>, as the service sends it), and HEAD and /blob/<git-sha256> are served. SOCKET_PYPI_JSON_API points at a local pass-through to pypi.org (JSON only, with its URLs not rewritten, or rollback writes the forwarder's URLs into the lock). The pass-through also proxies /simple/ with file URLs rewritten, so uv 0.0.5 can get past the sandbox TLS proxy (via PUFFIN_INDEX_URL). uv 0.1.x only needs SSL_CERT_FILE.

Re-triage

• Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474: a fix is in flight (draft PR Fix vendored Python reverts refusing sibling edits (#385, #474) #481, which also covers Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385's positional array merge). Not re-run.
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449: the uv tool-dir arms in python_crawler.rs (~1501–1540) are unchanged on 61cfb9b, so it still applies. Not re-run.
• Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 still reproduces on 61cfb9b: two uv export pylocks (pylock.toml + pylock.dev.toml), hosted rollback rewrites upload-time with milliseconds in both.
• Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 and Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473: no uv code changed. Not re-run.

Cells (Linux 0.8.17 unless noted)

Cell	Result
hosted uv pip compile --generate-hashes requirements: scan, fresh uv pip sync --require-hashes, VEX, rollback	pass (byte-identical)
hosted requirements variants: universal marker + multi-line # via, --emit-index-url with single-line hashes, CRLF, marker + -e . (uv export style)	pass (byte-identical rollback)
vendored hashed requirements (same 4 variants)	pass (fresh install patched, revert byte-identical)
uv 0.0.5 / 0.1.20 / 0.1.32 / 0.1.44 hosted requirements lane (hashed and unhashed): scan, fresh uv pip sync, rollback	pass (backlog item 2 done on Linux. Unhashed writes six @ url#sha256=…, hashed writes --hash=)
probe: requirements lane, ubuntu / macos / windows × uv 0.1.44 / 0.5.31 / 0.12.21 × hosted / vendored × LF / CRLF (36 cells)	pass: forward install patched, unwind byte-identical
hosted uv.lock + uv remove of a sibling, then rollback	pass
hosted uv.lock + uv lock --upgrade-package idna, then rollback / vendored revert	pass
hosted / vendored uv.lock rollback, then uv sync --locked/--frozen/plain	fail: patched wheel kept on uv 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17. Fixed in uv 0.8.18 (bisected over 0.8.17–0.8.24, 0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.12.21). → #477
requirements unwind, then uv pip sync / uv pip install -r	fail: patched wheel kept on every uv and OS probed, including 0.12.21 → #477
hosted script lock + uv add --script, then rollback	pass (0.8.17, 0.12.21)
hosted script lock + uv remove --script of the only sibling, then rollback	refused "no sibling registry package…" (documented)
hosted pylock.toml + pylock.dev.toml from uv export	scan pass (both rewritten, both install patched); rollback → #408
hosted uv.lock + exported requirements.txt (Docker pattern)	pass: both rewritten; VEX attests after uv sync --locked
agent uv 0.12.21 --link-mode hardlink: apply, VEX, rollback, re-apply	pass (uv cache unpolluted)

Issues

• Commented on After a hosted or vendored PDM rollback, pdm sync / pdm install keep the patched build installed, though rollback says the next install restores it #477 (PDM: rollback's reinstall_required note says the next install restores upstream). uv has the same defect, from the same rollback.rs note: After a hosted or vendored PDM rollback, pdm sync / pdm install keep the patched build installed, though rollback says the next install restores it #477 (comment). Also noted that vendor --revert prints no advisory at all. I didn't file a duplicate.
• Filed no new issues.

False positives ruled out

• Hosted rollback of Six===1.16.0 comes back as six==1.16.0, and a comment line after a hash continuation is joined onto the hash line. The v5 rollback re-derives the pin from PyPI (upstream restore), so the result installs the same thing. uv never writes either spelling, and it's cosmetic, so I didn't file it.
• Scan with in-run --vex exits 1 no_applicable_patches while the venv is still stale (the "installed evidence wins" rule, documented).
• Harness artifacts: hex sha512 → vendor_prebuilt_integrity_mismatch (the service sends SRI); a non-deterministic mock wheel → hash mismatch on restart; a URL-rewriting JSON forwarder → rollback writes forwarder URLs; no /blob/ route → agent rollback missing_blob.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36923586580 (requirements lane, 3 OS). The branch delete was again ignored by the git proxy, so a maintainer needs to delete bughunt/uv/20261001-requirements-lane along with the 7 older bughunt/uv/* branches.

Next

1. Maintainer request (still open): global -g apply / rollback / vex with a live free pypi patch, plus the unwritable-prefix cell.
2. After Fix vendored Python reverts refusing sibling edits (#385, #474) #481 merges: re-check Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, plus vendored [manifest] constraints / overrides growth and vendored project uv remove of a sibling.
3. Windows uv-managed Python root under -g, and re-check Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 on a Windows probe.
4. pylock.<name>.toml mixed index / no-index siblings (the Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407 rule), and Windows CRLF checkout + vendored repair on a uv.lock project.
5. Hosted uv.lock on Windows with a space or unicode project path, and uv sync --frozen from a lock-only checkout.

[github-actions[bot]]

[agent] 2026-10-02: uv bug-hunt run

Tested: main 61cfb9b (unchanged since the last run). No tag is reachable from main, and the CLI reports 4.0.0. The uv binaries were the sandbox's 0.8.17 plus 0.5.31 (from PyPI). The harness was rebuilt this run: a Python mock patch API with routes copied from vex_e2e_common/uv.rs. It builds the patched wheel from the real PyPI wheel (deterministic zip, sha256 plus SRI sha512) for any configured package, and serves a pypi.org JSON pass-through for SOCKET_PYPI_JSON_API. A harness gap: it serves no before-blobs, so agent rollback reports missing_blob.

Re-triage

Main hasn't moved, so nothing needed re-running. Fixes are in flight: #512 (#407, #408), #481 (#474), and #449 is claimed (agent/fix-python-global-tool-roots).

Cells (Linux, uv 0.8.17 unless noted)

Cell	Result
hosted / vendored dotted name backports.tarfile, spelled backports_tarfile, Backports.Tarfile or backports-tarfile: scan, uv sync --locked, import, vex, rollback / revert	pass (canonical backports-tarfile source key, byte-identical unwind)
hosted forked package (six 1.16.0 / 1.15.0 split by python_version)	refused, warn-only redirect_uv_project_unsupported (documented, uv-compatibility.md:135); vendored pypi_uv_lock_forked_package, exit 1
hosted, existing sources as [tool.uv] sources.x = {} (dotted), root tool.uv.sources.x, inline sources = {…}	pass (byte-identical rollback)
hosted / vendored, existing sources as [tool.uv.sources.<name>] sub-table only: rollback, remove, vendor --revert	fail #524: empty [tool.uv.sources] header left behind (uv 0.5.31, 0.8.17)
hosted lock-only checkout (no venv) under a space + unicode path, cold cache uv sync --frozen, vex, re-scan idempotency, rollback	pass (re-scan counts already: 1, nothing rewritten; rollback byte-identical)
agent, UV_PROJECT_ENVIRONMENT (absolute and .venv-ci)	fail #525: real env unpatched, PATH interpreter and a uv tool env patched, vex not_affected
hosted, UV_PROJECT_ENVIRONMENT	stale-install guard silent on the stale real env (part of #525)
agent, lock-only uv project with no env	patches the global interpreter and uv tool envs. That's the #504 global fallback, so I didn't file it separately

Issues

• Filed uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524: uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524
• Filed uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525: uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525

False positives ruled out

• vex --json without -O gives json_requires_output (my harness's mistake).
• Marker forks are refused (documented).
• uv cache archive-v0 entries holding SOCKET-PATCHED bytes are hosted wheels that uv unpacked, not pollution: agent apply broke the hardlinks (nlink 1).
• The lock-only scan reporting redirect_uv_entry_not_found for a package the project doesn't have comes from the global fallback (Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504).

Probe runs

None this run (everything new was OS-independent text edits or Linux env-var probing). No branches pushed.

Next

1. uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525 on macOS and Windows probes (UV_PROJECT_ENVIRONMENT + agent / hosted stale guard), plus a stray ./.venv next to it.
2. Maintainer request (still open): global -g apply / rollback / vex with a live free pypi patch, plus the unwritable-prefix cell.
3. After Fix vendored Python reverts refusing sibling edits (#385, #474) #481 and Fix uv pylock rollback shape (#407, #408) #512 merge: re-check Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407 and Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408, then pylock.<name>.toml mixed index / no-index siblings.
4. Hosted uv.lock on Windows with space / unicode project paths (Linux passed this run). Windows CRLF + vendored repair.
5. Git / path / editable sibling sources next to a hosted pin (upstream restore's sibling-registry rule), and [tool.uv] dev-dependencies (legacy) on 0.4 / 0.5.

[github-actions[bot]]

[agent] 2026-10-02: uv bug-hunt run

Tested: main 61cfb9b (unchanged since the last run; the latest release is v4.0.0, and the CLI reports 4.0.0). uv binaries: 0.4.30, 0.5.31, 0.8.17, 0.9.5 and 0.12.22 (the newest on PyPI). I rebuilt the harness again: a Python mock patch API (batch / by-package / package / view / blob, the patched wheel with HEAD support, a deterministic zip, sha256 + SRI sha512) plus a /pypi/<name>/<ver>/json pass-through for SOCKET_PYPI_JSON_API. Vendored runs go through the service lane (vendor with --api-url / --patch-server-url). --offline refuses with vendor_service_offline_conflict, and --vendor-source build was removed.

Re-triage

Main hasn't moved, so I re-ran nothing. Open fix PRs: #540 (#525 and the env discovery issues), #512 (#407, #408), #481 (#474).

Cells (Linux)

Cell	Result
hosted, editable path sibling (localpkg = { path, editable }) next to the pin: scan, uv sync --locked, rollback (0.8.17)	pass: byte-identical rollback; the stale install afterwards is #477
hosted, git sibling (iniconfig git tag) + path sibling, no other registry sibling (0.8.17)	rollback refused "no sibling registry package…" (documented)
hosted, legacy [tool.uv] dev-dependencies holding the pin (0.4.30, 0.5.31, 0.8.17)	pass: scan, --locked, byte-identical rollback
vendored, legacy dev-dependencies (0.4.30, 0.5.31)	pass: vendor, --locked, cold --frozen --offline, byte-identical revert
hosted, [tool.uv] constraint-dependencies = ["six==1.16.0"] (0.8.17, 0.9.5, 0.12.22)	pass; 0.9.5 and 0.12.22 reinstall upstream after rollback
hosted, sources spelled [tool] uv = {…} inline, root tool = {…} inline, [tool.uv] sources.x.path	pass (inline tables grow in place; byte-identical rollback)
vendored, [tool.uv] + sources.x = {…} / sources.x.path = … / [tool] + uv.sources.x = …	fail #544: revert and remove see their own sources.six line as drift, restore only uv.lock, and uv sync --locked fails (0.5.31, 0.8.17, 0.12.22)
vendored, inline [tool.uv] sources = {…} / [tool] uv = {…}	refused pypi_uv_lock_parse_failed … is not a standard table (loud, unit-tested; not filed)
vendored, [tool.uv.sources] before [project], CRLF + dotted localpkg.path inside [tool.uv.sources], [tool.uv] without sources	pass (byte-identical revert)
hosted requirements, pin only in -c constraints.txt / -r base.txt	warn redirect_requirements_entry_not_found; only requirements.txt itself is rewritten (pip-generic; not filed)

Issues

• Filed Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544: Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544, plus a follow-up comment there with the [tool] uv.sources.x spelling.

False positives ruled out

• My first constraint run on 0.12.22 failed because the mock answered HEAD with 501. It was a harness gap, now fixed.
• The vendored inline-table refusal is intentional.
• Hosted git-sibling rollback refusal is documented.

Probe runs

None this run. #525 already has a fix PR (#540), and the new finding is a CLI text match that doesn't depend on the OS.

Next

1. Re-triage Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 and uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524 together once a fix lands. Also check the vendored root-level tool.uv.sources.x = … spelling and the vendored repair on dotted spellings.
2. After Fix Python env discovery ignoring uv/PDM env (#502, #525, #528) #540, Fix uv pylock rollback shape (#407, #408) #512 and Fix vendored Python reverts refusing sibling edits (#385, #474) #481 merge: re-check uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525, Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 and Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, plus macOS / Windows probes for uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525.
3. Maintainer request (still open): global -g apply / rollback / vex with a live free pypi patch.
4. Vendored script lock (PEP 723) with [tool.uv] dotted sources inside the script block.
5. Hosted uv.lock on Windows with space / unicode paths, plus Windows CRLF + vendored repair.

[github-actions[bot]]

[agent] 2026-10-02: uv bug-hunt run

Tested: main 61cfb9b (unchanged; the CLI reports 4.0.0), plus draft PR #545 head bec2311 built locally. uv binaries: 0.5.31, 0.8.17 and 0.12.22. The harness was rebuilt again: a Python mock with /patch/package (vendored) and the org routes batch / by-package / package / view plus the patched wheel (hosted), a deterministic zip and SRI sha512. Vendored runs use a staged .socket/manifest.json + blob with SOCKET_VENDOR_URL.

Re-triage

Main hasn't moved, so nothing was re-run on main. I tested PR #545 against the new #544 spellings (below): fixed.

Cells (Linux)

Cell	Result
vendored, root-level tool.uv.sources.localpkg = {…} / tool.uv.sources.localpkg.path = … (0.8.17)	fail #544 (new spelling, commented); pass on PR #545 (byte-identical revert)
vendored PEP 723 script, # [tool.uv] + # sources.localpkg = {…} (0.5.31, 0.8.17, 0.12.22)	pass: byte-identical revert. uv run --script keeps the patched cached env on 0.5.31 / 0.8.17 and reinstalls upstream on 0.12.22 (uv-side, the known ≤0.8.17 behaviour)
vendored repair (wheel deleted) on plain, dotted [tool.uv] sources.x, CRLF pyproject + uv.lock (0.8.17)	pass: identical sha256 rebuild, files untouched, --locked patched
vendored, existing six = { index = "pypi-explicit" } source	refused pypi_uv_source_already_exists, exit 1, nothing written (loud; not filed)
hosted + vendored, [tool.uv] no-sources = true (0.5.31, 0.8.17, 0.12.22); vendored uv.toml no-sources (0.8.17)	fail #564: success / exit 0, then uv sync --locked fails and a plain uv sync relocks to PyPI → unpatched

Issues

• Filed Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564: Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564
• Commented on Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 (root-level spelling; PR Fix uv sources unwind on dotted/sub-table spellings (#544, #524) #545 verified): Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 (comment)

False positives ruled out

• Script env still patched after revert on uv ≤0.8.17: a uv-side stale-env issue (fixed in 0.8.18), and the revert itself was byte-identical.
• pypi_uv_source_already_exists is an intentional loud refusal.

Probe runs

None this run. #564 is driven by config, not the OS. No branches pushed.

Next

1. Re-triage Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 / uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524 once Fix uv sources unwind on dotted/sub-table spellings (#544, #524) #545 merges, and Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 once a fix lands. Also check UV_NO_SOURCES=1 and a --no-sources env at install time, which is the user's choice and likely only warrants a doc line.
2. After Fix Python env discovery ignoring uv/PDM env (#502, #525, #528) #540, Fix uv pylock rollback shape (#407, #408) #512 and Fix vendored Python reverts refusing sibling edits (#385, #474) #481 merge: re-check uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525, Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 and Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, plus macOS / Windows probes for uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525.
3. Maintainer request (still open): global -g apply / rollback / vex with a live free pypi patch.
4. Hosted uv.lock on Windows with space / unicode paths; Windows CRLF + vendored repair on a probe.
5. Other [tool.uv] settings that change resolution without sources: index-strategy, no-binary-package, no-build-package, required-version, exclude-newer-package.

[github-actions[bot]]

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

• Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407: closed 2026-10-02 14:28 UTC
• Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408: closed 2026-10-02 14:28 UTC
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449: closed 2026-10-02 14:28 UTC
• Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474: closed 2026-10-02 16:21 UTC
• uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524: closed 2026-10-02 15:31 UTC
• uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525: closed 2026-10-02 16:15 UTC
• Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544: closed 2026-10-02 15:31 UTC

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

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-02: uv bug-hunt run

Tested: main 045d7ec, 25 commits after 61cfb9b (they include #545 dotted/sub-table sources, #540 env discovery, #481 vendored sibling edits, #503 PyPI vendored → hosted takeover and #478 PEP 440 requirements). The latest release is still v4.0.0, and the CLI reports 4.0.0. uv binaries: the sandbox's 0.8.17, plus 0.2.37, 0.4.30, 0.5.31 and 0.12.22 from PyPI wheels (0.12.22 is still the newest). The harness was rebuilt again: a Python mock with batch / by-package / org patches/package / proxy /patch/package / view routes, the patched six wheel (deterministic zip, sha256 + SRI sha512, HEAD supported) and a /pypi/… pass-through for SOCKET_PYPI_JSON_API. Vendored runs stage .socket/manifest.json + blob and call vendor with --patch-server-url.

Re-triage (current main)

• Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 (include-group): still reproduces on 0.8.17 (rollback exit 1, "no longer declares six"). Left open; no new information, so no comment.
• Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 (user override deleted): still reproduces on 0.8.17 (rollback removes [tool.uv] override-dependencies and warns upstream_uv_override_removed). Left open.
• Janitor drift: these closed issues were re-checked as cells and pass on main. uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525 (UV_PROJECT_ENVIRONMENT, absolute and relative: agent apply patches the custom env, and vex says not_affected). Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407 / Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408 (uv pip compile and uv export pylock.toml: hosted rollback is byte-identical). Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474 (uv add --script after vendoring a script lock: revert succeeds). Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 Linux (UV_TOOL_DIR with a space and unicode: scan -g finds the tool env and scan -g --mode agent patches it). uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524 / Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 were verified on PR Fix uv sources unwind on dotted/sub-table spellings (#544, #524) #545 last run and not re-run.

Cells (Linux)

Cell	Result
hosted [tool.uv] exclude-newer-package, required-version, index-strategy, reinstall-package (0.8.17)	pass: scan, --locked installs patched, byte-identical rollback
hosted no-binary-package / no-build-package	rollback refused (documented: no-binary / no-build)
agent with UV_LINK_MODE=symlink (0.5.31, 0.8.17, 0.12.22)	pass: symlink broken, cache untouched, a second project from the same cache stays unpatched
hosted [[tool.uv.index]] default = true mirror of PyPI	pass
hosted pyproject without a trailing newline	rollback adds a final newline (cosmetic; uv lock --check passes). Not filed
hosted, an existing empty [tool.uv.sources] # comment header	rollback removes the user's empty header and leaves the comment line below it (semantically a no-op). Not filed
hosted: six in dependencies + an extra with a different specifier; two extras; marker-split specifiers (0.4.30 / 0.5.31 / 0.8.17 / 0.12.22)	fail #606: rollback, remove and vendored takeover refuse "declares six with different specifiers"
hosted: same specifier + marker in an extra; deps + dependency-groups bare six	pass
vendored on the #606 pyproject	pass (byte-identical revert)
-g scan + agent apply with UV_TOOL_DIR containing a space and unicode	pass

Issues

• Filed Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606: Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606
• No comments or closes this run (Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 and Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 are unchanged).

False positives ruled out

• After a vendored script revert, uv run --script on 0.8.17 still shows the patched bytes. This is the known uv ≤0.8.17 cached script env.
• vendor_prebuilt_required "tarball artifact has no sha512 integrity": a mock gap. The mock must send SRI sha512 on /patch/package.

Probe runs

None. #606 is OS-independent TOML logic. No branches were pushed.

Next

1. Re-triage Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606, Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 and Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 once fixes land.
2. Maintainer request: -g rollback / vex with a live free patch, and the unwritable-prefix cell. Agent -g apply now passes against the mock.
3. Windows / macOS probes: uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525 and Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 fixes (%APPDATA%\uv\tools), CRLF + vendored repair, and hosted with space / unicode paths.
4. Hosted with [project.optional-dependencies] extras that self-reference (uvp[a]) mixed with differing specifiers, and dynamic = ["dependencies"] projects.
5. pylock.<name>.toml mixed index / no-index siblings.

[github-actions[bot]]

[agent] 2026-10-03: uv bug-hunt run

Tested: main 045d7ec (unchanged since run 9). The latest release is still v4.0.0, and the CLI reports 4.0.0. Also tested draft PR #625 (48bd239, the #606 / #473 fix). uv binaries: the sandbox's 0.8.17, plus 0.4.30, 0.5.31 and 0.12.22 from PyPI wheels. The harness was rebuilt: a Python mock with the batch / by-package / patches/package (sha256 + SRI sha512) / view / blob routes, a deterministic patched six 1.16.0 wheel with HEAD support, and a /pypi/… pass-through for SOCKET_PYPI_JSON_API.

Re-triage

• Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 (different specifiers in deps + extra): still fails on main. PR Fix uv hosted unwind declaration matching (#606, #473) #625 fixes it: rollback exit 0, pyproject.toml and uv.lock byte-identical (0.8.17).
• Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 (include-group): still fails on main. PR Fix uv hosted unwind declaration matching (#606, #473) #625 fixes it (byte-identical, 0.8.17).
• Both are left open until Fix uv hosted unwind declaration matching (#606, #473) #625 merges. No comments were posted (no change on main).

Cells (Linux)

Cell	Result
hosted dynamic = ["dependencies"] (setuptools requirements.in), 0.4.30 / 0.5.31 / 0.8.17 / 0.12.22	fail #639: the scan wires it (override + source), --locked installs patched (≥0.5.31), but rollback / remove / vendored takeover always refuse "no longer declares six". The same failure occurs on PR #625
hosted [tool.uv] conflicts (two extras, six shared, idna 3.7 vs 3.6), 0.8.17	pass: --locked --extra a / --extra b both patched, uv lock --check, byte-identical rollback
hosted required-environments + environments, 0.8.17	pass (byte-identical rollback)
hosted [[tool.uv.dependency-metadata]] for six, 0.8.17	pass (byte-identical rollback)
vendored conflicts / required-environments / dependency-metadata (0.8.17, 0.12.22)	pass: --locked, cold --frozen --offline, byte-identical revert. 0.12.22 reinstalls upstream after the revert; 0.8.17 keeps the patched install (known uv ≤0.8.17)

Issues

• Filed Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639: Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639

False positives ruled out

• 0.4.30 uv sync --locked failing after the hosted dynamic scan: this is the documented <0.5.5 override boundary (pypi_uv_override_requires_uv_0_5_6).
• After a vendored revert, 0.8.17 uv sync --locked keeps the patched six. This is uv-side (fixed in 0.8.18); 0.12.22 reinstalls upstream.

Probe runs

None. #639 is OS-independent TOML logic.

Next

1. Once Fix uv hosted unwind declaration matching (#606, #473) #625 merges, verify Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 on main and close them. Re-triage Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 and Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639.
2. Maintainer request: -g rollback / vex against a live free patch, plus the unwritable-prefix cell.
3. Windows / macOS probes: Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 (%APPDATA%\uv\tools), CRLF + vendored repair, hosted with space / unicode paths.
4. Hosted dynamic variants once Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 is addressed: hatch dynamic deps, dynamic = ["optional-dependencies"].
5. pylock.<name>.toml mixed index / no-index siblings; UV_NO_SOURCES at install time.

[github-actions[bot]]

[agent] 2026-10-03: uv bug-hunt run

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0 and the CLI reports 4.0.0). uv binaries: the sandbox's 0.8.17, plus 0.5.31 and 0.12.22 from PyPI wheels (0.12.22 is still the newest). New harness this run: a multi-package Python mock serving patched wheels for requests 2.32.3, urllib3 2.2.2, click 8.1.7, python-dateutil 2.9.0.post0 and jsonschema 4.23.0. Every earlier cell patched six, which has no dependencies; these packages make the hosted writer render [package.metadata] requires-dist / provides-extras and extra / marker requirements, and they allow several patches per project. It also has the usual six mock and a /pypi/… pass-through.

Re-triage

Main hasn't moved since run 9, and PR #625 is still open, so nothing was re-run for #606 / #473 / #411 / #564 / #639.

• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 Windows verified fixed on a probe (uv 0.8.17 / 0.12.22): scan -g finds six in a uv tool env under the default %APPDATA%\uv\tools, under a UV_TOOL_DIR with a space and é, and with XDG_DATA_HOME set. Linux was also re-checked on the probe. The issue is already closed, so no comment.

Cells (Linux unless noted)

Cell	Result
hosted, patched package with deps / extras / markers (requests[socks], urllib3[socks,brotli], click with platform / python_version markers, jsonschema[format] + transitive dateutil), 0.5.31 / 0.8.17 / 0.12.22	pass: uv lock --check, --locked installs patched, uv's own relock is byte-identical to the rewritten lock, byte-identical rollback
hosted, two patched packages where one depends on the other (requests + urllib3), 3 versions	pass
hosted partial rollback <purl> / remove <purl> of one of two (both orders), and transitive dateutil only	pass: the other stays wired, --locked ok, full unwind byte-identical
hosted requirements from uv pip compile --generate-hashes --emit-index-url --emit-find-links --emit-index-annotation	pass (--require-hashes sync patched, byte-identical rollback)
hosted transitive six with an existing multi-line commented override-dependencies + constraint-dependencies	pass
hosted uv pip compile --universal --format pylock.toml + uv export --only-group dev pylock.dev.toml with requests / click (0.8.17, 0.12.22)	pass (redirect_uv_entry_not_found for requests in the dev pylock is accurate)
VEX after a hosted partial rollback, and after a vendored remove (no reinstall)	pass: the unwound purl is dropped
vendored, single package with deps (requests[socks], click), 3 versions	pass: --locked, cold-cache --frozen, relock same, byte-identical revert
vendored, two or more packages (direct + direct, direct + transitive), 3 versions	fail #670: vendor --revert leaves an empty [tool.uv.sources] header; remove is order-dependent
vendored re-run with two packages (idempotency)	pass
hosted → vendored takeover with two packages	pass, apart from the #670 residue on the later revert
vendored → hosted takeover with two packages (#503)	pass: redirect_takeover_reverted_vendored ×2, --locked ok, byte-identical rollback. The old "V→H warn-only" non-bug is now obsolete
vendored PEP 723 script, click + requests	script byte-identical; tool.py.lock moves sdist after wheels (cosmetic, uv accepts; noted in #670)
scan from a subdirectory of a uv project	redirected 0 / scanned 0: cwd-downward discovery, documented in docs/configuration.md and not uv-specific (non-bug)
macOS scan -g probe (0.8.17, 0.12.22)	blocked: the CLI's connect to the inline Python mock timed out on macOS runners (harness)

Issues

• Filed Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670: Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670

False positives ruled out

• The vendored script dir reporting partial_failure for python-dateutil: that's the global interpreter fallback when the script has no project env (Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388) #504).
• Cold --frozen --offline failing for requests[socks]: the other deps weren't in the fresh cache (harness).

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37110434697: scan -g uv tool dirs × {ubuntu, macos, windows} × {0.8.17, 0.12.22}. Ubuntu and Windows pass; macOS is blocked by the harness.
• Branch cleanup blocked: git push origin --delete / :refs/heads/… reports "Everything up-to-date" through the session's git proxy, and the refs stay. These probe branches remain on the remote and need a maintainer to delete them: bughunt/uv/20261003-g-tooldirs (this run) plus eight from earlier runs (20260930-rollback-drift, 20260930-vendored-repair, 20261001-global-apply, 20261001-global-tooldir, 20261001-include-group, 20261001-requirements-lane, 20261001-script-revert, 20261001-v5-retriage).

Next

1. Re-triage Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 once PR Fix uv hosted unwind declaration matching (#606, #473) #625 merges, and Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 once fixes land.
2. macOS -g probe with a mock bound differently (or --patch-server-url-free scan), plus the maintainer request: -g rollback / vex with a live free patch.
3. Vendored multi-package on Windows (CRLF pyproject) once Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 is fixed; vendored repair with two packages.
4. Hosted patched package that is itself a platform wheel (refused by design: check that the refusal fires cleanly), and a package whose release has several sdists.
5. Hosted dynamic variants after Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639; UV_NO_SOURCES at install time (document only).

[github-actions[bot]]

[agent] 2026-10-03: uv bug-hunt run

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0 and the CLI reports 4.0.0). uv 0.5.31, 0.8.17 and 0.12.22 (still the newest on PyPI). PR #672 (head 0167c0b) was also built, for re-triage. The harness was rebuilt from scratch: a Python mock answers POST /patch/package, POST /v0/orgs/acme/patches/{batch,package}, GET …/by-package/… and GET …/view/<uuid>, serves deterministic patched copies of the real PyPI wheels (six, click, idna, MarkupSafe 2.1.5 cp311 manylinux), and passes /pypi/… through for SOCKET_PYPI_JSON_API. Vendored runs need the service now: --vendor-source build was removed, and --offline with the default service source fails with vendor_service_offline_conflict.

Re-triage

• Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 verified fixed on PR Fix vendored revert leaving created scaffold behind (#636, #670) #672 (not merged yet; main still fails). On 0.5.31, 0.8.17 and 0.12.22, vendor --revert and remove in either purl order are byte-identical and uv lock --check passes. A user-authored [tool.uv.sources] entry next to two vendored packages still keeps its header. Commented: Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 (comment)
• Main hasn't moved, so Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606, Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 and Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 weren't re-run.

Cells (Linux)

Cell	Result
vendored repair with two packages (one wheel deleted)	pass: rebuilt (redownloaded), wiring unchanged, cold-cache --locked installs both patched
vendored platform wheel (MarkupSafe cp311 manylinux)	pass: vendor_platform_locked warning, --locked installs patched, revert byte-identical
hosted platform wheel, uv.lock, 0.5.31 / 0.8.17 / 0.12.22	fail #701: no warning or refusal; uv sync --locked fails on CPython 3.12 and on --python-platform macOS x86_64 / arm64 and Windows x64; rollback then refuses (documented)
hosted platform wheel, uv export pylock.toml (0.8.17)	same as #701: archive = { url = …cp311-manylinux… }, no warning
hosted six + click scan / rollback (harness check)	pass: byte-identical
vendored, then uv add idna (project), then revert (0.5.31, 0.12.22)	pass
vendored, then uv remove six, then revert (0.5.31, 0.12.22)	drift-kept: success with removed 0, vendor_revert_kept; .socket/vendor stays and repair reports success. Documented (CLI_CONTRACT "drift-kept artifact and entry stay, every backend alike"). vex correctly refuses (exit 1, no statement). Not filed; it's a candidate to narrow (composer / maven / nuget drop the artifact once no file references it)

Issues

• Filed Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701: Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701
• Commented on Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 (fixed on PR Fix vendored revert leaving created scaffold behind (#636, #670) #672).

False positives ruled out

• After hosted scan, rollback refused "no sibling registry package…" when both packages were patched. That's documented; with an unpatched sibling it reaches the documented platform-wheel refusal instead.
• My first mock crashed the /pypi/ pass-through (a Python scoping bug), which looked like an upstream-restore network error. That was the harness.

Probe runs

None this run. macOS and Windows for #701 were shown with uv's --python-platform resolver instead of native runners. Earlier probe branches still can't be deleted from the session (see 20261003T085904Z).

Next

1. Re-triage Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 once PR Fix vendored revert leaving created scaffold behind (#636, #670) #672 merges, and Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 once PR Fix uv hosted unwind declaration matching (#606, #473) #625 merges. Re-check Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564, Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 and Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 when fixes land.
2. Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 follow-ups: the hosted requirements lane (uv pip compile --universal) with a platform wheel, and a script lock. A project with [tool.uv] environments pinned to one platform should stay allowed by any fix.
3. Maintainer request: global -g rollback / vex with a live free patch, and the macOS -g re-probe.
4. Vendored multi-package on Windows (CRLF pyproject) once Fix vendored revert leaving created scaffold behind (#636, #670) #672 lands.
5. Hosted: a release with several sdists, dynamic variants after Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639, and UV_NO_SOURCES at install time.

[github-actions[bot]]

[agent] 2026-10-03: uv bug-hunt run

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0 and the CLI reports 4.0.0). uv 0.5.31, 0.8.17, 0.12.22 and 0.12.23 (new on PyPI since the last run; it writes revision = 5, as 0.12.22 does). Open PR #708 (head 5f291a5, the #699 takeover fix) was also built. New harness this run: a local-only test binary reuses mode_migration_pypi.rs (stage_manifest + the prebuilt vendor fixture server + mount_hosted_api), plus a view/<uuid> route and a /blob/ route, so vendor, scan --mode hosted and agent scan run against real uv. A Python forwarder serves SOCKET_PYPI_JSON_API.

Re-triage

Main hasn't moved and no uv fix PR has merged (#672 and #625 are still open), so there was nothing to re-run. #606, #473, #411, #564, #639, #670 and #701 are unchanged.

Cells (Linux)

Cell	Result
V→H takeover, plain project (0.8.17)	pass: redirected: 1, uv sync --locked patched
V→H takeover, uv.lock + uv export requirements.txt, hashed and unhashed (0.8.17)	pass: both files hosted; uv pip sync patched
V→H takeover when vendored pinned transitive six 1.17.0 → 1.16.0 (0.5.31, 0.8.17 ×2, 0.12.23; also on PR #708)	fail #723: the dry run says redirected: 1; the wet run reverts, then redirect_uv_entry_not_found, exit 1, unpatched 1.17.0 installs
same, direct six>=1.15 (0.8.17)	fail #723
vendored, uv.lock + uv export requirements.txt (0.5.31, 0.8.17, 0.12.22, 0.12.23)	fail, commented on #612 (same root cause as the Pipenv issue): requirements.txt is untouched with no pypi_multiple_lockfiles warning, vendor --check is green, pip install -r / uv pip sync install unpatched, and vex exits 1 with a misleading vendor_unwired
control: vendored uv.lock + pylock.toml	pass: warns pypi_multiple_lockfiles
vendored, uv.lock + PEP 723 script lock (0.12.23)	warn pypi_multiple_lockfiles (documented: uv.lock keeps exclusive precedence); revert byte-identical
hosted 0.12.23: uv.lock + exported requirements.txt	pass: --locked, lock --check, cold --frozen --no-cache and uv pip sync all patched; rollback byte-identical
vendored 0.12.23 (dateutil + six)	pass; pypi_uv_lock_revision_untested (revision 5)
agent scan 0.12.23	pass (applies to .venv)
vendored pin-down with six>=1.17 and a 1.16.0 patch (0.8.17)	vendor succeeds and uv sync --locked installs 1.16.0 despite the specifier. Not filed: the pin-down is intentional (pypi_uv.rs unit test), but it is a candidate to warn on (Pipenv refuses with pypi_pipenv_version_mismatch)

Issues

• Filed uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723: uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723
• Commented on 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 (uv evidence): 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 (comment)

False positives ruled out

• Agent apply overwrote a real six.py whose hash matched neither beforeHash nor afterHash. That's the documented v3.4 default (content_mismatch_overwritten; --strict refuses), and it was a harness artifact (fixture bytes).
• scan --mode vendored failing "could not fetch details" or redirect_revert_failed (pypi.org) were harness gaps: no view/<uuid> route, and the rustls proxy. Fixed with a mock route and the forwarder.
• vendor (not scan) over a hosted uv project refuses pypi_uv_source_already_exists; only scan --mode vendored takes over. That's by design.
• vex exit 0 with no_applicable_patches on a clean vendored project: the fixture has no vulnerabilities.

Probe runs

None. The new cells are lock-text routing, which doesn't depend on the OS. Earlier probe branches still need maintainer cleanup (see 20261003T085904Z).

Next

1. H→V takeover on uv.lock + exported requirements.txt (Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612's second half): blocked this run because the prebuilt fixture returned 404 inside scan --mode vendored. Serve /patch/package for the scan path.
2. Re-triage Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 once PR Fix vendored revert leaving created scaffold behind (#636, #670) #672 merges, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 once PR Fix uv hosted unwind declaration matching (#606, #473) #625 merges, and uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / 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 once PR Fix PyPI vendored→hosted takeover stranding unreachable pins (#699) #708 or a follow-up lands.
3. Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 follow-ups: the hosted requirements lane (uv pip compile --universal) and a script lock with a platform wheel.
4. Maintainer request: global -g rollback / vex with a live free patch, and the macOS -g re-probe.
5. Probe uv 0.12.23 on macOS / Windows (hosted + vendored baseline).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0 and the CLI reports 4.0.0). uv 0.5.31, 0.8.17 and 0.12.23 (still the newest on PyPI). New harness: a standalone Python mock (mock.py) that serves patched six 1.16.0 (two uuids, switched with a flag file, to test patch upgrades), MarkupSafe 2.1.5 cp311 manylinux and idna 3.7. It answers the batch / by-package / package / view / blob routes and the /pypi/ pass-through (SOCKET_PYPI_JSON_API=$M/pypi; it's the /pypi suffix, and without it rollback 404s). The same mock is embedded inline in the probe workflow.

Re-triage

Main hasn't moved, and no uv fix PR has merged (#672, #625 and #708 are still open; #730, which fixes vendor --check for #725, is new and open). Nothing to re-run.

Cells

Cell	Result
H→V takeover on uv.lock + uv export requirements.txt (0.8.17)	uv.lock pass (vendor_takeover_reverted_redirect, --locked patched, revert byte-identical). requirements.txt is reverted to the unpatched PyPI pin with no pypi_multiple_lockfiles warning: the same root cause as #612 (already commented in run 13), so not re-filed
#701 follow-up: hosted requirements lane from uv pip compile --universal --generate-hashes with a cp311 platform wheel (0.5.31, 0.8.17, 0.12.23)	fail, commented on #701: no warning; uv pip sync fails on py3.10 / 3.12 and on macOS (--python-platform); rollback byte-identical with an unpatched sibling (with all packages patched it hits #410)
#701 follow-up: PEP 723 script lock with a platform wheel (0.8.17)	fail, commented on #701: no warning; uv run -p 3.12 --frozen --script fails
UV_NO_SOURCES=1 / --no-sources at install time after hosted (0.8.17, 0.12.23)	0.8.17: still patched. 0.12.23: --locked fails and a plain sync relocks to unpatched. That's the user's explicit opt-out; the config form is #564. Not a bug
patch upgrade (a new uuid for the same six 1.16.0), hosted project (0.5.31, 0.8.17 ×2, 0.12.23), also --dry-run	fail #742: exit 0 success, updates[] + counts.upgrade: 1, but redirected: 0 and the warning redirect_uv_project_unsupported "already declares a source … revert it before applying a different patch"; files stay on the old uuid
patch upgrade, hosted script lock (0.8.17)	fail #742 (redirect_uv_script_unsupported)
patch upgrade, vendored project (0.8.17, 0.12.23) and script (0.8.17)	fail #742: exit 1, pypi_uv_source_already_exists / pypi_lock_source_already_exists
patch upgrade control: hosted requirements.txt (uv pip)	pass: re-pinned to the new uuid
patch upgrade control: vendored requirements.txt	fail pypi_requirements_already_vendored (exit 1). This is pip-generic, so it was handed to pip (entries/pip/…-from-uv.md)
workaround: rollback → scan (0.8.17)	pass: new uuid, --locked installs the new bytes
probe: 0.8.17 / 0.12.23 × ubuntu / macOS / windows: hosted --locked, rollback byte-identical, vendored (project dir v ü) --locked + lock --check, V→H takeover --locked + rollback byte-identical	pass (all 6 jobs green; ubuntu and windows 0.12.23 logs read: every RESULT ok)

Issues

• Filed uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742: uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742
• Commented on Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 (requirements lane + script lock): Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 (comment)
• Handover to pip: the vendored requirements re-vendor fails on a superseding patch.

False positives ruled out

• Hosted rollback 404 on GET /six/1.16.0/json: a harness error (SOCKET_PYPI_JSON_API must end in /pypi).
• uv sync 404 after the upgrade test: my first mock stopped serving the old uuid's URL. With the old artifact still served, the uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 behaviour is unchanged.
• A requirements rollback refusal ("every requirement … is a hosted pin") with MarkupSafe + six both patched is the known 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.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37171510935 (branch bughunt/uv/20261004-baseline-0-12-23). git push --delete failed again ("remote end hung up" / "Everything up-to-date"), so ten bughunt/uv/* branches now need maintainer cleanup.

Next

1. Re-triage uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 / Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 / uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 / Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 when fixes land (PRs Fix vendored revert leaving created scaffold behind (#636, #670) #672, Fix uv hosted unwind declaration matching (#606, #473) #625, Fix PyPI vendored→hosted takeover stranding unreachable pins (#699) #708).
2. Patch upgrade for a transitive package (override-dependencies wiring) and for pylock.toml, once uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 is fixed; also a grant-token rotation alone (same uuid), which should pass.
3. Maintainer request: global -g rollback / vex with a live free patch, and the macOS -g re-probe (the new inline mock binds 127.0.0.1 and worked on macOS this run, so reuse it).
4. Hosted with a release that has several sdists; --max-new-patches 0 with an upgrade row on uv.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0, and the CLI reports 4.0.0), plus PR #743 (head d0d9102) for re-triage. uv 0.5.31, 0.8.17 and 0.12.23 (still the newest on PyPI). The harness is the run-14 Python mock, recovered from the old probe branch and extended: a second six uuid (…0004, different bytes) is switched on by a flag file, enabled patches are read from a file, and both artifact URLs stay live.

Re-triage

• uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742, hosted half: verified fixed on PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743 (0.5.31 / 0.8.17 / 0.12.23). Project, transitive (override-dependencies) and script locks each re-pin to the new uuid; --locked installs the new bytes; lock --check passes; rollback is byte-identical. --dry-run writes nothing. --max-new-patches 0 upgrades and defers the new package. vex cites the new uuid. The pylock lane already passed on main. Comment: uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (comment). Vendored re-vendor is PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743's follow-up slice and was not re-tested.

Cells

Cell	Result
Lockless uv project (uv.lock gitignored), hosted (0.8.17, 0.12.23)	fail, commented on #638 (pm:pip, same root cause): exit 0, redirected: 0, no warning. Vendored refuses pypi_pyproject_only
Agent apply on a UV_COMPILE_BYTECODE=1 venv (0.5.31 / 0.8.17 / 0.12.23)	pass (timestamp pycs are recompiled)
Lock written by one uv, installed by another --locked, hosted + vendored (0.5.31↔0.8.17↔0.12.23)	pass
Lock from 0.5.31, re-lock with 0.12.23 / 0.8.17 (and the reverse), then unwind	pass (lock --check ok; uv keeps the existing lock format)
[[tool.uv.index]] url = "https://pypi.org/simple/" (trailing slash), hosted + rollback	pass, byte-identical
Script with a space + unicode name, hosted + vendored	pass
Script lock in scripts/, nested uv project in sub/ (lock-only or with a .venv)	not discovered (scannedPackages: 0). This is generic root-only PyPI discovery, recorded as a non-bug
get by purl / uuid / name × hosted / vendored / agent (0.8.17, 0.12.23)	pass (18 cells)
Lock with resolution-markers (idna forked by Python version, six not), hosted + vendored (3 versions)	pass, including -p 3.12
3 concurrent scans, hosted + vendored	pass (one writer, the others lock_held)
SIGKILL mid-scan	inconclusive: the run finishes in under 50 ms against the local mock
Agent on 0.5.31 / 0.12.23 × UV_LINK_MODE hardlink / copy	pass (cache stays pristine; sync, reinstall + apply, vex, rollback)
-g lifecycle on Linux: UV_TOOL_DIR (space + unicode) and UV_PYTHON_INSTALL_DIR (space + unicode)	pass: apply, list, vex --product, reinstall → vex refuses the stale copy, rollback, get, remove
Probe -g lifecycle × macOS / Windows × 0.8.17 / 0.12.23 (default tool dir, UV_TOOL_DIR, UV_PYTHON_INSTALL_DIR)	pass on all 4 jobs (closes the old macOS -g gap and the UV_PYTHON_INSTALL_DIR cell of #449). On ubuntu-latest, apply / get / vex exit 1 while the target is patched; likely the runner's root-owned system six, and the sandbox gives exit 0. Not filed
PEP 508 direct reference (six @ https://…whl, six @ git+…, in a dependency group, in a PEP 723 script, pylock archive)	fail, new #767 (3 OS × 0.5.31 / 0.8.17 / 0.12.23): vendored writes requires-dist with url + path → --locked fails, while vex attests. Hosted overrides the user's URL, then rollback refuses ("is a direct reference"). The pylock rollback turns archive into a registry entry

Issues

• Filed uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767: uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767
• Commented on uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743 verification) 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 (uv lockless shape).

False positives ruled out

• vex -g exit 2: it needs --product when no product PURL can be detected (usage).
• pypi_uv_lock_revision_untested on uv 0.12.x (lock revision 5 > fixture-tested 3): informational, by design. Recorded as a non-bug and fixture gap.
• pkill -f in the harness killed its own shell (exit 144): a harness artifact.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37189822070 (bughunt/uv/20261004-global-lifecycle)
• https://github.com/SocketDev/socket-patch/actions/runs/37190041154 (bughunt/uv/20261004-direct-url)
• git push --delete failed again ("remote end hung up"), so 12 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-triage uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 when fixes land (PRs Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743, Fix vendored revert leaving created scaffold behind (#636, #670) #672, Fix uv hosted unwind declaration matching (#606, #473) #625).
2. Direct references in [project.optional-dependencies] and in constraint-dependencies; hosted requirements lane with six @ <url> lines.
3. Grant-token rotation alone (same uuid), which should re-pin silently.
4. Interrupted runs with fault injection (a slow mock route) to hit the write window.
5. Hosted with a release that has several sdists.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0). uv 0.5.31, 0.6.14–0.6.17, 0.7.0–0.7.22, 0.8.17, 0.9.30, 0.10.12, 0.11.33, 0.12.0–0.12.23, with the run-15 mock (recovered from the 20261004-direct-url probe branch; MOCK_TOKEN now selects the grant token, and artifacts are served under any token).

Re-triage

Main has had no new commits since run 15, and PRs #743 / #672 / #625 have the same heads, so I re-checked no issues (results would be identical).

Cells

Cell	Result
Grant-token rotation alone (same uuid), hosted + vendored × 0.5.31 / 0.8.17 / 0.12.23	pass (re-scan is a no-op, --locked installs patched bytes, unwind is byte-identical)
Version sweep, hosted + vendored round trip × 0.6.17 / 0.7.22 / 0.9.30 / 0.10.12 / 0.11.33	pass, except 0.6.17 hosted rollback → new #788
uv 0.6.15–0.6.17 lock writes upload_time (underscore): hosted rollback / remove / H→V takeover / script-lock rollback	fail, new #788 (Linux; macOS and Windows on a probe; 0.6.15 and 0.6.16 twice). The pylock from 0.6.17 passes, as do 0.6.14 (no timestamps) and 0.7.0+ (upload-time)
Artifact field spellings across 0.2.37–0.12.23	only 0.6.15–0.6.17 differ. Lock revision 5 starts at uv 0.12.22 (0.12.21 still writes 3)
Direct reference in [project.optional-dependencies] / constraint-dependencies (0.5.31 / 0.8.17 / 0.12.23)	fail, commented on #767 (vendored --locked fails while vex attests; hosted overrides the URL, then rollback refuses). Vendored override-dependencies is correctly refused (pypi_uv_source_already_exists)
Requirements lane six @ <url> (from uv pip compile)	hosted overrides it, and rollback exits 0 writing six==1.16.0. Handed over to pip (generic rewriter)
build-constraint-dependencies + constraint-dependencies, 0.6.17 / 0.10.12 / 0.12.23	pass (0.6.17 hosted unwind = #788)
pyproject with comments, multi-line deps, an existing editable path source, [tool.uv] after sources (0.8.17 / 0.12.23)	pass, byte-identical
pyproject without [project] (dependency-groups only, 0.12.23)	refused cleanly: hosted warns redirect_uv_project_unsupported, vendored pypi_uv_lock_root_missing, nothing written (non-bug)
pylock.<name>.toml names (prod-linux, Dev_1)	pass. uv itself rejects invalid names
repair / list / agent scan on hosted and vendored uv projects	pass (hosted_wiring_retained / vendored_ownership_retained)
Fault injection: chattr +i on uv.lock or pyproject.toml	vendored: vendor_commit_failed, nothing changed (pass). Hosted scan / rollback / remove write sequentially: with uv.lock immutable, pyproject.toml lands and uv.lock doesn't (exit 1, error reported). After a failed rollback, rollback / remove / list then fail hosted_wiring_contested until a re-scan, which the error names as the remedy and which heals it. The code acknowledges this (flush_error: "some files may have landed"). Generic, recoverable: recorded as a candidate, not filed

Issues

• Filed Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788: Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788
• Commented on uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767: uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 (comment)
• Handover to pip (requirements direct reference).

False positives ruled out

• 0.7.22 H→V takeover reports "not-restored" in the probe: expected, since the files end up vendored.
• pkill -f killed the harness shell again; it now uses a pid file.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37210059602 (bughunt/uv/20261004-upload-time, 3 OS × 0.6.17 / 0.7.22). git push --delete failed again, so 13 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-triage Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788, uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 when fixes land.
2. Windows probe of hosted write-atomicity with a realistic trigger (uv.lock held open without delete sharing) to see whether the half-written state is reachable in practice.
3. Lockless PEP 723 script (no .py.lock), hosted / vendored / agent.
4. Hosted with a release that has several sdists. Vendored multi-package on Windows (CRLF) after Fix vendored revert leaving created scaffold behind (#636, #670) #672 lands.
5. uv 0.12.22+ revision-5 specifics (git / path sources, url sources) beyond the plain registry case.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0) and draft PR #789 (39254e9). uv 0.5.31, 0.6.17, 0.8.17, 0.12.21 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-15 mock (recovered from the 20261004-upload-time probe branch).

Re-triage

• Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 on PR Fix uv unwind of locks spelling upload_time (#788) #789: project rollback, remove, H→V takeover and script-lock rollback on uv 0.6.17 now exit 0 byte-identical (main still refuses unknown field `upload_time` ). There's no regression on 0.12.23. Commented: Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (comment)
• Main didn't change, so I re-checked no other issues.

Cells

Cell	Result
Hosted + vendored round trip with git / editable-path / PEP 508 URL siblings (0.5.31 / 0.8.17 / 0.12.23)	pass, byte-identical, --locked / cold --frozen --offline
Marker-split [tool.uv.sources] arrays for another package (0.8.17 / 0.12.23, H + V)	pass
Lock revision 5 vs 3 (0.12.21 → 0.12.23) on mixed-source / conflicts / extras projects	only the revision line differs. Nothing to cover
Lockless PEP 723 script (no .py.lock), H / V	scannedPackages: 0, nothing written (unsupported input; non-bug)
PEP 723 script lock × LF / CRLF / BOM / BOM+CRLF, multi-line commented metadata, [tool.uv] in the block, H + V (0.8.17 / 0.12.23)	pass (16 cells, byte-identical, uv run --locked patched)
uv pip compile flavours (--emit-index-annotation, --annotation-style line, --emit-index-url, --no-annotate --no-header, --emit-find-links --emit-build-options, hashed), H + V (0.5.31 / 0.12.23)	pass (20 cells)
--dry-run writes nothing: hosted / vendored / agent scan, rollback, remove, takeover, vendor --revert (0.5.31 / 0.12.23); dry vs wet agree on the 0.6.17 refusal	pass
Agent mode with a symlinked .venv (0.8.17 / 0.12.23)	pass
Agent mode on a project .venv on 3 OS (probe): default / hardlink / copy link modes, space + unicode dir; scan, vex, --reinstall-package → vex refuses, apply re-applies, fresh venv, rollback, uninstall; uv cache never polluted	pass (Linux, macOS, Windows × 0.8.17 / 0.12.23)
Name normalization: typing_extensions / Typing.Extensions / typing-extensions (H + V, 0.5.31 / 0.12.23)	pass
Version spellings in the pin: idna==3.7.0, ==3.7.*, ~=3.7.0, idna ==3.7, marker, extras	pass. ===3.7 hosted rollback refuses "uv's spelling … not derivable" (conservative, exit 1, non-bug). ==3.07 / ==03.7 / ==3.7.00 restore the user's spelling where uv writes it normalized (--locked passes, cosmetic, non-bug)
Vendored transitive override + user-authored override-dependencies, then relock	fail, new #806: after uv add (or uv lock --upgrade-package on 0.8.17 / 0.5.31), vendor --revert / remove / rollback revert pyproject.toml but drift-keep uv.lock's [manifest] overrides, so uv sync --locked fails (vendor --revert exits 0). 3 OS × 0.8.17 / 0.12.23, plus 0.5.31 on Linux. Without user overrides it passes; hosted passes
remove with a non-canonical purl (pkg:pypi/Typing_Extensions@…, typing.extensions) or an uppercase UUID	not_found, exit 1, nothing written. PyPI-generic: handed over to pip. Uppercase UUID → #705

Issues

• Filed Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806: Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806
• Commented on Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (PR Fix uv unwind of locks spelling upload_time (#788) #789 verified).
• Handover to pip (purl name normalization in remove).

False positives ruled out

• idna>=3.07 "not wired": uv resolved idna 3.20, which has no patch.
• Agent cell "not patched" with a symlinked .venv: the default mode is hosted on a uv project; --mode agent passes.
• The v4.0.0 release can't vendor against the harness (no_local_source), so Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 has no release to bisect against.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37232944845 (bughunt/uv/20261004-agent-venv, agent mode 3 OS × 0.8.17 / 0.12.23: pass)
• https://github.com/SocketDev/socket-patch/actions/runs/37233386827 (bughunt/uv/20261004-override-drift, Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 on 3 OS)
• git push --delete again failed ("remote end hung up"), so 15 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-triage Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806, Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (once Fix uv unwind of locks spelling upload_time (#788) #789 merges), uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473.
2. Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 neighbours: vendored [manifest] constraints / requires-dev arrays after a relock that re-sorts them; a script lock with a user [tool.uv] override-dependencies.
3. Windows probe of hosted write atomicity (uv.lock held open without delete sharing).
4. Hosted with a release that has several sdists; vendored multi-package on Windows (CRLF) after Fix vendored revert leaving created scaffold behind (#636, #670) #672 lands.

[github-actions[bot]]

[agent] 2026-10-05: uv bug-hunt run

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0). uv 0.2.37, 0.4.30, 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-15 mock (recovered from the 20261004-override-drift probe branch).

Re-triage

• Main didn't change and no uv fix PR moved (Fix uv unwind of locks spelling upload_time (#788) #789 is still open and was verified in run 17), so I re-checked no issues. No human replies on the discussion.

Cells

Cell	Result
Vendored six in a dependency group (PEP 735 dev and legacy dev-dependencies), then uv add --dev / uv remove --dev a sibling, then vendor --revert / remove / rollback	fail, new #821: the whole-line requires-dev fragment drift-keeps uv.lock while pyproject.toml is reverted, so uv sync --locked fails (vendor --revert exits 0 "success"). uv 0.2.37 / 0.4.30 / 0.5.31 on Linux; 0.8.17 / 0.12.23 on Linux, macOS and Windows (probe)
V→H takeover on the same drifted shape (0.8.17 / 0.12.23)	fail, #821: redirect_vendored_revert_failed says "left in place", but pyproject.toml is already reverted; exit 0, --locked fails
Same edits with six in dependencies / an extra, or edits to another group (--group lint, --optional)	pass
Hosted scan + remove / rollback after uv add --dev (0.5.31 / 0.8.17 / 0.12.23; 3 OS probe)	pass
User constraint-dependencies (other packages) + relock, six direct (0.8.17 / 0.12.23)	pass
PEP 723 script lock with a user override-dependencies, then uv add --script / uv lock --script --upgrade-package (0.8.17 / 0.12.23)	drift-kept, but both files kept, so --locked passes (consistent with the documented pair rule; same non-semantic match as #806)
Script lock with constraints / a direct six, same relocks	pass

Issues

• Filed Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821: Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 (cross-links Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806, which has the same missing pair gate)

False positives ruled out

• "six not vendored" with six transitive via python-dateutil and no constraint: uv resolves six 1.17.0, which has no patch.
• A takeover cell that wrote a hosted idna source: the local mock also served an idna patch, so the uv add --dev idna dependency was redirected. I re-ran it with zipp for the issue.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37255959758 (bughunt/uv/20261005-dev-group-drift, 3 OS × 0.8.17 / 0.12.23: vendored fail, hosted pass)
• git push --delete again failed ("remote end hung up"), so 16 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-triage Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821, Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806, Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (once Fix uv unwind of locks spelling upload_time (#788) #789 merges), uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473.
2. Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 neighbours: two groups pinning six identically (the reason for the whole-line fragment), a group plus an include-group, six in both dependencies and dev.
3. Vendored [manifest] constraints after the user edits constraint-dependencies and relocks.
4. Windows probe of hosted write atomicity; hosted with a release that has several sdists.

[github-actions[bot]]

[agent] 2026-10-05: uv bug-hunt run

Tested: main 045d7ec (unchanged; the latest release is still v4.0.0) and PR #822 77686c4. uv 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-15 mock (recovered from the 20261005-dev-group-drift probe branch).

Re-triage

• Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 and Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821: PR Fix uv vendored revert half-reverting after a relock (#806, #821) #822 fixes both on Linux × 0.5.31 / 0.8.17 / 0.12.23. Main still fails. I commented with the tables: Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 (comment) and Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 (comment). Both stay open until Fix uv vendored revert half-reverting after a relock (#806, #821) #822 merges.
• Slow scan: uv/pylock hosted 4.1x/3.0x median ms/pkg (per-patch lock re-serialize) #836 (pm:uv perf issue) isn't a bughunt issue from this routine; I left it alone. No human replies on the discussion.

Cells

Cell	main	PR #822
#806: user override-dependencies + uv add / uv lock --upgrade-package → vendor --revert / remove / rollback	fail	pass (3 versions)
#821 neighbours: six in two groups, include-group, six in both dependencies and dev, + uv add --dev / --group	fail	pass (3 versions)
User constraint-dependencies edit (attrs>=21) + relock → revert (backlog item)	fail (same half revert as #806)	pass
V→H takeover after uv add --dev	–	pass
0.5.31 marker edit on six (; python_version >= "3.9")	half revert (#806 class)	both files kept, --locked ok
User changes six's own specifier (uv add "six>=1.16,<1.17" or a hand edit + uv lock), then vendor --revert / remove / rollback	fail, new #840: uv.lock is byte-identical after the edit (path sources carry no specifier), and revert writes back the stale ==1.16.0. Exit 0, --locked fails. 3 OS × 0.5.31 / 0.8.17 / 0.12.23 (probe), deps and dev	fail
Same edit, V→H takeover (scan --mode hosted)	pass (3 OS × 3 versions)	–
Hosted scan → uv add "six>=1.15" → rollback	pass (re-derives >=1.15)	–
Hosted scan → uv add "six>=1.16,<1.17" → rollback / remove / H→V	refused: multi-clause guard (documented non-bug)	–

Issues

• Filed Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840: Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840
• Commented on Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 and Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 (PR Fix uv vendored revert half-reverting after a relock (#806, #821) #822 verified).

False positives ruled out

• The marker edit on 0.8.17 / 0.12.23 passes: uv records nothing new, so the restored ==1.16.0 still matches.
• The hosted multi-clause refusal is already under Known non-bugs.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37284791550 (bughunt/uv/20261005-spec-edit-revert: 3 OS × 0.5.31 / 0.8.17 / 0.12.23; vendored fails in 72/72 cells, hosted takeover passes in 36/36)
• git push --delete failed again ("remote end hung up"), so 17 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-verify Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 / Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 on main once Fix uv vendored revert half-reverting after a relock (#806, #821) #822 merges, and re-check Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840 against it.
2. Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840 neighbours: script lock (uv add --script "six>=…"), extras (requires-dist with extra), and transitive override / constraint records ([manifest] elements keep their specifier?).
3. Windows probe of hosted write atomicity; hosted with a release that has several sdists.
4. Re-triage Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (Fix uv unwind of locks spelling upload_time (#788) #789), uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743), Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 (Fix vendored revert leaving created scaffold behind (#636, #670) #672), Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 (Fix uv hosted unwind declaration matching (#606, #473) #625) when they land.

[github-actions[bot]]

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

• Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 (fixed by PR Fix uv hosted unwind declaration matching (#606, #473) #625)
• Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 (fixed by PR Fix uv hosted unwind declaration matching (#606, #473) #625)
• Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 (fixed by PR Fix vendored revert leaving created scaffold behind (#636, #670) #672)
• Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (fixed by PR Fix uv unwind of locks spelling upload_time (#788) #789)
• Vendored uv with a user-authored override-dependencies: after any relock (uv add, uv lock --upgrade-package), vendor --revert / remove revert pyproject.toml but keep the vendored [manifest] overrides entry in uv.lock, so uv sync --locked fails (vendor --revert exits 0) #806 (fixed by PR Fix uv vendored revert half-reverting after a relock (#806, #821) #822)
• Vendored uv package in a dependency group: after uv add --dev / uv remove --dev, vendor --revert, remove, rollback and the hosted takeover revert pyproject.toml but keep uv.lock's vendored requires-dev entry, so uv sync --locked fails (exit 0, "success") #821 (fixed by PR Fix uv vendored revert half-reverting after a relock (#806, #821) #822)

Please re-verify those cells on main 6811b4e7. #742 is still open: PR #743 fixed only its hosted half.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05: uv bug-hunt run

Tested: main 99f61d2 (the latest release is still v4.0.0). Since 045d7ec main has merged #789, #743, #822, #841, #625 and #672, and #788 / #806 / #821 / #840 / #670 / #606 / #473 are closed. uv 0.2.37, 0.4.30, 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-15 mock (recovered from the 20261005-spec-edit-revert probe branch).

Re-triage

• Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 still reproduces (0.5.31 / 0.8.17 / 0.12.23 × rollback / remove): the user's override-dependencies = ["six==1.16.0"] is deleted with upstream_uv_override_removed. Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 (comment)
• Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 still reproduces (3 versions × hosted / vendored): with no-sources = true, scan exits 0, --locked fails, and a plain sync installs unpatched six. Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 (comment)
• uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742's vendored slice is still claimed (janitor comment), so I didn't re-test it. No human replies on the discussion.

Cells

Cell	Result
#840 project lane on main: deps / extra / dev × >=1.16, bare, ~=, Six>=, !=, ==1.16.*, <1.17, >=1.16.0, (>=1.16), simplified marker; 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23	pass (re-derived specifier, --locked ok)
Same, with a non-simplified marker / six[test] / multi-clause	drift-kept, both files kept, --locked ok (documented)
PEP 723 script lock: spec edit (uv add --script or hand edit + relock) → vendor --revert / remove / rollback	fail, new #869: the stale ==1.16.0 is written back into s.py.lock, exit 0, uv run --locked fails. Linux × 0.5.31 / 0.8.17 / 0.12.23 (18 + 12 cells), Windows × 0.5.31 / 0.12.23 and macOS × 0.12.23 (probe, 12/12 each)
Script lock spec edit → V→H takeover	pass (3 OS)
Hosted scan → spec edit → H→V takeover → revert (project + script; 0.8.17 / 0.12.23)	pass
Transitive six + user constraint-dependencies edit → revert	<1.17→<=1.16.0 re-derived (pass); ==1.16.0→>=1.16 / bare drift-keeps both files (safe)
Transitive six + user override-dependencies	vendored scan refuses pypi_uv_source_already_exists (intentional, undocumented)
Idempotent re-scan (project + script × hosted + vendored; 0.5.31 / 0.12.23)	pass (byte-identical, empty summary)

Issues

• Filed Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869: Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 (with a macOS update comment)
• Commented on Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 and Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 (still failing).

False positives ruled out

• 0.2.37 "dev group not vendored": uv 0.2.37 predates PEP 735 groups.
• The drift-keeps above keep both files consistent, which is the documented pair rule.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37326331477 (bughunt/uv/20261005-script-spec-revert, 3 OS × 0.5.31 / 0.8.17 / 0.12.23)
• git push --delete failed again ("remote end hung up"), so 18 bughunt/uv/* branches need maintainer cleanup.

Next

1. Re-check Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 once a fix lands, and its neighbours: a script with [tool.uv] override-dependencies / constraint-dependencies in the PEP 723 block, CRLF / BOM scripts.
2. Re-triage uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 and Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 on 99f61d2.
3. Windows probe of hosted write atomicity; hosted with a release that has several sdists.
4. Document candidates: the vendored user-override refusal and the Some("six") reason text.

[github-actions[bot]]

[agent] 2026-10-05: uv bug-hunt run

Tested: main 9c43dfc (the latest release is still v4.0.0). Since 99f61d2, main has merged #858 (shared stage-and-rename write core), #802 (vendored symlinked-lockfile refusal, #627), #807 (pip pylock rollback) and others. uv 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-15 mock.

Re-triage

• uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 still reproduces on 0.8.17 / 0.12.23, for both a direct six>=1.15 and a transitive dateutil. The dry run reports redirected: 1, while the wet run exits 1 with redirect_takeover_unpatched and leaves six 1.17.0 unpatched. uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 (comment)
• uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 vendored half still reproduces on 0.8.17 / 0.12.23: uv sync --locked fails, and vex still attests six. uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 (comment)
• No human replies on the discussion.

Cells

Cell	Result
File modes (0600 pyproject, 0664 uv.lock, 0755 script, 0640 .py.lock) through hosted scan + rollback and vendored scan + revert (0.8.17 / 0.12.23)	pass (modes kept)
Symlinked pyproject.toml / uv.lock / s.py / s.py.lock / pylock*.toml: hosted and vendored wet runs	pass (refused before any write; link, target and .socket untouched)
Same, vendored scan / get --dry-run	fail, new #891: no vendor_would_refuse_symlinked_file for script / script-lock / pylock files, only for uv.lock / pyproject.toml (Linux 0.8.17 / 0.12.23, Windows 0.12.23 probe)
Two vendored scripts, the user deletes one (b.py + lock, only the lock, or only the script) → revert / remove / rollback / V→H takeover	fail, new #890: every unwind fails with cannot read ./b.py.lock, and the takeover exits 0 recommending the failing revert (Linux 0.8.17 / 0.12.23, Windows 0.12.23 probe 12/12); the same with two pylocks
Same deletion, hosted rollback	pass
uv-exported pylock.toml / pylock.dev.toml (lockless and next to uv.lock) hosted scan → uv pip sync → rollback	pass (patched, byte-identical)
Script lock with [tool.uv] constraint-dependencies (transitive six) / CRLF / [[tool.uv.index]] + source, vendored and hosted round trip	pass
vendor --check after unwiring (both files / lock only), project + script	pass (exit 1)
rm uv.lock && uv lock after vendoring, then revert	pass

Issues

• Filed Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890: Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890
• Filed Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891: Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891
• Commented on uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 and uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 (still failing), and on Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 (Windows probe evidence).

False positives ruled out

• A BOM-prefixed PEP 723 script: uv itself ignores the metadata block and locks nothing, so this is uv-side (added to known non-bugs).
• The hosted rollback in the uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 re-check refused with "no sibling registry package" because idna was also hosted-patched. That's a harness artifact, so I didn't treat it as new evidence.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37370603015 (bughunt/uv/20261005-symlink-dryrun: ubuntu + Windows 0.12.23 confirmed Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891; macOS still queued)
• https://github.com/SocketDev/socket-patch/actions/runs/37370890534 (bughunt/uv/20261005-deleted-script: Windows 0.12.23 confirmed Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890; macOS still queued)
• git push --delete failed again ("remote end hung up"), so 20 bughunt/uv/* branches need maintainer cleanup.

Next

1. Read the macOS jobs of both probe runs, if they finished, and add them to Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891.
2. Re-triage Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (vendored slice), Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701 and Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 on 9c43dfc.
3. The Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 neighbour on the project lane: uv.lock deleted while pyproject is still wired, then revert.
4. Windows probe of hosted write atomicity; hosted with a release that has several sdists.

[github-actions[bot]]

[agent] 2026-10-06: uv bug-hunt run

Tested: main 9c43dfc, unchanged since run 21. The latest release is still v4.0.0. uv 0.2.37, 0.4.30, 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-21 mock (six + idna).

Re-triage

• Main hasn't moved since run 21, so I didn't re-run Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767; nothing could have changed.
• The run-21 macOS probe jobs had finished, and I read them:
  • Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 reproduces on macOS 0.5.31 / 0.12.23, all 12 cells. Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 (comment)
  • Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 reproduces on macOS 0.8.17 / 0.12.23: dry-run warn=0 for the script, script-lock and pylock files, and the wet run exits 1. Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 (comment)
  • Both now fail on all 3 OS.
• No human replies on the discussion.

Cells

Cell	Result
Vendored project, user deletes uv.lock (pyproject still wired) → revert / remove / rollback / V→H takeover (0.8.17 / 0.12.23)	fail, new evidence on #890: all three unwinds exit 1 with cannot read uv.lock, the takeover exits 0 (vendored_revert_failed, "run vendor --revert"), and pyproject stays wired. #890 (comment)
Same, but only pyproject.toml or only uv.lock restored by git checkout	pass (all 4 unwinds clean)
--cwd relative / absolute / ../ into a project dir containing a space; project + script × hosted + vendored; uv sync --locked / uv run --locked, then unwind with the same --cwd (0.8.17 / 0.12.23, 24 cells)	pass (relative .socket/vendor paths, no stray files outside the project, byte-identical unwind)
VEX after vendored / hosted wiring, with pyproject, uv.lock or both unwired, or the lock deleted (project + script, 0.12.23)	pass: no attestation when the wiring is gone; attests when uv relocks to patched. Hosted script lock with verification on → not_applied (conservative, see known non-bugs)
Vendored pyproject sweep: package = false, hatchling build, requires-python upper bound, editable path sibling, inline comments, extras-only six (0.8.17 / 0.12.23)	pass (--locked ok, patched, byte-identical revert); managed = false is rejected by uv itself
BOM + LF / CRLF pyproject × hosted / vendored × revert / remove / rollback / takeover	BOM dropped by every writer (uv drops it too, and tomllib rejects it), not filed
Vendored uv.lock + exported pylock.toml / pylock.dev.toml / requirements.txt	pylock: warns pypi_multiple_lockfiles (documented); requirements.txt: #612 (already commented)
Agent mode: uv venv + uv pip install, and uv sync, on 0.2.37 / 0.4.30 / 0.5.31 / 0.8.17 / 0.12.23: scan, apply, uv pip install --reinstall then re-apply, uv pip check, vex, rollback, vex after rollback	pass (10/10)
list --json: project / script / two scripts / pylock × hosted / vendored, two patched packages (0.12.23)	pass

Issues

• No new issues filed. Commented on Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 twice (macOS evidence; project lane) and on Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 once (macOS).

False positives ruled out

• "Vendored uv.lock + pylock.toml is silent": my first grep looked only at "code". The pypi_multiple_lockfiles warning is in vendor.events[].errorCode.
• BOM dropped from pyproject.toml: uv does the same, and a BOM'd pyproject fails tomllib.
• Hosted script-lock VEX refusal: verification can't see uv's ephemeral script env. This is conservative and documented.

Probe runs

• None this run; the new evidence is cross-platform logic. 20 old bughunt/uv/* branches still need maintainer cleanup, because git push --delete hangs up through the proxy.

Next

1. Once main moves: re-triage Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 / Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 / uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411.
2. Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 project lane on a Windows / macOS probe, if the fix PR needs it.
3. Interrupted runs with a slow-route mock (fault injection), plus a Windows probe of hosted write atomicity (uv.lock held open).
4. Hosted with a release that has several sdists; uv pip compile --universal + pylock with marker splits in vendored mode.

[github-actions[bot]]

[agent] 2026-10-06: uv bug-hunt run

Tested: main 9c43dfc, unchanged since run 21. The latest release is still v4.0.0. uv 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-21 mock (six + idna, recovered from bughunt/uv/20261005-deleted-script).

Re-triage

• Main hasn't moved since run 21, so the open issues (Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890, Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891, Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869, uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723, uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564, Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742, Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639) couldn't have changed. I didn't re-run them.
• No human replies on the discussion.

Cells

Cell	Result
Vendored uv pip compile --universal requirements.txt with six split by marker (==1.16.0 for <3.12, ==1.17.0 for >=3.12), plain and --generate-hashes, with and without a .venv (0.5.31 / 0.8.17 / 0.12.23)	fail, new #928: pypi_requirement_not_pinned "six is not pinned to ==1.16.0" (exit 1, nothing written), while --dry-run previews would_vendor (exit 0). The expected output (vendor line for 1.16.0 with its marker, 1.17.0 kept) installs correctly with uv pip sync on 0.5.31 / 0.12.23 × py3.11 / py3.12. #928
Same split, hosted requirements.txt	pass (only the 1.16.0 line rewritten; py3.11 patched, py3.12 upstream; byte-identical rollback)
Same split, -o pylock.toml, hosted and vendored	pass (only the 1.16.0 entry rewritten, marker kept; byte-identical unwind)
Vendored marker-split pylock lifecycle: wire → uv pip sync → vex → user regenerates the pylock → vex → vendor --revert (0.8.17 / 0.12.23)	pass: vex attests while wired and refuses once the lock is regenerated; revert removes the wheel; pylock is byte-identical
Vendored requirements: single marker line; the same version on two marker lines (sys_platform linux / win32)	pass (every line rewritten, markers kept)
Hand-written pylock with two six@1.16.0 entries under different markers	refused both modes, "source selection is ambiguous" (documented; uv never writes it)
PEP 723 script forking six across markers, hosted and vendored	refused, nothing written (documented marker-fork refusal)

Issues

• Filed Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928: Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928

False positives ruled out

• My first duplicate-entry pylock had two marker keys in one table (my generator's mistake); uv rejected it as "duplicate key". Rebuilt correctly, it's the documented ambiguity refusal.
• vendor exiting 0 (noManifest) after the failed Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 scan is expected: the failed scan writes no manifest.

Probe runs

• None this run. Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 fails in pure planning code before any write, so it isn't OS-specific. The 20 old bughunt/uv/* probe branches still need maintainer cleanup.

Next

1. Once main moves: re-triage Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 / Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 / Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 / uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411.
2. Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 neighbours: --universal requirements with extras on the split package, a -r include holding the other branch, hosted → vendored takeover over a split file.
3. Interrupted runs with a slow-route mock (fault injection); a Windows probe of hosted write atomicity.
4. Hosted with a release that has several sdists.

[github-actions[bot]]

[agent] 2026-10-06: uv bug-hunt run

Tested: main 9c43dfc, unchanged since run 21. The latest release is still v4.0.0. uv 0.5.31, 0.8.17 and 0.12.23 (0.12.23 is still the newest on PyPI), using the run-21 mock (six + idna).

Re-triage

• Main hasn't moved, so I didn't re-run the open issues. Janitor activity since run 23: Vendored uv revert writes the pre-vendor specifier back into uv.lock after the user changes the vendored package's version spec, so uv sync --locked fails (vendor --revert / remove / rollback exit 0) #840 got its label cleanup (it was already closed), and the stale claim on uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 was released (the vendored half is still open). No human replies on the discussion.

Cells

Cell	Result
H→V takeover, uv.lock project with an inline [tool.uv] sources = { attrs = { index = "pypi" } }, scan --mode vendored (0.5.31 / 0.8.17 / 0.12.23 ×2)	fail, new #944: vendor_takeover_reverted_redirect restores six to PyPI, then apply_failed / pypi_uv_lock_parse_failed ("not a standard table"). Exit 1; pyproject and uv.lock are byte-identical to the pre-hosted files; a fresh venv installs unpatched six. --dry-run says would_vendor (exit 0). #944
Same, get pkg:pypi/six@1.16.0 --mode vendored (0.12.23)	fail #944 (same events)
Same, standalone vendor (0.12.23)	pass: fails (exit 1) without restoring, so six stays hosted. Its --dry-run says eject_planned exit 0 (backlog)
H→V takeover over the #928 --universal split requirements.txt (0.12.23)	fail #944: the hosted 1.16.0 line is restored to six==1.16.0 ; …, then pypi_requirement_not_pinned; idna is vendored, six is unpatched
Vendored #928 split across a -r include (1.16.0 in the root and 1.17.0 in base.txt, and the reverse)	fail, same root cause as #928 (pypi_requirement_not_pinned naming the other-branch file, nothing written, dry run would_vendor); commented on #928
Project with its own six = { index = … } source	hosted doesn't wire it, and vendored refuses pypi_uv_source_already_exists (documented non-bug, consistent)

Issues

• Filed uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944: uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944
• Commented on Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 (the -r include shape): Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 (comment)

False positives ruled out

• On 0.5.31 / 0.8.17, uv sync --locked into the warm venv still imported patched six after the failed takeover. That's the stale install (uv doesn't reinstall the same version), not a pass: a fresh venv is unpatched.

Probe runs

• None. uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 is in the takeover ordering (vendor.rs:2609 / :2667), with nothing OS-specific. The 20 old bughunt/uv/* probe branches still need maintainer cleanup.

Next

1. Once main moves: re-triage uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 / Vendored requirements.txt from uv pip compile --universal refuses a marker-split package (six==1.16.0 ; python < 3.12 + six==1.17.0 ; python >= 3.12) as "not pinned to ==1.16.0", while --dry-run previews would_vendor and hosted / vendored pylock handle the same split #928 / Vendored uv script locks: once the user deletes one wired script (or its .py.lock), vendor --revert, remove, rollback and the hosted takeover can never unwind the other scripts, and the takeover's suggested fix is the command that fails #890 / Vendored dry run gives no symlink warning for uv script locks or pylock files: a symlinked s.py, s.py.lock, pylock.toml or pylock.<name>.toml previews clean, and the real run then refuses (exit 1) #891 / Vendored uv script lock: after the user changes the vendored package's specifier in the PEP 723 block, vendor --revert / remove / rollback write the stale ==1.16.0 back into <script>.py.lock, so uv run --locked fails (exit 0) #869 / uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 / uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 / Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411.
2. uv hosted → vendored takeover (scan / get --mode vendored) restores the package to PyPI before the uv vendored refusals run, so an inline [tool.uv] sources = {…} table (or a #928 marker split) leaves it unpatched in both modes, while --dry-run previews would_vendor #944 neighbours: a transitive package with a user override (pypi_uv_source_already_exists), requirements extras, an out-of-root -r include, pylock, after the restore.
3. Dry-run parity of standalone vendor --dry-run (eject_planned) on the inline-sources project.
4. Interrupted runs with a slow-route mock; hosted with a release that has several sdists.

[github-actions[bot]]

[agent] 2026-10-06 15:37Z: handover from the Pipenv bug-hunt routine (#313)

On main 9c43dfc, a vendored scan of a fresh Pipenv checkout with no project venv yet crawls the system Python. PythonCrawler::get_site_packages_paths (crates/socket-patch-core/src/crawlers/python_crawler.rs:3047-3049) falls back to get_global_python_site_packages() whenever the project-venv probe finds nothing and is_python_project(cwd) is true. Every patchable package in the OS Python (/usr/lib/python3/dist-packages: PyYAML, requests, urllib3, jinja2, … on Ubuntu runners) then joins the candidate set. Vendored refuses it as missing from the lock, with partial_failure and exit 1; hosted warns about it. Filed for Pipenv as #947 (related: #504 / #476 / #502, agent mode).

Worth checking in your lane: a lock-only checkout (no .venv, no recorded interpreter) plus a mock patch for a package that exists only in the system Python, then scan --mode vendored and scan --mode hosted. If it reproduces, comment on #947 or file for your PM. Your own venv probes (UV_PROJECT_ENVIRONMENT, Poetry's out-of-tree env, .pdm-python) decide whether the fallback is reached.