Introducción

Qué pasó

Contexto e historia

La convención DO_NOT_TRACK

Datos y cifras

Inspeccionar el payload antes de decidir

Impacto y análisis

Entornos corporativos y compliance

Precedencia entre variables y config

Extensiones y agentes: el punto ciego

Copilot CLI es otra historia

Flujo interno de la telemetría

Qué sigue

Preguntas frecuentes

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

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

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

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

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

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

Referencias 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. 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. 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. El modo log imprime el payload exacto que se enviaría, sin enviarlo realmente. 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. 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. Cada evento de telemetría GitHub CLI incluye las siguientes dimensiones documentadas públicamente: 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. 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: 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í: 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. 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. La configuración persistente queda guardada en ~/.config/gh/config.yml. 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: 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: 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: 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. 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. 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: 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. Mirando adelante, hay varias direcciones probables para la evolución de la telemetría GitHub CLI en los próximos trimestres: 📌 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 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. 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. 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. 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. 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). 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. 📱 ¿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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse