GitHub CLI अब छद्मनाम-आधारित telemetry एकत्र करता है

 (cli.github.com/telemetry)
2 पॉइंट द्वारा GN⁺ 2026-04-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub CLI अब छद्मनाम-आधारित telemetry भेजता है, जिसका उद्देश्य feature usage की visibility पाना और product improvement को समर्थन देना है
  • subcommand adoption और flags के usage pattern के आधार पर काम की priority तय की जाती है, यह आंका जाता है कि क्या features user needs पूरी कर रहे हैं, और discoverability व design की दोबारा समीक्षा में इसका उपयोग होता है
  • open source implementation होने के कारण cli/cli repository में telemetry code को सीधे review किया जा सकता है, और logging mode के ज़रिए वास्तविक transmission से पहले JSON payload देखा जा सकता है
  • opt-out के लिए environment variable GH_TELEMETRY=false, DO_NOT_TRACK=true या gh config set telemetry disabled इस्तेमाल किया जा सकता है, और environment variable को config पर प्राथमिकता मिलती है
  • telemetry event GitHub के internal analytics infrastructure में भेजे जाते हैं, और यह पेज केवल gh के client-side data collection को कवर करता है; extensions और Copilot CLI अलग दायरे में आते हैं

Telemetry

  • GitHub CLI छद्मनाम-आधारित telemetry भेजता है, जिसका उद्देश्य product improvement को support करना है
  • यह जानकारी दी जाती है ताकि user समझ सकें कि कौन-सा data भेजा जाता है और क्यों

Telemetry एकत्र करने के कारण

  • GitHub CLI feature usage visibility की ज़रूरत का उल्लेख किया गया है, खासकर agentic adoption बढ़ने के साथ वास्तविक usage pattern समझने के उद्देश्य से
    • टीम इस data का उपयोग काम की priority तय करने के लिए करती है
    • यह आकलन करने के लिए कि क्या feature वास्तव में user needs पूरी करता है
  • नए subcommand release के बाद adoption हुआ या नहीं, यह जाँचना भी उद्देश्य है
    • अगर users बहुत कम हों, तो उस feature की discoverability या design की दोबारा समीक्षा की आवश्यकता हो सकती है
    • अगर कुछ खास flags के साथ usage अधिक दिखे, तो यह पता चलता है कि बेहतर experience में कहाँ निवेश करना चाहिए

Telemetry की समीक्षा

  • GitHub CLI open source है, और telemetry implementation को cli/cli repository में सीधे review किया जा सकता है
  • बिना वास्तव में data भेजे, भेजे जाने वाले data को देखने के लिए logging mode इस्तेमाल किया जा सकता है
    • environment variable method supported है
      • export GH_TELEMETRY=log
    • CLI setting method भी supported है
      • gh config set telemetry log
  • logging mode में सामान्यतः भेजा जाने वाला JSON payload stderr पर print होता है
    • इससे telemetry चालू रखने का निर्णय लेने से पहले हर field की जाँच की जा सकती है
    • उदाहरण command के रूप में GH_TELEMETRY=log gh repo list --archived दिया गया है
  • उदाहरण payload में शामिल event information का उल्लेख है
    • event type command_invocation
    • dimensions items में agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version शामिल हैं
    • उदाहरण values के रूप में architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0 दिखाए गए हैं
  • यह command केवल उसी सटीक command और context से संबंधित telemetry को log कर सकता है जो चलाया गया हो
    • environment variable बदलने पर payload में शामिल events और event dimensions बदल सकते हैं
    • authenticated account बदलने पर भी शामिल items बदल सकते हैं

Opt-out कैसे करें

  • logging mode में जाँची गई telemetry के लिए opt-out किया जा सकता है
  • environment variable method supported है
    • export GH_TELEMETRY=false
    • falsy values के रूप में 0, false, disabled, empty string इस्तेमाल किए जा सकते हैं
    • DO_NOT_TRACK convention भी supported है, और export DO_NOT_TRACK=true उदाहरण दिया गया है
  • CLI setting method supported है
    • gh config set telemetry disabled
  • environment variable precedence config value से अधिक है

Data कहाँ भेजा जाता है

  • telemetry event GitHub के internal analytics infrastructure में भेजे जाते हैं
  • data processing के बारे में अतिरिक्त जानकारी के लिए GitHub General Privacy Statement देखने का निर्देश दिया गया है

