Claude Code को खतरनाक तरीके से (सुरक्षित रूप से) चलाना

 (blog.emilburzo.com)
26 पॉइंट द्वारा GN⁺ 2026-01-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code के --dangerously-skip-permissions फ़्लैग को सुरक्षित रूप से इस्तेमाल करने का तरीका
  • Docker, VM, Firejail जैसे कई isolated execution environments की समीक्षा के बाद Vagrant-आधारित virtual machine (VM) को सबसे उपयुक्त माना गया
  • Vagrant के ज़रिए पूर्ण VM isolation, reproducible configuration, और local folder sharing बनाए रखते हुए Docker-in-Docker की समस्या से बचा गया
  • Claude Code को VM के भीतर sudo permissions के साथ सिस्टम पर स्वतंत्र रूप से काम करने के लिए सेट किया गया, और वास्तव में web app चलाना, DB configuration, test automation जैसी चीज़ें करवाई गईं
  • यह तरीका गलती से होने वाले filesystem damage को रोकने में प्रभावी है, और ज़रूरत पड़ने पर VM को delete/recreate करके सुरक्षित रूप से reset किया जा सकता है

पृष्ठभूमि

  • Claude Code का उपयोग करते समय हर बार permission request की पुष्टि करने की असुविधा दूर करने के लिए --dangerously-skip-permissions फ़्लैग आज़माया गया
    • यह फ़्लैग package install, configuration change, file delete जैसे सभी काम बिना पूर्व स्वीकृति के अपने आप करता है
    • इससे workflow नहीं टूटता और efficiency बढ़ती है, लेकिन filesystem damage का जोखिम मौजूद रहता है
  • इसे रोकने के लिए host OS account से अलग environment में इसे चलाने की ज़रूरत महसूस हुई

जिन तरीकों पर विचार किया गया

  • isolation के लिए पहले Docker पर विचार किया गया, लेकिन Claude को Docker image build करनी होती है और container चलाने होते हैं, इसलिए Docker-in-Docker configuration की ज़रूरत पड़ती है
    • इस स्थिति में --privileged mode चाहिए, जिससे sandboxing का उद्देश्य ही बेअर्थ हो जाता है
    • network nesting, volume mount permission issues जैसी वजहों से जटिलता और अस्थिरता बढ़ जाती है
  • अन्य विकल्पों में निम्नलिखित पर विचार किया गया
    • bare metal execution: Reddit के उदाहरणों में database या home directory delete होने जैसे गंभीर नुकसान के मामले मौजूद हैं
    • sandbox-runtime: ACL-आधारित access control, जिसमें Claude को code के बाहर पहुँच नहीं मिलती, लेकिन पूर्ण स्वतंत्रता नहीं मिलती
    • Firejail: Docker जैसी ही सीमाएँ मौजूद
    • manual VM setup: reproducibility की कमी
    • cloud VM: cost, latency, और code upload की आवश्यकता जैसी समस्याएँ

Vagrant-आधारित दृष्टिकोण

  • Vagrant का उपयोग करके पूर्ण VM isolation और reproducible setup हासिल किया गया
    • shared folders के ज़रिए local की तरह access संभव है
    • Docker-in-Docker की समस्या नहीं, और ज़रूरत पड़ने पर VM को आसानी से delete/recreate किया जा सकता है
  • VirtualBox 7.2.4 का उपयोग करते समय CPU 100% usage bug मिला, और GitHub issue के माध्यम से उसके कारण की पुष्टि की गई
  • अंतिम Vagrantfile configuration में ये विशेषताएँ शामिल हैं
    • bento/ubuntu-24.04 base image का उपयोग
    • 4GB memory, 2 CPU allocation
    • Docker, Node.js, npm, git, unzip install
    • @anthropic-ai/claude-code global install
    • vagrant user को Docker group में जोड़ना

