GitHub CLI now collects pseudoanonymous telemetry

Original Article ↗ Hacker News Discussion ↗

GitHub’s command‑line tool is introducing default-on “pseudonymous” telemetry in version 2.91.0, prompting users to seek ways to opt out or pin older releases. Commenters debate whether developer tooling should ever phone home, with critics calling it spyware that erodes trust and may run afoul of privacy expectations or regulations, while supporters argue that usage analytics are essential for prioritizing features and improving products. Many note that GitHub could already infer much from server-side API logs and question why additional client-side tracking is necessary.

Telemetry rollout and opt-out mechanisms

  • Telemetry is being enabled by default in gh starting with v2.91.0; earlier versions (e.g., 2.90.0) don’t include it.
  • Opt-out methods mentioned: GH_TELEMETRY=false, DO_NOT_TRACK=true, and gh config set telemetry disabled.
  • The gh config command currently warns that telemetry is unknown, but still writes it into ~/.config/gh/config.yml, so users can “pre-disable” for future versions.
  • Some warn to re-check settings after updates in case flags are reset or new telemetry flags appear.

What is being collected and how “anonymous” it is

  • GitHub describes data as “pseudonymous” / “pseudonymous identifiers”, interpreted by many as “not actually anonymous” and trivially linkable.
  • Some see this as essentially spying; others argue that anonymous or pseudonymous aggregate metrics are standard practice and not equivalent to screen recording or full surveillance.

Arguments for telemetry

  • Pro-telemetry comments:
    • Helps prioritize features, understand real usage, and spot problem areas.
    • Claimed to be indispensable for modern product development versus “flying blind”.
    • Usage data can reveal mismatches between what users say they want and what they actually use.
  • Some argue it’s especially useful when teams are large, transient, or disconnected from users, and when direct user research doesn’t scale.

Critiques and trust issues

  • Many object to opt-out rather than opt-in, labeling it spyware-like, especially for developer tools and libraries that run locally.
  • Strong distrust of Microsoft’s motives; expectation that data will ultimately serve business / AI training interests more than users.
  • Several argue that GitHub already sees all API traffic, so client-side telemetry is unnecessary and more invasive.
  • Concern that data is a black box: users can’t verify what is collected, how it’s used, or whether policies will change.

Usability, alternatives, and practical concerns

  • Some say gh CLI is powerful and useful (PRs, issues, workflows, CI checks), especially for automation and agents; others prefer pure git or alternative forges (Gitea/Forgejo, Codeberg, Radicle, GitSocial).
  • Worries about telemetry impacting CLI performance or causing odd failures/timeouts, especially in CI/bastion environments with restricted outbound traffic.
  • Debate over telemetry-driven design in general: can improve UX, but also risks misinterpreting “engagement”, killing niche but important features, and over-optimizing for metrics.

Legal and regulatory questions

  • A few raise GDPR/European privacy concerns and suggest contacting GitHub’s privacy/support channels.
  • Others doubt regulators will prioritize a case like this, given limited resources and larger issues.