GitHub CLI activa telemetría por defecto: qué envía y cómo desactivarla

Introducción

⏱️ Lectura: 13 min

GitHub publicó oficialmente su política de telemetría para la herramienta gh, el cliente de línea de comandos que millones de desarrolladores usan a diario. La telemetría GitHub CLI es pseudoanónima, está activada por defecto y envía metadatos sobre cada comando ejecutado a la infraestructura interna de la empresa. La documentación detalla qué se recopila, cómo inspeccionarlo localmente y cómo desactivarlo por completo usando variables de entorno o configuración persistente.

📑 En este artículo

1. Introducción
2. Qué pasó
3. Contexto e historia
   1. La convención DO_NOT_TRACK
4. Datos y cifras
   1. Inspeccionar el payload antes de decidir
5. Impacto y análisis
   1. Entornos corporativos y compliance
   2. Precedencia entre variables y config
   3. Extensiones y agentes: el punto ciego
   4. Copilot CLI es otra historia
6. Flujo interno de la telemetría
7. Qué sigue
8. Preguntas frecuentes
   1. ¿GitHub CLI envía el contenido de mis repos o código?
   2. ¿Cómo verifico qué se enviaría sin activarlo en producción?
   3. ¿El opt-out se sincroniza entre miembros de un equipo?
   4. ¿Qué pasa con las extensiones como gh-copilot o gh-dash?
   5. ¿DO_NOT_TRACK funciona igual en Windows que en Linux o macOS?
   6. ¿Hay alguna diferencia con la telemetría de GitHub Copilot CLI?
9. Referencias

La decisión llega en un momento en que la adopción agentic —agentes de IA que usan la CLI de forma autónoma— está creciendo a un ritmo acelerado y el equipo de GitHub necesita visibilidad sobre qué features realmente se usan en la práctica, tanto por humanos como por bots.

Qué pasó

GitHub actualizó su sitio oficial con una página dedicada exclusivamente a la telemetría del cliente gh, siendo transparente sobre el tipo de datos que el binario envía de vuelta a sus servidores. Cada invocación genera un evento command_invocation con una serie de dimensiones que identifican el comando, las flags utilizadas y el entorno de ejecución.

La novedad no es que la CLI haya empezado a recolectar datos de un día para otro, sino que ahora existe documentación explícita, herramientas integradas de inspección y un mecanismo claro y reproducible para optar out. El mensaje implícito de GitHub es contundente: los agentes de IA están usando gh a escala masiva, y entender cómo lo hacen se volvió prioridad estratégica para el roadmap del producto.

La motivación oficial es directa: cuando se lanza un subcomando nuevo, el equipo necesita saber si alguien lo usa y con qué flags. Si la adopción es baja, revisan la discoverability o el diseño. Si ven patrones de uso concentrados en ciertos flags, invierten ahí en mejor UX. Sin telemetría, esas decisiones se toman a ciegas.

Contexto e historia

La telemetría en herramientas de desarrollo no es algo nuevo. Homebrew introdujo su analytics opcional en 2016, Visual Studio Code envía datos de uso desde su lanzamiento en 2015, el CLI de .NET y Next.js recolectan métricas pseudoanónimas por defecto desde hace años, y Docker Desktop hace lo propio. Todas siguen patrones similares: instalación, device ID anónimo, lista de comandos usados, errores frecuentes, sistema operativo y arquitectura.

Lo que diferencia el anuncio de GitHub es la franqueza sobre el motivo. En lugar de frases genéricas del estilo “mejorar el producto”, la documentación explica con detalle cómo las métricas alimentan decisiones concretas de priorización. Esta transparencia se alinea con la tendencia de los últimos dos años hacia políticas de datos más legibles y menos legales en herramientas open source.

El razonamiento se vuelve aún más crítico cuando consideramos la adopción por parte de agentes LLM. Herramientas como Claude Code, Cursor y GitHub Copilot CLI invocan gh cientos de veces al día en sesiones autónomas donde un humano no está presente. Medir qué subcomandos son más útiles para agentes frente a humanos cambia completamente las prioridades de ingeniería y explica por qué el campo agent aparece en cada payload.

La convención DO_NOT_TRACK

Un detalle relevante para quienes buscan privacidad consistente: gh respeta la variable de entorno DO_NOT_TRACK, una convención propuesta en consoledonottrack.com para herramientas de línea de comandos. Esto permite que un desarrollador exporte la variable una sola vez en su shell y automáticamente opte out de la telemetría en cualquier herramienta compatible con el estándar, sin tener que configurar cada CLI por separado.

💡 Tip: Si trabajás en LATAM con conexiones cobradas por consumo o con restricciones corporativas de salida a internet, desactivar la telemetría también reduce tráfico saliente innecesario y evita posibles bloqueos en firewalls estrictos.

Datos y cifras

Cada evento de telemetría GitHub CLI incluye las siguientes dimensiones documentadas públicamente:

• command — el subcomando ejecutado, por ejemplo gh repo list o gh pr create.
• flags — las flags utilizadas, sin sus valores (se envía archived, no archived=true).
• device_id — UUID generado localmente por instalación, no vinculado a tu cuenta de GitHub.
• invocation_id — UUID único por cada invocación individual del comando.
• os — sistema operativo detectado: darwin, linux o windows.
• architecture — arquitectura del CPU: arm64, amd64, etc.
• version — versión instalada de gh, por ejemplo 2.91.0.
• is_tty — si la salida va a una terminal interactiva o está redirigida a pipe/script.
• agent — identificador del agente que invoca, vacío cuando es un humano.
• timestamp — fecha y hora de ejecución en formato UTC ISO 8601.

Lo que explícitamente no se envía: argumentos posicionales (como el nombre del repo en gh repo view owner/repo), valores de flags, variables de entorno arbitrarias, tokens de autenticación, contenido de archivos ni respuestas de la API de GitHub. Esa lista de exclusiones es la parte más tranquilizadora de la política.

Inspeccionar el payload antes de decidir

Una de las mejores decisiones de diseño de la telemetría de GitHub CLI es permitir ver exactamente qué se enviaría, sin enviarlo. Basta con ejecutar cualquier comando con la variable GH_TELEMETRY=log seteada:

# Linux / macOS (bash/zsh)
GH_TELEMETRY=log gh repo list --archived

# Windows PowerShell
$env:GH_TELEMETRY="log"; gh repo list --archived

# Windows CMD
set GH_TELEMETRY=log && gh repo list --archived

El output va a stderr (no stdout), lo que significa que no interfiere con scripts que procesan la salida normal de gh vía pipe. El payload JSON resultante es algo así:

{
  "events": [{
    "type": "command_invocation",
    "dimensions": {
      "agent": "",
      "architecture": "arm64",
      "command": "gh repo list",
      "device_id": "1e9a73a6-c8bd-4e1e-be02-78f4b11de4e1",
      "flags": "archived",
      "invocation_id": "eda780f5-27f9-433c-a7ae-7a033361e572",
      "is_tty": "true",
      "os": "darwin",
      "timestamp": "2026-04-16T14:55:13.418Z",
      "version": "2.91.0"
    }
  }]
}

Inspeccionar antes de aceptar es una filosofía que más herramientas deberían adoptar. La barrera entre “no sé qué envía” y “puedo ver exactamente qué envía” es la diferencia entre opacidad y consentimiento informado.

Impacto y análisis

La implementación de la telemetría GitHub CLI sigue principios razonables: el payload es mínimo, el opt-out es trivial y existe un modo de inspección antes de decidir. Comparado con otros clientes que recolectan stack traces completos, contenidos anonimizados o árboles de directorios, gh se queda en el espectro menos invasivo de la industria de herramientas de desarrollo.

Sin embargo, hay consideraciones prácticas que los equipos en LATAM deberían evaluar, especialmente aquellos que trabajan bajo regulaciones locales o políticas corporativas de datos.

Entornos corporativos y compliance

Para empresas con políticas de protección de datos estrictas —bancos, salud, gobierno, fintech regulada— incluso telemetría pseudoanónima puede requerir autorización explícita. La recomendación estándar es deshabilitarla vía política de configuración en imágenes base de desarrollo, en contenedores Docker corporativos o bloqueándola a nivel de red egress. gh facilita el primer camino con un solo comando:

gh config set telemetry disabled

Este comando escribe en ~/.config/gh/config.yml, y el archivo puede distribuirse a todo el equipo como parte del onboarding o del aprovisionamiento de máquinas nuevas. Para Dockerfiles:

RUN gh config set telemetry disabled
# o, más limpio:
ENV GH_TELEMETRY=false
ENV DO_NOT_TRACK=1

Precedencia entre variables y config

Un detalle crítico que suele pasar desapercibido: las variables de entorno tienen precedencia sobre la configuración persistente. Esto significa que si alguien tiene GH_TELEMETRY=true exportada en su shell (o heredada de un Dockerfile upstream), la configuración de telemetry disabled no surte efecto en esa sesión. En auditorías reales, conviene validar ambas capas:

# Verificar variable de entorno
echo $GH_TELEMETRY        # Linux / macOS
$env:GH_TELEMETRY         # Windows PowerShell

# Verificar configuración persistente
gh config get telemetry

Extensiones y agentes: el punto ciego

La documentación es explícita en un aspecto importante: las extensiones de gh —tanto oficiales como de terceros— pueden tener su propia telemetría independiente. El opt-out global del binario no les aplica. Esto incluye herramientas populares del ecosistema como gh-dash, gh-copilot y cualquier extensión instalada vía gh extension install desde el marketplace de la comunidad.

⚠️ Ojo: Auditar telemetría es una tarea por extensión. Revisá la documentación de cada una antes de asumir que deshabilitar gh te cubre completamente. No hay un interruptor maestro que aplique a todo el ecosistema de extensiones.

Copilot CLI es otra historia

