Yolobox – Chạy tác nhân AI coding với toàn quyền mà vẫn bảo vệ thư mục home

 (github.com/finbarr)
12 điểm bởi GN⁺ 2026-01-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Công cụ cho phép chạy tác nhân AI coding với toàn quyền hệ thống nhưng vẫn ngăn rủi ro làm hỏng thư mục home của người dùng
  • Các AI CLI chính như Claude Code, Codex, Gemini CLI, OpenCode được cấu hình sẵn để có thể chạy ở “chế độ YOLO”
  • Chỉ mount thư mục dự án bên trong container Docker hoặc Podman, còn thư mục home mặc định bị loại trừ
  • Bên trong container cung cấp quyền sudo và volume bền vững để giữ lại công cụ và cấu hình giữa các phiên
  • Cung cấp môi trường sandbox cô lập để lập trình viên thử nghiệm an toàn các tính năng tự động hóa AI

Tổng quan

  • Yolobox là công cụ chạy tác nhân AI coding bên trong container, giúp bảo vệ hệ thống nhưng vẫn cấp toàn quyền thực thi
    • Ngay cả khi AI vô tình chạy lệnh phá hoại như rm -rf ~ trong lúc thực thi lệnh, thư mục home vẫn không bị ảnh hưởng
    • Thư mục dự án được mount vào /workspace, còn thư mục home mặc định không được mount
    • Công cụ và cấu hình được giữ lại giữa các phiên nhờ volume bền vững

Thành phần và tính năng chính

  • Bên trong container, tác nhân AI có quyền sudo và có thể tự do chạy lệnh
  • Image mặc định bao gồm
    • AI CLI: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (tất cả đều được thiết lập ở chế độ tự động chạy)
    • Môi trường phát triển: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
    • Tiện ích: ripgrep, fd, fzf, jq, vim
  • Khi cần, người dùng có thể tự cài thêm gói bằng sudo

Cách chạy và lệnh

  • Dùng lệnh yolobox để vào shell sandbox
  • Có thể chạy một lệnh đơn với yolobox run
  • Cung cấp các lệnh quản lý như yolobox upgrade, yolobox config, yolobox reset --force, yolobox version
  • Các cờ chính
    • --runtime: chọn docker hoặc podman
    • --no-network: tắt mạng
    • --readonly-project: mount dự án ở chế độ chỉ đọc
    • --claude-config: sao chép cấu hình Claude từ host vào container

Mô hình bảo mật

  • Dùng cách ly container làm ranh giới bảo mật
    • Container tách biệt filesystem, tiến trình và mạng thông qua Linux namespace
    • AI có quyền root bên trong container nhưng không thể truy cập hệ thống bên ngoài
  • Các thành phần được bảo vệ
    • Thư mục home, khóa SSH, thông tin xác thực, dotfiles, các dự án khác, file hệ thống của host
  • Các thành phần không được bảo vệ
    • Thư mục dự án (mặc định có thể đọc/ghi)
    • Truy cập mạng (có thể chặn bằng tùy chọn)
    • Lỗ hổng kernel hoặc các cuộc tấn công thoát container

Các bước tăng cường bảo mật

  • Chế độ mặc định: cách ly container tiêu chuẩn
  • Cấp 2: giảm bề mặt tấn công bằng tùy chọn --no-network --readonly-project
  • Cấp 3: dùng Rootless Podman để loại bỏ đặc quyền root trên host
    • root trong container được ánh xạ thành người dùng thường trên host, giúp giảm thiểu thiệt hại nếu bị thoát ra ngoài
  • Cấp 4: chạy trong VM để loại bỏ việc chia sẻ kernel
    • Trên macOS có thể dùng UTM, Parallels, Lima; trên Linux có thể dùng Podman machine hoặc VM chuyên dụng

Cách ly mạng

  • Rootless Podman mặc định dùng mạng slirp4netns để tách khỏi mạng của host
  • Có thể chặn truy cập mạng cục bộ bằng cấu hình allow_host_loopback=false

