GitHub CLI now collects pseudoanonymous telemetry

Original Article ↗ Hacker News Discussion ↗

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.