[BUG] crewai-cli's runtime pin uv~=0.11.6 installs a second, capped uv into every consumer .venv

Description

crewai-cli lists uv~=0.11.6 in its runtime dependencies (lib/cli/pyproject.toml, line 24; the 1.15.22 wheel on PyPI carries the same requirement). crewai depends on crewai-cli==1.15.22, so uv add crewai in any project resolves the uv PyPI package and drops a second uv binary into that project's .venv/bin.

The CLI never imports uv as a library. There is no import uv / from uv anywhere under lib/cli/src; the only uses are subprocess argv:

• install_crew.py:52 — ["uv", "sync"]
• run_crew.py:445 — ["uv", "run", "--no-sync", "python", "-c", ...]
• run_crew.py:764 — ["uv", "run", script_name]

Those resolve uv through PATH. With the venv activated (or .venv/bin on PATH via direnv and similar), PATH finds the venv copy first, so both the CLI's subprocess calls and the user's own uv ... commands silently run the pinned uv instead of the one they installed.

~=0.11.6 means >=0.11.6,<0.12. The newest release it can pick is 0.11.33; the current uv release is 0.12.17, and the gap only grows from here. Every project that depends on crewai inherits the cap.

Steps to Reproduce

1. mkdir repro && cd repro && uv init --python 3.12
2. uv add crewai
3. ls -la .venv/bin/uv
4. .venv/bin/uv --version
5. uv --version (outside the venv, then again with it activated)

Expected behavior

No uv binary inside .venv/bin. uv --version reports the same uv whether or not the venv is activated: the one the user installed.

Screenshots/Code snippets

$ ls -la .venv/bin/uv
-rwxr-xr-x 1 davidlong wheel 39856400 Sep 18 21:19 .venv/bin/uv
$ .venv/bin/uv --version
uv 0.11.33 (fece32fc5 2026-07-28 aarch64-apple-darwin)
$ grep -n -A1 '^name = "uv"$' uv.lock
3305:name = "uv"
3306-version = "0.11.33"

Outside the venv, uv --version prints whatever you installed (0.12.17 is current). With the venv activated it prints 0.11.33.

Operating System

macOS Sonoma

Python Version

3.12

crewAI Version

1.15.22

crewAI Tools Version

Not installed (not involved).

Virtual Environment

Venv (uv-managed .venv)

Evidence

See the snippets above. On main:

• lib/cli/pyproject.toml:24 — "uv~=0.11.6"
• pyproject.toml:276 — "uv>=0.11.15,<1" (the workspace's own requirement, set in #5992)

Possible Solution

At minimum, widen crewai-cli's pin to match the workspace: uv>=0.11.15,<1. That removes the <0.12 cap and adopts the same floor the repo already chose for itself in #5992 (which cites GHSA-4gg8-gxpx-9rph as the reason for 0.11.15). Today the shipped package still allows 0.11.6 through 0.11.14, so it is looser on that advisory than the repo's own tooling.

The stronger option is to drop uv from dependencies entirely and document it as a prerequisite. The CLI already assumes uv is on PATH for uv sync / uv run, and a pip-installed uv inside a venv is rarely what anyone wants. That changes the install story, so I'd treat it as a follow-up.

I'm happy to open the PR for either. The PR template asks first-time contributors to link an open issue, hence filing this first.

Additional context

None beyond the above.

Start with the runtime dependency at lib/cli/pyproject.toml:24 and compare it with the workspace requirement at pyproject.toml:276. Review the uv subprocess entry points in install_crew.py and run_crew.py, then reproduce the dependency resolution with the listed uv commands. Done means the chosen dependency approach no longer installs a capped uv binary into a consumer .venv and matches the agreed install behavior.