GitHub CLI Just Turned on Telemetry by Default — Here's the 30-Second Opt-Out

GitHub shipped gh v2.91.0 yesterday. In the changelog, halfway down, is a line that reads: "GitHub CLI: Opt-out usage telemetry."

Translation: starting with this release, the GitHub CLI sends pseudonymous usage data to GitHub by default. You are opted in until you take action. The opt-out is straightforward, but you have to know to go do it.

The Hacker News thread is predictably lively, and The Register ran a piece titled "GitHub opts all CLI users into telemetry collection whether they want it or not." Both are accurate. Both miss the more important framing, which is what this tells you about where the CLI tools sitting in your $PATH are actually going.

This post is short. The opt-out is thirty seconds. The broader trend is worth a few more minutes.

The Opt-Out, First

If you use gh on your dev machine, CI, or inside agent loops like Claude Code, you want to do this today. It will take less time than reading this section.

The cleanest way, which applies across most modern dev CLIs because of a shared convention:

export DO_NOT_TRACK=1

Put it in your ~/.zshrc or ~/.bashrc. Open a new shell. Done. This respects the DO_NOT_TRACK environment-variable convention that a growing list of tools honor — Homebrew, pnpm, turbo, nextjs, and now gh.

The gh-specific way:

gh config set telemetry disabled

Either works. The DO_NOT_TRACK version is better because it generalizes across tools, so when the next dev CLI enables telemetry by default — and there will be a next one, probably within the quarter — you're already covered.

Verify it worked:

gh config get telemetry

That's the whole opt-out. Thirty seconds. Done.

What's Actually Being Collected

GitHub's public documentation at cli.github.com/telemetry lists the data scope, and it's worth actually reading instead of guessing. The headline items:

• Command names and subcommands (gh pr create, gh issue list)
• Command flags used (but not flag values)
• Exit codes
• Error types when things fail
• Extension/plugin names in use
• A pseudonymous machine identifier
• Approximate geography (country-level)
• OS and shell environment

What's explicitly not collected, according to GitHub: argument values, file paths, repo names, or anything you typed as a prompt. GitHub says the identifier rotates and can't be tied back to your GitHub account.

I am not going to pretend to evaluate those claims independently. The GitHub CLI is open-source and you can read the telemetry code yourself — several people already have. The consensus on the HN thread reading it line-by-line is that the implementation is broadly consistent with the documented scope. "Pseudonymous" is doing some work in that sentence, but it's not obviously dishonest.

The thing that actually matters, separate from what's collected today, is that the collection channel now exists, on by default, in a tool that you run hundreds of times a week, including inside agent loops where the command frequency is way higher than human-driven use.

Why This Matters More Than It Sounds

gh is used inside a lot of loops.

When Claude Code reviews a PR, it runs gh pr view. When Codex opens a PR from a branch, it runs gh pr create. When your CI triggers a release pipeline, it runs gh release create. When you do aider --auto-commits --lint, eventually it hits gh too. When a startup with 20 engineers running agentic workflows has each of them doing 500+ agent operations per day, each agent doing 10+ gh calls per operation, you're looking at 100,000+ gh calls per day from that company alone.

Every one of those calls is now a telemetry event. The aggregate picture of "which companies are running which kinds of agentic workflows" is trivially derivable from this feed. Not because of the machine ID — that really does rotate — but because the fingerprint of agent-driven CLI usage is extremely distinctive (burst patterns, tight command sequences, non-human timings) and maps to specific agent vendors if you have any visibility at all into which tools produce which patterns.

I'm not claiming GitHub is doing this. I'm claiming the telemetry channel is now open, by default, in the CLI that sits in the middle of every agentic coding workflow that goes through GitHub. Four years from now, when someone builds "the definitive public data product on how developers use AI coding tools," this is one of the feeds they'll be sourcing from.

If that feels abstract, think about it this way: your npm commands are partly visible to npm. Your vercel commands are fully visible to Vercel. Your gh commands are now visible to GitHub. The stack of "every tool my terminal runs is also a telemetry emitter" is real, and it's compounding quietly.

The Trend Line

gh is not the first. It is the latest.

• GitHub Copilot announced in late March that starting April 24 — tomorrow — it will train on free and Pro users' data by default. Opt-out is in settings, not defaulted to privacy.
• Cursor has had opt-out-by-default telemetry for about a year. Extensive. Pseudonymous, per docs.
• Vercel CLI collects telemetry by default. Opt-out via vercel telemetry disable.
• Next.js collects anonymous telemetry during builds by default. Opt-out via npx next telemetry disable or DO_NOT_TRACK=1.
• npm has shipped increasingly aggressive telemetry in its registry client over the last eighteen months.
• Homebrew has had Google Analytics on by default since 2016. (Disable via HOMEBREW_NO_ANALYTICS=1.)
• pnpm collects optional telemetry, opt-in, which is actually exemplary.

