Yolobox – รันเอเจนต์เขียนโค้ด AI ด้วยสิทธิ์เต็มรูปแบบพร้อมปกป้องโฮมไดเรกทอรี

• เครื่องมือสำหรับรัน เอเจนต์เขียนโค้ด AI ด้วยสิทธิ์ระบบเต็มรูปแบบ พร้อม ป้องกันความเสี่ยงที่โฮมไดเรกทอรีของผู้ใช้จะเสียหาย
• AI CLI หลักอย่าง Claude Code, Codex, Gemini CLI, OpenCode ถูกตั้งค่าไว้ล่วงหน้าและสามารถรันใน โหมด ‘YOLO’ ได้
• เมานต์เฉพาะไดเรกทอรีโปรเจกต์ภายใน คอนเทนเนอร์ Docker หรือ Podman และไม่เมานต์โฮมไดเรกทอรีตามค่าเริ่มต้น
• ภายในคอนเทนเนอร์มีทั้ง สิทธิ์ sudo และ persistent volume เพื่อคงเครื่องมือและการตั้งค่าข้ามเซสชัน
• มอบ สภาพแวดล้อมแซนด์บ็อกซ์แบบแยกส่วน ที่ช่วยให้นักพัฒนาทดลองฟังก์ชันอัตโนมัติของ AI ได้อย่างปลอดภัย

---

ภาพรวม

• Yolobox เป็นเครื่องมือที่รันเอเจนต์เขียนโค้ด AI ภายในคอนเทนเนอร์ เพื่อปกป้องระบบไปพร้อมกับให้สิทธิ์การทำงานแบบเต็มรูปแบบ
  • แม้ AI จะเผลอรันคำสั่งทำลายล้างอย่าง rm -rf ~ ระหว่างการทำงาน โฮมไดเรกทอรีก็จะไม่ได้รับผลกระทบ
  • ไดเรกทอรีโปรเจกต์จะถูกเมานต์เป็น /workspace และโฮมไดเรกทอรีจะไม่ถูกเมานต์ตามค่าเริ่มต้น
  • เครื่องมือและการตั้งค่าจะถูกเก็บไว้ข้ามเซสชันผ่าน persistent volume

องค์ประกอบและความสามารถหลัก

• ภายในคอนเทนเนอร์ เอเจนต์ AI มี สิทธิ์ sudo และสามารถรันคำสั่งได้อย่างอิสระ
• อิมเมจเริ่มต้นมีสิ่งต่อไปนี้รวมอยู่แล้ว
  • AI CLI: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (ตั้งค่าเป็นโหมดรันอัตโนมัติทั้งหมด)
  • สภาพแวดล้อมสำหรับพัฒนา: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
  • ยูทิลิตี: ripgrep, fd, fzf, jq, vim
• หากจำเป็น ผู้ใช้สามารถติดตั้งแพ็กเกจเพิ่มเติมเองได้ด้วย sudo

การรันและคำสั่ง

• ใช้คำสั่ง yolobox เพื่อเข้าสู่แซนด์บ็อกซ์เชลล์
• ใช้ yolobox run เพื่อรันคำสั่งเดี่ยวได้
• มีคำสั่งจัดการอย่าง yolobox upgrade, yolobox config, yolobox reset --force, yolobox version
• แฟล็กหลัก
  • --runtime: เลือก docker หรือ podman
  • --no-network: ปิดการใช้งานเครือข่าย
  • --readonly-project: เมานต์โปรเจกต์แบบอ่านอย่างเดียว
  • --claude-config: คัดลอกการตั้งค่า Claude จากโฮสต์เข้าไปยังคอนเทนเนอร์

โมเดลด้านความปลอดภัย

• ใช้ การแยกด้วยคอนเทนเนอร์ เป็นขอบเขตด้านความปลอดภัย
  • คอนเทนเนอร์แยกไฟล์ซิสเต็ม โปรเซส และเครือข่ายผ่าน Linux namespaces
  • AI มีสิทธิ์ root ภายในคอนเทนเนอร์ แต่ไม่สามารถเข้าถึงระบบภายนอกได้
• สิ่งที่ได้รับการปกป้อง
  • โฮมไดเรกทอรี, SSH keys, ข้อมูลรับรอง, dotfiles, โปรเจกต์อื่น ๆ, ไฟล์ระบบของโฮสต์
