fix: the verify extra must not repin a user's environment

[GiulioDER]

Reported from a real install: pip install 'cca-audit[verify]' downgraded a user's mcp from 2.1.0 to 1.29.0 and broke unrelated MCP tooling. Nothing in this project imports mcp.

semgrep 1.175.0 requires mcp==1.29.0, but you have mcp 2.1.1 which is incompatible.

Why it is a bug, not bad luck

semgrep was never a library dependency. semgrep_check.py resolves it on PATH and spawns it, exactly like cargo, which nobody would think to pip-install. It sat in verify because "the whole deterministic layer in one install" read as tidy. It is not tidy when the price is rewriting packages unrelated to auditing.

It moves to a taint extra so the pins are chosen rather than inherited, and pipx install semgrep becomes the documented path: isolated environment, binary on PATH, which is all resolve_tool ever wanted.

Measured on the built wheel, full resolution with --ignore-installed:

Extra	Packages	semgrep / mcp / pywin32 / ruamel.yaml.clib
[verify] before	68	all present
[verify] now	15	all absent
[taint]	68	present, by explicit opt-in

The second half, and why the first is safe

Dropping semgrep from verify would have been the "extra that half-enables a feature" mistake pyproject.toml itself warns about, silently, because availability was resolve_tool(name) is not None. That answers whether a file is on PATH, not whether it can run.

That gap was live on the reporting machine. semgrep resolved fine, then died with:

OSError: [WinError 4551] An Application Control policy has blocked this file

and capabilities reported taint fully available with unavailable: {} while every taint claim escalated to UNCERTAIN. The command whose entire job is to say where the verifier is blind was blind to it. A coverage report that overstates coverage is worse than none, because its specificity is what makes it trusted.

So tools are now probed by execution. A non-zero exit from --version counts as unavailable too, and that detail is load-bearing: the OSError was raised inside semgrep's own process, so nothing was raised here and the only visible symptom was the exit code. An exception-only check would have reproduced the original bug.

After, on the same machine:

"unavailable": {"taint": "semgrep at ...semgrep.EXE exited 1 on --version (OSError: [WinError 4551] An Application Control policy has blocked this file)"}

pyright and cargo still report available. The probe is cached per process and has one caller, _capabilities, so it costs one spawn per tool per audit.

Tests

tests/test_extras_do_not_repin_the_environment.py pins the packaging decision and asserts the premise it rests on: that nothing under cca_checks imports semgrep. If that ever changes this fails, rather than leaving the pipx advice quietly wrong.

tests/test_toolpath.py covers absent, clean, unexecutable, non-zero-exit and hanging tools.

ruff clean, pyright 0 errors, 85 tests pass locally.

🤖 Generated with Claude Code