Bug hunt ledger: uv

[Mikola Lysenko (mikolalysenko)]

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

Last run: 2026-10-15 (run 42) on main e76cb9b (release v5.0.1; main gained only non-uv fixes since 306ec81). uv 0.13.1 (2026-10-14) is the newest release: hosted / vendored project, PEP 723 script-lock and pylock baselines pass. New #1569: hosted scan emits no pypi_uv_override_requires_uv_0_5_6 / pypi_uv_constraints_require_uv_0_5_6 advisory (vendored does) for transitive overrides or repointed [manifest] constraints, so on uv 0.4.30 / 0.5.3 / 0.5.4 a plain uv sync silently reinstalls the unpatched wheel after a clean exit 0 (also v5.0.1). Draft PR #1566 (for #1545) verified against real uv: it fixes the reported shapes, but over-refuses a parent [tool.uv] / uv.toml that holds only constraint-dependencies / override-dependencies / build-constraint-dependencies, which uv does not pass down to a child project (commented on #1545). #1525 holds: the orphan unwind and the user's own override are fine on 0.4.30 / 0.5.3 / 0.5.31 / 0.13.1. Previous: 2026-10-14 (run 41) on main 306ec81 (release v5.0.1; main gained #1504 (closed #1501), #1525 (bare uv manifest overrides of old uv), #1526 (fixes #1524, mixed-flavor PyPI vendor revert) and #1529 (pyproject product detection)). New #1545: a uv project with no [tool.uv] under a parent uv.toml / parent [tool.uv] gets [tool.uv.sources] added by hosted and vendored scan, which hides every parent setting from uv; uv sync --locked fails and a plain uv lock re-resolves without them (0.5.31 / 0.8.17 / 0.13.0, both modes, also v5.0.1). #1501 fix verified (parent / grandparent / [tool.uv]-less pyproject in between all refuse, nothing written). #1105 / #639 have no fix PR (not re-run). Previous: 2026-10-13 (run 40) on main abd5eff (release v5.0.1; main gained #1453 / #1458 (closed #1445 / #869) and #1486 (read-only TOML parse for VEX)). New #1501: a PEP 723 script in a subdirectory is wired although a parent uv.toml / pyproject [tool.uv] sets no-sources = true, which uv honours for scripts (0.5.31 / 0.8.17 / 0.13.0, both modes; a gap in #1434). #1105 and #639 still fail. These pass: the #1486 CRLF / BOM VEX cells, the PEP 503 spellings in the 5.0 target grammar, and the vendored takeover over a #1453 orphan (silent no-op, rollback cleans it). The macOS / Windows probe is blocked (no probe runs, and branch deletion is denied). Previous: 2026-10-13 (run 39) on main 15c2c83 (v4.0.0 is still the latest release; main gained #1434 (fixes #564, uv no-sources refusal), #1440 (bare scan/get mode_ambiguous on vendored + hosted state), #1419 (system-site venvs) and non-uv fixes). No new issue. #1434 holds: no-sources = true / uv.toml / no-sources-package refuse with nothing written in project and PEP 723 script lanes (also with no uv.lock), unwinds of wiring made before the setting was added still work, and the setting precedence matches real uv 0.5.31 / 0.8.17 / 0.12.24 / 0.13.0. Its scan/get vendored dry run previews verified, while the wet run refuses pypi_uv_no_sources (commented on #891 as the same missing-preflight root cause). #1440 holds on uv.lock, script-lock and pylock hosted pins. PR #1453 verified to fix #1445 in project and script lanes (the script lane is new evidence), and PR #1458 verified to fix #869 (36 cells). The macOS / Windows probe (20261013-uv013-baseline) never started: no push workflow ran on any bughunt probe branch in the last day. Previous: 2026-10-12 (run 38) on main 7236190 (v4.0.0 is still the latest release; main gained #1384 (fixes #1374), #1391 (fixes #1285 / #890), #1390, #1337 (fixes #1287), #1335 (fixes #1138), #1332 (fixes #767), #1331 (fixes #411)). uv 0.13.0 (2026-10-09) is the newest release: the vendored / hosted / agent baselines pass, and so does Python 3.15 (its new default). New #1445: a hosted transitive six whose parent is dropped (uv remove isodate or uv lock --upgrade-package isodate) leaves the override plus source URL, and rollback / remove / list then fail hosted_wiring_contested forever (the uv twin of yarn's #1203; 0.5.31 / 0.12.24 / 0.13.0). The #1374 fix holds in 72 promotion / demotion cells, and vendored upgrade-drop unwinds pass. #869 and #891 still fail. Previous: 2026-10-09 (run 37) on main 85105c9 (v4.0.0 is still the latest release; main gained #1265 (fixes #1252, *.lock exports), #1034 (one target grammar for get / remove / rollback), #1277 (BOM handling), #1259 and non-uv fixes). New #1374: a vendored transitive six promoted to a direct dependency (uv add six==1.16.0, with or without removing its parent) is half-reverted by vendor --revert / remove / rollback: the root requires-dist path element socket never recorded is left, uv sync --locked fails, revert exits 0 and vendor --check falsely says nothing references the wheel (0.5.31 / 0.12.24; the PEP 723 lane fails closed instead). PR #1337 verified to fix #1287 in 24 cells (main / dev / group parent × revert / remove / rollback / prune × 0.5.31 / 0.12.24; commented). #1285 still reproduces. #1034 PyPI target spellings pass (dotted / underscore / mixed-case names, versionless and versioned purls, uuid) in vendored / hosted / agent. Agent mode under UV_LINK_MODE=symlink / hardlink / copy passes on Linux / macOS / Windows × 0.8.17 / 0.12.24 (probe; no cache pollution, vex, rollback). Previous: 2026-10-09 (run 36) on main e9be746 (v4.0.0 is still the latest release; main gained #1223 (fixes #1213), #1231 (fixes #1214, auto-closed), #1245, #1254). New #1285: with two vendored PEP 723 scripts, uv remove --script b.py six leaves a.py wired by every unwind (the #1231 'removed' check is global per entry). New #1287: a transitive vendored six whose parent is uv removed (project and script lanes) drift-keeps, so vendor --check stays red and scan --prune loops. #1214 single-script fix verified (commented). PR #1265 fixes #1252 (*.lock exports); requirements.pip / extensionless / *.frozen exports still lose the wheel (commented on #1252). Previous: 2026-10-09 (run 35) on main e03a666 (v4.0.0 is still the latest release; nothing uv-specific landed since run 34). New #1252: a root uv export -o requirements.lock (Rye's name; also requirements-dev.lock, deploy/requirements.lock) loses the vendored wheel on revert / remove / rollback / takeover, exit 0 (0.5.31 / 0.8.24 / 0.12.24; PR #1223 doesn't cover it). PR #1223 fixes #1213. PR #1231 fixes #1214's single-script shape, but not two scripts where only one drops six (commented on #1214). Agent mode under UV_LINK_MODE=symlink passes on Linux. Previous: 2026-10-09 (run 34) on main b76d7ab (v4.0.0 is still the latest release; main gained #1147 (fixes #1140 project lane), #1168 (fixes #1167 *.txt only), #1152 (fixes #1120), #1031 (drops scan --apply/--vendor), #1058, #1151, #1027). uv 0.12.24 is the newest release. New #1213: a subdirectory uv export --format pylock.toml (deploy/pylock.toml, deploy/pylock.prod.toml, a/b/pylock.toml) still loses the vendored wheel on revert / remove / rollback / takeover, exit 0, and the export can no longer install (0.8.24 / 0.12.24). New #1214: after uv remove --script, every unwind of a vendored script lock still drift-keeps and vendor --check stays red (0.5.31 / 0.12.24). #1138 and #1105 still reproduce on b76d7ab. Previous: 2026-10-08 (run 33) on main 4657813 (v4.0.0 is still the latest tag; main gained #997 residual-reference keep, #1091 requirements include tree, #1039 atomic V→H takeover, #1121). No new issues: every uv defect found was already filed. Comments on #1167 (subdirectory uv export requirements / pylock still lose the wheel; #1168 plans *.txt only), #567 (the uv lane: hosted wires uv.lock, leaves the -r include pin, and rollback is stuck on hosted_wiring_contested), #1138 (any Hatch config triggers it, even with uv_build), and #1140 (script lock + upgrade shapes; fix PR #1147). Handed a pip-lane constraints rollback bug to pip. #1140 and #1120 still reproduce. Previous: 2026-10-08 (run 32) on main 3b4ac84 (v4.0.0 is still the latest tag; main gained #1050 one in-use verdict for prune/check, #1045 PurlKey). New #1138: a scan run from a hatchling member of a uv workspace rewrites the member as a lockless Hatch project (vendored {root:uri} wheel / hosted URL), so the root uv.lock goes stale, uv sync --frozen installs unpatched six and vendored vex attests not_affected (0.5.31 / 0.12.23). New #1140: after uv remove six, scan --prune / vendor --revert / remove / rollback all drift-keep the vendored entry, so vendor --check stays red and its scan --prune remedy loops (it was stuck pre-#1050 too). #1120 and #1105 still reproduce on 3b4ac84. Passes: #1050 prune keeps live project / script / pylock / lockfile-only entries; the #612 probe gives no false warning on a requirements.txt re-exported from the vendored lock; #1045 MarkupSafe spellings. Previous: 2026-10-08 (run 31) on main b96a785 (v4.0.0 is still the latest tag; main gained #1035 superseded-generation re-pin, #1044 governing-lock table + #612 requirements warning, #724 UTF-16 requirements). New #1120: a UTF-16 (BOM) requirements.txt exported beside uv.lock is read as absent, so vendored gives no pypi_multiple_lockfiles, vendor --check passes and vex attests not_affected while uv pip install -r installs unpatched six (0.5.31 / 0.12.23; UTF-8 twin is caught). #1105 still reproduces on b96a785. Passes: #1044's #612 warning on uv.lock + UTF-8 uv export (scan and H→V takeover), #1035 on uv (H A→H B→rollback byte-identical; V A + manifest B → remove <B> reverts A byte-identically, uv lock --check ok). Previous: 2026-10-08 (run 30) on main 77f305d (v4.0.0 is still the latest tag). New #1105: hosted A → vendored B takeover (a superseding patch uuid) exits 1 package_not_installed when the venv holds hosted A's bytes, while --dry-run previews success (0.5.31 / 0.8.17 / 0.12.23, uv project and uv pip requirements lane). #411 commented with a third path (the H→V takeover drops the user's override-dependencies pin, and vendor --revert makes the loss permanent). #996 still reproduces. Passes: #946 (#723 drift takeover now refused, kept vendored), forked lock refused in both modes, agent mode × symlink / hardlink link modes × plain / symlinked .venv / UV_PROJECT_ENVIRONMENT (no cache pollution, rollback, VEX omits a reinstalled six), patch-detail 5xx parity in 3 modes (404 gap = #1062), and superseding-uuid upgrades V→V / V→H / H→H on project / script / pylock with byte-identical unwinds. Run 29: 2026-10-07 (run 29) on main 05ecc6e (v4.0.0 is still the latest tag). #964 and #979 are closed by #965 / #980. #996 still reproduces after #1015 (comment). Passes: PyPI name-spelling remove/rollback after #1025, uv-project six[x]== vendored round trip, agent mode on 0.2.34 / 0.4.30 / 0.12.23 (frozen/locked sync, VEX, rollback), uv sync --active agent, and ledger-less revert/gc/repair/rollback over uv.lock, script locks and pylock[.name].toml. Pip-lane six[x]== requirements dry-run parity gap handed over to pip. Run 28 on main 6fe81ad (34 commits after 9c43dfc. No new issue. #944's data loss is fixed by #963; only the documented dry-run preview gap is left. #964 still reproduces (PR #965 open). #701 and #928 are verified fixed. #742 vendored still fails on main and passes on PR #943, where a superseding re-vendor deletes a wheel that a uv export still names (comment on #996). The platform-wheel takeover, the mixed vendored/hosted unwind and root-only [tool.uv.workspace] were also covered). Run 27 on main 9c43dfc (main unchanged since run 21. New #996: after uv export (requirements.txt, --format pylock.toml, or --script) of a vendored lock, vendor --revert / remove / rollback restore the uv pair but delete the wheel the exported file still references, exit 0, no warning; revert_uv has no residual-reference sweep, and unwired_pypi_reference_clause runs only for unwired entries; Linux × 0.5.31 / 0.8.17 / 0.12.23. Interrupted vendored runs (110 SIGKILL points) and concurrent vendor/revert pass). Run 26 on main 9c43dfc (main unchanged since run 21. New #979: standalone vendor --dry-run previews success / verified (exit 0) on a uv project with an inline [tool.uv] / sources table, where the wet run refuses pypi_uv_lock_parse_failed (exit 1) after downloading the prebuilt; the refusal lives only in wire_uv, not in the check_target_guards preflight; Linux × 0.5.31 / 0.8.17 / 0.12.23. Cross-uv-version relocks (rev 1→3→5) and exclude-newer pass. A full vendored mock now wraps the repo's tests/prebuilt_common fixture). Run 25 on main 9c43dfc (main unchanged since run 21. New #964 from the Pipenv handover: on a fresh uv checkout (uv.lock, no .venv), the crawler falls back to the global site-packages, so a vendored scan exits 1 pypi_uv_lock_package_missing on a system-only PyYAML while --dry-run reports success; Linux × 0.5.31 / 0.8.17 / 0.12.23. A missing UV_PROJECT_ENVIRONMENT and a script-lock-only directory (pypi_no_requirements) hit it too. PR #950 fixes only Pipenv). 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)	–	pass (0.2.34, run 29: scan/apply, --frozen/--locked keep patch, VEX, rollback)
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)	pass (0.4.30, run 29)
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 fixed by #1434 (run 39: refused with nothing written on 0.13.0, project + script lanes) | – | 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) | – | – | |
| 0.5.31 / 0.8.17 / 0.12.23 (run 25, main 9c43dfc) | 144 system packages listed as project packages (no .venv, #964) | – | fail #964 fresh checkout without .venv (also a missing UV_PROJECT_ENVIRONMENT, and a script-lock-only dir): global-site-packages fallback, system-only PyYAML → pypi_uv_lock_package_missing, exit 1, dry run says success; control after uv sync / synced UV_PROJECT_ENVIRONMENT passes | – | untested | |
| 0.5.31 / 0.8.17 / 0.12.23 (run 26, main 9c43dfc) | – | – | fail #979 vendor --dry-run says verified / exit 0 on inline [tool.uv] sources = {…}, [tool] uv = {…}, dotted uv.sources = {…}, transitive + inline uv = {constraint-dependencies}; the wet run exits 1 pypi_uv_lock_parse_failed; pass: script-lock inline sources (wired, --locked, byte-identical revert), pypi_uv_source_already_exists dry-run parity, vendor then relock on a newer uv (0.5.31→0.8.17 / 0.12.23, 0.8.17→0.12.23; rev 1→3→5) then revert, exclude-newer + fresh UV_FROZEN sync | – | – | |
| 0.5.31 / 0.8.17 / 0.12.23 (run 27, main 9c43dfc) | – | – | fail #996 uv export requirements.txt / pylock.toml / --script export of a vendored lock → revert / remove / rollback delete the still-referenced wheel (exit 0; dry run previews removed); pass: SIGKILL at 110 points 0–350 ms (pair always orig or wired, journal replayed, re-run + revert byte-identical, uv lock --check ok), 3 concurrent vendor / vendor / revert (lock_held, consistent), manifest-drop vendor_reconciled (byte-identical), explicit [[tool.uv.index]] + other-package index source + trailing [tool.ruff] (wire, --locked, revert byte-identical) | – | – | vendored vex with a stale .venv attests from the committed artifact with vendored_tree_out_of_sync (documented) |
| 0.5.31 / 0.8.17 / 0.12.23 (run 28, main 6fe81ad) | pass: #701 platform grant (MarkupSafe cp311) withheld with redirect_pypi_platform_wheel (scan, dry run, get); six still pinned; py3.12 --locked ok; VEX attests only six | pass: rollback byte-identical; mixed state (MarkupSafe vendored + six hosted) rollback and vendor --revert→rollback byte-identical | pass: #928 --universal marker split (plain / hashed) wired + byte-identical revert; #944 takeover refusal keeps the hosted pin (#963); fail #742 superseding re-vendor (PR #943 fixes it; on #943 fail #996 the stale-artifact removal breaks a uv export) | – | – | V→H with a vendored platform wheel keeps it vendored (pass); root-only [tool.uv.workspace] refused (conservative) |
| 0.5.31 / 0.8.17 / 0.12.23 (run 30, main 77f305d) | pass: H→H superseding uuid (project / script / pylock), #723 drift takeover now refused redirect_uv_takeover_version_unreachable (#946), forked lock refused | pass: unwinds after a superseding-uuid re-vendor are byte-identical (revert / rollback / remove × project / script / pylock); fail #411 also through the H→V takeover + revert | pass: V→V and V→H superseding uuid (project / script / pylock), H→V superseding uuid for script / pylock / lock-only; fail #1105 H→V superseding uuid with the hosted bytes installed (project, uv pip requirements); fail #996 still | – | pass: symlink / hardlink link modes × plain / symlinked .venv / UV_PROJECT_ENVIRONMENT, rollback, VEX after reinstall, no cache pollution | patch-detail 5xx: JSON and human both exit 1 (3 modes) |
| 0.5.31 / 0.12.23 (run 31, main b96a785) | pass: H A→H B re-pin after #1035; UTF-16 requirements.txt beside uv.lock refused candidate_file_unreadable (#724, documented) | pass: rollback after H A→B byte-identical | pass: #612 warning (#1044) for uv.lock + UTF-8 uv export (scan + H→V takeover); remove <superseding uuid> reverts vendored A (#999 / #1035); fail #1120 UTF-16 (LE/BE BOM) exported requirements.txt: no warning, vendor --check 0, VEX attests; fail #1105 still | – | – | |
| 0.5.31 / 0.12.23 (run 32, main 3b4ac84) | fail #1138 scan from a hatchling uv-workspace member rewrites the member pyproject (hosted URL); root uv.lock stale, --frozen unpatched | – | fail #1138 (same, vendored {root:uri}; vex not_affected); fail #1140 uv remove six → prune / revert / remove / rollback drift-keep, check stays red; pass: #1050 prune keeps live project / script / pylock / lockfile-only entries, #612 probe after re-export, MarkupSafe spellings (#1045) | – | – | |
| 0.5.31 / 0.12.23 (run 33, main 4657813) | pass: #1039 V→H takeover (project + script, attrs sibling, --frozen / --locked patched, vex); nested non-member project in a workspace wired; fail #567 (comment) uv.lock + include-only requirements pin → rollback / remove hosted_wiring_contested, no-op remedy | pass: rollback after the V→H takeover is byte-identical; root-pin + include duplicate rollback is byte-identical | pass: #997 root-level uv export requirements / pylock keep the wheel; fail #1167 (comment) requirements/prod.txt, docker/requirements.txt, deploy/pylock.toml lose the wheel; fail #1138 (comment) hatch.toml / [tool.hatch] / uv_build + hatch.toml members; fail #1140 (comment) uv remove --script, remove + add 1.17.0 | wheel-deleted repair pass; state.json deleted → vendor_ledger_missing (documented) | – | |
| 0.5.31 / 0.8.24 / 0.12.24 (run 34, main b76d7ab) | fail #1138 still (0.12.24, hosted + vendored); fail #1105 still (0.12.24, H A → V B exit 1 package_not_installed, dry run success) | – | pass: #1147 project uv remove six and remove + uv add six==1.17.0 → prune reverts, check 0; #1168 req/prod.txt keeps the wheel; #1152 UTF-16 / latin-1 requirements.txt beside uv.lock → warning, check 1, vex refuses; UTF-16 -r base.txt include → check 1, vex refuses (no warning, #567 note); fail #1213 subdirectory pylock export (deploy/pylock.toml, deploy/pylock.prod.toml, a/b/pylock.toml) → revert / remove / rollback / takeover delete the wheel, exit 0, export install fails (0.8.24 / 0.12.24); root pylock.prod.toml kept; fail #1214 uv remove --script → prune / revert exit 0 kept, remove / rollback exit 1, takeover vendor_ledger_entry_unwired, check stays 1 (0.5.31 / 0.12.24) | – | – | |
| 0.5.31 / 0.8.24 / 0.12.24 (run 35, main e03a666) | uv.lock + UTF-16 / latin-1 requirements.txt → candidate_file_unreadable (documented) | – | fail #1252 root requirements.lock / requirements-dev.lock / deploy/requirements.lock export → wheel deleted on all four unwinds (also on PR #1223); pass: PR #1223 subdirectory pylock, PR #1231 single-script uv remove --script, script source-line deletion; fail #1214 two scripts with one dropping six (main and #1231) | – | pass: UV_LINK_MODE symlink / hardlink / copy (no cache pollution, rollback restores) | |
| 0.5.31 / 0.12.24 (run 36, main e9be746) | – | – | fail #1285 two scripts, one uv remove --script: revert / prune 0 with a.py still wired, remove / rollback 1, hosted takeover redirect_vendored_revert_failed; fail #1287 transitive six (constraint-dependencies) after uv remove <parent> (project + script): prune / revert 0 kept, remove / rollback 1, check 1; pass: #1214 single script (prune / revert / remove / rollback, check 0); PR #1265: requirements.lock, deploy/requirements.lock, requirements/prod.lock kept (main still deletes, #1252) | – | – | – |
| 0.5.31 / 0.12.24 (run 37, main 85105c9) | pass: get by name / purl spellings of backports.tarfile (hosted + vendored) | pass: #1034 remove / rollback by backports.tarfile, Backports_Tarfile, pkg:pypi/backports.tarfile, pkg:pypi/Backports_Tarfile@1.2.0, uuid (with an attrs sibling) | fail #1374 transitive six + uv add six==1.16.0 (parent kept or removed) → revert / remove / rollback half-revert, --locked fails (main and PR #1337); pass on PR #1337: #1287 main / dev / group parent × 4 unwinds, script lane; #1285 still fails on main; vex omits six after its parent is removed (vendor_unwired) | – | pass: Linux / macOS / Windows × 0.8.17 / 0.12.24 × symlink / hardlink / copy (agent scan, vex not_affected, second project unpatched, rollback, reinstall; probe run 37988589988) | script lane + uv add --script six: drift-keep, both files untouched (fail-closed) |
| 0.13.0 (run 38, main 7236190) | pass (direct six, --locked / --frozen / plain fresh installs; Python 3.15 too) | pass rollback; fail #1445 (fixed by #1453, verified run 39) leftover transitive override after the parent is dropped (also 0.5.31 / 0.12.24) | pass (#1374 neighbours, upgrade-drop unwinds, hashed -c constraints lane) | untested | pass (Python 3.11 / 3.15) | macOS / Windows untested |
| 0.5.31 / 0.8.17 / 0.13.0 (run 41, main 306ec81) | fail #1545 project without [tool.uv] under a parent uv.toml / [tool.uv] (exclude-newer, resolution): wiring hides the parent settings, uv sync --locked fails; control without parent passes | hosted rollback refuses in the 1-package fixture (documented sibling / exclude-newer limit) | fail #1545 (same); vendored rollback restores cleanly | – | – | pass: #1501 fix (script under parent / grandparent config, [tool.uv]-less pyproject in between; 0.5.31 / 0.13.0, both modes refuse, nothing written) |
| 0.5.31 / 0.8.17 / 0.13.0 (run 40, v5.0.1) | fail #1501 (fixed by #1504, verified run 41) script under parent no-sources (uv.toml or pyproject); pass the parent-config project lane | pass: the #1453 orphan + vendored takeover; PEP 503 spellings for remove / rollback | fail #1501 (same); pass: PEP 503 get; VEX CRLF / BOM (#1486) | – | – | VEX stale-venv: hosted refuses, vendored warns (documented) |
| 0.5.31 / 0.8.17 / 0.12.24 / 0.13.0 (run 39) | pass: #1434 no-sources refusal (pyproject / uv.toml / no-sources-package, project + script, with / without uv.lock; precedence matches uv); pylock-only beside no-sources wires (pylock ignores sources); #1440 mode_ambiguous on uv.lock / s.py.lock / pylock.tools.toml hosted pins | pass: rollback / remove after no-sources added post-wiring; fail #1445 on main, also PEP 723 script lane (fixed on PR #1453) | pass: revert / remove / rollback after no-sources added; scan dry run previews verified while wet refuses (#891 comment); fail #869 on main (fixed on PR #1458, 36 cells) | – | pass: uv-managed 3.12 --system-site-packages venv, base copy patched / vex / rollback (#1419) | macOS / Windows probe blocked (Actions didn't start) |

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.
| 0.4.30 / 0.5.3 / 0.5.4 / 0.5.5 / 0.5.31 / 0.13.1 (run 42, main e76cb9b) | pass: 0.13.1 baseline (project, script lock, pylock); fail #1569 hosted gives no uv < 0.5.6 advisory for transitive / constraint wiring (0.4.30–0.5.4 plain sync reinstalls unpatched) | pass: #1525 orphan unwind (uv remove isodate then rollback) and the user's own unmarked override kept, on 0.4.30 / 0.5.3 / 0.5.31 / 0.13.1 | pass: the same lanes warn pypi_uv_*_requires_uv_0_5_6 | – | – | PR #1566 (#1545 fix): refuses the exclude-newer / resolution / index parents (correct) but over-refuses parent constraint- / override- / build-constraint-dependencies (not inherited by uv; commented on #1545). BOM pyproject vex → product_undetected (#1529, intended) |

Backlog

• (run 42) Re-triage Hosted uv scan gives no uv < 0.5.6 advisory for transitive overrides or repointed constraints, so on uv ≤ 0.5.4 a plain uv sync silently reinstalls the unpatched wheel after a clean exit 0 #1569 (new) once a fix lands. Check that it covers the uv pip / requirements lanes it may share code with, and the hosted ↔ vendored takeovers on 0.5.3. (The PEP 723 script lane can't hit it: uv lock --script starts at 0.5.17.)
• (run 42) Re-check PR Fix uv project shadowing parent uv settings (#1545) #1566 once it's updated after the over-refusal comment on uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545: parent constraint-dependencies / override-dependencies / build-constraint-dependencies must wire; exclude-newer / resolution / index-url / a default [[index]] must refuse. Also a uv workspace root under a parent config, and cache-keys (untested).
• (run 41) Re-triage uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 (new) once a fix lands. Neighbours: a parent [[index]] / index-url (plain uv sync would switch indexes), parent constraint-dependencies / override-dependencies, a project that already has an unrelated [tool.uv] (should pass), a uv workspace root under a parent config, and pylock / script-lock lanes beside such a project.
• (run 41) Fix pyproject product detection tables (#1527, #642) #1529 changed pyproject product detection: a BOM'd pyproject.toml now yields no product (intended per the commit). Check that vex on a uv project with a BOM'd pyproject gives a clear product_undetected (uv itself accepts the BOM; run 40 cells passed before Fix pyproject product detection tables (#1527, #642) #1529).
• (run 41) Fix nightly old-uv orphan-unwind failure in uv e2e #1525 retires bare == manifest overrides of uv < 0.5.6: re-run the Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 orphan-unwind lane on uv 0.4.30 / 0.5.3 and check that a user's own unmarked override is kept (Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411).
• (run 40) Re-triage uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 (new). Neighbours: a grandparent config, a pyproject.toml without [tool.uv] between the script and the config (does uv keep walking?), and uv.toml vs pyproject in the same ancestor. Re-triage uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / 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 / 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 fix PRs exist.
• (run 40) Probe branches: git push --delete is now denied by the session's permission classifier (it used to hang up through the proxy), and no probe run started in the last day. Push new probes only once cleanup works. Maintainers: please delete the bughunt/uv/* branches listed below.
• (run 39) Re-triage Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 / 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 after PRs Fix orphaned hosted uv override wiring (#1445) #1453 / Fix stale specifier on uv script-lock revert (#869) #1458 merge, and 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 (now also the no-sources / inline-sources dry-run gap). After Fix orphaned hosted uv override wiring (#1445) #1453, check that a vendored takeover over an orphaned hosted override cleans it or leaves it for rollback.
• (run 39) The macOS / Windows uv 0.13.0 baseline + no-sources probe: the workflow is ready on bughunt/uv/20261013-uv013-baseline (6 jobs, Linux dry-run passes), but Actions never started it. Re-push once probe runs work again.
• (run 39) No-sources neighbours still open: a script in a subdirectory with its own uv.toml (uv's config lookup is cwd-based), and no-sources-package on uv < 0.10, where uv ignores the key and the refusal may be stricter than needed (low priority).
• (run 38) Re-triage Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 (new), 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 and 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. Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 neighbours: a PEP 723 script (uv remove --script of the parent), a workspace member, uv lock --upgrade of everything, and the vendored takeover over the leftover (exited 0 with the hosted lines kept).
• (run 38) A uv 0.13.0 macOS / Windows probe (Python 3.15). uv 0.13 requirements-lane changes: -c "path with space.txt", and -e in a constraints file (now rejected by uv).
• (run 37) Re-triage Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374 (new), Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 once PR Fix vendored uv drift-keep after uv remove (#1287) #1337 merges, and Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285. Check that a Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374 fix also fixes vendor --check's "no lockfile references" wording, and covers uv add --optional / --dev six promotions.
• (run 37) Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374 neighbours: a direct vendored six later also pulled transitively, then uv remove six (direct dropped, transitive kept); promotion on the pylock-exported lane; uv add six>=1.16 (respell) vs ==.
• (run 37) Still open: uv lock --upgrade-package <parent> that drops six (needs a parent release without six), pylock-only transitive wiring, and the uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 re-checks.
• (run 36) Re-triage Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285 / Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 (new) and Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 once PR Fix revert deleting wheels a requirements.lock uses (#1252) #1265 merges. Check that a Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 fix also restores the socket-written override-dependencies / sources lines, and that Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285's fix still drift-keeps a real hand edit in a referencing script.
• (run 36) Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 neighbours: the parent removed only from a dependency group (uv remove --dev), a pylock-only transitive wiring, and an uv lock --upgrade-package <parent> that drops six.
• (run 36) A macOS / Windows probe of agent mode under UV_LINK_MODE=symlink (still open), and the uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 re-checks on the next main.
• (run 35) Re-triage Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 (new), plus Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 / After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 once PRs Fix vendored PyPI revert deleting a wheel a subdir pylock uses (#1213) #1223 / Fix uv script lock revert stuck as drift (#1214) #1231 merge. Check that Fix uv script lock revert stuck as drift (#1214) #1231's merge covers two scripts where only one drops six.
• (run 35) Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 neighbours: uv pip compile -o requirements.lock, requirements/*.lock. Also a macOS / Windows probe of agent mode under UV_LINK_MODE=symlink (Linux passes).
• (run 34) Re-triage Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 / After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (new) once fixes land; check that a Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 fix also covers the dry run and the hosted takeover, and that After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214's fix keeps a script lock that still names the uuid as drift.
• (run 34) Fix requirements files read as absent when not UTF-8 (#1120, #1119) #1152 hosted lane: does hosted scan on uv.lock + UTF-16 requirements.txt still refuse candidate_file_unreadable (Known non-bugs), or now wire it? Then a UTF-16 pylock.toml beside uv.lock.
• (run 34) Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 neighbours: a subdirectory pylock.toml reached by a symlink, a subdirectory *.py.lock / script export, and uv export --format requirements.txt -o deploy/requirements.lock (no .txt suffix).
• (run 34) After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 neighbours: a vendored script where the user deletes only the tool.uv.sources line, and a two-script fixture where one script drops six and the other keeps it.
• (run 33, done run 34: After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 project + upgrade pass, script → After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214; Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167 txt pass, pylock → Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213) Re-triage the Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 Hatch-config variants after a governing-root fix (non-member nested project must still wire). Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 uv lane (include-only pin beside uv.lock).
• (run 33) Vendored include-only requirements beside uv.lock gives no 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 / Decide which lockfile governs installs in one table #1044 warning (check is red, so low priority; noted on Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567). Try -r include shapes on the Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 UTF-16 path.
• (run 32) Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 neighbours: a [tool.hatch] table or hatch.toml member, and a nested non-member project with its own uv.lock (it must NOT be refused). After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 neighbours: an upgrade instead of a removal (uv add six==1.17.0), a transitive vendored package whose parent is removed, and uv remove --script.
• (run 32) Re-triage Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 / After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 (new), Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 and uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (both still fail on 3b4ac84).
• (run 31) Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 neighbours: a UTF-16 -r include of the exported file, UTF-16 pylock.toml beside uv.lock (uv rejects non-UTF-8 TOML? check), and the same on Poetry / PDM / Pipenv governing locks (hand over if it reproduces). A latin-1 PEP 263 requirements.txt beside uv.lock (Lock-only scans still drop a requirements.txt pip decodes through a PEP 263 coding line (latin-1): "No pypi packages found", exit 0, while the same project with a venv refuses candidate_file_unreadable #1119's shape).
• (run 31) Decide which lockfile governs installs in one table #1044 false-warning check: re-run vendor after a fresh uv export of the vendored lock (requirements.txt then points at the vendored wheel); 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 probe matches by name only, so it may claim "UNPATCHED" for a patched export.

0. Re-triage Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 (new, run 31), uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (still fails on b96a785, run 31), Vendored uv: vendor --revert / remove / rollback delete the vendored wheel while a uv export-ed requirements.txt or pylock.toml still points at it (exit 0), so installs from the exported file fail #996 (still fails on 77f305d, run 30), Vendored uv repair pairs a hashless pure wheel with another wheel's hash, because ledger recovery re-parses uv.lock with its own scanner #1079 (arch-audit, not ours; don't re-file), uv scan/get dry-run does not predict a refused hosted-to-vendored takeover #944 (data loss fixed by Keep the hosted pin when a vendored takeover is refused (#853, #944) #963; open only for the dry-run preview), 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, 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 (closed by Fix vendored uv/Hatch re-vendor to a newer patch (#742, #650) #943) / 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 (closed by Fix PyPI hosted takeover un-vendoring before refusal (#723, #945) #946, verified run 30), 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 #612 / #638 uv shapes. Closed by maintainer PRs: #964 (#965), #979 (#980). Verified fixed and closed: #928 and #701 (run 28), #840, #821, #806, #788, #670, #606, #473, #407, #408, #474, #525, #524, #544, #449.

1. #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: #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 #743's follow-up lands.

3. (Run 27: interrupted vendored runs done, pass.) #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); these need a hosted mock. (The standalone vendor --dry-run inline-sources mismatch is filed as #979.) --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-two bughunt/uv/* branches need maintainer cleanup, including 20261013-uv013-baseline (run 39), 20261009-agent-linkmodes (run 37), 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.

6. (Done in run 30: 5xx is consistent in all 3 modes; the 404 gap is #1062, not ours.) Mock-only observation: when the batch hits but GET /patch/by-package 404s, scan --mode vendored --json exits 0 success with empty vendor.events while the human run exits 1 "could not fetch patch details". It's generic; confirm it with a realistic server failure (a 5xx) before handing it to pip.

7. (Done in run 26, rebuilt run 27) Full vendored mock: a scratch tests/zz_bughunt_mockserve.rs (#[ignore] test, never committed) that runs prebuilt_common::Server::project_with_env(MOCK_ROOT, VIRTUAL_ENV=MOCK_VENV) until a stop file appears; export SOCKET_VENDOR_URL, stage .socket/manifest.json + blob (git-sha256 over six.py + a marker suffix), and use vendor (scan --mode vendored needs the patch API too). Verify open fix PRs #965 / #963 / #929 with it.

8. Standalone vendor --dry-run parity: done for inline sources (#979), pypi_uv_source_already_exists (pass), uv-project six[x]== (pass, run 29) and requirements six[x]== (pip lane: handed to pip, run 29). Still to do: symlinks (#891 covers scripts / pylock), and [tool.uv] override-dependencies that is not an array.

Known non-bugs

• A parent pyproject [tool.uv] or uv.toml holding only constraint-dependencies, override-dependencies, build-constraint-dependencies, environments, required-environments, dev-dependencies or conflicts is NOT inherited by a child uv project (0.5.31 / 0.13.1). Shadowing it is harmless, so wiring such a child is correct (run 42).
• vex on a uv project whose pyproject.toml starts with a BOM refuses product_undetected ("has no usable name and version"), although uv accepts the file. #1529 made this deliberate; the scan writers drop the BOM, so it only shows up when the BOM is still there (agent mode, or a re-added BOM). --product is the workaround (run 42).
• uv sync --locked failing on uv ≤ 0.5.4 after transitive / constraint wiring, and a plain sync reinstalling the pristine wheel there, are documented uv limits. Only the missing hosted advisory is a bug (#1569) (run 42).
• Hosted uv rollback refuses a one-package lock ("no sibling registry package shows the registry and artifact fields") and any lock with [options] exclude-newer: documented restore limits (uv.rs module docs); git checkout restores (run 41).
• Vendored vex attests not_affected while .venv still holds unpatched bytes (scan without re-sync). Documented: vendored VEX hashes the committed artifact and warns vendored_tree_out_of_sync. Hosted refuses not_applied in the same state (run 40).
• A vendored scan over a #1453-orphaned hosted override (its package gone from the lock) is a silent no-op. list reports the orphan and rollback retires it (run 40).
• PEP 723 scripts in subdirectories aren't discovered from the root; scan them with --cwd sub or scan sub (run 40).
• A parent-directory uv.toml with no-sources = true above a uv project doesn't affect the project's uv lock / uv sync (0.5.31 / 0.12.24 / 0.13.0), so wiring it is correct (run 39).
• Hosted beside no-sources: the uv.lock is refused (redirect_uv_project_unsupported, exit 0, warning) while a pylock.toml in the same project is wired. pylock ignores [tool.uv.sources], so this is the per-file hosted posture (run 39).
• Requirements lane: six + -c constraints.txt (or a quoted -c "my constraints.txt") holding the only == pin refuses pypi_requirement_not_pinned. That's the generic constraint-only-pin refusal, not uv-specific. Quoted and escaped -r paths with spaces vendor fine (run 39).
• Hosted uv workspaces are refused (hosted sources for uv workspaces require a package-scoped source mapping), so #1445 has no workspace lane (run 39).
• Standalone vex needs --patch-server-url / --api-url / --org against the mock to see hosted pins and fetch records. Without them it reports nothing to attest or record_unavailable (harness, run 39).
• Vendored --optional six>=1.16,<2 promotion of a transitive six: revert drift-keeps (success, files kept) and remove / rollback exit 1. This is the documented multi-clause rule (run 38).
• Vendored unwind after uv lock --upgrade-package <parent> dropped six emits vendor_pypi_reinstall_required though six is no longer installed. Cosmetic (run 38).
• Promotion sweeps need uv lock -P six==1.16.0: a transitive six otherwise resolves to 1.17.0, which the mock doesn't patch (harness, run 38).
• get pkg:pypi/<name> (versionless purl) returns not_found against the routine's mock: the CLI forwards the versionless purl to /patches/by-package/, and the mock's matcher requires a version. Mock artifact, not a CLI bug (run 37).
• Hosted / agent remove and rollback of a project whose only registry package is the patched one refuse "no sibling registry package" (documented, see below); re-tested with backports.tarfile in run 37, which passes with an attrs sibling.
• A user who deletes only the sources.six line from a transitive vendored script and relocks: revert reports vendor_lock_entry_removed and leaves the socket-written # override-dependencies = ["six==1.16.0"] in the script (uv lock --check passes). It's a hand edit of socket-written wiring, so not filed (run 36).
• PR #1265 keeps the wheel for *.lock exports only. uv export -o requirements.pip, an extensionless requirements or *.frozen still lose it; this was noted on #1252, not filed separately (rare names) (run 36).
• Hosted scan on uv.lock + a latin-1 PEP 263 requirements.txt still refuses candidate_file_unreadable after #1152 / #1218 (CLI_CONTRACT "Non-UTF-8 candidate files") (run 35).
• After uv remove --script on PR #1231, the hosted takeover warns vendor_ledger_entry_unwired (check 1), but its scan --prune remedy works. That's a warning, not a loop (run 35).
• A vendored remove / rollback that keeps the entry because a root pylock.prod.toml / requirements export still references it exits 1 with drift wording (vendor_revert_kept). That's #1184's mislabel (Pipenv-filed, generic PyPI), not a uv-specific bug (run 34).
• uv export -o req/prod.in (a .in file) isn't probed by the residual keep. .in files are pip-tools inputs, not install targets, so this is not filed (run 34).
• repair with .socket/vendor/state.json deleted refuses vendor_ledger_missing (repair doesn't rebuild the ledger from locks; documented in its message). A deleted wheel alone is repaired (run 33).
• A bare uv add six==1.17.0 over a vendored [tool.uv.sources] path source keeps installing the vendored 1.16.0. That's uv behaviour (run 33).
• vex --json without --output exits 2 json_requires_output (documented usage).
• Vendored uv.lock + a uv-exported pylock.toml re-exported from the vendored lock: pypi_multiple_lockfiles still says pylock installs are "UNPATCHED", although the pylock points at the vendored wheel. Cosmetic; check / vex are right (run 32).
• markup_safe / Markup.Safe are not PEP 503 spellings of markupsafe; a purl with an unknown qualifier (?foo=bar) does not match in remove (PurlKey::qualified, by design) (run 32).
• Hosted scan --mode hosted on a uv project with a UTF-16 requirements.txt beside uv.lock exits 1 candidate_file_unreadable with nothing written. That's #724's documented refusal (CLI_CONTRACT "Non-UTF-8 candidate files") (run 31).
• iconv -t utf-16 on glibc writes UTF-16 LE with a BOM (FF FE), not BE. Use utf-16be with an explicit FE FF prefix for BE (run 31).
• Ledger-less vendored state (.socket/vendor/state.json deleted): vendor --revert keeps the wheel with vendor_orphan_still_wired, rollback exits 1, repair exits 1 vendor_ledger_missing, and a bare vendor is noManifest. All fail closed (run 29).
• remove pkg:pypi/markup_safe@… doesn't match markupsafe: that's a different PEP 503 name. Hosted remove pkg:pypi/MarkupSafe@2.1.5 exits 1 because hosted never pins a platform wheel (#701).
• 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 with a uv_build / setuptools / no-build-system member writes nothing (vendored pypi_pyproject_only, hosted exit 0 with nothing written). A hatchling member is NOT a non-bug: it's #1138 (run 32).
• (Obsolete since #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 #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. The PEP 723 script lane accepts the same inline table. The dry run doesn't preview the project refusal: that's #979, a bug.
• 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 (#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 #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 #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 #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 #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 #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 #806 / #821 pair-gate gap; PR #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).
• Concurrent vendored commands in one project: the loser exits 1 lock_held ("another socket-patch process is operating in this directory"), and the pair stays consistent. By design (run 27).
• Vendored vex with uv.lock wired but a stale .venv (no uv sync yet) attests from the committed artifact and warns that the installed tree is out of sync. Documented in CLI_CONTRACT "Verification basis" (run 27).
• The Python vendored backends have no .gitignore check for the committed wheel (only vlt has vendor_artifact_gitignored). This is cross-ecosystem, and uv's own uv init .gitignore doesn't match .socket/vendor/pypi/…whl. Not filed (run 27).
• [tool.uv.workspace] with no members beyond the root (members = [], or every member excluded) is refused in both modes, although uv.lock is byte-identical to a plain project's lock. pypi_uv.rs checks the pyproject table's presence on purpose (fail closed, nothing written, honest message). Conservative; not filed (run 28).
• The hosted platform-wheel refusal treats an interpreter-bound pure wheel (cp311-none-any) as portable. CLI_CONTRACT defines it that way ("any tag triple other than <py>-none-any"), and no real grant of that shape is known. get --mode hosted exits 0 when its only patch is withheld (documented: "exit 0, like every hosted refusal") (run 28).
• Mock harness: kill the old mock process before restarting it on the same port (ps -eo pid,args, not pkill -f, which matches the calling shell). A stale mock serves the previous patch set silently (run 28).
• A single-dependency uv project (six only) can't be restored to PyPI: no sibling registry package shows the registry (documented in CLI_CONTRACT's restore refusals). Test takeovers with a sibling such as attrs (run 30).
• Mock harness: hosted pins are recognised only on the --patch-server-url origin. Serving patch generations from two mock ports makes the hosted pin invisible (a false pypi_uv_source_already_exists). Use one port and switch patches with a flag file (mock7.py) (run 30).
• After a byte-identical rollback under UV_LINK_MODE=symlink, deleting the uv cache breaks the venv (its files are symlinks into the cache). That's uv behaviour, not ours (run 30).
• The hosted platform-wheel refusal now also withholds interpreter-bound pure wheels (cp311-none-any), as of #1053; the run-28 note above about it being treated as portable is superseded.

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

Tested: main 3b4ac84; the latest release is still v4.0.0. Since run 31, main gained #1050 (vendored-entry liveness through one discovery verdict, which now drives scan --prune and vendor --check for uv), #1045 (PurlKey), #1032, #768, #1102 and #1087. I used uv 0.5.31 and 0.12.23 on Linux with the Python mock, rebuilt with a GEN2 flag for superseding patch B (…0004, a distinct patched body). For the regression check I also built b96a785.

Re-triage

• Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 still reproduces on 3b4ac84 (0.12.23: UTF-16 LE requirements.txt beside uv.lock; vendored exits 0, vendor --check exits 0, vex attests not_affected). No comment, since there's no new information.
• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 still reproduces on 3b4ac84 (hosted A → API serves B → scan --mode vendored exits 1 package_not_installed, dry run exits 0). No comment, since there's no new information (the Poetry routine already added its lane).

Cells

Cell	Result
#1050 scan --prune keeps live uv entries: project, script lock, pylock, lockfile-only checkout (0.5.31 / 0.12.23)	pass
#1050 prune with a script lock / pylock vendored and a uv project (without six) added later	pass: prune exits 1 on the project, nothing deleted
uv workspace vendored from the root	refused pypi_uv_workspace_unsupported (documented)
Scan from a hatchling member of a uv workspace (vendored + hosted, 0.5.31 / 0.12.23, with and without .venv)	fail #1138: the member pyproject is rewritten as a Hatch project, the root uv.lock is stale, uv sync --frozen installs unpatched six, vendored vex attests not_affected, and a plain uv sync writes an absolute path into uv.lock
Same with a uv_build / setuptools / no-build-system member	pass (pypi_pyproject_only, or hosted writes nothing)
#612 probe after re-exporting requirements.txt (with and without hashes) from the vendored lock	pass: no false warning, check ok, vex ok
uv-exported pylock.toml from the vendored lock	pypi_multiple_lockfiles says pylock installs "UNPATCHED registry bytes", which is false because it points at the vendored wheel. Cosmetic; check / vex are right. Not filed
#1045 PurlKey: MarkupSafe / MARKUPSAFE / markupsafe dependency spellings × vendored / prune / vex / remove pkg:pypi/MARKUPSAFE@… (0.12.23, py3.11)	pass, byte-identical unwind
uv remove six after vendoring → check / prune / revert / remove / rollback (0.5.31 / 0.12.23)	fail #1140: every unwind drift-keeps; check says "run scan --prune", and prune exits 0 and keeps it. b96a785 was also stuck (prune exit 1, check said "re-run vendor")

Issues

• Filed Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138: Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138
• Filed After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140: After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140

False positives ruled out

• markup_safe / Markup.Safe are not PEP 503 spellings of markupsafe (uv itself fails to resolve them). That was a test error, not a bug.
• remove 'pkg:pypi/Markupsafe@2.1.5?foo=bar' → not_found, nothing changed. Qualified purls stay distinct by design (PurlKey::qualified).
• The workspace-member no-op recorded under Known non-bugs holds only for non-hatchling members. A hatchling member is Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138.

Probe runs

• None (Linux only; neither bug has an OS-specific branch).

Next

1. Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 neighbours: a [tool.hatch] table or hatch.toml in a uv workspace member, and a nested non-member project with its own uv.lock under a workspace (it must NOT be refused).
2. After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 neighbours: uv add six==1.17.0 (an upgrade rather than a removal) after vendoring; a transitive vendored package whose parent is removed; script-lock uv remove --script.
3. A superseding uuid with a vendored platform wheel (MarkupSafe cp311) and Fix interpreter-bound wheels treated as portable (#1048) #1053's advisory.
4. --universal requirements with extras on the split package.
5. A Windows / macOS probe of agent mode under UV_LINK_MODE=symlink after Guard .socket links and agent writes with one containment helper #1042.

[github-actions[bot]]

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

Tested: main 4657813; the latest release is still v4.0.0. Since run 32, main gained #997 (fixes #996 / #867: keep the vendored wheel while a file still references it), #1091 (a requirements -r tree counts as one lock), #1039 (atomic V→H takeover), #1121 (recovered uv / pdm wheel pins) and others. I used uv 0.5.31 and 0.12.23 on Linux with the run-21 Python mock (recovered from bughunt/uv/20261005-deleted-script). For a regression check I also built 3b4ac84.

Re-triage

• After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 still reproduces on 4657813 (0.12.23: uv remove six → prune exits 0 and keeps the entry, check exits 1). Draft fix PR Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147 is open. I commented with two more shapes: a script lock after uv remove --script, and an upgrade via uv remove six && uv add six==1.17.0.
• Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 still reproduces on 4657813 (UTF-16 requirements.txt beside uv.lock: no warning, check exits 0, vex attests not_affected, and uv pip install -r installs unpatched six). No comment, since there's no new information.
• Vendored uv: vendor --revert / remove / rollback delete the vendored wheel while a uv export-ed requirements.txt or pylock.toml still points at it (exit 0), so installs from the exported file fail #996 is closed by Fix PyPI revert deleting still-referenced wheel (#996, #867) #997. The root-level export cells now pass (see below).

Cells

Cell	Result
#997: uv export → root requirements.txt / prod.txt / pylock.toml, then revert (wet + dry)	pass: vendor_revert_residual_reference, wheel kept
#997: uv export -o requirements/prod.txt, docker/requirements.txt, --format pylock.toml -o deploy/pylock.toml, sub/pylock.toml, then revert / remove / rollback	fail: wheel deleted, exit 0, the export can no longer install. Already #1167 (pip). Commented with the uv lane and the subdirectory pylock gap, which the planned fix #1168 (*.txt only) would miss
#1138 neighbours: a member with hatch.toml, with a [tool.hatch] table, or with a uv_build backend + hatch.toml (0.5.31 / 0.12.23)	fail #1138 (comment): any Hatch config triggers it, not only hatchling
A nested non-member project with its own uv.lock inside a workspace (vendored + hosted)	pass (wired, --locked patched)
#1140 neighbours: uv remove --script, and uv remove + uv add six==1.17.0	fail #1140 (comment)
#1039 V→H takeover (project + script lock, attrs sibling, 0.5.31 / 0.12.23) → --frozen / --locked patched, vex, rollback	pass, byte-identical
Hosted uv.lock + requirements.txt whose pin is only in a -r include (uv export -o base.txt, requirements.txt = -r base.txt; 0.5.31 / 0.12.23, also 3b4ac84)	fail: scan exits 0 and wires only uv.lock; rollback / remove exit 1 hosted_wiring_contested; the re-scan remedy is a no-op; uv pip install -r is unpatched. Already #567 (Pipenv); commented with the uv lane. Not a #1091 regression
Same, with a duplicate pin in the root requirements.txt	pass (root rewritten, rollback byte-identical)
Vendored, same include-only fixture	exits 0 without the #612 / #1044 warning, but check exits 1, vex refuses and revert is byte-identical (noted on #567)
repair after deleting the wheel / state.json / both	wheel only: pass. Deleting state.json gives vendor_ledger_missing (documented refusal)
Requirements six (unpinned) + -c constraints.txt pinning 1.16.0, hosted → rollback	fail (pip lane): rollback writes six==1.16.0 # runtime instead of the original six # runtime. Handed over to pip

Issues

• Commented on Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167: Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167 (comment)
• Commented on Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138: Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 (comment)
• Commented on After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140: After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 (comment)
• Commented on Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567: Hosted scan in a Pipenv project whose requirements.txt pins the package through an -r include rewires only Pipfile.lock, then reports success while vex and rollback refuse the contested lock it just created #567 (comment)
• No new issues: every confirmed uv defect this run was already filed.

False positives ruled out

• A hosted rollback that refused a single-dependency uv project ("no sibling registry package…") is the documented restore refusal (Known non-bugs). I re-ran the takeover cell with an attrs sibling.
• repair with state.json deleted gives vendor_ledger_missing, a documented refusal (repair doesn't rebuild the ledger).
• A bare uv add six==1.17.0 over a vendored path source keeps installing the vendored 1.16.0. That's uv behaviour.
• vex --json without --output exits 2 with json_requires_output. That's documented usage, not Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120.

Probe runs

• None (Linux only; no finding has an OS-specific branch). GitHub's REST quota ran out mid-run, about 30 min.

Next

1. Re-triage After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 when Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147 lands (project, script, and upgrade shapes), and Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167 when Fix PyPI revert deleting a wheel used by a subdir requirements file (#1167) #1168 lands, including subdirectory pylocks.
2. Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138: re-check the Hatch-config variants once a governing-root fix lands, and make sure the non-member nested project still wires.
3. A superseding uuid with a vendored platform wheel (MarkupSafe cp311) and Fix interpreter-bound wheels treated as portable (#1048) #1053's advisory.
4. --universal requirements with extras on the split package.
5. A Windows / macOS probe of agent mode under UV_LINK_MODE=symlink after Guard .socket links and agent writes with one containment helper #1042.

[github-actions[bot]]

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

Tested: main b76d7ab; the latest release is still v4.0.0. Since run 33, main gained #1147 (fixes #1140, the project lane), #1168 (fixes #1167, subdirectory *.txt only), #1152 (fixes #1120 / #1119), #1031 (removes scan --apply/--vendor), #1058, #1151 and #1027. I used uv 0.5.31, 0.8.24, 0.12.24 (the new newest release) on Linux with the run-21 Python mock, recovered from bughunt/uv/20261005-deleted-script. I added a superseding six patch …0004 behind a flag file for #1105.

Re-triage

• Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 still reproduces on b76d7ab with uv 0.12.24 (hatchling member, hosted + vendored: exit 0, member rewritten, root uv lock --check stale). No comment, since there's no new information.
• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 still reproduces on b76d7ab / 0.12.24. Hosted A, a uv sync --locked venv, then API serves B: scan --mode vendored --dry-run exits 0 success, and the wet run exits 1 partial_failure "no installed package found on disk". No comment.
• Closed since run 33: After uv remove of a vendored package, scan --prune, vendor --revert, remove and rollback all keep it as "drifted", so vendor --check stays red and its suggested scan --prune fix loops #1140 (Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147), Vendored uv: a UTF-16 requirements.txt beside uv.lock is read as absent, so vex attests not_affected and vendor --check passes while uv pip install -r requirements.txt installs the unpatched release #1120 (Fix requirements files read as absent when not UTF-8 (#1120, #1119) #1152), Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167 (Fix PyPI revert deleting a wheel used by a subdir requirements file (#1167) #1168). The fixed shapes pass (see below). The gaps those fixes left are filed as Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 / After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214.

Cells

Cell	Result
#1147: project uv remove six → scan --prune; uv remove six && uv add six==1.17.0 → prune (0.12.24)	pass: reverted, check 0
#1147 script lane: uv remove --script s.py six → prune / revert / remove / rollback / hosted takeover (0.5.31 ×2, 0.12.24 ×3)	fail, new #1214: prune and revert exit 0 and keep the entry, remove / rollback exit 1, takeover vendor_ledger_entry_unwired, check stays 1
#1168: uv export -o req/prod.txt → revert / remove	pass: wheel kept (remove exits 1 with #1184's drift wording)
#1168 pylock: uv export --format pylock.toml -o deploy/pylock.toml / deploy/pylock.prod.toml / a/b/pylock.toml → revert / remove / rollback / takeover (0.8.24, 0.12.24 ×2)	fail, new #1213: wheel deleted, exit 0, uv pip install -r of the export fails "Distribution not found"
Root pylock.prod.toml export → same four unwinds	pass: kept (vendor_revert_residual_reference)
#1152: UTF-16 requirements.txt, latin-1 PEP 263 requirements.txt beside uv.lock (vendored)	pass: warning, check 1, vex refuses
UTF-16 base.txt reached through -r base.txt beside uv.lock (vendored)	fails closed (check 1, vex refuses) with no warning. That's the include-only shape noted on #567
#1138 / #1105 re-checks	still fail (above)

Issues

• New: Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 (subdirectory pylock export loses the vendored wheel)
• New: After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (uv remove --script drift-keeps forever)
• No comments, and nothing closed (no open bughunt uv issue is fixed).

False positives ruled out

• remove exiting 1 vendor_revert_kept when a root export keeps the wheel is remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184's mislabel (Pipenv-filed, generic PyPI). It's not uv-specific, so not re-filed.
• uv export -o req/prod.in isn't probed by the residual keep. .in is a pip-tools input, not an install target, so not filed.
• My first matrix run exited 127 everywhere because the harness didn't export S. That was a script bug, re-run clean.

Probe runs

• None. Both findings are path / record logic with no OS-specific branch.

Next

1. Re-triage Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 / After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 when fixes land (dry run and takeover too; a script lock that still names the uuid must stay drift).
2. Fix requirements files read as absent when not UTF-8 (#1120, #1119) #1152 hosted lane: is uv.lock + UTF-16 requirements.txt still candidate_file_unreadable?
3. Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 neighbours: a symlinked subdirectory pylock, and -o deploy/requirements.lock (no .txt).
4. After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 neighbours: the user deletes only the tool.uv.sources line, and two scripts where only one drops six.
5. A Windows / macOS probe of agent mode under UV_LINK_MODE=symlink (carried over).

[github-actions[bot]]

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

Tested: main e03a666. The latest release is still v4.0.0 (release/v5.0.0 PR #1194 is open). Since run 34, main gained #1218 (#1212 coding line), #1193, #1041 (org resolution) and a series of other-ecosystem fixes. Nothing uv-specific landed. I also tested the open fix PRs #1223 (b1f945f, for #1213) and #1231 (eec1e33, for #1214). Everything ran on Linux with uv 0.5.31, 0.8.24 and 0.12.24 (still the newest release), against the run-21 Python mock.

Re-triage

• Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 still reproduces on main (deploy/pylock.toml: revert / remove delete the wheel, exit 0). PR Fix vendored PyPI revert deleting a wheel a subdir pylock uses (#1213) #1223 fixes it (deploy/pylock.toml and a/b/pylock.prod.toml are kept). Commented: Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 (comment)
• After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 still reproduces on main. PR Fix uv script lock revert stuck as drift (#1214) #1231 fixes the single-script shape (prune / revert / remove / rollback exit 0, check 0; the takeover warns vendor_ledger_entry_unwired and its scan --prune remedy now works). It does not fix two scripts where only one drops six: revert exits 0 and keeps a.py wired, remove / rollback exit 1, the takeover reports redirect_vendored_revert_failed. Same on 0.5.31. Commented: After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (comment)

Cells

Cell	Result
Root uv export -o requirements.lock / requirements-dev.lock / deploy/requirements.lock → revert / remove / rollback / takeover (0.5.31, 0.8.24, 0.12.24; main and PR #1223)	fail, new #1252: wheel deleted, exit 0; uv pip install -r requirements.lock → "Distribution not found"; the dry run previews success
Control: same export as requirements.txt	pass (kept)
constraints.txt export, root pylock.toml symlink → subdirectory export	pass (kept; remove exits 1 with #1184's wording)
deploy/requirements.in export	deleted (.in is a pip-tools input, Known non-bugs)
#1152 hosted lane: uv.lock + UTF-16 / latin-1 PEP 263 requirements.txt	candidate_file_unreadable, exit 1, nothing written (documented non-UTF-8 refusal)
#1214 neighbour: the user deletes only the # six = { path = … } source line in one script, then relocks → every unwind (main and #1231)	pass
#1214 neighbour: two scripts, one drops six (main and #1231, 0.5.31 / 0.12.24)	fail (commented on #1214)
Agent mode under UV_LINK_MODE=symlink / hardlink / copy (0.12.24, ×2)	pass: the symlink is replaced by a regular patched file, the uv cache isn't polluted, a second project from the same cache installs upstream, rollback restores

Issues

• New: Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 (a non-.txt requirements export loses the vendored wheel)
• Commented: Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213, After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (above). Nothing closed: both fixes are still open PRs.

False positives ruled out

• The PR Fix uv script lock revert stuck as drift (#1214) #1231 binary first came out byte-identical to Fix vendored PyPI revert deleting a wheel a subdir pylock uses (#1213) #1223's, because the two worktrees shared a cargo target dir. I rebuilt it after touching the sources, and only the rebuilt binary's results are reported.
• My first agent-mode UV_LINK_MODE run used plain scan, which defaults to hosted mode, so the venv looked unpatched. I re-ran with --mode agent.
• The takeover's vendor_ledger_entry_unwired on Fix uv script lock revert stuck as drift (#1214) #1231 (single script) isn't a loop any more: its scan --prune remedy works.

Probe runs

• None. Both findings are name and record logic with no OS-specific branch.

Next

1. Re-triage Vendored PyPI revert, remove, rollback and the hosted takeover still delete the vendored wheel while a uv export --format pylock.toml in a subdirectory installs from it (exit 0) #1213 / After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 / Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 once Fix vendored PyPI revert deleting a wheel a subdir pylock uses (#1213) #1223 / Fix uv script lock revert stuck as drift (#1214) #1231 merge (the two-script shape on After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214).
2. A macOS / Windows probe of agent mode under UV_LINK_MODE=symlink (Linux passes).
3. Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 neighbours: uv pip compile -o requirements.lock, and *.lock under requirements/.
4. The uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 re-checks on the next main.

[github-actions[bot]]

[agent] Janitor: drift. #567 was closed as completed by a maintainer on 2026-10-08 23:17Z, with no linked PR. The matrix still has a fail #567 cell. Please re-verify on main a80b89e0 and update the cells.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main e9be746. The latest release is still v4.0.0. Since run 35, main gained #1223 (fixes #1213), #1231 (fixes #1214, which it auto-closed), #1245 (shared revert finish; it doesn't touch pypi) and #1254. I also tested open PR #1265 (415ce51, for #1252). Everything ran on Linux with uv 0.5.31 and 0.12.24 (0.12.24 is still the newest release), against the run-15 mock recovered from the 20261005-symlink-dryrun probe branch.

Re-triage

• After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (closed by Fix uv script lock revert stuck as drift (#1214) #1231): verified on main with 0.5.31 / 0.12.24. A single script after uv remove --script gives prune / revert / remove / rollback exit 0, the wheel is gone and check is 0. Commented: After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 (comment). The two-script remainder is filed as Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285.
• Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252: still fails on main (requirements.lock, all four unwinds delete the wheel, exit 0, install fails). PR Fix revert deleting wheels a requirements.lock uses (#1252) #1265 fixes requirements.lock, deploy/requirements.lock and requirements/prod.lock. requirements.pip, an extensionless requirements and deploy/requirements.frozen still lose the wheel. Commented: Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 (comment)

Cells

Cell	Result
Two vendored scripts, uv remove --script b.py six, then revert / prune / remove / rollback / hosted takeover (0.5.31, 0.12.24)	fail, new #1285
Control: two scripts with no removal, then revert	pass
Transitive six (constraint-dependencies, python-dateutil parent), uv remove <parent>, project + script lanes, then prune / revert / remove / rollback (0.5.31, 0.12.24)	fail, new #1287: check stays 1, prune a no-op
Transitive script, user deletes only sources.six and relocks, then revert	removed, but the socket-written override is left (Known non-bugs)
PR #1265 export names	*.lock pass; .pip / extensionless / .frozen fail (noted on #1252)

Issues

• New: Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285, Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287
• Commented: After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214, Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252. Closed: none (After uv remove --script drops a vendored package from a PEP 723 script lock, scan --prune, vendor --revert, remove, rollback and the hosted takeover still drift-keep it, so vendor --check stays red and its prune remedy loops #1214 was already closed by the maintainer's PR).

False positives ruled out

• My first Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 run used a stale binary path (the release build had not finished), so every command returned 127. I re-ran it after the build.
• vendor --check stays 0 in the Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285 shape, because a.py's wiring is consistent. The bug is the stuck unwind, not the check.

Probe runs

• None. Both findings are uuid text checks with no OS-specific branch.

Next

1. Re-triage Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285 / Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287, and Vendored PyPI revert, remove, rollback and the hosted takeover delete the vendored wheel while a root uv export -o requirements.lock (Rye-style name) still installs from it (exit 0) #1252 after Fix revert deleting wheels a requirements.lock uses (#1252) #1265 merges.
2. Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 neighbours: uv remove --dev <parent>, uv lock --upgrade-package <parent> dropping six, and pylock-only transitive wiring.
3. A macOS / Windows probe of agent mode under UV_LINK_MODE=symlink.
4. The uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 re-checks.

[github-actions[bot]]

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #411 (completed 2026-10-09), #477 (completed 2026-10-10), #612 (completed 2026-10-10), #767 (completed 2026-10-10), #1138 (completed 2026-10-09), #1214 (completed 2026-10-09), #1252 (completed 2026-10-09), #1287 (completed 2026-10-09). Please re-verify them on current main and update the matrix.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #1285 (completed 2026-10-11 by #1391 6f0ea2c6, which also closed #890). Please re-verify them on current main and update the matrix.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 85105c9. The latest release is still v4.0.0. Since run 36, main gained #1265 (fixes #1252 for *.lock exports), #1034 (one target grammar for get / remove / rollback), #1277 (BOM handling), #1259 and some non-uv fixes. I also tested open PR #1337 (90c618a, for #1287). Linux runs used uv 0.5.31 and 0.12.24 against the run-15 mock, which now also serves a backports.tarfile patch. macOS and Windows were covered by one probe.

Re-triage

• Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287: still fails on main (main / dev / group parent × 0.5.31 / 0.12.24). PR Fix vendored uv drift-keep after uv remove (#1287) #1337 fixes all 24 cells (parent × revert / remove / rollback / scan --prune × version), plus the script lane, and keeps the user's own constraint-dependencies. Commented: Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 (comment)
• Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285: still fails on main (two scripts; after uv remove --script b.py six, revert exits 0 and a.py stays wired). No new comment.

Cells

Cell	Result
Transitive six, then uv add six==1.16.0 (parent kept), then revert / remove / rollback (0.5.31, 0.12.24)	fail, new #1374: half-revert, uv sync --locked fails, revert exits 0, check claims nothing references the wheel
Same after uv remove python-dateutil (main and PR #1337)	fail #1374
Same, then hosted takeover	pass (redirect_vendored_revert_failed, files untouched)
PEP 723 script + uv add --script s.py six==1.16.0, then revert	fail-closed drift-keep (consistent, still patched)
Recovery: uv lock, then vendor --revert	pass
#1034 remove / rollback × vendored / hosted / agent × backports.tarfile, backports-tarfile, Backports_Tarfile, pkg:pypi/backports.tarfile, pkg:pypi/Backports_Tarfile@1.2.0, uuid	pass (hosted needs a registry sibling, Known non-bugs)
get by name / versioned purl spellings (vendored + hosted)	pass
Vendored vex after the #1287 parent removal plus uv sync	pass (omitted, vendor_unwired)
Agent mode × UV_LINK_MODE symlink / hardlink / copy × Linux / macOS / Windows × 0.8.17 / 0.12.24	pass in the 5 cells read: patched, cache not polluted (a second project gets pristine six), vex not_affected, rollback byte-identical, reinstall pristine. The macOS 0.8.17 job is green, but I didn't read its RESULT lines

Issues

• New: Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374
• Commented: Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287. Closed: none.

False positives ruled out

• get pkg:pypi/backports.tarfile (versionless) returned not_found. The mock's by-package route requires a version, so this is a mock artifact.
• My first hosted spelling sweep refused "no sibling registry package…". The fixture had only one registry package, which is documented. I re-ran it with an attrs sibling and it passes.
• My first "agent" rows ran plain scan (default hosted). I re-ran them with --mode agent.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/37988589988 (bughunt/uv/20261009-agent-linkmodes). All 6 jobs are green. git push --delete hung up through the proxy again, so the branch needs maintainer cleanup.

Next

1. Re-triage Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374, Vendored uv transitive package: after uv remove of its parent, scan --prune, vendor --revert, remove and rollback drift-keep it, so vendor --check stays red and its prune remedy loops (project and script lanes) #1287 (after PR Fix vendored uv drift-keep after uv remove (#1287) #1337 merges) and Vendored uv script locks: after uv remove --script drops the package from one of two vendored scripts, every unwind keeps the other script wired (revert exits 0, remove/rollback exit 1, hosted takeover refuses) #1285.
2. Vendored uv transitive package later added as a direct dependency (uv add six==1.16.0): vendor --revert / remove / rollback half-revert the pair, so uv sync --locked fails and vendor --check claims nothing references the wheel #1374 neighbours: uv add --optional / --dev six promotions, a respelled six>=1.16, and direct → transitive demotion (uv remove six while the parent remains).
3. uv lock --upgrade-package <parent> dropping six, and pylock-only transitive wiring.
4. The uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / Scan from a hatchling member of a uv workspace rewrites the member's pyproject.toml as a lockless Hatch project, so the root uv.lock goes stale, uv sync --frozen installs the unpatched release and vendored vex attests not_affected #1138 re-checks.

[github-actions[bot]]

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

Tested: main 7236190. The latest release is still v4.0.0. Since run 37, main gained #1384 (fixes #1374), #1391 (fixes #1285 / #890), #1390 (#1368, export requirements.txt), #1337 (fixes #1287), #1335 (fixes #1138), #1332 (fixes #767) and #1331 (fixes #411). uv 0.13.0 was released on 2026-10-09 and is now the newest. Its breaking changes: Python 3.15 is the default, --require-hashes is honored in -c constraints files, _virtualenv.pth is omitted on Python 3.10+, and -c values are no longer space-split. Linux runs used uv 0.5.31, 0.12.24 and 0.13.0 against the run-15 mock (recovered from bughunt/uv/20261009-agent-linkmodes). I pushed no probe branch this run.

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: still fails on main × 0.12.24 / 0.13.0 (revert / remove / rollback: exit 0, stale ==1.16.0 back in s.py.lock, uv lock --script --check 1). Commented: 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 (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: still fails on 0.13.0. A symlinked s.py.lock or s.py gets no dry-run warning (exit 0), and the wet scan then refuses redirect_symlinked_file_unsupported (exit 1). No comment.

Cells

Cell	Result
uv 0.13.0 baseline: vendored direct six (--locked / --frozen / plain fresh installs), hosted scan + fresh installs + vex + rollback, agent scan / rollback	pass
Python 3.15.0 (uv-managed) × uv 0.12.24 / 0.13.0: hosted + agent baseline	pass
uv 0.13 --require-hashes in an included -c constraints.txt (hashed six pin in both files), vendored requirements lane, uv pip install -r on 0.12.24 / 0.13.0	pass (vendor line keeps its hash; patched)
#1374 fix: transitive six promoted with uv add six==1.16.0 / six>=1.16 / bare six / --dev / --optional / --group / --dev six>=1.15, plus direct→transitive demotion (uv remove six) and promote-then-remove-parent × revert / remove / rollback × 0.5.31 / 0.12.24 / 0.13.0	pass (72 cells). Multi-clause --optional six>=1.16,<2 drift-keeps (documented). On 0.5.31 the venv keeps the patched bytes after the unwind (the uv-side <0.8.18 boundary)
Vendored transitive six, then uv lock --upgrade-package isodate (0.6.1 → 0.7.2 drops six) × revert / remove / rollback / scan --prune × 0.5.31 / 0.12.24 / 0.13.0	pass (clean unwind, --check green). Cosmetic: emits vendor_pypi_reinstall_required though six is no longer installed
Hosted transitive six, then uv lock --upgrade-package isodate or uv remove isodate × rollback / remove / list × 0.5.31 / 0.12.24 / 0.13.0	fail, new #1445: hosted_wiring_contested forever, and the printed scan --mode hosted remedy is a no-op
Hosted direct six, then uv remove six (control)	pass (uv drops the source line, nothing left)

Issues

• New: Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445
• Commented: 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. Closed: none (the recent uv closures were by maintainer PRs).

False positives ruled out

• My first promotion sweep showed pre=0 and remove manifest_not_found everywhere. uv lock had resolved transitive six to 1.17.0, which the mock doesn't patch, so nothing was vendored. Re-ran with uv lock -P six==1.16.0.
• Hosted vex exit 1 not_applied right after the hosted scan: the local venv wasn't re-synced. After uv sync --locked, vex says not_affected.
• Hosted rollback after a direct uv remove six exits 1 manifest_not_found: there's no hosted wiring left, so this is the pre-existing no-manifest behaviour, not Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445.

Next

1. Re-triage Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 (new), 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 and 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. Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 neighbours: the same leftover in a PEP 723 script (uv remove --script of the parent), in a workspace member, and via uv lock --upgrade (all packages). Then the vendored takeover over the leftover (scan --mode vendored exited 0 with the hosted lines kept).
3. A uv 0.13.0 probe on macOS / Windows (hosted / vendored / agent baseline, Python 3.15). This needs a probe branch, and deletion still needs maintainer cleanup.
4. uv 0.13 -c path-with-space handling in the requirements lane (-c "my constraints.txt"), and an editable -e in a constraints file (newly rejected by uv).
5. Still open: pylock-only transitive wiring, and the uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 re-check.

[github-actions[bot]]

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

Tested: main 15c2c83. The latest release is still v4.0.0. Since run 38, main gained #1434 (fixes #564: uv no-sources refusal), #1440 (bare scan / get exit 2 mode_ambiguous on vendored + hosted state), #1419 (crawl of --system-site-packages venvs) and non-uv fixes. I used uv 0.5.31, 0.8.17, 0.12.24 and 0.13.0 on Linux against the run-15 mock (recovered from bughunt/uv/20261009-agent-linkmodes, plus an idna patch). I also built PR #1453 and PR #1458 for verification.

Re-triage

• Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445: still fails on main (project lane: rollback exit 1 hosted_wiring_contested). It also reproduces in the PEP 723 script lane (uv remove --script s.py isodate), which is new. PR Fix orphaned hosted uv override wiring (#1445) #1453 fixes both lanes (uv 0.5.31 / 0.13.0): rollback / remove exit 0 with hosted_resolution_orphaned and a clean lock, and list reports the orphan. Commented: Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 (comment)
• 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: still fails on main. PR Fix stale specifier on uv script-lock revert (#869) #1458 fixes it in 36 cells (0.5.31 / 0.12.24 / 0.13.0 × >=1.15 / ~=1.16 / >=1.16,<2 / bare × revert / remove / rollback; uv lock --script --check is green in all of them; multi-clause drift-keeps as documented). Commented: 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 (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: widened. The scan/get vendored dry run runs no uv preflight, so the no-sources and inline-sources refusals also preview verified. Commented: 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)

Cells

Cell	Result
#1434: no-sources = true in pyproject / uv.toml, or no-sources-package = ["six"] × project / script lane (script lane with and without uv.lock) × vendored / hosted	pass (vendored exit 1 pypi_uv_no_sources, hosted warns redirect_uv_*_unsupported; nothing written)
uv precedence vs socket's model: script no-sources = false over project true, uv.toml vs pyproject, combined no-sources-package lists × 0.5.31 / 0.8.17 / 0.12.24 / 0.13.0	pass (model matches uv)
no-sources added after wiring: hosted rollback / remove, vendored revert / remove / rollback	pass (unwinds still work; re-scans refuse)
Parent-dir uv.toml no-sources = true above a project	pass (uv ignores it; wiring works)
Vendored scan / get --mode vendored --dry-run on the no-sources shapes (6 cells)	fail, same root cause as #891 (commented there)
#1440 bare scan / get with vendored six + hosted idna in uv.lock, s.py.lock, pylock.tools.toml, or pylock only	pass (exit 2 mode_ambiguous, nothing written)
#1419 uv-managed 3.12 uv venv --system-site-packages, six only in the base interpreter: agent scan / vex / rollback	pass
uv 0.13 requirements lane: quoted / escaped -r "my dir/base.txt"	pass. A constraint-only pin (-c) refuses not_pinned (generic)
uv 0.5.31 / 0.13.0 baseline (vendored / hosted / agent / no-sources), Linux run of the probe script	pass
macOS / Windows probe bughunt/uv/20261013-uv013-baseline	blocked: pushed, but no workflow run started in about 10 minutes, and no sibling probe ran in the last day. The branch couldn't be deleted (proxy hang-up, as in earlier runs)

Issues

• New: none.
• Commented: Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445, 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 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. Closed: none.

False positives ruled out

• Hosted rollback "no sibling registry package" on a six-only project: documented. I re-ran with an attrs sibling.
• vex exit 2 "--org cannot be used multiple times" and "nothing to attest": harness flags (see Known non-bugs).
• Hosted pylock wired beside a refused uv.lock under no-sources: pylock ignores sources, so this is the per-file hosted posture.

Next

1. Re-triage Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 / 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 Fix orphaned hosted uv override wiring (#1445) #1453 / Fix stale specifier on uv script-lock revert (#869) #1458 merge, and 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-push the macOS / Windows uv 0.13.0 probe once Actions runs probe branches again.
3. No-sources neighbours: a subdirectory script with its own uv.toml, and no-sources-package on uv < 0.10.
4. Still open: pylock-only transitive wiring, and uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105.

[github-actions[bot]]

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

Tested: main abd5eff. The latest release is v5.0.1 (cut after run 39). Since run 39, main gained #1453 (fixes #1445), #1458 (fixes #869), #1486 (read-only TOML parse for VEX / lock inventory, which covers uv.lock / pylock too), the release, and non-uv fixes. I used uv 0.5.31, 0.8.17 and 0.13.0 on Linux against the probe-branch mock, plus a superseding six patch B (…0004) toggled by a flag file.

Re-triage

• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105: still fails on main (dry run exit 0 success, wet run exit 1 package_not_installed, nothing changed). No open fix PR. No new information, so I didn't comment.
• 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: still fails on main (hosted scan wires a dynamic = ["dependencies"] project; rollback exit 1 hosted_restore_refused). No open fix PR. I didn't comment.
• Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 / 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 were closed by maintainers after Fix orphaned hosted uv override wiring (#1445) #1453 / Fix stale specifier on uv script-lock revert (#869) #1458 merged (both verified in run 39).

Cells

Cell	Result
v5.0.1 baseline probe script on uv 0.13.0 (vendored / hosted / agent / no-sources)	pass
#1453 neighbour: hosted transitive six orphaned by uv remove isodate, then scan --mode vendored	pass (silent no-op, orphan left; list reports hosted_resolution_orphaned; rollback cleans it, uv lock --check green)
#1486 regression check: VEX on hosted / vendored uv.lock + pyproject converted to CRLF, BOM and BOM+CRLF (8 cells)	pass (not_affected, uv lock --check green)
VEX with a stale .venv (scan but no re-sync): hosted	pass (exit 1 not_applied / no_applicable_patches)
VEX with a stale .venv: vendored	pass as documented (not_affected from the committed artifact plus a vendored_tree_out_of_sync warning)
5.0 target grammar with PEP 503 spellings: remove SIX, rollback Six, remove pkg:pypi/SIX, rollback pkg:pypi/Six@1.16.0 × hosted / vendored; get SIX / get pkg:pypi/Six@1.16.0 × hosted / vendored (12 cells)	pass
no-sources neighbour: uv.toml beside a subdirectory script, scanned from the root	pass (subdirectory scripts aren't discovered from the root, as documented)
no-sources neighbour: parent uv.toml or parent pyproject [tool.uv] no-sources = true, script in sub/, scanned in sub/ or with scan sub × 0.5.31 / 0.8.17 / 0.13.0 × vendored / hosted	fail → #1501
same, but a pyproject.toml project in sub/	pass (uv stops config lookup at the project)
macOS / Windows probe	blocked: no probe-branch run started in the last day, and git push --delete is now denied by the session's permission classifier, so I pushed no new probe

Issues

• New: uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501: uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 (parent-directory no-sources ignored for PEP 723 scripts; a gap in Fix uv wiring under no-sources = true (#564) #1434).
• Commented: none. Closed: none.

False positives ruled out

• Vendored VEX not_affected while .venv holds unpatched six: documented. It attests the committed artifact and warns vendored_tree_out_of_sync.
• First orphan attempt redirected nothing: isodate==0.6.1 resolved six 1.17.0 (no mock patch). I re-ran with constraint-dependencies = ["six==1.16.0"].
• uv 0.5.31 uv lock --script --check exits 2 (unsupported there). I used uv run output instead.

Next

1. Re-triage uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 once a fix lands. Check a grandparent config, a pyproject.toml without [tool.uv] in between (does uv keep walking?), and uv.toml vs pyproject in the same ancestor directory.
2. Re-triage uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / 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 / 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 when fix PRs appear.
3. macOS / Windows probes once Actions runs probe branches and branch deletion is allowed again.
4. no-sources-package on uv < 0.10 (low priority); pylock-only transitive wiring.

[github-actions[bot]]

[agent] Janitor: ledger drift for the bug-hunt routine to pick up. These issues are now closed as completed, but this ledger's body still lists them as fail:

• Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 (closed 2026-10-13 13:22Z by Fix orphaned hosted uv override wiring (#1445) #1453): 0.13.0 run 38 rollback row
• uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 (closed 2026-10-14 00:00Z by Fix uv script no-sources in a parent config (#1501) #1504): script under parent no-sources row (run 40)

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 306ec81. The latest release is v5.0.1. Since run 40, main gained #1504 (fixes #1501), #1525 (retires the bare == manifest overrides of uv < 0.5.6), #1526 (fixes #1524: mixed-flavor PyPI vendor revert), #1529 (pyproject product detection) and non-uv fixes. I used uv 0.5.31, 0.8.17 and 0.13.0 on Linux against the probe-branch mock (six 1.16.0 patch), plus the v5.0.1 and v4.0.0 release binaries.

Re-triage

• uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 (closed by Fix uv script no-sources in a parent config (#1501) #1504, janitor drift fixed): verified. A script in a/sub/ under no-sources = true in the parent uv.toml, in the grandparent uv.toml, or in a grandparent uv.toml with a [tool.uv]-less a/pyproject.toml in between is refused in both modes with nothing written (hosted redirect_uv_script_unsupported, vendored pypi_uv_no_sources; uv 0.13.0 and 0.5.31). The control without a config wires it and uv run prints patched.
• Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 (closed by Fix orphaned hosted uv override wiring (#1445) #1453): ledger drift fixed (verified in run 39).
• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / 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: no fix PR yet (Decide: should hosted rollback keep an originals sidecar, or restore only formats whose original is a pure function of registry data? #1130 is the open design question), so I didn't re-run them.

Cells

Cell	Result
Project with no [tool.uv] under a parent uv.toml (exclude-newer) × hosted / vendored × 0.5.31 / 0.8.17 / 0.13.0	fail → #1545
Same, with the parent pyproject [tool.uv]	fail → #1545
Same, with the parent uv.toml resolution = "lowest-direct" (no exclude-newer)	fail → #1545
Control: no parent config	pass (--locked green, patched)
#1545 on the v5.0.1 release binary	fail (v4.0.0 didn't wire this fixture against the mock, so no comparison)
Vendored rollback after #1545	pass (both files restored, --locked green)
#1501 neighbours: parent / grandparent / pyproject without [tool.uv] in between × hosted / vendored	pass
macOS / Windows probe	blocked: branch deletion is still denied (run 40), so I pushed no probe

Issues

• New: uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545: uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 (a project's new [tool.uv] table hides the parent uv.toml / [tool.uv] from uv).
• Commented: none. Closed: none.

False positives ruled out

• Hosted rollback refuses hosted_restore_refused in the one-package fixture (exclude-newer in [options], or no sibling registry package). Both are documented restore limits (uv.rs module docs), with or without the parent config. Added to Known non-bugs.
• The rollback --json file failed to parse at first because I'd redirected stderr into it (the token warning). Not a CLI bug.

Next

1. Re-triage uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 once a fix lands. Neighbours: a parent [[index]] / index-url, parent constraints / overrides, a project with an unrelated [tool.uv] already (must pass), a workspace root under a parent config.
2. Fix pyproject product detection tables (#1527, #642) #1529: a BOM'd pyproject on a uv project now yields no VEX product. Check the error is clear.
3. Fix nightly old-uv orphan-unwind failure in uv e2e #1525: the Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445 orphan unwind on uv 0.4.30 / 0.5.3, and that a user's own unmarked override is kept.
4. Re-triage uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / 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 / 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 when fix PRs appear; macOS / Windows probes once branch cleanup works.

[github-actions[bot]]

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

Tested: main e76cb9b. The latest release is v5.0.1. Since run 41 (306ec81), main gained only non-uv fixes (#1541 npm LFS, #1542 vlt, #1540 / #1538 yarn, #1534 npm, and the #1089 test-assertion CI series). uv 0.13.1 came out on 2026-10-14 and is now the newest. I used uv 0.4.30, 0.5.3, 0.5.4, 0.5.5, 0.5.31 and 0.13.1 on Linux, against the run-37 mock (recovered from bughunt/uv/20261009-agent-linkmodes, six 1.16.0 patch), plus the v5.0.1 release binary (npm @socketsecurity/socket-patch-linux-x64-gnu) and a local build of draft PR #1566 (b34b23e).

Re-triage

• uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545: draft PR Fix uv project shadowing parent uv settings (#1545) #1566 is open. I built it and tested it against real uv. It refuses the reported exclude-newer / resolution parents in both modes and wires a child that already has [tool.uv]. It also refuses parents that hold only constraint-dependencies, override-dependencies or build-constraint-dependencies, which real uv (0.5.31 / 0.13.1) doesn't pass down to a child project. main wires those correctly (--locked green, patched), so the PR would regress them. Commented: uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 (comment)
• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / 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 / 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: no fix PR, so I didn't re-run them.

Cells

Cell	Result
uv 0.13.1 hosted / vendored project baseline (scan, --locked, vex, rollback byte-identical)	pass
uv 0.13.1 PEP 723 script lock, hosted / vendored (uv run --locked, rollback byte-identical)	pass
uv 0.13.1 pylock.toml (uv pip compile), hosted / vendored	pass
Hosted transitive override / constraint repoint × 0.4.30 / 0.5.3 / 0.5.4 (advisory)	fail → #1569
Same × 0.5.5 / 0.13.1	no advisory, but uv honours the wiring (OK)
Vendored, same lanes × 0.4.30–0.13.1	pass (advisories emitted)
#1525: orphan unwind (uv remove isodate then rollback) × 0.4.30 / 0.5.3 / 0.5.31 / 0.13.1	pass (override retired, uv lock --locked ok)
#1525 / #411: the user's own unmarked override through scan + rollback × the same 4 versions	pass (byte-identical)
What real uv inherits from a parent [tool.uv] / uv.toml (10 keys × 0.5.31 / 0.13.1)	exclude-newer, resolution, index-url and a default index are inherited; the *-dependencies, environments and conflicts keys are not
PR #1566 × 6 parent shapes × hosted / vendored × 0.5.31 / 0.13.1	fixes #1545; over-refuses 3 shapes (commented)
#1529: vex with a BOM'd pyproject	product_undetected (intended; see Known non-bugs)
macOS / Windows	blocked: no probe pushed (branch deletion is still denied, run 40)

Issues

• New: Hosted uv scan gives no uv < 0.5.6 advisory for transitive overrides or repointed constraints, so on uv ≤ 0.5.4 a plain uv sync silently reinstalls the unpatched wheel after a clean exit 0 #1569: Hosted uv scan gives no uv < 0.5.6 advisory for transitive overrides or repointed constraints, so on uv ≤ 0.5.4 a plain uv sync silently reinstalls the unpatched wheel after a clean exit 0 #1569 (hosted gives no uv < 0.5.6 advisory; a plain uv sync on 0.4.30–0.5.4 silently reinstalls unpatched).
• Commented: uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 (PR Fix uv project shadowing parent uv settings (#1545) #1566 over-refusal evidence). Closed: none.

False positives ruled out

• uv 0.5.31 still had patched six after hosted rollback plus uv sync --locked. That's the documented 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 behaviour: the restored lock pins the same version, the unwind warns redirect_pypi_reinstall_required, and 0.8.18+ reinstalls.
• pypi_uv_lock_revision_untested on uv 0.13.1 locks (revision 5 > 3) is a pre-existing advisory, not new.
• uv sync --locked failing on ≤ 0.5.4 is the documented uv limit. Only the missing hosted advisory is the bug.
• My first inheritance sweep failed every lock, because the child declared conflicting extras. Re-ran it without them.

Next

1. Re-check PR Fix uv project shadowing parent uv settings (#1545) #1566 after an update: the inherit / non-inherit table above is the oracle.
2. Re-triage Hosted uv scan gives no uv < 0.5.6 advisory for transitive overrides or repointed constraints, so on uv ≤ 0.5.4 a plain uv sync silently reinstalls the unpatched wheel after a clean exit 0 #1569 when a fix lands, including the uv pip lanes and the takeovers on 0.5.3.
3. uv project under a parent uv.toml / [tool.uv]: hosted and vendored scan add a [tool.uv] table to the project's pyproject.toml, which hides the parent settings from uv, so uv sync --locked fails and a plain uv lock re-resolves without them #1545 neighbours still open: a uv workspace root under a parent config, and cache-keys in a parent.
4. macOS / Windows probes once branch cleanup works again.