The trend is clear: opt-out-by-default for every dev tool that has a financial reason to understand its users. The justifications are uniformly reasonable ("we need this data to improve the product"). The aggregate effect is that your terminal emits a lot more data about your workflow than it did five years ago, and almost none of it is visible without going to look.

The Solo Operator Angle

Big companies have CISOs and security policies that require audit of what every tool in the dev environment does. Solo operators don't, and as a result, are systematically more exposed.

You are the one running gh as yourself, logged into your real GitHub account, on your real projects, with your agent loops pointing at your client work. You are the one paying for Cursor Pro and logged into your real IDE on your real repos. The difference between a solo operator and an engineer at Google is that Google has security review for every tool; you have a slightly healthier suspicion and, if you're lucky, a friend who forwarded you a Hacker News link.

This is not a reason to be paranoid, and the "everything is surveillance" framing is counterproductive. But the correct mental model is: every CLI tool in your $PATH has an incentive to emit telemetry, and most of them do or will, and the price to the tool vendor of adding telemetry is nearly zero while the price to you of discovering it is significant.

The practical response is a thirty-minute dotfile hygiene pass, probably once a quarter. Here's mine.

The 30-Minute Dotfile Hygiene Pass

Put all of these in .zshrc or .bashrc. None of them require any tool changes. Just environment variables that tools honor.

# Universal "no telemetry" convention — growing list of tools honor this
export DO_NOT_TRACK=1

# Homebrew — on by default since 2016
export HOMEBREW_NO_ANALYTICS=1

# Next.js telemetry (in addition to DO_NOT_TRACK for belt-and-braces)
export NEXT_TELEMETRY_DISABLED=1

# Azure CLI
export AZURE_CORE_COLLECT_TELEMETRY=false

# .NET CLI
export DOTNET_CLI_TELEMETRY_OPTOUT=1

# gcloud
gcloud config set disable_usage_reporting true 2>/dev/null

# Gatsby
export GATSBY_TELEMETRY_DISABLED=1

And the per-tool disables for things that don't honor DO_NOT_TRACK:

# GitHub CLI
gh config set telemetry disabled 2>/dev/null

# Vercel CLI
vercel telemetry disable 2>/dev/null

# Turbo
turbo telemetry disable 2>/dev/null

# Firebase
firebase --no-analytics 2>/dev/null

Also worth doing, separately from telemetry:

# GitHub Copilot — opt out of training on your prompts/code
# (Go to github.com/settings/copilot — this must be done in the browser as of April 2026)

# Cursor — optional, disable in Settings → Privacy

That's the full pass. Thirty minutes if you're thorough, most of which is the Copilot and Cursor browser dance.

What I Actually Do About This

I have a file in my dotfiles called telemetry-off.sh that runs all of the above. Any new dev machine I set up gets it in the first five minutes, before I install anything else. Any new tool I pick up gets a quick Google for "[tool name] telemetry opt out" and the relevant env var added. It takes 30 seconds per tool and pays back whenever someone asks me about it later.

I don't lose sleep over telemetry in general. But the hygiene is cheap enough that it's weird not to do it, and the GitHub CLI news from yesterday is a good forcing function to refresh the whole set.

One thing I don't do: argue about it on the internet. The "telemetry is fine, stop complaining" and "telemetry is surveillance, burn the tools" takes are both tedious. The boring middle position — opt out where easy, move on with your life — is the one worth defaulting to.

The Broader Point

The terminal used to be the private part of the developer workflow. Your commands were yours. Your tools ran locally. Your logs stayed on your disk. That era is quietly ending, and it's ending not because of any single villain but because every SaaS-adjacent CLI tool has a financial reason to know how it's used and almost no incentive to ask first.

The counter-move is not to leave gh or vercel or next behind — they're great tools. The counter-move is to build the ten-line dotfile that opts out of the telemetry layer once, so that the next time a tool flips the default, you're already covered.

gh v2.91.0 is not a scandal. It is a reasonable product decision with a defensible implementation. But the rate at which new default-on telemetry gets added to dev CLIs is going to keep rising through 2026, and a disciplined solo operator's response is to treat that as an environmental condition to handle with a dotfile, not a drama to have feelings about.

Go add DO_NOT_TRACK=1 to your shell right now. Come back when it's done. You just bought yourself several years of forward coverage on a trend that's not going away.