fix(telemetry): keep telemetry inert during shell completion (BE-4274)

[mattmillerai]

ELI-5

When you press Tab to autocomplete a comfy ... command, the CLI runs a tiny hidden invocation just to list the possible completions. It should do nothing else — but a fish user reported (GitHub #506) that this hidden run was still spinning up the PostHog analytics client (a background thread + network setup). This PR makes sure telemetry stays completely asleep during tab-completion, and adds a test so it never wakes up there again.

What changed

• comfy_cli/tracking.py: added _in_shell_completion() (detects the _<PROG>_COMPLETE env var Click/Typer set during completion, across comfy / comfy-cli / comfycli and any alias, for fish/bash/zsh) and an early-return guard in _get_providers() so no telemetry provider (PostHog or Mixpanel) is constructed on the completion path. The guard is uncached, so a real invocation is never affected.
• tests/comfy_cli/test_tracking_completion.py: new regression tests — detection matrix across shells/entrypoints, a gateway test asserting _get_providers() builds nothing under completion, and an end-to-end test that drives the real Typer completion resolution for fish/bash/zsh and asserts the PostHog client is never constructed.

Honest note on scope (please read)

While triaging I found the behavior was already fixed incidentally by #535 (BE-3289, "build telemetry providers lazily"), which landed on main earlier the same day — after #506 was filed (2026-07-11). With lazy construction, providers are built only inside _dispatch(), which never runs during completion. I verified this empirically: driving the actual Typer fish completion on clean origin/main resolves the full command list and constructs zero telemetry providers (no posthog import, no PostHogProvider.__init__, no _get_providers call).

So this PR is deliberately not a behavior fix on top of a broken main. Its value is:

1. The regression test the ticket explicitly asks for (acceptance criterion 3) — which did not exist. This is the real, lasting deliverable: it locks PostHog client is initialized unconditionally during fish shell completion, adding ~10 seconds to every completion #506's fix so a future change that eagerly builds providers can't silently re-break completion.
2. An explicit guard that encodes completion-inertness intentionally at the construction gateway, rather than leaving it an incidental side effect of fix: build telemetry providers lazily so comfy install can upgrade pydantic_core (BE-3289) #535's lazy-init (whose motivation was a Windows pydantic_core DLL lock, unrelated to completion). The two concerns are only coupled by accident today.

Acceptance criteria

• Telemetry/PostHog client is NOT initialized during shell-completion resolution (fish, bash, zsh) — already true via fix: build telemetry providers lazily so comfy install can upgrade pydantic_core (BE-3289) #535; now explicit + tested.
• Normal command invocations still initialize telemetry exactly as before — guard only fires when a completion env var is present (control test included).
• A test asserts no telemetry init when the completion env var is set.

Testing

• pytest tests/comfy_cli/test_tracking_completion.py tests/comfy_cli/test_tracking_providers.py tests/comfy_cli/test_tracking.py → 142 passed.
• ruff check + ruff format --diff (CI-pinned 0.15.15), repo-wide → clean.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 22 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 15d742ab-bb59-48d2-a555-fee5d700270e

📥 Commits

Reviewing files that changed from the base of the PR and between 85b62da and cb46e4b.

📒 Files selected for processing (2)

• comfy_cli/tracking.py
• tests/comfy_cli/test_tracking_completion.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-4274-posthog-completion

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-4274-posthog-completion

---

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

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

Found 2 finding(s).

Severity	Count
🟢 Low	2

Panel: 6/8 reviewers contributed findings.

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