GitHub aclara un punto crucial: esta política aplica solo al binario gh. GitHub Copilot CLI —una herramienta separada con su propio binario y documentación— tiene política de recolección independiente. Este matiz es importante porque muchos equipos usan ambas herramientas simultáneamente y asumen erróneamente que la configuración se hereda de una a otra.

Flujo interno de la telemetría

El siguiente diagrama muestra cómo gh decide si enviar o no cada evento, y en qué orden evalúa los distintos mecanismos de opt-out:

graph LR
  A["gh comando"] --> B{"DO_NOT_TRACK set?"}
  B -->|"Si"| X["No envia"]
  B -->|"No"| C{"GH_TELEMETRY=false?"}
  C -->|"Si"| X
  C -->|"No"| D{"config disabled?"}
  D -->|"Si"| X
  D -->|"No"| E["Construye payload"]
  E --> F["Envia a analytics"]

La jerarquía queda clara: DO_NOT_TRACK gana sobre GH_TELEMETRY, que a su vez gana sobre la configuración persistente. Conocer ese orden evita sorpresas cuando la telemetría parece seguir activa pese a haber intentado deshabilitarla por un solo canal.

Qué sigue

Mirando adelante, hay varias direcciones probables para la evolución de la telemetría GitHub CLI en los próximos trimestres:

• Más granularidad agentic. El campo agent actualmente está vacío para invocaciones humanas. A medida que agentes LLM se identifiquen correctamente vía headers o variables dedicadas, GitHub podrá segmentar métricas humanas vs. agentes y ajustar el diseño de subcomandos en consecuencia.
• Estándar para extensiones. Es probable que surja una guía o SDK oficial para que las extensiones adopten el mismo contrato de opt-out, unificando la experiencia del usuario y cerrando el punto ciego actual.
• Transparencia extendida. Dado que el código es open source en el repositorio cli/cli, analistas de privacidad pueden auditar la implementación real línea por línea. No hay sorpresas ocultas, y eso refuerza la credibilidad del mensaje.
• Presión regulatoria creciente. Con GDPR, CCPA y regulaciones LATAM emergentes —como la LGPD brasileña o la Ley Federal de Protección de Datos Personales en México— cualquier recolección requiere base legal clara y mecanismos documentados de opt-out. GitHub está cumpliendo con el estándar mínimo de la industria, pero la barra va a seguir subiendo.

📌 Nota: La primera vez que gh detecta que no hay configuración explícita, podría mostrar un aviso visible sobre la telemetría. Hoy no lo hace, pero es un cambio esperable dado el énfasis regulatorio global.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿GitHub CLI envía el contenido de mis repos o código?

No. La telemetría solo envía metadatos del comando ejecutado: nombre del subcomando, flags usadas (sin valores), sistema operativo, arquitectura, versión y un identificador anónimo de dispositivo. No se transmiten argumentos posicionales como nombres de repos, ni contenido de archivos, ni respuestas de la API de GitHub, ni tokens de autenticación.

¿Cómo verifico qué se enviaría sin activarlo en producción?

Ejecutá cualquier comando con GH_TELEMETRY=log. El payload JSON se imprimirá en stderr sin enviarse a los servidores de GitHub. Es el método recomendado antes de decidir si mantener la telemetría activa o no, y es útil también para auditorías internas en equipos corporativos.

¿El opt-out se sincroniza entre miembros de un equipo?

No automáticamente. gh config set telemetry disabled escribe localmente en el archivo de configuración del usuario actual. Para distribuir la decisión al equipo conviene incluir el comando en scripts de onboarding, imágenes Docker base, configuraciones de dotfiles compartidos o plantillas de devcontainers.

¿Qué pasa con las extensiones como gh-copilot o gh-dash?

Las extensiones tienen telemetría independiente. Deshabilitar la telemetría de gh no desactiva automáticamente la de sus extensiones instaladas. Hay que revisar la documentación de cada una para ver cómo hacer opt-out, y GitHub explicita este punto en la política oficial para evitar confusión.

¿DO_NOT_TRACK funciona igual en Windows que en Linux o macOS?

Sí, pero la sintaxis para exportar la variable varía según el shell. En Windows PowerShell es $env:DO_NOT_TRACK=1, en CMD es set DO_NOT_TRACK=1, y en bash o zsh es export DO_NOT_TRACK=1. Para hacerlo permanente, agregalo al perfil del shell correspondiente (.bashrc, .zshrc, $PROFILE).

¿Hay alguna diferencia con la telemetría de GitHub Copilot CLI?

Sí. La política descrita aplica solamente al binario gh. GitHub Copilot CLI es una herramienta distinta con recolección de datos separada y documentación propia. Si usás ambas herramientas, deberás configurar el opt-out por separado en cada una, ya que no comparten configuración ni variables de entorno.

Referencias

• GitHub CLI — Telemetry — Política oficial de telemetría con todos los detalles técnicos y ejemplos de payload.
• cli/cli en GitHub — Código fuente del cliente gh, auditable públicamente bajo licencia MIT.
• Console Do Not Track — Convención abierta para la variable de entorno DO_NOT_TRACK en herramientas CLI.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.