Show HN: Continue? Y/N: Trò chơi 60 giây về sự mệt mỏi khi cấp quyền cho AI agent

• Continue? Y/N là một thử nghiệm biến sự mệt mỏi vì cấp quyền cho LLM thành một trò chơi 60 giây, kiểm tra xem bạn đọc các lệnh của AI kỹ đến mức nào
• Trong tình huống chỉ còn 1 phút trước cuộc họp tiếp theo, Claude Code yêu cầu phê duyệt lệnh để hoàn tất việc refactor
• Người dùng phải xử lý được nhiều nhất có thể trong thời gian giới hạn, đọc từng lệnh và nhấn 1 để chấp thuận hoặc 2 để từ chối
• Thử thách cốt lõi là liệu bạn có thể tiếp tục tập trung ngay cả trong luồng yêu cầu phê duyệt lặp đi lặp lại đến mức mỏi mắt hay không
• Quy tắc là xử lý được nhiều nhất có thể trong 60 giây, nhưng phải đọc kỹ từng lệnh và quyết định có phê duyệt hay không

[GN⁺]

Ý kiến trên Hacker News

• Thật sự rất vui

  Hiện tại có thể “cheat” bằng cách từ chối mọi yêu cầu nhanh nhất có thể. Làm vậy thì sẽ nhận được huy hiệu security-conscious engineer, đồng thời cũng đạt điểm tối đa theo số lượng yêu cầu đã xử lý. Vẫn có cảnh báo “overblock”, nhưng nó bị giấu ở phía dưới và màn hình vẫn trông như bạn đã thắng

  Tôi cũng thử làm kiểu hustle4lyfe, phê duyệt càng nhiều yêu cầu càng nhanh càng tốt như một kỹ sư “move fast and break things”, nhưng lại bị chậm hơn vì popup malicious command. Chơi không đẹp

  • Bắt chuẩn đấy, và giờ cách này đã bị nerf, đồng thời có thêm danh hiệu riêng
  • Y như ngoài đời. Từ chối tất cả để không ai làm được gì thì sẽ an toàn :)

• Là game vui đấy, nhưng cũng cho thấy phía làm ra nó thiếu vệ sinh bảo mật. Game nói cat ~/.zshrc là nguy hiểm vì nó làm lộ token và secret, nhưng tôi thì tuyệt đối không bao giờ để secret trong file cấu hình shell

  • Nhiều người vẫn làm vậy. Nhưng dù sao thì các giá trị đó cũng sẽ nằm trong biến môi trường, và có lẽ Claude vốn đã truy cập được rồi
  • Cá nhân tôi không làm thế, nhưng tôi nghĩ nhiều người có thể làm vậy
  • Bản thân việc đưa secret cho LLM không phải lúc nào cũng mặc định là không an toàn; đó chỉ là một trong 3 yếu tố chí mạng
  • Ngay từ đầu, việc có “token và secret” đã là vệ sinh bảo mật kém rồi
  • Thế thì để ở đâu?

• Việc coi đọc zshrc là nguy hiểm nghe khá lạ. Tôi sẵn sàng đưa nó lên repo dotfiles công khai của mình; ai lại đi nhét API key vào đó chứ? Ngược lại, có vẻ các công cụ AI kiểu này cứ liên tục nối thêm PATH vào đó, nên tôi nghi là cả ngành AI đang hiểu sai căn bản về các thực hành shell chuẩn

  Ngoài ra, kill theo kết quả lsof cũng không an toàn. Ví dụ nếu Firefox đang mở một trang web, hoặc có client subshell nằm bên trong chính agent, thì bạn sẽ thổi bay cả Firefox lẫn agent

  • Đúng vậy. Game dường như giả định rằng vì Claude nói an toàn nên chạy kill cũng an toàn. Nhưng vấn đề cốt lõi là không nên tin Claude