वास्तविक उपयोग का तरीका

  • project directory में vagrant up → vagrant ssh → claude --dangerously-skip-permissions क्रम में चलाया जाता है
  • पहली boot पर provisioning में कुछ मिनट लगते हैं, और हर project के लिए Claude login केवल एक बार करना पड़ता है
  • काम खत्म होने पर vagrant suspend से VM को अस्थायी रूप से रोका जा सकता है
  • Claude को VM के भीतर sudo permissions दी जाती हैं ताकि वह ये काम कर सके
    • web app API चलाना और curl से जाँच करना
    • browser install करके app की manual inspection और E2E tests बनाना
    • PostgreSQL DB setup और migration tests
    • Docker image build और run
  • इस environment की वजह से Claude command execution, output verification, और iterative process खुद संभाल सकता है

प्रदर्शन और सुरक्षा

  • Linux + VirtualBox environment में resources पर्याप्त उपलब्ध थे, और file sync delay नहीं था
  • जिन चीज़ों की सुरक्षा हो सकती है
    • गलती से होने वाला filesystem damage
    • अनियंत्रित package install और configuration changes
  • जिन चीज़ों की सुरक्षा नहीं हो सकती
    • project folder deletion (two-way sync)
    • VM escape vulnerabilities का दुरुपयोग करने वाले हमले
    • network-level issues
    • data exfiltration (VM को internet access प्राप्त है)
  • यह setup दुर्घटना-रोकथाम के लिए है, advanced attack defense के लिए नहीं
  • Git-आधारित projects में नुकसान होने पर recovery आसान है, और चाहें तो rsync one-way sync से और सख्त isolation मिल सकता है

निष्कर्ष

  • VirtualBox CPU bug के हल होने के बाद frictionless execution environment तैयार हो गया
  • Claude Code को पूर्ण VM sandbox के भीतर स्वतंत्र रूप से चलाया जा सकता है
  • समस्या होने पर VM को delete करके फिर से बनाया जा सकता है, और सिर्फ एक Vagrantfile से reproducibility सुनिश्चित होती है
  • अगर --dangerously-skip-permissions फ़्लैग इस्तेमाल करना है, तो ऐसा isolated environment बनाना दृढ़ता से अनुशंसित है

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