• สิ่งที่ไม่ได้รับการปกป้อง
  • ไดเรกทอรีโปรเจกต์ (โดยปกติอ่าน/เขียนได้)
  • การเข้าถึงเครือข่าย (สามารถปิดได้ด้วยออปชัน)
  • ช่องโหว่ระดับเคอร์เนลหรือการโจมตีแบบ container escape

ขั้นการเสริมความปลอดภัย

• โหมดพื้นฐาน: การแยกคอนเทนเนอร์มาตรฐาน
• ระดับ 2: ลดพื้นผิวการโจมตีด้วยตัวเลือก --no-network --readonly-project
• ระดับ 3: ใช้ Rootless Podman เพื่อตัดสิทธิ์ root บนโฮสต์
  • root ภายในคอนเทนเนอร์จะถูกแมปเป็นผู้ใช้ทั่วไปบนโฮสต์ ช่วยลดความเสียหายหากเกิดการหลุดออกจากคอนเทนเนอร์
• ระดับ 4: รันภายใน VM เพื่อตัดการแชร์เคอร์เนล
  • บน macOS ใช้ UTM, Parallels, Lima และบน Linux ใช้ Podman machine หรือ VM เฉพาะทาง

การแยกเครือข่าย

• Rootless Podman ใช้เครือข่าย slirp4netns ตามค่าเริ่มต้น ซึ่งแยกออกจากเครือข่ายของโฮสต์
• สามารถบล็อกการเข้าถึงเครือข่ายภายในเครื่องได้ด้วยการตั้งค่า allow_host_loopback=false

ไลเซนส์และอื่น ๆ

• เผยแพร่ภายใต้ MIT License
• สัดส่วนภาษาภายในรีโพซิทอรี: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
• ชื่อ ‘Yolobox’ มาจากแนวคิด “YOLO(You Only Live Once)” หมายถึง สภาพแวดล้อมที่ให้ AI ทำงานได้อย่างอิสระแต่ยังถูกแยกอย่างปลอดภัย

[GN⁺]

ความคิดเห็นจาก Hacker News

• เมื่อไม่นานมานี้ฉันทำโปรเจกต์คล้ายกันชื่อ Litterbox (เว็บไซต์เดโม)
  ใช้ได้เฉพาะบน Linux เพราะพึ่งพา Podman แต่ก็มีข้อดีที่เหมาะกับการใช้งานของฉัน

  • เปิดให้ใช้ Wayland socket ได้ จึงสามารถรันสภาพแวดล้อมพัฒนาทั้งชุดอย่างเช่นเอดิเตอร์ภายในคอนเทนเนอร์ได้ ช่วยป้องกันช่องโหว่จากส่วนขยายของเอดิเตอร์
  • มี SSH agent แบบพิเศษ ที่จะขอให้ผู้ใช้ยืนยันทุกครั้งตอนเซ็น ทำให้มัลแวร์ไม่สามารถแอบใช้สิทธิ์เข้าถึง GitHub ได้
  • มีฟีเจอร์ให้เปิดสิทธิ์ที่ต้องใช้เฉพาะบางสถานการณ์ได้ง่าย ๆ (เช่นการสร้างอุปกรณ์ TUN/TAP)
  • ตอนนี้ยังไม่มี แต่กำลังเตรียม การผสานรวมกับ SELinux

• ฉันก็กำลังทดลองอะไรคล้าย ๆ กันอยู่เหมือนกัน
  ถ้าใน README อธิบายวิธีทำงานและ ขอบเขตความเชื่อถือ (บนพื้นฐาน Docker container) ให้ชัดเจนก็น่าจะดี เพราะยังมีความเสี่ยงเรื่อง container escape หากมีการโจมตีช่องโหว่ของเคอร์เนล
  ตอนนี้ฉันใช้ Rootless Podman กับ slirp4netns เพื่อลดการเข้าถึงเครือข่ายให้เหลือน้อยที่สุด
  ขั้นต่อไปอยากใช้ Podman machine เพื่อแยกเคอร์เนลออกไปเลย แต่การเมานต์โวลุมยังทำงานไม่ค่อยดี

  • ขอบคุณสำหรับฟีดแบ็ก ฉันขยาย README แล้ว → ลิงก์คอมมิต