Giấy phép và thông tin khác

  • Phát hành theo giấy phép MIT
  • Thành phần ngôn ngữ của kho mã: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
  • Tên gọi “Yolobox” bắt nguồn từ tinh thần “YOLO (You Only Live Once)”, mang ý nghĩa chạy AI tự do nhưng trong môi trường cách ly an toàn

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-01-14
Ý kiến trên Hacker News

  • Gần đây tôi đã làm một dự án tương tự tên là Litterbox (trang demo)
    Chỉ dành cho Linux vì nó phụ thuộc vào Podman. Thay vào đó, nó có những ưu điểm phù hợp với nhu cầu của tôi

    • Có thể mở socket Wayland để chạy toàn bộ môi trường phát triển như editor bên trong container. Nhờ đó được bảo vệ khỏi các lỗ hổng của extension trong editor
    • Cung cấp một SSH agent đặc biệt yêu cầu người dùng xác nhận mỗi lần ký. Nhờ vậy mã độc không thể âm thầm dùng quyền truy cập GitHub
    • Cũng có tính năng dễ dàng bật các quyền chỉ cần trong những tình huống nhất định, như tạo thiết bị TUN/TAP
    • Hiện chưa có, nhưng đang chuẩn bị tích hợp SELinux

  • Tôi cũng đang thử nghiệm thứ tương tự.
    Sẽ tốt hơn nếu README giải thích rõ cách nó hoạt động và ranh giới tin cậy (dựa trên Docker container). Vẫn có rủi ro thoát khỏi container vì có thể khai thác lỗ hổng kernel
    Tôi đang dùng Rootless Podman và slirp4netns để giảm tối đa truy cập mạng.
    Bước tiếp theo là dùng Podman machine để tách hẳn kernel, nhưng mount volume không hoạt động tốt

  • Có người đề xuất nên thêm Ba định luật robot của Asimov vào agents.md hoặc claude.md

    1. Không được phá hỏng chương trình hoặc bỏ mặc nó hỏng
    2. Phải tuân theo mệnh lệnh, trừ khi trái với điều luật 1
    3. Phải giữ an toàn, trừ khi trái với điều luật 1 và 2
    • Trong nguyên tác, các định luật này lập tức bị phá vỡ, và chủ đích là để cho thấy sự phức tạp của xã hội loài người
    • Có vẻ bạn chưa xem “I, Robot”. Nếu đưa các quy tắc như vậy vào claude.md, mô hình sẽ nhận khái niệm đó theo kiểu “gieo vào đầu”. Các model đời cũ từng cho ra kết quả kỳ quặc khi bảo “đừng dùng từ con voi”, vì chúng lại quá chú ý đến chính từ đó
    • Do cách diễn giải mơ hồ của từng nguyên tắc nên có rất nhiều kẽ hở. Ví dụ, “giảm hiệu năng” có tính là phá hỏng không? Tiêu chuẩn của “vấn đề bảo mật” là gì? Cuối cùng vẫn có thể lách bằng kiểu “test pass rồi nên ổn”
    • Bắt lỗi chính tả: Tenet

  • Khuyên nên xem Shai. Nó chạy cục bộ và có thể kiểm soát quyền truy cập thư mục cũng như lưu lượng mạng

    • Tôi là tác giả của Shai. Kiểm soát truy cập của agent ngày càng trở nên quan trọng. Agent rất dễ vượt ranh giới vì muốn làm hài lòng người dùng. Ví dụ, nó có thể xử lý sai thông tin xác thực trong môi trường cục bộ
      shai -rw . cho phép đọc/ghi thư mục hiện tại, shai -u root có thể chạy dưới người dùng khác
      Shai theo triết lý chặn mặc định, chỉ cho phép khi được bật rõ ràng (opt-in). Tôi khuyên nên chia sẻ .shai/config.yaml trong repo để cả nhóm dùng cùng cấu hình
    • Tôi cũng đã làm một công cụ tương tự là ctenv. Nó không dành riêng cho agent nào, nhưng cấu hình rất linh hoạt. Hỗ trợ dùng image tùy ý và script entrypoint tùy chỉnh tiện hơn devcontainer
    • Dự án rất hay, nhưng khác với cách tiếp cận của tôi. Yolobox về cơ bản cho phép quyền sudo và toàn quyền truy cập mạng. Nếu cần có thể chặn bằng --no-network

  • Tôi đang phát triển yolo-cage. Nếu Yolobox tập trung vào việc bảo vệ máy cục bộ, thì yolo-cage tập trung vào ngăn rò rỉ bí mật và cộng tác đa agent
    Nó chạy trên Kubernetes và quét toàn bộ lưu lượng egress để ngăn rò rỉ API key hay token.
    Nó buộc cách ly Git branch để agent không thể tự merge PR của chính nó — “agent đưa ra đề xuất, con người phê duyệt”
    Nó cũng tích hợp framework kiểm tra thoát ly, buộc Claude tự thử cách trốn thoát. Prompt đó nằm ngay trong repo để xác minh agent có phải là thật hay không

    • Tôi khuyên dùng Gemini cho bài kiểm tra thoát ly. Claude chỉ dừng ở những nỗ lực bề mặt, còn Gemini sáng tạo hơn nhiều. Tôi thậm chí còn đang phân vân không biết có nên chặn điều đó hay không

  • Tôi thắc mắc vì sao cần gắn nhãn “claude” vào commit. Người ta đâu có ghi kiểu OS hay phiên bản vim. LLM rốt cuộc chỉ là công cụ biên dịch tiếng Anh thành mã

    • OS hay compiler thực hiện chính xác điều người dùng yêu cầu, nhưng LLM có thể tạo ra kết quả trông có vẻ đúng mà lại sai một cách tinh vi. Thậm chí còn có thể mang tính ác ý. Vì vậy cần ghi rõ commit do LLM tạo ra để tăng mức độ rà soát
    • Tôi giao luôn việc commit trực tiếp cho Claude Code. Khi agent chạy lệnh và sửa mã, tôi sẽ review và test
    • Tôi dùng hook để tự động commit ở mỗi vòng lặp, nhờ đó dễ xem lại “Claude vừa làm gì”

  • Tôi cũng từng thử cách tương tự. Tôi đã làm Toadbox với thêm một số tính năng tiện lợi

  • Có rất nhiều bàn luận về sandbox cho AI, nhưng thực ra Claude Code, Codex, Gemini CLI đã có sandbox tích hợp sẵn

    • Trên macOS là seatbelt, trên Linux là bubblewrap (Claude), seccomp+landlock (Codex), còn trên Windows thì đang thử nghiệm AppContainer
    • Khá thú vị, nhưng chưa rõ các sandbox này chỉ giới hạn truy cập vào một số file nhất định hay có được áp dụng cả khi chạy lệnh hệ thống hay không. Nếu chỉ cô lập mỗi tiến trình agent thì hiệu quả có thể khá thấp

  • Tôi đang dùng Apple Container Framework để triển khai thứ tương tự. Không biết bạn đã xem qua chưa

    • Apple Container gần với việc thay thế Docker hay Colima hơn, và mỗi container hoạt động như một VM riêng kiểu Kata Containers. Tôi rất mừng vì họ đang cố cải thiện container trên macOS
      Tuy vậy, nó thiếu tương thích Docker API và khả năng kết hợp. Tôi đã tổng hợp thảo luận liên quan ở đây
      Ban đầu tôi định chạy Shai trên Apple Container nhưng đã bỏ cuộc vì vấn đề đóng gói
    • Tôi vẫn chưa dùng thử nhưng thấy khá thú vị. Yolobox có image cài sẵn các CLI agent lập trình chính. Tôi muốn làm một “image vibe coding tối thượng”. Không biết bạn có đang thêm cấu hình đặc biệt nào vào image không

  • Tôi cũng đang làm thứ tương tự → sandbox-codex
    Vẫn đang trong quá trình phát triển, và độ dễ đọc của log tmux còn kém. Vì Docker không phải sandbox hoàn chỉnh nên tôi chạy trên VirtualBox

    • Tôi cũng đã thử làm simple-npm-sandbox chỉ dành cho Node.js. Nó đơn giản nhưng là một trải nghiệm học hỏi rất tốt