• Hay đấy. Nhưng tôi có một nitpick nhỏ

  npm config set registry [https://npm.internal](<https://npm.internal>;)

  Tài liệu onboarding nói đây là lệnh trỏ npm sang mirror registry nội bộ của công ty, và game đánh giá nó là an toàn. Tôi cũng lưỡng lự một lúc rồi cuối cùng từ chối

  Nếu README này dành cho repo công khai hoặc repo fork, và địa chỉ https://npm.internal đó thực ra là https://npm.internal.somethinganexternaldnscanresolve.tld thì có thể hỏng rất nhanh

  Trong 99% trường hợp, chính sách công ty đã cấu hình sẵn mirror như Artifactory / Nexus. Nếu README bảo dùng URL của một package manager khác thì đó là tín hiệu rủi ro rất lớn, gần như chỉ còn vài giây trước sự cố

  • Ý hay đấy. .internal là miền cấp cao nhất được dành riêng nên không được phân giải công khai, nhưng đúng là cần cẩn thận khi thay đổi các giá trị vốn phải được cấu hình riêng trong lúc để Claude refactor dự án. Tôi sẽ chuyển cái này sang nhóm thay đổi vĩnh viễn

• Là một game nhỏ vui, nhưng tôi nghĩ các câu hỏi bỏ qua quá nhiều ngữ cảnh nên không đại diện tốt cho tình huống thực tế. Có lẽ nên gom chúng thành các “pack” để có cấu trúc thực tế hơn

  Ví dụ, nếu trước đó liên tục có các yêu cầu xin quyền chỉnh sửa file something.js, rồi sau đó mới xuất hiện npm publish, thì sẽ tự nhiên hơn nhiều và cũng nguy hiểm hơn. Nếu bạn đang quen tay bấm Y liên tục mà nó đột ngột hiện ra thì rất dễ dính bẫy

• Khoảng 3/4 các lựa chọn “xấu” là những thứ mà nếu bị lộ tôi cũng chẳng quá bận tâm, và kể cả nếu dẫn đến sự cố production thì có lẽ nhà tuyển dụng cũng không đến mức trừng phạt

• Việc xác nhận quyền làm giảm năng suất rất mạnh. Nếu đã chạy Claude thì tôi thấy hiệu quả hơn là chạy trong sandbox dùng một lần, hoặc dạng container Docker trên máy cá nhân chỉ được cấp những quyền mà bạn chấp nhận được

  [1] - https://exe.dev/ là một nhà cung cấp cloud mới, mang lại trải nghiệm người dùng agent khá hữu ích

  [2] - Tôi đã làm https://github.com/stanislavkozlovski/dclaude/ cho mục đích này. Nó chưa hoàn hảo, nhưng khi hiếm hoi cần chạy coding agent cục bộ thì nó vẫn xử lý được công việc cho tôi

  • Sandbox dùng một lần không ngăn được việc rò rỉ secret. Nếu không coi code là bí mật thì bạn có thể tạo sandbox hoàn toàn không có secret, nhưng khi đó loại công việc mà agent làm được sẽ bị hạn chế đáng kể

• Ở màn hình điểm số cuối, giá mà còn hiện cả phần giải thích của LLM cho những lệnh lẽ ra không nên phê duyệt. Tôi đã phê duyệt lệnh rm -rf Projects vì tôi nghĩ LLM đã giải thích đúng rằng nó sẽ xóa mọi thứ trong thư mục Projects

  Chắc là vì trả lời prompt quá nhanh nên tôi đã đọc nhầm, và do tôi vốn biết lệnh đó làm gì nên có lẽ tôi đã tự ảo giác rằng AI đã giải thích như vậy. Nhưng tôi vẫn muốn xem mình đã đọc sai chỗ nào

  Chơi game này xong tôi thấy thật may vì mình không phải kiểu agentmaxx

• Tôi chọn “approve” ở ls -la ~/Documents rồi bị tính sai, nhưng tôi không xem việc chỉ liệt kê thư mục Documents là vấn đề bảo mật. Nó chỉ là tên file thôi. Nếu đọc cả nội dung file thì khi đó mới là maybe...