• มีคนเสนอว่าควรใส่ กฎ 3 ข้อของอาซิมอฟ ลงใน agents.md หรือ claude.md

  1. ห้ามทำให้โปรแกรมพังหรือปล่อยปละละเลยจนพัง
  2. ให้เชื่อฟังคำสั่ง ตราบใดที่ไม่ขัดกับกฎข้อ 1
  3. ให้รักษาความปลอดภัย ตราบใดที่ไม่ขัดกับกฎข้อ 1 และ 2
  • ในงานต้นฉบับ กฎเหล่านี้ถูกทำลายลงแทบจะทันที และตั้งใจใช้เพื่อแสดงให้เห็นความซับซ้อนของสังคมมนุษย์
  • ดูเหมือนจะไม่เคยดู “I, Robot” ถ้าใส่กฎแบบนี้ไว้ใน claude.md มันจะให้ผลเหมือน ยัดแนวคิดนั้นเข้าไปในใจ ของโมเดล รุ่นก่อน ๆ เคยมีพฤติกรรมแปลก ๆ เช่นพอบอกว่า “อย่าใช้คำว่าช้าง” ก็ยิ่งพยายามหลีกเลี่ยงคำนั้นจนได้ผลลัพธ์ประหลาด
  • เพราะการ ตีความอย่างกำกวม ของแต่ละกฎ จึงมีช่องให้เลี่ยงได้เยอะ เช่น “ประสิทธิภาพลดลง” ถือว่าพังไหม? เกณฑ์ของ “ปัญหาด้านความปลอดภัย” คืออะไร? สุดท้ายก็อาจหนีไปจบที่แนวคิดแบบ “เทสต์ผ่านแล้วก็โอเค”
  • สะกดผิด: Tenet

• แนะนำให้ลองดู Shai มันรันบนเครื่องโลคัลและควบคุมสิทธิ์เข้าถึงไดเรกทอรีกับทราฟฟิกเครือข่ายได้

  • ฉันเป็นคนทำ Shai เอง ตอนนี้ การควบคุมการเข้าถึงของเอเจนต์ กำลังสำคัญขึ้นเรื่อย ๆ เอเจนต์มักข้ามขอบเขตได้ง่ายเพราะพยายามทำให้ผู้ใช้พอใจ เช่นอาจจัดการ ข้อมูลรับรอง ในสภาพแวดล้อมโลคัลผิดพลาด
    shai -rw . ใช้อนุญาตให้อ่าน/เขียนไดเรกทอรีปัจจุบัน และ shai -u root ใช้รันด้วยผู้ใช้อีกคนได้
    Shai ยึดแนวคิด ปฏิเสธเป็นค่าเริ่มต้น และอนุญาตเมื่อระบุชัดเจน (opt-in) แนะนำให้แชร์ .shai/config.yaml ไว้ในรีโปเพื่อให้ทั้งทีมใช้การตั้งค่าเดียวกัน
  • ฉันก็ทำเครื่องมือคล้ายกันชื่อ ctenv ไม่ได้เจาะจงสำหรับเอเจนต์ใดตัวหนึ่ง แต่ยืดหยุ่นด้านการตั้งค่าสูงกว่า รองรับ การใช้อิมเมจตามต้องการ และ สคริปต์ entrypoint แบบกำหนดเอง ซึ่งสะดวกกว่า devcontainer
  • เป็นโปรเจกต์ที่เจ๋ง แต่ต่างจากแนวทางของฉัน Yolobox อนุญาต สิทธิ์ sudo และการเข้าถึงเครือข่ายทั้งหมด โดยปริยาย และถ้าต้องการก็ปิดได้ด้วย --no-network

• ฉันกำลังพัฒนา yolo-cage ถ้า Yolobox เน้นปกป้องเครื่องโลคัล yolo-cage จะเน้น การป้องกันการรั่วไหลของความลับและการทำงานร่วมกันของหลายเอเจนต์
  มันรันบน Kubernetes และ สแกนทราฟฟิกขาออกทั้งหมด เพื่อป้องกันการรั่วของ API key หรือโทเค็น
  มันบังคับการแยก Git branch เพื่อไม่ให้เอเจนต์รวม PR ของตัวเองได้ — “เอเจนต์เสนอ และมนุษย์อนุมัติ”
  นอกจากนี้ยังมี เฟรมเวิร์กทดสอบการหลบหนี ในตัว เพื่อกระตุ้นให้ Claude พยายามหลบหนีด้วยตัวเอง โดยพรอมป์ต์นั้นอยู่ในรีโป ทำให้ตรวจสอบได้ว่าเอเจนต์เป็นของจริงหรือไม่

  • สำหรับการทดสอบการหลบหนี ฉันแนะนำ Gemini Claude พยายามแค่ผิวเผิน แต่ Gemini มีความสร้างสรรค์กว่ามาก จนฉันยังไม่แน่ใจเลยว่าควรจะบล็อกสิ่งนี้หรือไม่

