GitHub CLI ตอนนี้เก็บเทเลเมทรีแบบนามแฝงแล้ว

 (cli.github.com/telemetry)
2 คะแนน โดย GN⁺ 2026-04-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GitHub CLI จะส่ง เทเลเมทรีแบบนามแฝง โดยมีเป้าหมายเพื่อเพิ่มการมองเห็นการใช้งานฟีเจอร์และช่วยปรับปรุงผลิตภัณฑ์
  • ใช้ข้อมูลเรื่อง การนำ subcommand ไปใช้งาน และรูปแบบการใช้ flags เพื่อกำหนดลำดับความสำคัญของงาน ประเมินว่าตอบโจทย์ผู้ใช้หรือไม่ และนำไปทบทวน discoverability กับ design
  • เป็น การติดตั้งใช้งานแบบโอเพนซอร์ส จึงสามารถตรวจสอบโค้ดเทเลเมทรีได้โดยตรงในรีโพซิทอรี cli/cli และใช้ logging mode เพื่อดู JSON payload ก่อนส่งจริงได้
  • การปิดการส่งข้อมูลแบบ opt-out ทำได้ด้วยตัวแปรสภาพแวดล้อม GH_TELEMETRY=false, DO_NOT_TRACK=true หรือ gh config set telemetry disabled โดยตัวแปรสภาพแวดล้อมจะมีลำดับความสำคัญสูงกว่าค่า config
  • อีเวนต์เทเลเมทรีจะถูกส่งไปยัง โครงสร้างพื้นฐานการวิเคราะห์ภายในของ GitHub และหน้านี้กล่าวถึงเฉพาะการเก็บข้อมูลฝั่งไคลเอนต์ของ gh เท่านั้น โดย extensions และ Copilot CLI เป็นคนละส่วน

เทเลเมทรี

  • GitHub CLI ส่ง เทเลเมทรีแบบนามแฝง เพื่อช่วยปรับปรุงผลิตภัณฑ์
  • ให้ข้อมูลเพื่อให้ผู้ใช้เข้าใจว่ามีการส่งข้อมูลอะไรบ้างและส่งไปด้วยเหตุผลใด

เหตุผลที่เก็บเทเลเมทรี

  • กล่าวถึงความจำเป็นในการมองเห็น การใช้งานฟีเจอร์ของ GitHub CLI โดยเฉพาะเมื่อการใช้งานเชิง agentic เพิ่มขึ้น จึงต้องการเข้าใจรูปแบบการใช้งานจริง
    • ทีมงานใช้ข้อมูลนี้ในการกำหนดลำดับความสำคัญของงาน
    • ใช้ประเมินว่าฟีเจอร์ต่าง ๆ ตอบสนองความต้องการของผู้ใช้จริงหรือไม่
  • ระบุชัดว่าต้องการตรวจสอบ การนำ subcommand ใหม่ไปใช้งานหลังเปิดตัว
    • หากแทบไม่มีผู้ใช้ อาจต้องทบทวน discoverability หรือ design ของฟีเจอร์นั้น
    • หากพบการใช้งานสูงร่วมกับ flags บางรายการ ก็จะช่วยชี้จุดที่ควรลงทุนเพื่อสร้างประสบการณ์ที่ดีกว่าเดิม

การตรวจสอบเทเลเมทรี

  • GitHub CLI เป็น โอเพนซอร์ส และสามารถตรวจสอบการติดตั้งใช้งานเทเลเมทรีได้โดยตรงในรีโพซิทอรี cli/cli
  • หากต้องการดูข้อมูลที่จะถูกส่งโดยไม่ส่งจริง สามารถใช้ logging mode ได้
    • รองรับการตั้งค่าผ่านตัวแปรสภาพแวดล้อม
      • export GH_TELEMETRY=log
    • รองรับการตั้งค่าผ่าน CLI
      • gh config set telemetry log
  • ใน logging mode จะพิมพ์ JSON payload ที่ปกติจะถูกส่งออกไปยัง stderr
    • ผู้ใช้สามารถตรวจดูแต่ละฟิลด์ก่อนตัดสินใจว่าจะเปิดใช้เทเลเมทรีต่อหรือไม่
    • ยกตัวอย่างคำสั่ง GH_TELEMETRY=log gh repo list --archived
  • ระบุข้อมูลอีเวนต์ที่รวมอยู่ใน payload ตัวอย่าง
    • ประเภทอีเวนต์ command_invocation
    • ใน dimensions มี agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
    • ตัวอย่างค่า เช่น architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0
  • คำสั่งดังกล่าวสามารถบันทึกได้เฉพาะเทเลเมทรีของ คำสั่งและบริบทที่ถูกรันจริงเท่านั้น
    • หากเปลี่ยนตัวแปรสภาพแวดล้อม events และ event dimensions ที่รวมอยู่ใน payload ก็อาจเปลี่ยนตาม
    • หากเปลี่ยนบัญชีที่ยืนยันตัวตนแล้ว รายการข้อมูลที่รวมอยู่ก็อาจต่างออกไปเช่นกัน

