GitHub CLI nay thu thập telemetry dựa trên định danh giả

 (cli.github.com/telemetry)
2 điểm bởi GN⁺ 2026-04-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • GitHub CLI gửi telemetry dựa trên định danh giả nhằm tăng khả năng quan sát việc sử dụng tính năng và hỗ trợ cải thiện sản phẩm
  • Dựa trên mức độ chấp nhận subcommand và mẫu sử dụng flags để quyết định ưu tiên công việc, đánh giá liệu tính năng có đáp ứng nhu cầu người dùng hay không, và xem xét lại discoverability cũng như design
  • Với triển khai mã nguồn mở, có thể trực tiếp xem xét mã telemetry trong kho cli/cli, và có thể dùng logging mode để kiểm tra JSON payload trước khi thực sự gửi đi
  • Có thể opt-out bằng biến môi trường GH_TELEMETRY=false, DO_NOT_TRACK=true hoặc gh config set telemetry disabled; biến môi trường được ưu tiên hơn config
  • Các sự kiện telemetry được gửi tới hạ tầng phân tích nội bộ của GitHub; trang này chỉ nói về việc thu thập dữ liệu phía client của gh, còn extensions và Copilot CLI là các đối tượng riêng

Telemetry

  • GitHub CLI gửi telemetry dựa trên định danh giả nhằm hỗ trợ cải thiện sản phẩm
  • Cung cấp thông tin để người dùng hiểu dữ liệu nào được gửi đi và vì sao

Vì sao thu thập telemetry

  • Đề cập nhu cầu có khả năng quan sát việc sử dụng các tính năng của GitHub CLI, đặc biệt khi mức độ agentic adoption tăng lên, nhằm hiểu cách công cụ đang thực sự được sử dụng
    • Nhóm sử dụng dữ liệu này để quyết định ưu tiên công việc
    • Đánh giá liệu tính năng có thực sự đáp ứng nhu cầu người dùng hay không
  • Nêu rõ mục đích kiểm tra mức độ chấp nhận sau khi phát hành subcommand mới
    • Nếu hầu như không có người dùng, có thể cần xem xét lại discoverability hoặc design của tính năng đó
    • Nếu xác nhận có mức sử dụng cao cùng với một số flags nhất định, có thể xác định nơi nên đầu tư để mang lại trải nghiệm tốt hơn

Xem xét telemetry

  • GitHub CLI là mã nguồn mở, và có thể trực tiếp xem xét phần triển khai telemetry trong kho cli/cli
  • Có thể dùng logging mode để xem dữ liệu dự kiến sẽ được gửi mà không thực sự gửi đi
    • Hỗ trợ cách dùng bằng biến môi trường
      • export GH_TELEMETRY=log
    • Hỗ trợ cách dùng bằng cấu hình CLI
      • gh config set telemetry log
  • Trong logging mode, JSON payload vốn sẽ được gửi sẽ được in ra stderr
    • Có thể kiểm tra từng trường trước khi quyết định có tiếp tục bật telemetry hay không
    • Đưa ra ví dụ lệnh GH_TELEMETRY=log gh repo list --archived
  • Nêu rõ thông tin sự kiện có trong payload ví dụ
    • Kiểu sự kiện command_invocation
    • Các mục dimensions gồm agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
    • Ví dụ giá trị gồm architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0
  • Lệnh đó chỉ có thể ghi log telemetry về chính xác lệnh đã chạy và ngữ cảnh của nó
    • Khi thay đổi biến môi trường, các events và event dimensions có trong payload có thể thay đổi
    • Khi thay đổi tài khoản đã xác thực, các mục được bao gồm cũng có thể thay đổi

Cách opt-out

  • Có thể opt-out khỏi telemetry đã được kiểm tra trong logging mode
  • Hỗ trợ cách dùng bằng biến môi trường
    • export GH_TELEMETRY=false
    • Có thể dùng các giá trị falsy như 0, false, disabled, chuỗi rỗng
    • Cũng hỗ trợ quy ước DO_NOT_TRACK, với ví dụ export DO_NOT_TRACK=true
  • Hỗ trợ cách dùng bằng cấu hình CLI
    • gh config set telemetry disabled
  • Biến môi trường được ưu tiên cao hơn giá trị config

Dữ liệu được gửi tới đâu

  • Các sự kiện telemetry được gửi tới hạ tầng phân tích nội bộ của GitHub
  • Để biết thêm về cách xử lý dữ liệu, tham khảo GitHub General Privacy Statement