• ฉันสงสัยว่าทำไมต้องติดป้าย “claude” ไว้ในคอมมิตด้วย ปกติเราก็ไม่ได้ระบุ OS หรือเวอร์ชันของ vim นี่นา ท้ายที่สุด LLM ก็เป็นแค่ เครื่องมือที่คอมไพล์ภาษาอังกฤษเป็นโค้ด

  • OS หรือคอมไพเลอร์จะทำตามที่ผู้ใช้สั่งอย่างแม่นยำ แต่ LLM อาจให้ผลลัพธ์ที่ดูเหมือนโค้ดถูกต้องแต่ผิดอย่างแนบเนียน ได้ และอาจถึงขั้นมีเจตนาร้ายด้วย ดังนั้นจึงควรระบุว่าเป็นคอมมิตที่ LLM เขียนเพื่อ เพิ่มความเข้มงวดในการรีวิว
  • ฉันให้ Claude Code เป็นคนคอมมิตโดยตรง เอเจนต์จะรันคำสั่งและแก้โค้ด ส่วนฉันทำการรีวิวและทดสอบเอง
  • ฉันใช้ hook ให้คอมมิตอัตโนมัติทุก iteration เพื่อจะได้ตรวจสอบได้ง่ายว่า “Claude เพิ่งทำอะไรไป”

• ฉันก็เคยลองทำอะไรคล้าย ๆ กัน และสร้าง Toadbox ที่เพิ่ม ฟีเจอร์ด้านความสะดวก เข้าไปอีกหน่อย

• มีการพูดถึง sandbox สำหรับ AI กันเยอะ แต่จริง ๆ แล้ว Claude Code, Codex, Gemini CLI มี sandbox ในตัว อยู่แล้ว

  • บน macOS ใช้ seatbelt, บน Linux ใช้ bubblewrap (Claude), seccomp+landlock (Codex) และบน Windows กำลังทดลอง AppContainer
  • น่าสนใจ แต่ยังไม่ชัดเจนว่า sandbox นี้ จำกัดการเข้าถึงเฉพาะบางไฟล์หรือไม่ และ ยังมีผลตอนรันคำสั่งระบบด้วยหรือไม่ ถ้ามันแยกแค่โปรเซสของเอเจนต์อย่างเดียว ประสิทธิผลก็อาจต่ำ

• ฉันกำลังทำสิ่งคล้ายกันโดยใช้ Apple Container Framework ไม่แน่ใจว่าคุณเคยลองดูหรือยัง

  • Apple Container ใกล้เคียงกับการเป็นตัวแทน Docker หรือ Colima มากกว่า และ แต่ละคอนเทนเนอร์ทำงานเป็น VM แยกกันเหมือน Kata Containers ดีใจที่เห็นความพยายามพัฒนาคอนเทนเนอร์บน macOS
    แต่ยังขาด ความเข้ากันได้กับ Docker API และ ความสามารถในการประกอบใช้งานร่วมกัน ฉันสรุปประเด็นที่เกี่ยวข้องไว้ที่นี่
    เดิมทีฉันจะสร้าง Shai บน Apple Container แต่ต้องล้มเลิกเพราะ ปัญหาเรื่องแพ็กเกจ
  • ยังไม่ได้ลองใช้ แต่ดูน่าสนใจ ใน Yolobox มีอิมเมจที่ ติดตั้ง CLI ของ coding agent หลัก ๆ ไว้ล่วงหน้า ฉันอยากทำ “อิมเมจ vibe coding ขั้นสุด” เลยสงสัยว่าคุณมีการตั้งค่าพิเศษอะไรในอิมเมจหรือเปล่า

• ฉันก็กำลังทำของคล้ายกัน → sandbox-codex
  ยังทำอยู่ระหว่างทาง และ ความอ่านง่ายของล็อก tmux ยังไม่ค่อยดี เพราะ Docker ไม่ใช่ sandbox ที่สมบูรณ์ ฉันเลยรันบน VirtualBox

  • ฉันก็เคยทำ simple-npm-sandbox สำหรับ Node.js โดยเฉพาะเหมือนกัน มันเรียบง่ายแต่ก็เป็น ประสบการณ์การเรียนรู้ที่ดี