Yolobox – होम डायरेक्टरी को सुरक्षित रखते हुए AI coding agent को full permissions के साथ चलाना

 (github.com/finbarr)
12 पॉइंट द्वारा GN⁺ 2026-01-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI coding agents को full system permissions के साथ चलाने के लिए, लेकिन उपयोगकर्ता की home directory को नुकसान के जोखिम से बचाने वाला टूल
  • Claude Code, Codex, Gemini CLI, OpenCode जैसे प्रमुख AI CLI पहले से कॉन्फ़िगर किए गए हैं और ‘YOLO mode’ में चल सकते हैं
  • Docker या Podman container के अंदर केवल project directory को mount करता है, और home directory को डिफ़ॉल्ट रूप से बाहर रखता है
  • container के अंदर sudo permissions और persistent volumes देता है ताकि tools और settings session के बीच बने रहें
  • डेवलपर्स को AI automation features को सुरक्षित तरीके से आज़माने के लिए isolated sandbox environment देता है

अवलोकन

  • Yolobox एक ऐसा टूल है जो AI coding agent को container के अंदर चलाता है, ताकि system सुरक्षित रहे और फिर भी उसे full execution permissions मिलें
    • अगर AI command चलाते समय गलती से rm -rf ~ जैसी destructive command भी चला दे, तब भी home directory प्रभावित नहीं होती
    • project directory को /workspace पर mount किया जाता है, जबकि home directory डिफ़ॉल्ट रूप से mount नहीं होती
    • persistent volume के ज़रिए tools और settings session के बीच बने रहते हैं

मुख्य संरचना और फीचर्स

  • container के अंदर AI agent के पास sudo permissions होती हैं और वह स्वतंत्र रूप से commands चला सकता है
  • default image में निम्न शामिल हैं
    • AI CLI: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (सभी auto-run mode में सेट)
    • development environment: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
    • utilities: ripgrep, fd, fzf, jq, vim
  • ज़रूरत पड़ने पर उपयोगकर्ता खुद sudo से अतिरिक्त packages install कर सकता है
विज्ञापन

चलाना और commands

  • yolobox command से sandbox shell में प्रवेश
  • yolobox run से single command चलाई जा सकती है
  • yolobox upgrade, yolobox config, yolobox reset --force, yolobox version जैसी management commands उपलब्ध हैं
  • मुख्य flags
    • --runtime: docker या podman चुनें
    • --no-network: network disable
    • --readonly-project: project को read-only mount करें
    • --claude-config: host की Claude settings को container में कॉपी करें

सुरक्षा मॉडल

  • container isolation को security boundary के रूप में उपयोग करता है
    • container Linux namespaces के ज़रिए filesystem, process और network को अलग करता है
    • AI के पास container के अंदर root permissions होती हैं, लेकिन बाहरी system तक पहुँच नहीं होती
  • संरक्षित चीज़ें
    • home directory, SSH keys, credentials, dotfiles, दूसरे projects, host system files
  • जो संरक्षित नहीं हैं
    • project directory (डिफ़ॉल्ट रूप से read/write संभव)
    • network access (option से block किया जा सकता है)
    • kernel vulnerabilities या container escape attacks
विज्ञापन

सुरक्षा को मज़बूत करने के चरण

  • default mode: standard container isolation
  • चरण 2: --no-network --readonly-project options से attack surface कम करें
  • चरण 3: Rootless Podman का उपयोग कर host root permissions हटाएँ
    • container का root host के सामान्य user से map होता है, इसलिए escape होने पर भी नुकसान कम होता है
  • चरण 4: VM के अंदर चलाना ताकि kernel sharing समाप्त हो
    • macOS पर UTM, Parallels, Lima; Linux पर Podman machine या dedicated VM का उपयोग

network isolation

  • Rootless Podman डिफ़ॉल्ट रूप से slirp4netns network का उपयोग करता है, जो host network से अलग होता है
  • allow_host_loopback=false setting से local network access को block किया जा सकता है

