Bug hunt ledger: uv

[Mikola Lysenko (mikolalysenko)]

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

Last run: 2026-10-04 (run 16) on main 045d7ec (new #788: uv 0.6.15–0.6.17 locks spell upload_time, so hosted rollback / remove / H→V takeover always refuse; 3 OS. Version sweep 0.6.17 / 0.7.22 / 0.9.30 / 0.10.12 / 0.11.33 otherwise passes; grant-token rotation passes; #767 extended to optional-dependencies and constraint-dependencies; requirements direct reference handed to pip). Run 15 (new #767: a PEP 508 direct-reference dependency (six @ https://… / git+…) gets vendored into a lock that uv sync --locked rejects while vex attests, and hosted overrides the user's URL and then refuses rollback; 3 OS × 3 uv versions. PR #743 verified to fix the hosted half of #742. -g lifecycle passes on macOS / Windows via a probe. A uv lockless-pyproject shape was added to #638). Run 14 (new #742: a superseding patch uuid is never applied on uv. Hosted re-scan refuses its own [tool.uv.sources] pin with exit 0 while listing the upgrade; vendored fails pypi_uv_source_already_exists. #701 extended to the uv pip compile --universal requirements lane and to script locks. 0.12.23 baseline passes on 3 OS via a probe). Run 13 (new #723 V→H takeover strands a version-pinned-down vendored package while the dry run previews success; uv evidence added to #612, where vendored uv.lock + an exported requirements.txt is left silently unpatched; uv 0.12.23 baseline passes). Run 12 (#670 verified fixed on PR #672; new #701 hosted platform-specific wheel narrows the universal uv.lock; vendored repair with two packages and a vendored platform wheel pass). Run 11 was on main 045d7ec (new multi-package harness: requests / urllib3 / click / dateutil / jsonschema patches; hosted with deps / extras / partial unwind all pass; new #670 vendored multi-package revert residue; #449 Windows verified fixed on a probe). Run 10 was 2026-10-03 on main 045d7ec + draft PR #625 (new #639 dynamic = ["dependencies"]; conflicts, required-environments, dependency-metadata pass; PR #625 verified fixing #606 / #473). Run 9 was on main 045d7ec (re-verified #525, #407, #408, #474 and #449-Linux as fixed; #473 and #411 still fail; new #606; [tool.uv] resolution settings, symlink link-mode). Run 8 was on main 61cfb9b (unchanged; this run added no-sources (#564), root-level dotted sources (#544, verified fixed on PR #545), vendored script dotted sources and repair on dotted / CRLF). Run 7 added path/git siblings, legacy dev-dependencies, constraint-dependencies, vendored sources spellings and uv 0.12.22). Run 6 was also on 61cfb9b (the dotted-name, sources-spelling, lock-only and UV_PROJECT_ENVIRONMENT cells). Run 5 was also on main 61cfb9b (v5; CLI reports 4.0.0, and the released 4.0.0 predates both the v4 uv rewriter and the v5 upstream restore). Earlier cells are from 2463257 / 6e7ef74. Linux runs use real uv against a local mock patch API (with integrity.sha512 in SRI form, a deterministic wheel, the /blob/ route and --patch-server-url), plus SOCKET_PYPI_JSON_API → a local pypi.org pass-through that must not rewrite file URLs. uv 0.1.x needs SSL_CERT_FILE; uv 0.0.5 needs PUFFIN_INDEX_URL → a local /simple/ proxy. macOS and Windows runs use probe branches.

Coverage matrix

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

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

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

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

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

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

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

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

Global (-g) mode

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

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

Backlog

0. Re-triage Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field upload_time instead of upload-time #788 (new), 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 (hosted half verified on PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743; vendored slice pending), Vendored uv with two or more packages: vendor --revert (and remove in purl order) leave an empty [tool.uv.sources] header in pyproject.toml #670 once PR Fix vendored revert leaving created scaffold behind (#636, #670) #672 merges, Hosted uv rollback, remove and vendored takeover refuse when the patched package is declared with different specifiers in dependencies and an extra (or under different markers), although each lock entry keeps its marker #606 / Hosted uv rollback and remove refuse when the patched package reaches a dependency group through PEP 735 include-group #473 once PR Fix uv hosted unwind declaration matching (#606, #473) #625 merges, and uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723 when a fix lands. Also Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411, Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564, Hosted uv scan wires a dynamic = ["dependencies"] project, but rollback, remove and the vendored takeover then always refuse ("pyproject.toml no longer declares six") #639 and Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701, and the Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 / Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638 uv shapes. Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407, Hosted rollback rewrites uv pylock.toml upload-time with milliseconds, so the restored file never matches what uv writes #408, Vendored uv script lock can't be reverted after uv add --script adds an unrelated dependency (vendor_lock_entry_drifted, still exit 0) #474, uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected #525, uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524, Vendored uv revert and remove half-revert a project whose sources use dotted keys under [tool.uv]: uv.lock is restored but the sources.<pkg> line stays, so uv sync --locked fails (vendor --revert exits 0) #544 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 (all OS, incl. UV_PYTHON_INSTALL_DIR) are verified fixed.
1. (Done in run 16: direct-reference follow-ups → uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767 comment + pip handover.) New: a Windows probe of hosted write atomicity (uv.lock held open without delete sharing); a lockless PEP 723 script; uv 0.12.22+ revision-5 specifics with git / path / url sources.
2. Patch-upgrade follow-ups: (grant-token rotation passes, run 16); vendored re-vendor once PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743's follow-up lands.
3. Interrupted runs with fault injection (a slow mock route), since SIGKILL can't hit the write window against the local mock. Hosted with a release that has several sdists. Vendored multi-package on Windows (CRLF) after Fix vendored revert leaving created scaffold behind (#636, #670) #672 lands.
4. Probe branches can't be deleted from the cloud session (git push --delete hangs up through the proxy). Thirteen bughunt/uv/* branches need maintainer cleanup, including 20261004-global-lifecycle, 20261004-direct-url and 20261004-upload-time.
5. (Done in run 15) The maintainer request for -g rollback / vex and the macOS -g re-probe, with the mock instead of a live patch. The unwritable-prefix cell is still open: ubuntu-latest runners exit 1 on apply / get / vex -g while the target is patched (likely the root-owned system six); confirm with stderr.

Known non-bugs

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

[github-actions[bot]]

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

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

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

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

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

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

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

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

[github-actions[bot]]

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

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

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

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

Cells (Linux unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

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

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

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells (Linux 0.12.21 unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major uv version and on Linux, macOS and Windows.

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

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed uv package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a uv project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × uv version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

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

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

Re-triage

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

Cells (global mode)

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux 0.8.17 unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

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

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells (Linux 0.8.17 unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux, uv 0.8.17 unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

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

---

Generated by Claude Code

[github-actions[bot]]

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

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

Re-triage (current main)

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Probe runs

None. #639 is OS-independent TOML logic.

Next

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

[github-actions[bot]]

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

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

Re-triage

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

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

Cells (Linux unless noted)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells (Linux)

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

Issues

• Filed uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723: uv vendored → hosted takeover strands a package that vendored mode pinned to a different version than uv.lock: the wet run reverts to the unpatched release (exit 1), while --dry-run previews a clean takeover #723
• Commented on Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 (uv evidence): Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 (comment)

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Issues

• Filed uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767: uv projects that declare the patched package as a PEP 508 direct URL (six @ https://… / git+…): vendored writes a lock uv sync --locked rejects while vex attests, and hosted overrides the user's URL then refuses to roll it back #767
• Commented on uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742 (PR Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743 verification) and Hosted scan --json on a PyPI project with no root requirements.txt (e.g. only requirements-dev.txt or requirements/base.txt) reports success with empty skipped and warnings, though the patched package is never pinned #638 (uv lockless shape).

False positives ruled out

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

Probe runs

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Probe runs

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

Next

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