Bug hunt ledger: uv

[Mikola Lysenko (mikolalysenko)]

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

Last run: 2026-10-02 (run 7) on main 61cfb9b (unchanged; this run 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)

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	pass	fail #449	fail #449	pass (exit 2)	blocked (e2e patch UUID not_found)
macOS	0.4.30 / 0.5.31 / 0.8.17 / 0.9.5	pass	fail #449	untested	untested	blocked
Windows	0.4.30 / 0.5.31 / 0.8.17 / 0.9.5	fail #449 (%APPDATA%\uv\tools)	fail #449	untested	untested	blocked

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 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 together with 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 a fix lands. Also check vendored root-level tool.uv.sources.x = …, and vendored repair on dotted spellings.
1. 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. Run 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 (plus a stray ./.venv next to UV_PROJECT_ENVIRONMENT).
2. Maintainer request (still open): global -g apply / rollback / vex against a live free pypi patch (the e2e UUID 725a5343-… returns not_found), plus the unwritable-prefix cell. Checklist in the 20261001T040000Z entry.
3. Vendored PEP 723 script lock whose script block carries [tool.uv] dotted sources.
4. 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.
5. pylock.<name>.toml mixed index / no-index siblings (after Fix uv pylock rollback shape (#407, #408) #512). Windows CRLF checkout + vendored repair on uv.lock.
6. Hosted uv.lock on Windows with space / unicode project paths.
7. 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, 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 (uv part), 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 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 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 once main moves.

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.
• vendored → hosted on a uv project is warn-only (redirect_uv_project_unsupported, exit 0). In v5, vendored_takeover only covers cargo/npm/golang. CLI_CONTRACT.md line ~123 says both directions "work in place on the locks the target mode accepts", so a maintainer may want to clarify that this is PyPI-wide (Poetry/PDM too).
• 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.

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