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

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

uv reads project settings from the nearest directory at or above the project that holds a uv.toml or a pyproject.toml with a [tool.uv] table. A pyproject.toml without [tool.uv] is skipped, and the lookup goes on to the parent. That's the usual monorepo layout: one root uv.toml (or root [tool.uv]) sets exclude-newer, resolution, indexes, constraints and so on for several independent projects below it.

When such a project has no [tool.uv] of its own, hosted and vendored scan write [tool.uv.sources] six = … into its pyproject.toml. That new table makes the project's own pyproject the governing settings file, so uv stops reading the parent and every parent setting disappears at once. The lock socket-patch wrote still records the parent's options ([options] exclude-newer / resolution-mode), so:

• uv lock --locked / uv sync --locked fail ("The lockfile at uv.lock needs to be updated"). uv explains why: Ignoring existing lockfile due to change in resolution mode: lowest-direct vs. highest, or Resolving despite existing lockfile due to removal of global exclude newer.
• A plain uv lock / uv sync re-resolves the whole project without the parent settings (no exclude-newer cutoff, default resolution, and the parent's index or constraints dropped). Other dependencies can silently move.
• scan exits 0 success, and the venv stays unpatched (SOCKET_PATCHED is 0) because the locked sync fails.

#1504 (#1501) already handles this lookup for the script lane (find_ancestor_uv_config), but treats the project lane as "a project stops that lookup at itself" (docs/testing/uv-compatibility.md, the #564 / #1501 bullet). That's only true when the project's pyproject already has [tool.uv]. Here, socket-patch is the one that adds it.

Repro (Linux, main 306ec81)

mkdir -p mono/app && cd mono
printf 'resolution = "lowest-direct"\n' > uv.toml          # or: exclude-newer = "2024-01-01T00:00:00Z"
cd app
printf '[project]\nname = "app"\nversion = "0.1.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0"]\n' > pyproject.toml
uv lock && uv sync --locked                                 # lock records [options] resolution-mode = "lowest-direct"
socket-patch scan --mode hosted --yes                       # or --mode vendored: exit 0, success
uv lock --locked                                            # FAILS: lockfile needs to be updated
uv lock --locked -v 2>&1 | grep -i ignoring                 # "change in resolution mode: `lowest-direct` vs. `highest`"

The same happens with the parent setting in ../pyproject.toml under [tool.uv] instead of ../uv.toml.

Real uv alone shows the mechanism, without socket-patch: in the fixture above, append an empty [tool.uv] to app/pyproject.toml, and uv lock --locked fails the same way on 0.5.31 and 0.8.17.

I ran it against a local mock of the patch API / vendor server (the probe-branch mock, with a six 1.16.0 patch). Control: the same fixture without the parent config passes (uv lock --locked 0, uv sync --locked 0, SOCKET_PATCHED 1).

Expected vs actual

• Expected: per CLI_CONTRACT / docs/testing/uv-compatibility.md, a wired uv project keeps uv sync --locked green, and a setting that would defeat the wiring is refused before any file is written (the Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / uv PEP 723 script in a subdirectory: hosted and vendored wiring ignore no-sources = true from a parent uv.toml / pyproject.toml, so uv run --locked fails and a plain uv run imports the unpatched package #1501 model). Either keep the parent's settings in effect, or refuse with a code naming the parent file, as the script lane now does.
• Actual: exit 0 success, and the locked install is broken.

Ways to fix it (for maintainers to choose): refuse when the project has no [tool.uv] and an ancestor uv.toml / [tool.uv] exists; or copy the ancestor's settings into the new [tool.uv] (that changes semantics and has merge pitfalls, so a refusal is probably safer).

Matrix (Linux; macOS / Windows not probed: probe branches are blocked this run)

I checked each cell with exclude-newer, and the hosted and vendored cells on all three versions again with resolution = "lowest-direct". Every run reproduced.

After the damage, vendored rollback restores both files and uv lock --locked is green again. Hosted rollback refuses hosted_restore_refused in this one-package fixture (no sibling registry package / exclude-newer), which is the documented restore limit, not this bug.

First bad release

Reproduces on the v5.0.1 release binary (both modes). v4.0.0 didn't wire this fixture against the mock, so I couldn't compare it. Not bisected further.

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:5948-5973 (plan_python_metadata_with): the project lane calls refuse_uv_no_sources / rewrite_project_metadata on the root files only, and never reads an ancestor config.
• crates/socket-patch-core/src/utils/python_script.rs:406 / :431 (root_governs_script, find_ancestor_uv_config): the ancestor lookup exists, but only the script lane uses it (hosted/engine.rs read_candidate_files).
• crates/socket-patch-core/src/utils/python_script.rs:602 (rewrite_project_metadata) and the vendored uv wiring in crates/socket-patch-core/src/vendor/pypi_uv.rs create the [tool.uv] table.