วิธี opt-out

  • สามารถ opt-out จากเทเลเมทรีที่ตรวจสอบผ่าน logging mode ได้
  • รองรับการตั้งค่าผ่านตัวแปรสภาพแวดล้อม
    • export GH_TELEMETRY=false
    • ใช้ค่าที่ตีความเป็น false ได้ เช่น 0, false, disabled, สตริงว่าง
    • รองรับธรรมเนียม DO_NOT_TRACK ด้วย โดยมีตัวอย่าง export DO_NOT_TRACK=true
  • รองรับการตั้งค่าผ่าน CLI
    • gh config set telemetry disabled
  • ตัวแปรสภาพแวดล้อมมีลำดับความสำคัญ สูงกว่าค่า config

ข้อมูลถูกส่งไปที่ใด

  • อีเวนต์เทเลเมทรีถูกส่งไปยัง โครงสร้างพื้นฐานการวิเคราะห์ภายใน ของ GitHub
  • หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับวิธีประมวลผลข้อมูล ให้ดู GitHub General Privacy Statement

ข้อมูลเพิ่มเติม

  • GitHub CLI รองรับการเพิ่มความสามารถผ่านการติดตั้ง extensions ของ GitHub และ บุคคลที่สาม รวมถึง agents
  • extensions เหล่านี้อาจเก็บข้อมูลการใช้งานของตนเองได้
    • ไม่ถูกควบคุมด้วยการตั้งค่า opt-out นี้
    • ควรตรวจสอบเอกสารของแต่ละ extension เพื่อดูวิธีรายงานเทเลเมทรีและดูว่าสามารถปิดได้หรือไม่
  • หน้านี้กล่าวถึงเฉพาะ การเก็บข้อมูลฝั่งไคลเอนต์ ของ GitHub CLI gh
    • ไม่ครอบคลุม GitHub Copilot และ Copilot CLI
    • Copilot CLI มีการจัดการการเก็บข้อมูลแยกต่างหาก
    • มีการแนะนำแหล่งข้อมูลที่เกี่ยวข้องคือ Using GitHub Copilot CLI, Responsible Use of the GitHub Copilot CLI

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-04-23
ความเห็นจาก Hacker News

  • สงสัยว่าทำไมทีมพัฒนาในองค์กรถึงพยายามสอดส่องผู้ใช้ด้วย telemetry กันตลอด
    อยากถามว่าแค่วิศวกรรมและการออกแบบที่ดีมันยังไม่พอหรือ
    Git ก็ทำงานได้ดีมาตลอดเกิน 20 ปีโดยไม่ต้องมีการวิเคราะห์ละเอียดว่าใครใช้ฟีเจอร์หรือคำสั่งอะไรบ้าง เลยสงสัยว่าถ้ามี telemetry แล้วมันจะดีขึ้นจริงหรือแค่เพิ่ม ข้อมูลที่รกรุงรัง เท่านั้น

    • เมื่อก่อนฉันก็คิดว่าไม่จำเป็น แต่พอได้สร้างสตาร์ทอัพเองแล้วความคิดก็เปลี่ยนไป
      ถ้าไม่มี analytics ก็เหมือนขับรถแบบปิดตา
      เราจะไม่รู้เลยว่าผู้ใช้ให้ความสำคัญกับอะไรจริง ๆ ต้องปรับปรุง flow ตรงไหน และความต่างระหว่างสิ่งที่คนพูดกับวิธีที่พวกเขาใช้ซอฟต์แวร์จริง ๆ นั้นมากจนน่าตกใจ
    • เพราะนักพัฒนากับผู้ใช้มีความต้องการและมุมมองต่างกัน เลยมองว่าแค่การออกแบบที่ดีอย่างเดียวไม่พอ
      หลายครั้งก็ยากที่จะได้ feedback ที่ดี จากผู้คน และถึงทุกคนจะบอกว่าชอบไอเดียของฟีเจอร์ X แต่ในความเป็นจริงอาจไม่มีใครใช้เลยก็ได้
      อีกทั้งต่อให้ดูเหมือนมีกลุ่มแฟนที่เสียงดัง ก็อาจไม่แปลงเป็นรายได้หรือการใช้งานจริง
      คิดว่าถ้า Git มี telemetry ก็น่าจะมีโอกาสสูงที่จะดีขึ้น
      Git ขึ้นชื่ออยู่แล้วว่า UI แย่
      ถ้ามีข้อมูลก็คงเห็นได้ทันทีว่าช่วงแรกคนสับสนกันมากแค่ไหน และการปรับปรุงอย่าง git restore แทนคำสั่งที่ไม่เป็นธรรมชาติอย่าง git checkout -- foo.txt ก็น่าจะเกิดขึ้นเร็วกว่านี้มาก
    • น่าเสียดายที่คิดว่าปรากฏการณ์แบบนี้เกิดจากการมี ผู้ตัดสินใจที่ไม่ใช่สายเทคนิค เยอะเกินไป
      คนที่ไม่ได้ใช้เครื่องมือเองไม่เข้าใจวิธีใช้งานจริง เลยทำให้ PM ที่ดูแลเครื่องมือสำหรับนักพัฒนาต้องเรียกร้องข้อมูลแบบนี้เพื่อให้ตัวเองทำงานได้
      มันดูคล้ายกับโครงสร้างที่ PM ฝั่งอีคอมเมิร์ซยัดสคริปต์ติดตามเต็ม frontend
      ทั้งที่เดิมทีแค่วิศวกรก็ออกแบบการปฏิสัมพันธ์กับผู้ใช้ได้ดีพออยู่แล้ว แต่หลังยุค VC แนวคิดที่ให้คนไม่เทคนิคมานำผลิตภัณฑ์เทคโนโลยีแบบลึก ๆ กลับกลายเป็นเรื่องปกติ ซึ่งรู้สึกว่านั่นแหละคือปัญหา
      สุดท้ายข้อมูลก็ไหลไปอยู่ในมือพวกเขา และดูเหมือนจะมีใครสักคนได้ใช้มันมาอธิบายว่าทำไม เงินเดือน PM ถึงคุ้มค่า
    • รู้สึกว่าคงพูดแบบฟันธงไม่ได้ว่าถ้า Git มี telemetry แล้วจะไม่ช่วย
      สำหรับฉันมัน ไม่ชัดเจน
    • มองว่า Git ทั้งการออกแบบและการใช้งาน แย่มาก
      เป็นตัวอย่างชัดเจนของการที่วิศวกรสร้างอินเทอร์เฟซให้วิศวกรด้วยกันเอง และไม่มีวงจร feedback ที่ดี
      น่า ironic ตรงที่ตัวอย่างนี้เองกลับย้ำว่า นักพัฒนาควรเข้าใจให้มากขึ้นว่าผลิตภัณฑ์ของตัวเองถูกใช้จริงอย่างไร
      สถานการณ์การใช้งานที่นักพัฒนาคิดไว้ในหัวมักต่างจากความจริงมากพอสมควร

  • มองว่าประเด็น opt-out ของ gh CLI ซับซ้อนกว่าที่คิด
    gh ทำงานใน CI/CD pipeline หรือสภาพแวดล้อมของเซิร์ฟเวอร์ด้วย ซึ่งในสภาพแวดล้อมแบบนั้นอาจไม่ต้องการให้มีการเชื่อมต่อออกไปยัง github.com เลย ไม่ใช่เพราะเรื่อง privacy แต่เพราะข้อจำกัดด้านเครือข่าย
    ถ้าเปิด telemetry เป็นค่าเริ่มต้นในที่แบบนั้น CI อาจล้มเหลว หรือ Bastion host อาจแตะ GitHub ไม่ได้เลย
    ขณะที่ตัว Git เองทำงานในเครื่องล้วน ๆ จนกว่าผู้ใช้จะสั่ง push อย่างชัดเจน
    โมเดลความเชื่อใจจึงต่างกัน
    Git จะไม่ phone home เด็ดขาดถ้าไม่ได้ตั้งค่าไว้ แต่ก็ยอมรับว่า gh เป็น wrapper ของ GitHub API จึงจำเป็นต้องมีการเรียกใช้งานตามหน้าที่
    อย่างไรก็ตาม แยกอีกเรื่องหนึ่งว่าจำเป็นไหมที่จะต้องเก็บและอัปโหลดรูปแบบการใช้คำสั่งเพิ่มเติมด้วย

    • ไม่คิดว่าถ้าส่ง telemetry ไม่ได้ โปรแกรมจะล้มแบบ hard error
    • สงสัยว่าถ้า gh เชื่อมต่อ GitHub.com ไม่ได้ มันก็แทบไม่มีประโยชน์อยู่แล้วหรือเปล่า
      หรือกรณีหลักจริง ๆ คือเชื่อมกับ enterprise GitHub

  • ถ้านักพัฒนา 3 คนใช้เวลา 80% ไปกับบางส่วนของ codebase ทั้งที่แทบไม่มีการใช้งาน และในทางปฏิบัติก็ไม่เห็นโอกาสว่ามันจะโตขึ้นได้ การย้ายคนไปทำอย่างอื่นหรือทบทวนฟีเจอร์นั้นใหม่อาจดีกว่า
    แต่ปัญหาของ analytics แบบนี้คือ มันอาจถูกใช้อย่างไม่เป็นพิษเป็นภัยก็จริง แต่ก็มีความเข้าใจอยู่เบื้องหลังว่าถ้าผูกตัวระบุเฉพาะกับรูปแบบพฤติกรรม ก็สามารถใช้ machine learning สร้างตัวตนกลับขึ้นมาใหม่ได้
    ถ้ามี timestamp ด้วยก็ยิ่งหนักขึ้น
    เพราะงั้นเลยคิดว่าน่าจะมีการเปิดเผยให้ชัดเจนว่า telemetry แบบไหนถูกส่งออกไปและเมื่อไร
    เช่น อาจมีตัวเลือกที่ไม่ส่งจริง แต่แสดงใน verbose mode ว่าจะส่งอะไรบ้าง ให้ผู้ใช้ตรวจดูก่อนแล้วค่อยตัดสินใจว่าจะเปิดหรือไม่
    รู้สึกว่าวิธีแบบ Steam Hardware Survey ที่แสดงให้เห็นว่าจะส่งอะไรบ้างนั้นเหมาะกว่า

  • ทุกคำสั่งของ gh ก็เป็นแค่ API wrapper ของ GitHub เท่านั้น ซึ่งทำให้การถกเถียงนี้ยิ่งชวนสับสนขึ้นไปอีก

  • ชอบ PR ที่สั้นแบบนี้
    https://github.com/cli/cli/pull/13254
    เนื้อหาก็เรียบง่าย อ่านแล้วเข้าใจว่าเป็นการลบ env var ที่เคยใช้บล็อก telemetry ออก เพื่อเปลี่ยนให้เป็น เปิดใช้งานโดยค่าเริ่มต้น

    • ไม่ใช่แค่เปิดโดยค่าเริ่มต้น แต่ดูเหมือนจะ ปิดไม่ได้เลย ด้วย
      ถ้าไม่ใช่ enterprise ก็แทบจะเป็นโครงสร้างที่บังคับเปิดใช้งาน

  • ดีใจมากที่เดือนก่อนตัดสินใจ deploy gitea ใน homelab
    มีฟีเจอร์ import มาจาก GitHub ด้วย และพูดตรง ๆ ว่ารู้สึกว่ามันเร็วกว่า GitHub และ uptime ก็ดีกว่า
    Claude ก็ใช้งานร่วมกับ tea CLI และ Git ได้ดี มันแทบจะเป็นสำเนาของ GitHub แต่จนถึงตอนนี้กลับรู้สึกว่าดีกว่าด้วยซ้ำ

    • ฉันใช้ Forgejo อยู่ ซึ่งน่าจะเพราะใช้ core code ร่วมกัน มันเลยยอดเยี่ยมจริง ๆ
      ทั้งเร็วและ uptime ดี
      แถมยังรันอยู่บน Pi 4 ในตู้ข้างโต๊ะได้อีก ดังนั้นถึงอินเทอร์เน็ตล่มก็ยังใช้งานต่อได้
      ส่วน backup ก็ส่งออกไป offsite ด้วย borg และ syncthing
      ตอนตั้งค่าอาจต้องลงแรงนิดหน่อย แต่หลังจากนั้นเวลาในการดูแลแทบจะเป็นศูนย์
      ประมาณสองสัปดาห์ค่อย SSH เข้าไปทีเพื่อดูพื้นที่ SSD, การใช้ RAM, apt update, upgrade และเช็กการอัปเกรดเวอร์ชันใหญ่

  • สงสัยว่าทุกคนไม่ได้คิดกันอยู่แล้วหรือว่า GitHub เก็บและสรุปทุก request ที่เข้ามายังเซิร์ฟเวอร์ของตัวเองอยู่แล้ว
    ท้ายที่สุดเหตุผลที่มี gh CLI ก็เพื่อโต้ตอบกับเซิร์ฟเวอร์นั้น
    ถ้าไม่ต้องการให้มีการติดตาม request เลย ก็มองว่าน่าจะต้อง opt-out อะไรอีกเยอะกว่าการตั้งค่านี้มาก

    • คิดว่าถ้ามีข้อมูลอยู่ที่เซิร์ฟเวอร์ ก็แน่นอนว่าเขาคงดูอยู่แล้ว
      แต่ครั้งนี้ดูเหมือนจะเพิ่ม metric ฝั่ง client เข้าไป เพื่อให้ติดตามได้ดีขึ้นไม่ใช่แค่การไปยัง GitHub เท่านั้น แต่รวมถึง flow ที่ไปยัง GitLab, Codeberg และที่อื่น ๆ ด้วย

  • จากมุม GitHub มันอาจเป็นเรื่องที่ดีก็ได้
    ทุกบริษัทต้องการข้อมูลแบบนี้ บางที่เอาไปใช้ปรับปรุงผลิตภัณฑ์ บางที่ก็ใช้เพื่อจุดประสงค์ที่ไม่น่าชื่นชมนัก
    รู้ว่าใน HN คนไม่ชอบ telemetry แต่ถ้าเคยสร้าง telemetry สำหรับ SaaS เอง จะรู้ว่ามันแทบจะเป็นสิ่งจำเป็น

    • มองว่า GitHub CLI ไม่ใช่ SaaS แต่เป็นยูทิลิตีบรรทัดคำสั่ง
    • หรือจริง ๆ ควรถามผู้ใช้โดยตรงก่อนจะดีกว่าไหม
      สุดท้ายก็อยากชี้ให้เห็นว่ามันขาด การพูดคุย
    • สงสัยว่าแนวทางปฏิบัติที่ เป็นมาตรฐานที่ดี ในการตรวจสอบว่าเครื่องมือส่ง telemetry อะไรบ้างควรเป็นอย่างไร
      ประเด็นสำคัญอยู่ที่รายละเอียด และกำลังคิดอยู่ว่าจะมีบริการตัวกลางที่น่าเชื่อถือซึ่งช่วยสร้างจุดกึ่งกลางที่ทั้งผู้ใช้และผู้สร้างผลิตภัณฑ์ยอมรับได้หรือไม่
      ระบุว่ากำลังสรุปข้อมูลที่ค้นมาด้วยความช่วยเหลือของ Claude ลงใน Gist
    • รู้สึกว่าน้ำเสียงของคนที่สนับสนุน AI ฟังดูคล้ายกันไปหมด

  • ทำให้นึกถึง Embrace, extend, extinguish ของ Microsoft
    สองขั้นแรกเกิดขึ้นไปแล้ว และคาดว่าใน 5 ปี GH CLI จะกลายเป็นวิธีเดียวในการโต้ตอบกับ repository บน GitHub
    จากนั้นขั้นที่สามก็จะสมบูรณ์และวงจรจะจบลง

    • ฉันยินดีเดิมพันกับคำทำนายนั้น
      ถึงขั้นอยากถามเลยว่าจะพนันกันเท่าไร เพราะมันฟังดูเป็น มุมมองที่ไม่สมจริง
    • คำกล่าวแบบนี้ชวนให้เหนื่อยใจจริง ๆ
      ผู้คนเอากรอบ EEE ไปครอบกับ WSL, การรองรับ GPU, WSLg, PowerShell อยู่เรื่อย ๆ แต่ในความเป็นจริงสิ่งนั้นก็ไม่เกิดขึ้น
      ตอนนี้ก็เหมือนกัน และตั้งแต่ต้นก็แทบไม่เห็นแม้แต่ร่องรอยของแผนแบบนั้น
      มันไม่ใช่เรื่องที่จะตีความจากความรู้สึกได้ อยากให้แสดง หลักฐาน ว่ากลวิธีซ้ำ ๆ ที่ Microsoft ใช้จริงในยุค 90 กำลังถูกทำซ้ำตรงไหนในตอนนี้
      Microsoft Git ก็ไม่ได้ปิดล็อกด้วยฟีเจอร์ที่มากกว่าโอเพนซอร์ส หรือ Microsoft Linux ก็เช่นกัน
      GitHub เป็น wrapper บน Git และมีการออกแบบแกนกลางว่าเป็น Git server ที่ทำงานบน HTTP และ SSH
      การทำลายพื้นฐานนั้นแล้วบังคับการเข้าถึง repository ให้ผ่าน gh อย่างเดียวเป็นการเปลี่ยนแปลงที่ใหญ่เกินไป จึงมองว่าไม่ค่อยเป็นจริงได้
      gh ก็เป็นแค่เครื่องมือที่ช่วยให้เรียก API ได้สะดวกขึ้นเท่านั้น และผู้ใช้ GitHub ส่วนใหญ่ก็แทบไม่รู้ด้วยซ้ำว่ามันมีอยู่
      ถ้ามีอะไรจะทำให้ GitHub พังได้มากกว่า EEE แบบมีเจตนาร้าย ก็คงเป็น การบริหารที่ไร้ความสามารถ
      รู้สึกว่ามีโอกาสมากกว่าที่มันจะตกต่ำเพราะผู้บริหารไม่เข้าใจผู้ใช้และตัวผลิตภัณฑ์
    • ฉันไม่ได้สงสัยคำทำนายนั้นไปเสียทั้งหมด
      ตอนนี้บาง repository ก็เริ่มรู้สึกว่ายุ่งยากถ้าจะจัดการโดยไม่มี gh และดูเหมือนจะเริ่มมี flow ที่กึ่งบังคับ ทีละน้อย
      แม้จะไม่รู้ว่า gh ให้อะไรเพิ่มมาบ้างเพราะไม่เคยใช้ แต่สำหรับฉัน แค่คำสั่ง Git มาตรฐานก็พอแล้ว

  • สับสนว่าคำว่า pseudonymous telemetry ที่พูดถึงตรงนี้หมายถึง telemetry แบบไม่ระบุตัวตน หรือจริง ๆ หมายถึง telemetry ที่ไม่ได้ anonymous กันแน่
    สองคำนี้แทบจะตรงข้ามกัน แต่ถ้าใช้ถ้อยคำตามนี้ก็ดูเหมือนกำลังบอกว่าเก็บข้อมูลที่ระบุตัวตนได้

    • ในหน้านั้นมีแค่คำว่า pseudonymous ส่วน pseudoanonymous ดูเหมือนเป็นคำที่คนเขียนโพสต์ HN แต่งขึ้นเอง
    • เข้าใจว่ามันหมายถึงแม้จะไม่ผูกกับตัวตนของบุคคลหรือบัญชี GitHub แต่สามารถดู telemetry ทั้งหมดที่มาจากเครื่องเดียวกันรวมกันได้
      ดูเหมือนแต่ละเครื่องจะมี UUID ติดอยู่ และใช้สิ่งนั้นเป็นตัวระบุเครื่อง