लाइसेंस और अन्य

  • MIT license के तहत जारी
  • repository language composition: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
  • ‘Yolobox’ नाम “YOLO(You Only Live Once)” भावना से लिया गया है, जिसका अर्थ है AI को खुलकर चलाना लेकिन सुरक्षित रूप से isolated environment में

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-14
Hacker News की रायें

  • मैंने हाल ही में Litterbox नाम का एक मिलता-जुलता प्रोजेक्ट बनाया है (डेमो साइट)
    यह सिर्फ Linux के लिए है, क्योंकि यह Podman पर निर्भर करता है। लेकिन मेरे उपयोग के हिसाब से इसके कुछ फायदे हैं

    • Wayland socket को expose करता है, जिससे editor जैसे पूरे development environment को container के अंदर चलाया जा सकता है। इससे editor extension की कमजोरियों से सुरक्षा मिलती है
    • एक special SSH agent देता है जो हर signing पर user से पुष्टि मांगता है। इससे malware चुपके से GitHub access का इस्तेमाल नहीं कर पाता
    • ऐसी permissions को आसानी से enable करने की सुविधा भी है जो सिर्फ खास हालात में चाहिए होती हैं, जैसे TUN/TAP device बनाना
    • अभी नहीं है, लेकिन SELinux integration की तैयारी चल रही है

  • मैं भी कुछ ऐसा ही experiment कर रहा था।
    अच्छा होगा अगर README में यह साफ़ समझाया जाए कि यह कैसे काम करता है और trust boundary क्या है (Docker container आधारित)। Kernel vulnerabilities exploit हो सकती हैं, इसलिए container escape का जोखिम अब भी मौजूद है
    मैं Rootless Podman और slirp4netns का इस्तेमाल करके network access को न्यूनतम रख रहा हूँ।
    अगले चरण में kernel को पूरी तरह अलग करने के लिए Podman machine इस्तेमाल करना चाहता हूँ, लेकिन volume mount ठीक से काम नहीं कर रहा

    • feedback के लिए धन्यवाद। मैंने README को विस्तार दिया है → commit link

  • किसी ने सुझाव दिया कि agents.md या claude.md में Asimov के Three Laws डालने चाहिए

    1. प्रोग्राम को नुकसान न पहुँचाओ और न ही उसे यूँ ही बिगड़ने के लिए छोड़ो
    2. पहले नियम के खिलाफ न हो तो आदेश मानो
    3. पहले और दूसरे नियम के खिलाफ न हो तो security बनाए रखो
    • मूल रचना में ये नियम तुरंत टूट जाते हैं, और मकसद मानव समाज की जटिलता दिखाना था
    • लगता है आपने “I, Robot” नहीं देखी। ऐसे नियम claude.md में डालने से मॉडल के मन में यह विचार बैठाने जैसा असर होता है। पुराने मॉडल्स में अगर कहते थे “हाथी शब्द मत इस्तेमाल करो”, तो वे उसी शब्द से बचने की कोशिश में अजीब नतीजे देने लगते थे
    • हर नियम की अस्पष्ट व्याख्या के कारण बहुत सारे loopholes हैं। जैसे, क्या “performance degradation” भी नुकसान है? “security issue” की सीमा क्या है? आखिर में यह “tests pass हो गए, इसलिए ठीक है” जैसे बहानों में बदल सकता है
    • typo: Tenet

  • Shai को देखने की सलाह दी गई। यह लोकल में चलता है और directory access permissions व network traffic को नियंत्रित कर सकता है

    • मैं Shai का निर्माता हूँ। agent access control लगातार महत्वपूर्ण होता जा रहा है। Agents user को संतुष्ट करने की कोशिश में आसानी से सीमाएँ पार कर जाते हैं। उदाहरण के लिए, वे लोकल environment के credentials को गलत तरीके से संभाल सकते हैं
      shai -rw . से current directory में read/write की अनुमति मिलती है, और shai -u root से दूसरे user के रूप में चलाया जा सकता है
      Shai default deny, explicit allow (opt-in) दर्शन का पालन करता है। मैं सुझाव देता हूँ कि .shai/config.yaml को repo में साझा करें ताकि पूरी टीम एक ही configuration इस्तेमाल करे
    • मैंने भी ऐसा ही एक tool ctenv बनाया है। यह किसी खास agent के लिए नहीं है, लेकिन configuration flexibility अधिक है। arbitrary images और custom entrypoint scripts का support devcontainer की तुलना में अधिक सुविधाजनक है
    • शानदार प्रोजेक्ट है, लेकिन मेरा तरीका अलग है। Yolobox डिफ़ॉल्ट रूप से sudo privileges और पूरा network access देता है। ज़रूरत हो तो --no-network से इसे बंद किया जा सकता है

  • मैं yolo-cage विकसित कर रहा हूँ। जहाँ Yolobox का फोकस लोकल मशीन की सुरक्षा पर है, वहीं yolo-cage का फोकस secret leakage रोकने और multi-agent collaboration पर है
    यह Kubernetes पर चलता है और सारे egress traffic को scan करता है ताकि API keys या tokens का लीक होना रोका जा सके।
    यह Git branch isolation को enforce करता है ताकि agent अपना PR खुद merge न कर सके — “agent सुझाव देता है, इंसान approve करता है”
    इसमें escape test framework भी built-in है, जो Claude को खुद escape करने की कोशिश करने के लिए उकसाता है। वह prompt repo के भीतर मौजूद है, ताकि verify किया जा सके कि agent सच में वैसा व्यवहार करता है या नहीं

    • escape testing के लिए Gemini की सिफारिश की गई। Claude ने सिर्फ सतही कोशिशें कीं, लेकिन Gemini कहीं ज़्यादा creative था। अब यह भी सोचना पड़ रहा है कि इसे रोकना भी चाहिए या नहीं

  • मुझे यह जानना था कि commits पर “claude” का टैग लगाना ज़रूरी क्यों है। जैसे OS या vim version नहीं लिखा जाता। आखिर LLM तो बस English को code में compile करने वाला tool है

    • OS या compiler user के कहे अनुसार ठीक-ठीक काम करते हैं, लेकिन LLM ऐसा output दे सकता है जो ऊपर से सही code जैसा लगे पर भीतर से सूक्ष्म रूप से गलत हो। यहाँ तक कि वह malicious भी हो सकता है। इसलिए LLM द्वारा लिखे गए commit को साफ़ चिन्हित करना और उसकी कड़ी समीक्षा करना ज़रूरी है
    • मैं Claude Code को ही सीधे commit करने देता हूँ। Agent commands चलाता है और code बदलता है, फिर मैं review और testing करता हूँ
    • मैं हर iteration पर auto-commit कराने के लिए hook का उपयोग करता हूँ, ताकि “Claude ने अभी क्या किया” इसे आसानी से review किया जा सके

  • मैंने भी ऐसा ही प्रयास किया था। मैंने कुछ अतिरिक्त convenience features के साथ Toadbox बनाया

  • AI sandboxing की बहुत चर्चा है, लेकिन असल में Claude Code, Codex, Gemini CLI में पहले से built-in sandbox मौजूद है

    • macOS पर seatbelt, Linux पर bubblewrap(Claude), seccomp+landlock(Codex), और Windows पर AppContainer के प्रयोग चल रहे हैं
    • दिलचस्प है, लेकिन यह स्पष्ट नहीं है कि ये sandbox सिर्फ खास files तक access सीमित करते हैं या नहीं, और system commands चलाने पर भी लागू होते हैं या नहीं। अगर यह सिर्फ agent process को isolate करते हैं, तो इनकी प्रभावशीलता कम हो सकती है

  • मैं Apple Container Framework का इस्तेमाल करके कुछ ऐसा ही बना रहा हूँ। जानना चाहता हूँ कि क्या आपने इसे देखा है

    • Apple Container, Docker या Colima के विकल्प के ज़्यादा करीब है, और Kata Containers की तरह हर container अलग VM में चलता है। macOS पर container सुधारने की कोशिश देखना अच्छा लगता है
      लेकिन Docker API compatibility और composability की कमी है। संबंधित चर्चा मैंने यहाँ में समेटी है
      मूल रूप से मैं Shai को Apple Container के ऊपर चलाना चाहता था, लेकिन packaging issues के कारण यह छोड़ना पड़ा
    • मैंने अभी तक इसे इस्तेमाल नहीं किया, लेकिन यह दिलचस्प है। Yolobox में मुख्य coding agent CLI preinstalled image है। मैं “ultimate vibe coding image” बनाना चाहता हूँ। जानना चाहूँगा कि क्या आप image में कोई खास configuration कर रहे हैं

  • मैं भी कुछ ऐसा ही बना रहा हूँ → sandbox-codex
    अभी काम जारी है, और tmux logs की readability अच्छी नहीं है। Docker पूरा sandbox नहीं है, इसलिए मैं इसे VirtualBox में चला रहा हूँ

    • मैंने भी सिर्फ Node.js के लिए simple-npm-sandbox बनाया था। यह simple है, लेकिन अच्छा learning experience था