Thông tin thêm

  • GitHub CLI hỗ trợ mở rộng tính năng bằng cách cài đặt extensions của GitHub và bên thứ ba, bao gồm cả agents
  • Các extensions này có thể tự thu thập dữ liệu sử dụng
    • Không bị kiểm soát bởi thiết lập opt-out này
    • Cần xem tài liệu của từng extension để biết cách chúng báo cáo telemetry và liệu có thể tắt hay không
  • Trang này chỉ nói về việc thu thập dữ liệu phía client của GitHub CLI gh
    • Không áp dụng cho GitHub Copilot và Copilot CLI
    • Copilot CLI xử lý việc thu thập dữ liệu riêng biệt
    • Tham khảo Using GitHub Copilot CLI, Responsible Use of the GitHub Copilot CLI để biết thêm thông tin

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-04-23
Ý kiến Hacker News

  • Tôi thắc mắc vì sao các đội ngũ phát triển trong doanh nghiệp lúc nào cũng muốn soi người dùng bằng telemetry
    Không lẽ chỉ kỹ thuật tốt và thiết kế tốt là vẫn chưa đủ sao
    Git đã vận hành tốt hơn 20 năm mà không cần phân tích chi li ai dùng tính năng nào hay lệnh nào, nên tôi nghi ngờ liệu có telemetry thì nó thật sự tốt hơn hay chỉ làm tăng thêm dữ liệu gây nhiễu

    • Trước đây tôi cũng nghĩ là không cần, nhưng sau khi tự làm startup thì quan điểm đã đổi
      Không có analytics thì giống như lái xe khi bị bịt mắt
      Bạn không biết người dùng thực sự coi trọng điều gì, nên tối ưu luồng nào, và khác biệt giữa điều mọi người nói với cách họ thực sự dùng phần mềm là lớn đến mức đáng ngạc nhiên
    • Vì nhà phát triển và người dùng có nhu cầu, suy nghĩ khác nhau nên tôi cho rằng chỉ thiết kế tốt thôi là chưa đủ
      Trong nhiều trường hợp rất khó lấy được phản hồi tốt từ mọi người, và dù ai cũng nói họ thích ý tưởng cho tính năng X thì thực tế có thể chẳng ai dùng
      Ngoài ra, dù có vẻ như có một nhóm fan rất ồn ào thì điều đó cũng chưa chắc chuyển thành doanh thu hay mức sử dụng thực tế
      Tôi nghĩ nếu Git có telemetry thì rất có thể nó đã tốt hơn
      Git nổi tiếng là UI tệ
      Dữ liệu hẳn đã cho thấy ngay từ sớm là người dùng chật vật nhiều đến mức nào, và chẳng hạn những cải tiến như git restore hẳn đã xuất hiện sớm hơn nhiều thay vì các lệnh kém trực quan như git checkout -- foo.txt
    • Đáng tiếc là tôi nghĩ hiện tượng này xảy ra vì có quá nhiều người ra quyết định không có nền tảng kỹ thuật
      Những người không trực tiếp dùng công cụ thì không hiểu cách nó được dùng trong thực tế, nên PM phụ trách công cụ cho dev sẽ đòi loại dữ liệu này để làm công việc của họ
      Nó giống với cấu trúc mà PM thương mại điện tử chất đống script theo dõi lên frontend
      Trước đây chỉ với kỹ sư thôi cũng đã có thể thiết kế cách tương tác với người dùng đủ tốt, nhưng sau thời kỳ VC thì mô hình sản phẩm công nghệ bị dẫn dắt sâu bởi người không chuyên kỹ thuật đã trở nên cố định, và đó mới là vấn đề
      Cuối cùng dữ liệu sẽ rơi vào tay họ, và ai đó lại có thể hợp thức hóa lương PM
    • Tôi không nghĩ có thể hiển nhiên khẳng định rằng nếu Git có telemetry thì nó cũng chẳng giúp ích gì
      Với tôi, điều đó không hề rõ ràng
    • Tôi cho rằng Git rất tệ về thiết kế và tính khả dụng
      Đây có vẻ là ví dụ tiêu biểu của việc kỹ sư làm giao diện cho kỹ sư mà không có vòng phản hồi tốt
      Trớ trêu thay, chính ví dụ này lại cho thấy rằng nhà phát triển cần hiểu tốt hơn sản phẩm của mình thực sự được dùng như thế nào
      Kịch bản sử dụng trong đầu nhà phát triển thường khác thực tế khá xa

  • Tôi nghĩ vấn đề opt-out của gh CLI phức tạp hơn tưởng tượng
    gh còn chạy trong môi trường CI/CD hoặc trên server, mà ở những môi trường đó người ta có thể không muốn có kết nối đi ra github.com không phải vì riêng tư mà vì ràng buộc mạng
    Ở những nơi như vậy, nếu telemetry mặc định bật thì CI có thể fail hoặc Bastion host có thể hoàn toàn không chạm được tới GitHub
    Trong khi đó, bản thân Git hoạt động hoàn toàn cục bộ cho đến khi người dùng chủ động push
    Tức là mô hình tin cậy khác nhau
    Git sẽ không bao giờ phone home nếu bạn không cấu hình, còn gh là wrapper cho GitHub API nên tôi thừa nhận về mặt chức năng nó cần có các lệnh gọi ra ngoài
    Nhưng tách biệt với chuyện đó, tôi nghĩ vẫn cần xem xét riêng xem có nên thu thập thêm và tải lên cả mẫu sử dụng lệnh hay không

    • Tôi không nghĩ chương trình sẽ hard error rồi chết chỉ vì không gửi được telemetry
    • Tôi thắc mắc nếu gh không kết nối được tới GitHub.com thì về cơ bản nó còn hữu dụng không
      Hay trường hợp chính là kết nối tới enterprise GitHub

  • Nếu ba nhà phát triển đang dành 80% thời gian cho một khu vực nào đó của codebase mà thực tế chẳng ai dùng và cũng khó có khả năng tăng lên trong tương lai, thì có lẽ nên chuyển nhân lực sang chỗ khác hoặc nghĩ lại chính tính năng đó
    Tuy nhiên, vấn đề với kiểu analytics này là dù có thể dùng một cách vô hại, vẫn tồn tại hiểu biết rằng có thể gắn định danh duy nhất với mẫu hành vi rồi dùng machine learning để tái dựng danh tính
    Nếu còn kèm cả timestamp thì càng nghiêm trọng hơn
    Vì vậy tôi nghĩ nên cho thấy chính xác telemetry nào được gửi đi và khi nào
    Ví dụ có thể có một tùy chọn không gửi đi nhưng hiển thị ở chế độ verbose những gì sẽ được gửi, rồi để người dùng xem xét xong mới quyết định có bật hay không
    Tôi thấy cách như Steam Hardware Survey, tức là cho thấy cái gì sẽ được gửi, mới là hợp lý

  • Mọi lệnh gh rốt cuộc cũng chỉ là wrapper cho API của GitHub, nên tôi cảm thấy cuộc tranh luận này vì thế lại càng rối hơn

  • Tôi thích những PR ngắn thế này
    https://github.com/cli/cli/pull/13254
    Nội dung cũng đơn giản, nên tôi hiểu là họ đã xóa env var dùng để chặn telemetry để chuyển sang bật mặc định

    • Không chỉ là bật mặc định, mà còn có vẻ như không thể tắt luôn
      Trừ enterprise ra thì cấu trúc này trông gần như là ép buộc phải bật

  • Tôi thật sự hài lòng vì tháng trước đã triển khai gitea cho homelab
    Nó có cả tính năng import từ GitHub, và thành thật mà nói tôi thấy còn nhanh hơn GitHub và uptime cũng tốt hơn
    Claude cũng kết nối tốt với tea CLI và Git, gần như là bản sao GitHub nhưng đến giờ tôi còn thấy nó tốt hơn

    • Tôi dùng Forgejo, có lẽ vì dùng chung core code nên nó thật sự rất tuyệt
      Tốc độ nhanh và uptime tốt
      Thậm chí nó chạy trên con Pi 4 trong tủ cạnh bàn làm việc nên dù mất Internet vẫn tiếp tục hoạt động
      Tôi còn gửi backup ra offsite bằng borg và syncthing
      Khâu thiết lập hơi tốn công một chút, nhưng sau đó thời gian bảo trì gần như bằng không
      Khoảng hai tuần tôi chỉ SSH vào một lần để kiểm tra dung lượng SSD, mức dùng RAM, apt update, upgrade, và các đợt nâng major version là xong

  • Tôi tự hỏi có phải ai cũng nghĩ rằng GitHub vốn đã thu thập và tổng hợp mọi request đi vào server của họ rồi không
    Suy cho cùng, lý do tồn tại của gh CLI cũng là để tương tác với chính các server đó
    Nếu bạn thật sự không muốn bị theo dõi request, thì có lẽ phải opt-out nhiều thứ hơn rất nhiều chứ không chỉ một thiết lập này

    • Tôi cho rằng đương nhiên họ đã xem dữ liệu phía server rồi
      Nhưng lần này có vẻ họ muốn bổ sung thêm metric phía client để theo dõi tốt hơn không chỉ luồng đi tới GitHub mà cả những luồng đi tới GitLab, Codeberg và nơi khác

  • Tôi nghĩ từ góc nhìn GitHub thì đây có thể là chuyện tốt
    Công ty nào cũng cần loại dữ liệu này, có nơi dùng để cải thiện sản phẩm và có nơi dùng cho những mục đích kém đẹp hơn
    Tôi biết người dùng HN ghét telemetry, nhưng nếu từng tự xây SaaS thì bạn sẽ hiểu telemetry gần như là bắt buộc

    • Tôi cho rằng GitHub CLI không phải SaaS mà là một tiện ích dòng lệnh
    • Hay ít nhất trước tiên cũng nên trực tiếp hỏi người dùng chứ
      Cuối cùng điều tôi muốn chỉ ra là thiếu đối thoại
    • Tôi tò mò đâu là thực tiễn tốt nhất để kiểm chứng nội dung telemetry của các công cụ
      Cốt lõi nằm ở chi tiết, và tôi đang nghĩ xem có dịch vụ trung gian đáng tin cậy nào có thể tạo ra vùng trung hòa để cả người dùng lẫn bên làm sản phẩm đều chấp nhận được hay không
      Tôi cũng nói rõ là đang tổng hợp những gì mình tìm hiểu được với sự trợ giúp của Claude thành một Gist
    • Tôi thấy giọng điệu của những người cổ vũ AI nghe giống nhau một cách lạ kỳ

  • Điều này khiến tôi nghĩ tới Embrace, extend, extinguish của Microsoft
    Hai bước đầu đã diễn ra rồi, và tôi dự đoán trong vòng 5 năm GH CLI sẽ trở thành cách duy nhất để tương tác với repository trên GitHub
    Khi đó bước thứ ba cũng hoàn tất và chu kỳ kết thúc

    • Tôi sẵn sàng cá cược rằng dự đoán đó sai
      Nó nghe như một viễn cảnh phi thực tế đến mức tôi còn muốn hỏi là anh định cược bao nhiêu
    • Những kiểu khẳng định như vậy thật sự khiến tôi mệt mỏi
      Mọi người từng liên tục áp khung EEE cho WSL, hỗ trợ GPU, WSLg và PowerShell, nhưng thực tế chẳng có chuyện đó xảy ra
      Bây giờ cũng vậy, và ngay từ đầu cũng khó thấy dấu hiệu nào cho thấy có kế hoạch như thế
      Đây không phải thứ có thể diễn giải bằng cảm giác; tôi muốn thấy bằng chứng rằng thủ pháp lặp lại mà Microsoft từng thực sự dùng trong thập niên 90 đang được tái hiện ở đâu vào lúc này
      Cũng không có chuyện Microsoft Git đang khóa nhiều tính năng hơn bản mã nguồn mở, Microsoft Linux cũng vậy
      GitHub là một wrapper trên Git, và có thiết kế cốt lõi là một Git server chạy trên HTTP và SSH
      Phá vỡ nền tảng đó để khóa quyền truy cập repository chỉ qua gh sẽ là thay đổi quá lớn nên tôi thấy không thực tế
      gh chỉ đơn giản là công cụ giúp gọi API dễ hơn, và phần lớn người dùng GitHub thậm chí còn không biết nó tồn tại
      Thứ có khả năng làm hỏng GitHub hơn không phải EEE ác ý, mà là quản lý kém năng lực
      Tôi thấy khả năng họ sa sút vì ban điều hành không hiểu người dùng và sản phẩm còn lớn hơn nhiều
    • Tôi không hoàn toàn nghi ngờ dự đoán đó
      Đã có những repository khiến tôi cảm thấy xử lý mà không có gh thì khá bất tiện, và tôi thấy đang dần xuất hiện luồng ép buộc
      Tôi không biết chính xác gh mang lại thêm điều gì vì chưa dùng, nhưng với tôi chỉ các lệnh Git tiêu chuẩn là đã đủ

  • Tôi thấy bối rối không biết pseudonymous telemetry ở đây có nghĩa là telemetry định danh giả hay thực chất là telemetry không hề ẩn danh
    Hai cách diễn đạt đó gần như trái ngược nhau, mà nếu theo đúng câu chữ hiện tại thì nghe như đang nói họ thu thập dữ liệu có thể nhận diện được

    • Trang đó chỉ dùng từ pseudonymous, còn pseudoanonymous có vẻ là cách nói do người đăng HN tự tạo ra
    • Tôi hiểu ý của nó là dữ liệu không gắn với danh tính thật của một người hay tài khoản GitHub, nhưng vẫn có thể xem toàn bộ telemetry phát ra từ một máy trong cùng một chỗ
      Có vẻ như mỗi máy sẽ có một UUID, và cấu trúc nhận diện máy dựa trên đó