chore: refresh the stale uv.lock so uv run stops dirtying working trees

[mattmillerai]

ELI-5

uv.lock on main didn't match pyproject.toml. Because of that, any uv run or uv sync quietly rewrote the lockfile, so your working tree went dirty just from running the tests — and that ~285-line diff then got swept into whatever you committed next. This PR regenerates the lockfile once, so it matches and stops moving.

Problem

main gained the bench optional-dependency group (optional-dependencies.bench = [ "anthropic>=0.40" ]) but the committed lock never gained anthropic or its transitive deps. On a pristine checkout of main:

$ uv lock --check
Resolved 80 packages
The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

This already caused real damage once: PR #530 (a focused credential/redirect fix) accidentally carried the regenerated lock, dropping the whole anthropic + pydantic subtree into a security review's diff. That churn was reverted out of #530, so the stale lock on main survived.

Change

uv lock, committing only uv.lock. Purely additive — 7 new packages:
anthropic, annotated-types, docstring-parser, jiter, pydantic, pydantic-core, typing-inspection.

Verification

• uv lock --check exits 0 on a fresh checkout of this branch (was non-clean on main).
• uv run -p 3.10 --extra dev pytest -q → 2573 passed, 37 skipped, and git status is clean afterwards (the lockfile no longer regenerates).
• ruff format --check . → 235 files already formatted.

Reviewer notes — the two non-additive lines

The diff removes exactly two lines; both are worth a second look, so here is the evidence up front.

1. provides-extras = ["dev", "preview"] → ["bench", "dev", "preview"] — the point of the PR.

2. exceptiongroup's dep on typing-extensions loses its python_full_version < '3.13' marker. This is the riskiest line in the diff, since it's a semantic edge change rather than an addition. It's safe:

• It is genuinely caused by the bench extra, not by lockfile-tool drift. Proof: removing the bench extra from pyproject.toml and re-locking with the same uv reproduces main's committed lock byte-for-byte identical. So the uv version used here (0.11.26) contributes zero churn of its own; 100% of the diff is the extra. It's uv's own marker simplification responding to the new resolution.
• It cannot change what gets installed anyway: typing-extensions>=4.7 is already an unconditional root dependency of comfy-cli, so it is present on every supported Python regardless of this edge's marker.

Risk / CI impact

None. Every CI job (pytest.yml, test-windows.yml, test-mac.yml, build-and-test.yml, run-on-gpu.yml) installs via pip install -e . and ignores uv.lock entirely — verified, not assumed. The benefit is purely developer-tree hygiene and keeping future diffs honest.

Judgment call: pylock.toml is also stale, and deliberately NOT fixed here

While reviewing I found the repo's pre-commit uv-export hook regenerates pylock.toml, and pylock.toml is stale on main too (it's missing posthog, backoff, distro).

I left it alone, deliberately:

• It is a separate, pre-existing defect with an unrelated cause. It reproduces identically on pristine main with the bench extra absent.
• This PR has zero effect on it. uv export runs without --all-extras, so the bench extra never reaches pylock.toml. Proof: the pylock.toml exported from this branch's refreshed lock is byte-for-byte identical to the one exported from pristine main.
• Sweeping ~50 lines of unrelated pylock.toml churn into this PR would repeat exactly the fix: route authed urllib paths through a shared NoRedirectHandler opener (BE-3274) #530 mistake this PR exists to undo.

Caveat this creates, stated plainly: the goal of "working trees stop going dirty" is fully achieved for uv run / uv sync (verified above), but a developer running pre-commit will still see pylock.toml rewritten by the uv-export hook. That wants its own follow-up.

Out of scope

ruff check . reports 14 errors — pre-existing and identical on pristine main, and untouchable by a lockfile-only diff. Not addressed here.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2dc5e397-416e-47eb-8a92-c0569f609895

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-3299-refresh-stale-uv-lock

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-3299-refresh-stale-uv-lock

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

✅ No high-signal findings.

Panel: 6/8 reviewers contributed findings.

Reviewers that did not contribute: kimi-k2.5:adversarial (empty), kimi-k2.5:edge-case (empty)