PostHog client is initialized unconditionally during fish shell completion, adding ~10 seconds to every completion

[kernkraft235]

On my system, each completion invocation takes approximately 10.6 seconds because importing the CLI unconditionally initializes a PostHog background worker and completions invoke the comfy command twice. Suppressing PostHog reduces completion to roughly 0.8 seconds because the CLI is executed twice.

IDK if the fact that I have strict DNS blocking is what’s causing posthog to take the full 5s each time, but it seems possible

Therefore, there appear to be two related performance problems:

1. Shell completion invokes the entire CLI twice per completion attempt.
2. CLI startup eagerly initializes telemetry and other command infrastructure that completion does not need.

Analytics are disabled in my configuration, which makes the unconditional PostHog initialization additionally surprising.

Environment

• comfy-cli: 1.12.0
• Shell: Fish
• OS: Linux
• Analytics disabled in the Comfy configuration
• DNS-level tracking-domain blocking is enabled

Reproduction

Compare an ordinary invocation of tabbing for a completion in fish shell then:

set -gx POSTHOG_API_KEY

It’s still kinda slow but it’s way more usable when you don’t post your hog each completion (~10s reduced to ~1s)

[dosubot]

Hi @kernkraft235! I'm Dosu and I'm helping the Comfy Org team.

Your diagnosis is correct. I can confirm both issues after looking at the code:

1. PostHog is initialized unconditionally at module import time, as part of a module-level PROVIDERS list in telemetry.py [1]. The opt-out checks (DO_NOT_TRACK, COMFY_NO_TELEMETRY, and the config flag) only gate sending events — they don't prevent the PostHogProvider from being instantiated [2]. So even with analytics disabled in your config, the PostHog client still gets created (and presumably attempts a network connection that hangs against your DNS blocking).

2. There's no completion-mode fast path. The CLI entry callback runs full initialization — ConfigManager, workspace manager, telemetry providers, and more — with no check for Typer's completion environment variables (e.g. _TYPER_COMPLETE) [3]. Since Fish completion invokes the comfy command twice per TAB press, you're paying that ~5s PostHog timeout twice.

Your workaround of unsetting POSTHOG_API_KEY effectively causes the PostHogProvider to be initialized with an empty key (the env var override is checked at import time) [4], which prevents the network hang.

A proper fix would likely involve:

• Lazy-initializing telemetry providers — deferring PostHogProvider instantiation until an event actually needs to be sent, and skipping it entirely if consent/config says no.
• Detecting completion mode early — checking for _TYPER_COMPLETE (or the equivalent env var) at the top of the entry callback and short-circuiting all non-essential initialization.

In the meantime, setting COMFY_NO_TELEMETRY=1 won't help the startup cost (since it only gates sending), but your set -gx POSTHOG_API_KEY trick or blocking at the DNS level are effective workarounds.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.