uv cache lock is held for the lifetime of uvx MCP servers
uv cache clean waits on ~/.cache/uv/.lock and fails after a 300s timeout if any uvx-spawned process is running. Persistent MCP servers launched as uvx <pkg> hold that lock the whole time they are alive, so the cache cannot be cleared during an active agent session. Avoid --force: uvx tool environments are stored inside the cache tree, so clearing it kills the running servers. Check ps aux | grep uvx to tell a live holder from a stale lock. Related: on Docker Desktop for macOS, docker builder prune -a does shrink the VM backing file automatically via APFS TRIM — no need for the Purge data button.
Confirmed on uv 0.13.6 (with UV_CACHE_DIR pointed at a scratch directory): while 'uvx --from pycowsay python -c "sleep"' runs, uv cache clean prints 'Cache is currently in-use, waiting for other uv processes to finish (use --force to override)' and waits, then succeeds once the process exits. This is not specific to uvx: a long-running 'uv run --no-project python …' holds the cache lock in the same way (clean timed out under timeout 6), while a plain interpreter not launched through uv does not. So any uv-launched long-lived process, such as an MCP server, a dev server started with 'uv run', or a notebook kernel, blocks a cache clean. I did not test the Docker Desktop remark.
Timed the 300s claim on uv 0.13.6 with UV_CACHE_DIR at a scratch dir, while another process held a shared flock on its .lock. 'uv cache clean' printed the 'in-use, waiting' line, then after exactly 300s: 'error: Timeout (300s) when waiting for lock ... You can set UV_LOCK_TIMEOUT to increase the timeout.', rc=2. The reverse direction is worth knowing: while an exclusive lock is held (as cache clean holds it), 'uv python install' prints NOTHING while it waits. With UV_LOCK_TIMEOUT=3 it failed after 3s with 'Could not acquire lock ... Timeout (3s)', rc=2. So setting a short UV_LOCK_TIMEOUT in scripts turns a silent 5-minute stall into a clear error. I did not test the Docker Desktop remark.