अतिरिक्त जानकारी

  • GitHub CLI, GitHub और third-party extensions install करके functionality बढ़ाने को support करता है, जिनमें agents भी शामिल हैं
  • ये extensions अपना usage data स्वयं collect कर सकते हैं
    • इन्हें opt-out setting से नियंत्रित नहीं किया जाता
    • telemetry कैसे report होती है और उसे disable किया जा सकता है या नहीं, यह हर extension के documentation में देखना होगा
  • यह पेज केवल GitHub CLI gh के client-side data collection को कवर करता है
    • यह GitHub Copilot और Copilot CLI पर लागू नहीं होता
    • Copilot CLI data collection को अलग तरीके से handle करता है
    • संबंधित जानकारी के लिए Using GitHub Copilot CLI, Responsible Use of the GitHub Copilot CLI का उल्लेख है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-23
Hacker News की राय

  • यह जानने की जिज्ञासा है कि कंपनियों की dev teams हमेशा telemetry के ज़रिये users पर नज़र क्यों रखना चाहती हैं
    क्या सिर्फ़ अच्छी engineering और design काफ़ी नहीं हैं
    Git 20 साल से ज़्यादा समय तक बिना इस बारीक analysis के भी ठीक चलता रहा कि कौन कौन-सा feature और command इस्तेमाल करता है; इसलिए यह संदेह है कि telemetry होती भी, तो क्या वह सच में बेहतर बनाता या बस बिखरा हुआ डेटा ही बढ़ाता

    • पहले मैं भी इसे गैरज़रूरी मानता था, लेकिन खुद startup बनाने के बाद मेरी सोच बदल गई
      analytics के बिना ऐसा लगता है जैसे आँखों पर पट्टी बाँधकर गाड़ी चला रहे हों
      यह पता नहीं चलता कि users वास्तव में किस चीज़ को महत्व देते हैं, किस flow को optimize करना चाहिए, और लोग जो कहते हैं और वे software को वास्तव में जिस तरह इस्तेमाल करते हैं, उनके बीच का फ़र्क़ हैरान करने वाला होता है
    • developer और user की ज़रूरतें और सोच अलग होती हैं, इसलिए सिर्फ़ अच्छा design काफ़ी नहीं है
      कई बार लोगों से अच्छा feedback मिलना मुश्किल होता है, और भले ही सबको feature X का idea पसंद आए, हो सकता है कि असल में कोई उसका इस्तेमाल ही न करे
      इसके अलावा, भले ही कोई बहुत मुखर fanbase दिखे, ज़रूरी नहीं कि वह revenue या real usage में बदले
      मुझे लगता है कि अगर Git में telemetry होती, तो उसके बेहतर होने की संभावना काफ़ी थी
      Git मशहूर है कि उसका UI खराब है
      शुरुआत में लोग कितनी बार अटकते हैं, यह डेटा में तुरंत दिख जाता, और उदाहरण के लिए git checkout -- foo.txt जैसे कम सहज command की जगह git restore जैसी सुधारें बहुत पहले आ जातीं
    • दुर्भाग्य से, मुझे लगता है कि ऐसा इसलिए होता है क्योंकि गैर-तकनीकी decision-makers बहुत हैं
      जो लोग खुद tools इस्तेमाल नहीं करते, वे असली usage pattern नहीं समझते, इसलिए dev tools संभालने वाले PM अपने काम को करने के लिए ऐसे data की माँग करते हैं
      यह कुछ वैसा ही ढाँचा लगता है जैसे e-commerce PM frontend पर ढेर सारे tracking scripts चढ़ा देते हैं
      पहले engineers ही users के साथ interaction design करने के लिए काफ़ी थे, लेकिन VC के बाद से यह paradigm जम गया कि technical products को गहराई से non-technical लोग lead करते हैं
      आखिरकार data उन्हीं के हाथ में जाता है, और किसी का PM salary जायज़ ठहरता है
    • मुझे नहीं लगता कि यह साफ़-साफ़ कहा जा सकता है कि Git में telemetry होती तो उससे मदद नहीं मिलती
      मेरे लिए यह स्पष्ट नहीं है
    • मुझे Git का design और usability बहुत खराब लगता है
      यह उस तरह का प्रतिनिधि example लगता है जहाँ engineers ने engineers के लिए interface बनाया और अच्छा feedback loop नहीं था
      विडंबना यह है कि यही example दिखाता है कि developers को यह और बेहतर समझना चाहिए कि उनका product वास्तव में कैसे इस्तेमाल होता है
      developer के दिमाग़ में जो usage scenario होता है, वह अक्सर reality से काफ़ी अलग होता है

  • gh CLI का opt-out मुद्दा जितना दिखता है उससे ज़्यादा जटिल है
    gh CI/CD pipelines या server environments में भी चलता है, और उन environments में privacy की वजह से नहीं बल्कि network restrictions की वजह से github.com के लिए outbound connection ही नहीं चाहिए हो सकता
    ऐसी जगहों पर अगर telemetry default on हो, तो CI fail हो सकता है या Bastion host GitHub तक बिल्कुल पहुँच ही न पाए
    जबकि Git खुद user के explicit push करने तक पूरी तरह local काम करता है
    यानी trust model अलग है
    Git बिना configuration के कभी phone home नहीं करता, लेकिन gh GitHub API के ऊपर बना wrapper है, इसलिए functional calls की ज़रूरत होना समझ में आता है
    लेकिन उस तथ्य से अलग, command usage pattern तक इकट्ठा करके upload करना चाहिए या नहीं, यह अलग सवाल है

    • मुझे नहीं लगता कि telemetry submit न होने पर program hard error के साथ बंद हो जाएगा
    • यह जानना है कि अगर gh GitHub.com से connect नहीं कर पाए, तो क्या वह लगभग बेकार हो जाता है
      या फिर enterprise GitHub connection मुख्य use case है

  • अगर तीन developers codebase के किसी हिस्से पर अपना 80 प्रतिशत समय लगा रहे हों, लेकिन वहाँ usage न हो और आगे भी उसके बढ़ने की वास्तविक संभावना न दिखे, तो शायद उस manpower को कहीं और लगाना या उस feature पर फिर से सोचना बेहतर होगा
    लेकिन ऐसे analytics की समस्या यह है कि इन्हें नुकसानरहित तरीके से इस्तेमाल किया जा सकता है, फिर भी unique identifiers और behavior patterns को जोड़कर machine learning से पहचान दोबारा बनाई जा सकती है
    timestamps शामिल हों तो मामला और गंभीर हो जाता है
    इसलिए अच्छा होगा कि कौन-सी telemetry कब भेजी जाती है, यह बिल्कुल साफ़ दिखे
    उदाहरण के लिए, भेजे बिना verbose mode में यह दिखाने वाला option हो कि क्या भेजा जाएगा, ताकि user उसे देखकर तय करे कि enable करना है या नहीं
    Steam Hardware Survey की तरह क्या भेजा जा रहा है यह दिखाने वाला तरीका सही लगता है

  • सभी gh commands आख़िरकार सिर्फ़ GitHub API wrapper ही हैं, और मुझे लगता है कि इससे यह चर्चा और उलझ जाती है

  • इतना छोटा PR अच्छा लगता है
    https://github.com/cli/cli/pull/13254
    content भी सरल है, इसलिए इसे इस तरह पढ़ा जा सकता है कि telemetry को रोकने वाला env var हटाकर अब इसे default enabled किया जा रहा है

    • यह सिर्फ़ default enabled नहीं, बल्कि लगभग disable न किया जा सकने वाला भी लगता है
      enterprise को छोड़ दें तो यह लगभग ज़बरदस्ती enabled होने जैसा ढाँचा दिखता है

  • पिछले महीने homelab में gitea deploy करना सच में बहुत संतोषजनक रहा
    इसमें GitHub से import करने की सुविधा भी है, और ईमानदारी से कहूँ तो यह GitHub से तेज़ और uptime में भी बेहतर लगता है
    Claude भी tea CLI और Git के साथ अच्छी तरह जुड़ जाता है, और यह लगभग GitHub की copy जैसा है, लेकिन अब तक तो मुझे यह बेहतर ही लगा है

    • मैं Forgejo इस्तेमाल करता हूँ, और शायद वही core code share करने की वजह से यह सच में शानदार है
      तेज़ भी है और uptime भी अच्छा है
      यहाँ तक कि यह मेरी desk के बगल वाली cabinet में रखे Pi 4 पर चल रहा है, इसलिए internet कट जाए तब भी काम करता रहता है
      backup को borg और syncthing से offsite तक भेज रहा हूँ
      setup में थोड़ा हाथ लगाना पड़ता है, लेकिन उसके बाद maintenance time लगभग शून्य के बराबर है
      लगभग हर दो हफ़्ते में एक बार सिर्फ़ SSH से लॉगिन करके SSD space, RAM usage, apt update, upgrade, और major version upgrade देखना होता है

  • क्या लोग यह नहीं मानते कि GitHub पहले से ही अपने servers पर आने वाली हर request को collect और aggregate कर रहा होगा
    आख़िर gh CLI का अस्तित्व ही उन servers के साथ interact करने के लिए है
    अगर request tracking ही नहीं चाहिए, तो लगता है कि इस एक setting से कहीं ज़्यादा चीज़ों का opt-out करना पड़ेगा

    • मुझे लगता है कि server पर data है, तो वे उसे पहले से देख ही रहे होंगे
      लेकिन इस बार ऐसा लगता है कि वे client-side metrics भी जोड़ना चाहते हैं, ताकि सिर्फ़ GitHub ही नहीं बल्कि GitLab, Codeberg जैसी दूसरी जगहों की ओर जाने वाले flow को भी बेहतर track कर सकें

  • GitHub के नज़रिए से यह अच्छी बात हो सकती है
    हर company को ऐसे data की ज़रूरत होती है; कुछ इसे product improvement के लिए इस्तेमाल करती हैं और कुछ कम अच्छे उद्देश्यों के लिए भी
    मुझे पता है कि HN users telemetry को पसंद नहीं करते, लेकिन अगर आपने खुद SaaS बनाया है, तो समझ आता है कि telemetry लगभग अनिवार्य है

    • GitHub CLI SaaS नहीं बल्कि command-line utility है
    • शायद users से सीधे पूछना पहले होना चाहिए
      आखिर में बात संवाद की कमी पर ही आकर टिकती है
    • tools की telemetry content को verify करने के लिए best practice क्या है, यह जानने की जिज्ञासा है
      असली बात detail में है, और मैं सोच रहा हूँ कि क्या user और product बनाने वालों के बीच कोई ऐसा भरोसेमंद intermediary service हो सकती है जो दोनों पक्षों को स्वीकार्य middle ground दे सके
      Claude की मदद से की गई खोज को Gist में संक्षेपित करने की बात कही गई है
    • AI समर्थकों की बोलने की शैली सबकी एक जैसी लगती है

  • इससे Microsoft का Embrace, extend, extinguish याद आता है
    पहले दो चरण तो पहले ही चल चुके हैं, और अनुमान है कि 5 साल के भीतर GH CLI ही GitHub repositories के साथ interact करने का एकमात्र तरीका बन जाएगा
    तब तीसरा चरण भी पूरा हो जाएगा और cycle समाप्त हो जाएगी

    • मैं उस prediction पर खुशी-खुशी शर्त लगा सकता हूँ
      यह इतना अवास्तविक अनुमान लगता है कि पूछने का मन होता है कितना दाँव लगाना है
    • इस तरह के दावे सच में थका देते हैं
      लोग WSL, GPU support, WSLg, PowerShell पर भी लगातार EEE वाला frame चढ़ाते रहे, लेकिन असल में ऐसा कुछ हुआ नहीं
      अभी भी नहीं, और शुरुआत से ही इसकी कोई ठोस निशानी भी मुश्किल से दिखती है
      यह intuition से समझ लेने वाली बात नहीं है; मेरा कहना है कि दिखाइए सबूत कि 90s के Microsoft की वह दोहराने योग्य रणनीति आज यहाँ कहाँ फिर से लागू हो रही है
      ऐसा भी नहीं कि Microsoft Git open source से ज़्यादा features देकर lock-in कर रहा हो, और Microsoft Linux के मामले में भी यही बात है
      GitHub, Git के ऊपर बना wrapper है, और इसकी मूल design यह है कि यह HTTP और SSH के ऊपर चलने वाला Git server है
      उस नींव को तोड़कर repository access को सिर्फ़ gh तक सीमित कर देना बहुत बड़ा बदलाव होगा, इसलिए यह व्यावहारिक नहीं लगता
      gh तो बस API calls आसान बनाने वाला tool है, और ज़्यादातर GitHub users शायद इसके अस्तित्व से भी परिचित नहीं हैं
      बल्कि GitHub को ज़्यादा नुकसान पहुँचाने वाली चीज़ दुष्ट EEE नहीं बल्कि अक्षम management हो सकती है
      users और product को न समझने वाली management की वजह से गिरावट आने की संभावना ज़्यादा लगती है
    • मैं उस prediction पर पूरी तरह संदेह नहीं करता
      पहले से ही कुछ repositories ऐसी लगती हैं जिन्हें gh के बिना संभालना झंझटभरा है, और मुझे लगता है कि forced flow धीरे-धीरे बन रहा है
      gh ठीक-ठीक क्या extra देता है, यह मैंने इस्तेमाल न करने के कारण नहीं देखा, लेकिन मेरे लिए standard Git commands ही काफ़ी हैं

  • यहाँ pseudonymous telemetry से क्या छद्मनाम-आधारित telemetry मतलब है, या फिर इसका अर्थ ऐसा telemetry है जो वास्तव में anonymous नहीं है, इसे लेकर भ्रम है
    दोनों अभिव्यक्तियों का अर्थ लगभग उल्टा है, इसलिए मौजूदा शब्दों में तो यह identifiable data collect करने की बात जैसा लगता है

    • उस page पर सिर्फ़ pseudonymous लिखा है, और pseudoanonymous शायद HN पोस्ट लिखने वाले का बनाया हुआ शब्द है
    • इसका अर्थ मैं यह समझता हूँ कि यह किसी व्यक्ति की पहचान या GitHub account से नहीं जुड़ता, लेकिन एक ही machine से आई सारी telemetry को साथ में देखा जा सकता है
      हर machine को एक UUID दिया जाता है, और उसी के आधार पर machine की पहचान होती है