GitHub CLI v2.91.0 Turns On Default Telemetry: What gh Collects and How to Opt Out in CI and Agent Pipelines

GitHub CLI v2.91.0, released April 22, 2026, turns on pseudonymous telemetry by default — every gh invocation now carries a 1-in-100 chance of emitting a structured payload to GitHub’s servers.¹² For teams wrapping gh inside Claude Code, Copilot CLI, GitHub Actions, or CI runners, the change transfers a data-collection decision they never made into every automated pipeline they operate.

What Shipped in v2.91.0

The v2.91.0 release is the first version of the official GitHub CLI to collect usage telemetry on by default.¹³ GitHub’s stated rationale, per the telemetry documentation: “As agentic adoption of GitHub CLI grows, our team needs visibility into how features are being used in practice.”¹ That framing names the use case directly — and it puts the compliance burden squarely on the agent authors and CI operators who now inherit that collection by default.

The implementation runs via a best-effort detached subprocess that batches payloads through Twirp client/server bindings, so telemetry does not block command execution.² Sampling is set at 1% of all invocations per device — a figure that matters to interpret correctly before dismissing it as inconsequential.

The Telemetry Payload: What gh Actually Collects

Per the telemetry documentation, each emitted record for a base command includes:¹

• command — the specific subcommand executed
• flags — which flags were passed (field name: flags)
• os, architecture — operating system and CPU architecture
• version — CLI version
• ci, github_actions — whether the invocation occurred inside a CI or Actions environment
• is_tty — whether the process has an interactive terminal
• timestamp
• device_id, invocation_id — randomized pseudonymous identifiers, persistent per device

The flags field records flag names. Whether flag values are also captured is not fully resolved in the current documentation, and GitHub CLI Issue #13263, filed April 22, 2026, explicitly cites this as a documentation gap that prevents informed security decisions.⁴ Teams that pass sensitive identifiers — org names, repository paths, branch names — as flag arguments should treat the collection scope as unresolved until GitHub clarifies.

Opt-Out Mechanics and CI Blind Spots

Three opt-out paths are documented:¹

# Environment variable — most reliable for ephemeral CI containers
export GH_TELEMETRY=false

# Honors the Do Not Track convention
export DO_NOT_TRACK=true

# Persistent local config
gh config set telemetry disabled

A diagnostic mode — GH_TELEMETRY=log — redirects payloads to stderr instead of GitHub’s ingest endpoint, allowing operators to inspect exactly what would be sent without transmitting it.¹ For teams auditing an existing pipeline, this is the right first step before deciding whether to opt out or accept the default.

The persistent config option only applies where a gh config file is writable and survives across runs. Ephemeral CI containers that build from scratch do not carry config state between jobs unless it is baked into the base image. The environment variable approach is the only robust choice for containerized pipelines.

The Agent Angle: gh Skills and the Compliance Gap

The v2.90.0 release on April 16, 2026 introduced gh skill, targeting Claude Code, GitHub Copilot, Cursor, Codex, Gemini CLI, and Antigravity.⁵ Six days later, v2.91.0 added a telemetry layer specifically for skill commands — recording skill_names, skill_owner, repo_visibility, install_count, and agent_hosts on top of the base command fields.⁶

That combination creates a broader collection surface than base gh telemetry. An AI agent that uses gh skill install during a session emits metadata about that session’s tooling configuration to GitHub: which skills are installed, who publishes them, in what repository visibility context. Developers building gh-backed agent plugins or distributing skill packages now have an implicit data egress path that downstream users of those tools did not consent to.

This is the structural problem that recurs when any dependency in an automated pipeline adds default telemetry: the pipeline operator becomes the de-facto data processor without making the disclosure. In GDPR-scoped EU infrastructure, HIPAA-adjacent developer toolchains, or FedRAMP contexts, the absence of an explicit consent step or telemetry-off wrapper is a compliance gap regardless of whether the underlying collection is considered benign.

Disabling gh telemetry does not cover GitHub Copilot, Copilot CLI, or third-party extensions, each of which handles data collection separately.¹ An agent stack combining gh with a Copilot CLI integration has multiple independent telemetry surfaces; auditing one leaves the others open.

Community Pushback: Issues #13263 and #13260

Two issues filed April 22, 2026 — the same day as the release — document the immediate friction.

Issue #13263, opened by user gsuberland, requests that default-on telemetry be rolled back until GitHub provides documentation sufficient for “informed security and privacy decisions.”⁴ The specific gaps cited: insufficient clarity on whether argument values are transmitted alongside flag names, what redaction logic applies before transmission, and how server-side pseudonymization is implemented. Without those answers, security teams in regulated environments cannot assess the risk surface with confidence — which, in practice, means the conservative response is to opt out and escalate.

Issue #13260 argues from the distribution angle: current opt-out mechanics require runtime action from end users, which creates an adoption problem for any packaging channel that needs to ship a privacy-conservative default.⁷ The request is a build-time compile flag to disable telemetry at the binary level, which would let Linux distribution maintainers, container base image authors, and enterprise toolchain bundlers ship gh without requiring downstream operators to manually configure an environment variable before first use.

Neither issue had a GitHub response at the time of access on April 23, 2026.

Action Items for Teams Running gh in Automation

For CI runners and agent pipelines:

Set GH_TELEMETRY=false in the runner’s environment variable configuration. This is the most durable approach for ephemeral containers because it does not rely on a writable config file persisting across builds. If you want to inspect payloads before deciding, run GH_TELEMETRY=log against a representative workload first.

If your pipeline uses gh skill commands, review the skills-specific fields — skill_names, skill_owner, repo_visibility, agent_hosts — against your data handling policies before the next release cycle.⁶ These fields were not present before v2.91.0 and may be out of scope for existing data-flow documentation.

For teams distributing gh-backed tooling:

If you ship a Claude Code plugin, Copilot skill, or CI utility that wraps gh, your users now inherit telemetry they did not accept from you. Setting GH_TELEMETRY=false in your wrapper’s execution environment, or documenting the requirement explicitly in your install instructions, closes that disclosure gap.

The build-time opt-out requested in Issue #13260 would solve this at the distribution layer.⁷ Until GitHub responds to that request — and there is no committed timeline as of April 23, 2026 — the runtime environment variable is the only reliable mechanism available.

Do not assume disabling gh telemetry covers the full agent stack. GitHub Copilot, Copilot CLI, and any third-party gh extensions maintain separate data egress paths and require separate audit.¹

Frequently Asked Questions

Does gh telemetry apply to GitHub Enterprise Server self-hosted deployments?

No. GitHub Enterprise Server instances have telemetry disabled by default and are exempt from the v2.91.0 collection. Teams running gh against a GHES API endpoint do not emit the sampled payloads described in the public telemetry documentation, so the opt-out configuration is only relevant for gh clients targeting github.com.

How does gh’s approach compare to other CLIs that added telemetry?

Homebrew added opt-out analytics in 2016 with an explicit first-run consent prompt before any collection began, and npm faced a similar backlash that led to clearer consent flows. GitHub CLI v2.91.0 ships telemetry enabled by default with no first-run prompt — the only signal to the user is the changelog entry and the telemetry documentation page, which most operators will never see.

What does the agent_hosts field in skills telemetry actually expose?

When a skill command is invoked through an AI agent like Claude Code or Cursor, the agent_hosts field records which platform originated the call. This gives GitHub visibility into which competing agent platforms are gaining traction among gh users — effectively competitive-intelligence data collected from tooling that plugin authors and their downstream users did not agree to share.

Can GitHub correlate sampled telemetry events over time despite the 1% rate?

Yes. The device_id is persistent per workstation and included in every sampled event. Over weeks of CI runs or daily developer usage, GitHub accumulates enough sampled events tied to the same device_id to build a behavioral profile — command frequency, OS/architecture changes, skill adoption patterns — even though each individual invocation only has a 1% chance of being recorded. The sampling rate limits volume, not longitudinal correlation.