uv 0.13.1 was released on 14 October 2026, and the two flags that matter most for CI are the same as in earlier versions: --locked fails when uv.lock is out of date, and --frozen uses it without asking. Picking the wrong one means a pipeline that installs something different from what a reviewer approved.
What's affected
Any Python project using uv where pyproject.toml can change without uv.lock changing with it. The docs describe the behavior this way:
--locked: "If the lockfile is not up-to-date, uv will raise an error instead of updating the lockfile."--frozen: use the lockfile "without checking if it is up-to-date".uv lock --checkis equivalent to--lockedfor other commands.
What to do now
- Create the drift. Add a dependency to
pyproject.tomlby hand without runninguv lock. - Check the lockfile:
uv lock --check
On our test project this printed the following and exited 1:
error: The lockfile at `uv.lock` needs to be updated, but `--check` was provided.
hint: To update the lockfile, run `uv lock`.
- Install with the strict flag:
uv sync --locked
It failed with the same error and exit code 1, and installed nothing.
- Compare with the permissive flag.
uv sync --frozenon the same drifted project succeeded with exit code 0 and did not complain about the new dependency. - Use
uv sync --lockedin CI anduv lock --checkas a fast pre-commit or pull request check. - Reserve
--frozenfor cases where you have verified the lock another way, such as a build that runs right after a lock check.
Quick check
Which flag would let a stale uv.lock reach production unnoticed?
--frozen. It skips the up-to-date check, so changes in pyproject.toml are ignored.