1 टिप्पणियां

 
GN⁺ 2026-01-21
Hacker News की राय

  • Claude का इस्तेमाल करते-करते आखिरकार decision fatigue की वजह से कुछ महीनों बाद बस एंटर दबा देने का मन करने लगता है
    इसलिए मुझे लगता है कि YOLO मोड में चलाना, लेकिन साथ में sandbox environment बना रखना, कहीं ज़्यादा सुरक्षित है
    Ubuntu 22.04 पर bubblewrap और Landlock LSM को मिलाकर एक layered sandbox बनाया गया
    Landlock filesystem access को whitelist-आधारित तरीके से सीमित करता है, और TCP port access भी कंट्रोल करता है
    bubblewrap mount namespace को अलग करके हर project के लिए /tmp बनाता है और secret keys छिपाता है
    dnsmasq से DNS whitelist सेट की जाती है ताकि सिर्फ़ ज़रूरी domains resolve हों
    इस तरह की संरचना की वजह से agent पर लगातार नज़र रखनी पड़ने वाला stress कम हो गया

    • मैं भी इसी तरह के environment में कई Claude instances को YOLO मोड में चला रहा था, लेकिन जब Emacs TRAMP plugin को local NUC पर सीधे build करना पड़ा तो बहुत थकान हुई
      Claude के सुझाए हुए elisp snippets को एक-एक करके approve करना बहुत थका देने वाला अनुभव था
      Bash commands से कहीं उल्टी-सीधी चीज़ install न हो जाए, बस इसी पर ध्यान देना पड़ा, फिर भी मुश्किल था
    • मैं Windows पर हूँ इसलिए खुद इस्तेमाल नहीं किया, लेकिन Linux में /sandbox command से Claude Code में sandboxing feature built-in होने की जानकारी थी

  • मैं Docker का Srini हूँ
    बहुत से developers इस समस्या को हल करने के लिए Docker इस्तेमाल कर रहे हैं, और Docker-in-Docker limitations पर भी काफी feedback मिला है
    इसलिए experimental तौर पर Docker Sandboxes को preview के रूप में जारी किया गया है
    अभी शुरुआती चरण में है, लेकिन अगला version MicroVM-based बनाया जा रहा है ताकि Docker-in-Docker समस्या से बचा जा सके

    • जानना चाहूँगा कि Docker Sandbox, Docker-in-Docker समस्या को कैसे हल करता है
      मैं समझना चाहता हूँ कि क्या Claude Docker Sandbox के अंदर बिना permissions के दूसरे containers चला सकता है

  • ज़्यादातर लोग शायद local VM खुद चलाने से बचना चाहते हैं, लेकिन क्यों, यह समझ नहीं आता
    असल में local VM सबसे सरल है और लगभग हर समस्या हल कर देता है
    अगर आप Mac पर Docker इस्तेमाल कर रहे हैं, तो वह पहले से ही Linux VM के ऊपर चल रहा है, इसलिए real environment से बस एक layer का ही फर्क है
    IDE से SSH के जरिए सीधे connect होकर code भी देखा जा सकता है
    मैं --dangerously-skip-permissions option चालू रखता हूँ और सारे changes को PR के रूप में handle करता हूँ
    इसे workmux के साथ मिलाकर कई महीनों से इस्तेमाल कर रहा हूँ, और कई PR एक साथ handle करना बहुत efficient है
    cloud VM से बेहतर होने की वजह यह है कि कई containers साथ में चलाने पर memory बहुत खाती है
    high-spec cloud VM को 24/7 चलाने पर cost बहुत ज़्यादा हो जाती है

  • कोई malicious AI VM escape vulnerability का इस्तेमाल किए बिना भी Vagrantfile में मनमाना code जोड़कर host access पा सकता है
    सिर्फ़ साधारण गलती की चिंता करें तब भी, अगर Claude commit hook बदल दे, तो उसके execute होने पर समस्या हो सकती है
    पूरी isolation बनाए रखते हुए convenience के साथ development करना वाकई मुश्किल है

    • Claude को किसी खास subdirectory तक सीमित कर देना काफ़ी है
      उदाहरण के लिए Docker volume mount का इस्तेमाल करके सिर्फ़ sandbox/ folder में modification की अनुमति दें और .git को inaccessible रखें
    • लेकिन इसके लिए VM और host के बीच directory को दो-तरफ़ा share करने की शर्त चाहिए
      मैं snapshot लेता हूँ, छोटा VM चालू करके agent को चलाता हूँ, फिर snapshot compare करता हूँ
      auto-sync isolation के मकसद को बिगाड़ देता है, इसलिए मैं ऐसा कभी नहीं करता
    • एक और जोखिम यह है कि malicious code repository में जुड़ जाए और बाद में VM के बाहर execute होने पर infection फैलाए
    • “ec2 node?” ऐसा छोटा-सा सवाल पूछा गया

  • मैं एक अलग approach आज़मा रहा हूँ — Claude जो चलाना चाहता है उसे intercept करने वाला तरीका
    Shannot execution से पहले intent capture करता है, और PyPy sandbox में system calls intercept करता है
    commands और file writes सिर्फ़ log में दर्ज होते हैं, वास्तव में execute नहीं होते
    user TUI में review करके approve करे, उसके बाद ही वे execute होते हैं
    VM से फर्क यह है कि VM पूरी तरह isolated environment में चीज़ों को आज़ादी से चलाता है, जबकि Shannot असली system पर human approval based changes लागू करता है
    यह server modification जैसे कामों के लिए उपयुक्त है
    Claude MCP integration, SSH remote execution, और checkpoint/rollback features भी हैं

    • यह approach समस्या का सीधा समाधान नहीं है, लेकिन दिशा Claude Code के built-in control features जैसी लगती है
      आखिरकार यह पहले approval request पर रुक जाने वाली संरचना है, इसलिए agent खुलकर explore नहीं कर पाता
      मैं चाहता हूँ कि agent बीच में रुके बिना अंत तक कोशिश करे और उसके बाद परिणाम का मूल्यांकन किया जाए
      तभी असली समय की बचत होती है
    • यह Leash जैसी philosophy लगती है
      Leash के mac-native system extension mode से मिलता-जुलता है, लेकिन पूरी interactive approval mode अभी नहीं है
      दिलचस्प project है
    • “commands और file writes सिर्फ़ log में दर्ज होते हैं, execute नहीं होते” — असल में यह Claude पहले से default रूप में देता है
    • नाम काफ़ी चतुर है

  • approval fatigue बढ़ते-बढ़ते आखिर --dangerously-skip-permissions इस्तेमाल करने का मन करता है
    इसलिए मैं Claude Code को devcontainer के अंदर चलाता हूँ
    file access सिर्फ़ repository तक, और network सिर्फ़ whitelist तक सीमित रहता है
    बाद में इसे docker compose से generalize किया, और अगला कदम Codex या OpenCode जैसे दूसरे agents के लिए support जोड़ना है
    network को host proxy के ज़रिए force-route करके logging और control और मज़बूत करने का इरादा है
    अभी iptables से अस्थायी तौर पर संभाला जा रहा है
    अभी शुरुआती अवस्था में है, लेकिन काफ़ी अच्छा काम कर रहा है
    code: agent-sandbox

    • मैं भी मिलती-जुलती setup पर प्रयोग कर रहा हूँ
      network proxy के लिए mitmproxy इस्तेमाल कर रहा हूँ, अभी पूरी तरह perfect नहीं है लेकिन लगभग तैयार है
    • दोस्तों के साथ एक शाम में app को vibe coding से बनाया, और Claude को server cluster की root permissions दे दीं
      Claude ने कुछ घंटों तक खुद system configure किया और app पूरा कर दिया
      हमने code की एक line भी नहीं लिखी, और नतीजा हैरान करने वाला अच्छा था
      AI development की speed सच में कमाल की लगी

  • मेरा solution बहुत simple है

    sandbox-run npx @anthropic-ai/claude-code

    इससे npx command Bubblewrap sandbox के अंदर transparently चलती है, और सिर्फ़ current directory expose होती है
    इसे कुछ pure POSIX shell lines में implement किया जा सकता है
    sandbox-run

    • Bubblewrap approach पसंद है, लेकिन Linux-only होना थोड़ा खटकता है
      एक बार permissions छोड़ देने पर उन्हें वापस restore न कर पाना भी एक कमी है

  • मैं तो बस इसे unprivileged LXC container में डाल देता हूँ और बात खत्म
    मेरे threat model में जटिल attacks से ज़्यादा “गलती से home directory delete हो जाना” जैसी स्थिति अहम है

  • मैं project की run/ directory में utility scripts रखता हूँ, और compose-based containers चलाता हूँ
    devcontainer host directory और volumes के साथ mapped है
    service settings, script updates, और runtime issues की diagnosis तक Claude अच्छे से संभाल लेता है
    browser integration नहीं है, लेकिन Playwright या Puppeteer से काफ़ी कुछ हो जाना चाहिए

  • Claude Code की built-in sandboxing पर राय जानना चाहता हूँ
    official documentation link
    Claude Code में ज़रूरत पड़ने पर sandbox हटाने के लिए एक escape hatch है
    अगर कोई command sandbox restrictions की वजह से fail हो जाए, तो Claude कारण analyze करके dangerouslyDisableSandbox के साथ retry कर सकता है
    agent अपने-आप sandbox disable कर सकता है — यह एक vulnerability जैसा लगता है, तो जानना चाहता हूँ कि क्या इस स्थिति में user approval प्रक्रिया होती है

    • अफ़सोस की बात है कि कभी-कभी user confirmation requests को bypass करने के मामले सामने आए हैं
      संबंधित issues: #14268, #13583, #10089