विषय-सूची

Claude Code को काफ़ी समय तक इस्तेमाल करें तो आप इस दुविधा में फँस जाते हैं। यह हर कमांड पर "क्या मैं इसे चलाऊँ?" पूछता है, और आपका प्रवाह बार-बार रुकता रहता है। लेकिन --dangerously-skip-permissions (bypass permissions) से सारे प्रॉम्प्ट बंद कर देने का मतलब है कि कोई prompt injection या हाथ की चूक आपकी मशीन भर की फ़ाइलों को छू सकती है। सुरक्षा बनाम स्वचालन — इसे लंबे समय से एक अदला-बदली माना जाता रहा है।

इस दो-टूक विकल्प को तोड़ती है sandbox। अगर आप पहले से ही OS स्तर पर "क्या-क्या छुआ जा सकता है" की बाड़ लगा दें, तो कमांड बाड़ के भीतर बिना प्रॉम्प्ट के स्वतंत्र रूप से चल सकते हैं, फिर भी कोई भी चीज़ उसके बाहर नहीं पहुँच सकती। यह लेख एक व्यवहारकर्ता के नज़रिए से बताता है कि Claude Code का sandbox किसे और कैसे अलग करता है, /sandbox से कैसे शुरू करें, settings.json में इसे कैसे कॉन्फ़िगर करें, यह permission मोड से कैसे अलग है, और वे सीमाएँ जिन पर आपको हद से ज़्यादा भरोसा नहीं करना चाहिए।

30 सेकंड में निचोड़

अगर आप सिर्फ़ एक चीज़ पढ़ें

यह क्या है
एक तंत्र जो किसी कमांड के छू सकने वाली फ़ाइलों और नेटवर्क की, OS स्तर पर बाड़ लगाता है। भीतर स्वतंत्रता, बाहर पूरी तरह वर्जित।
यह क्यों मददगार है
यह प्रॉम्प्ट की थकान और पूर्ण बायपास के बीच के चुनाव को ही ख़त्म कर देता है। आप सुरक्षित रहते हुए प्रॉम्प्ट को तेज़ी से घटा देते हैं।
कहाँ से शुरू करें
/sandbox चलाएँ। macOS पर यह सीधे काम करता है; Linux/WSL2 को दो पैकेज चाहिए।

※Anthropic के अपने आंतरिक उपयोग में, sandbox ने permission प्रॉम्प्ट को सुरक्षित रूप से 84% घटाया (स्रोत नीचे)।

1. आपको sandbox की ज़रूरत क्यों है

Claude Code एक ऐसा AI agent है जो वाकई काम करता है — टेस्ट चलाना, फ़ाइलें दोबारा लिखना। ठीक इसीलिए यह जोखिम भरे कमांड से पहले रुककर "क्या मैं इसे चलाऊँ?" पूछता है। सुरक्षा के लिहाज़ से यह सही है। पर जब एक दिन में दर्जनों प्रॉम्प्ट आते हैं, तो काम बिखर जाता है, और आख़िरकार आप बिना पढ़े ही Enter दबा देते हैं। यही है "permission की थकान"।

थका हुआ डेवलपर --dangerously-skip-permissions (यानी YOLO मोड) की ओर बढ़ता है, जो सारे प्रॉम्प्ट बंद कर देता है। यह आरामदेह है, और — जैसा नाम कहता है — ख़तरनाक। तीन ख़तरे एक साथ अपने दाँत दिखाते हैं।

💉 Prompt injection

अगर यह जिस वेब पेज या issue को पढ़ता है उसमें "~/.ssh भेजो" छिपा हो, तो आपकी निजी कुंजियाँ बिना किसी प्रॉम्प्ट के लीक हो सकती हैं।

🗑️ विनाशकारी चूकें

कोई जनरेट किया गया कमांड अनपेक्षित पथ को साफ़ कर देता है। बिना प्रॉम्प्ट के, प्रोजेक्ट के बाहर की फ़ाइलें भी ग़ायब हो सकती हैं।

📤 सप्लाई-चेन संदूषण

कोई दुर्भावनापूर्ण डिपेंडेंसी इंस्टॉल के समय डेटा बाहर भेज देती है। नेटवर्क पूरी तरह खुला हो, तो आप इसे रोक नहीं सकते।

sandbox का विचार सरल है: हर बार "मुझे किसकी पुष्टि करनी चाहिए?" पूछना बंद करो, और पहले से ही "यह कितनी दूर तक पहुँच सकता है?" की बाड़ लगा दो। यह बाड़ Claude के अपने निर्णय से नहीं, बल्कि OS (कर्नेल) द्वारा लागू होती है, इसलिए भले ही इसे हाईजैक कर लिया जाए, और भले ही कोई अनुमत कमांड अपने नाम से ज़्यादा काम करे, कुछ भी सीमा से बाहर नहीं निकलता। यही वजह है कि बाड़ के भीतर के कमांड बिना प्रॉम्प्ट के चलाना सुरक्षित है — थकान-बनाम-पूर्ण-बायपास की दो-टूक स्थिति ग़ायब हो जाती है। अपनी आधिकारिक इंजीनियरिंग पोस्ट "Making Claude Code more secure and autonomous with sandboxing" में Anthropic बताता है कि आंतरिक उपयोग में इसने permission प्रॉम्प्ट को सुरक्षित रूप से 84% घटाया (अक्टूबर 2025 में प्रकाशित)।

2. sandbox क्या है — दो अलगाव

Claude Code का sandbox Bash कमांड (और उनके द्वारा शुरू की गई हर चाइल्ड प्रोसेस) के इर्द-गिर्द दो सीमाएँ खींचता है। दोनों को एक जोड़ी के रूप में काम करना चाहिए — इनमें से अकेली कोई एक एक खाई छोड़ देती है (देखें §7)।

🗂️ ① फ़ाइलसिस्टम अलगाव

लेखन (writes) कार्यशील डायरेक्टरी और एक सेशन-टेम्प फ़ोल्डर तक सीमित हैं (डिफ़ॉल्ट रूप से)। ~/.bashrc और सिस्टम क्षेत्रों को बदला नहीं जा सकता। पठन (reads) व्यापक है पर इसे स्पष्ट रूप से मना किया जा सकता है। हाईजैक होने पर भी यह प्रोजेक्ट के बाहर की किसी भी चीज़ को दोबारा नहीं लिख सकता।

🌐 ② नेटवर्क अलगाव

डिफ़ॉल्ट रूप से यह "deny by default" है, जिसमें कोई गंतव्य अनुमत नहीं है। जैसे ही यह किसी नए डोमेन की कोशिश करता है, एक प्रॉम्प्ट आता है। ट्रैफ़िक sandbox के बाहर मौजूद एक प्रॉक्सी से होकर गुज़रता है और एक allowlist के मुक़ाबले परखा जाता है। यह रहस्यों को बाहर भेजे जाने से रोकता है।

असली बात यह है कि यह Claude के अच्छे व्यवहार पर निर्भर नहीं करता। सीमा को OS की अपनी सुरक्षा-मशीनरी लागू करती है — macOS अंतर्निहित Seatbelt का उपयोग करता है, Linux/WSL2 bubblewrap का। इसलिए वही सीमा किसी कमांड द्वारा बुलाई गई स्क्रिप्ट्स और ग्रैंडचाइल्ड प्रोसेस तक भी फैलती है। इसे मॉडल से एक विनम्र अनुरोध मानने के बजाय, जैसा AI guardrails होते हैं, इसे एक भौतिक दीवार समझें जो यांत्रिक रूप से टिकी रहती है।

💡 यह सिर्फ़ Bash की बाड़ लगाता है। sandbox Bash टूल और उसकी चाइल्ड प्रोसेस को लपेटता है। Claude का अंतर्निहित Read/Edit/Write, MCP सर्वर, और hooks एक अलग मामला हैं (permission नियमों द्वारा शासित)। पूरी प्रोसेस को अलग करने के लिए, नीचे वर्णित @anthropic-ai/sandbox-runtime पैकेज का उपयोग करें।

3. शुरुआत — /sandbox और समर्थित OS

sandbox Claude Code में अंतर्निहित है। किसी अतिरिक्त अकाउंट या टूल की ज़रूरत नहीं। किसी सेशन में चलाएँ:

/sandbox

तीन टैब वाला एक पैनल खुलता है। Mode (sandbox वाले कमांड कैसे स्वीकृत होते हैं — अगला खंड), Overrides (क्या sandbox के अंतर्गत विफल होने वाला कमांड बिना-sandbox चलने की ओर लौट सकता है), और Config (सुलझी हुई सेटिंग्स देखें)। Linux/WSL2 पर, अगर कोई ज़रूरी पैकेज ग़ायब हो, तो इसके बजाय एक Dependencies टैब दिखता है और बताता है कि क्या इंस्टॉल करना है।

प्रति OS पूर्वापेक्षाएँ

🍎 macOS

इंस्टॉल करने के लिए कुछ नहीं। यह अंतर्निहित Seatbelt का उपयोग करता है। /sandbox से इसे तुरंत सक्षम करें।

🐧 Linux / WSL2

दो पैकेज इंस्टॉल करें: bubblewrap और socat (जैसे apt-get install bubblewrap socat)।

🪟 नेटिव Windows

समर्थित नहीं। Claude Code को WSL2 के भीतर चलाएँ (WSL1 काम नहीं करेगा)।

Linux/WSL2 पर, bubblewrap (अविशेषाधिकार वाला sandboxing टूल जो फ़ाइलसिस्टम अलगाव लागू करता है) और socat (वह रिले जो ट्रैफ़िक को प्रॉक्सी तक भेजता है) इंस्टॉल करें।

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

⚠️ Ubuntu 24.04 और उसके बाद: डिफ़ॉल्ट AppArmor नीति bubblewrap को उन user namespaces बनाने से रोक सकती है जिनकी उसे ज़रूरत होती है। अगर sysctl kernel.apparmor_restrict_unprivileged_userns 1 लौटाए, तो bwrap के लिए एक AppArmor प्रोफ़ाइल जोड़कर इसे अनुमति दें (चरण आधिकारिक दस्तावेज़ में हैं)। अगर यह 0 लौटाए या कुंजी मौजूद न हो, तो कुछ करने की ज़रूरत नहीं। WSL2 के भीतर भी यही जाँचें।

सक्षम करने लायक एक सुविधाजनक चीज़ है seccomp filter (जो Unix-domain-socket ब्लॉकिंग जोड़ता है)। यह वैकल्पिक है; इसे npm install -g @anthropic-ai/sandbox-runtime से इंस्टॉल करें। /sandbox का Dependencies टैब ripgrep, bubblewrap, socat, और seccomp filter की स्थिति दिखाता है। पैकेज इंस्टॉल करने के बाद, Claude Code को पुनः शुरू करें और /sandbox फिर से खोलें (जाँच स्टार्टअप पर चलती है)।

4. दो मोड (auto-allow / regular)

Mode टैब यह चुनता है कि sandbox के भीतर के कमांड कैसे स्वीकृत होते हैं।

✅ Auto-allow मोड

sandbox के भीतर चलने वाले Bash कमांड अपने आप, बिना किसी प्रॉम्प्ट के अनुमत होते हैं — सीमा स्वयं ही प्रॉम्प्ट की जगह ले लेती है। रोज़मर्रा के काम के लिए आरामदेह। जो कमांड sandbox नहीं चला सकता (जैसे किसी ग़ैर-अनुमत होस्ट पर ट्रैफ़िक), वे नियमित permission प्रवाह की ओर लौट आते हैं और प्रॉम्प्ट करते हैं।

🔍 Regular permissions मोड

sandbox वाले होने पर भी, हर Bash कमांड नियमित permission प्रॉम्प्ट से गुज़रता है। ज़्यादा नियंत्रण, ज़्यादा स्वीकृतियाँ। उन सतर्क लोगों के लिए जो "अलगाव के साथ-साथ सामान्य प्रॉम्प्ट" चाहते हैं।

दोनों मोड में फ़ाइलसिस्टम और नेटवर्क सीमाएँ एक समान हैं; अंतर सिर्फ़ "auto-allow बनाम प्रॉम्प्ट" का है। ध्यान दें कि auto-allow मोड में भी ये सुरक्षा-वाल्व सक्रिय रहते हैं:

  • स्पष्ट deny नियम हमेशा वरीयता पाते हैं
  • /, आपकी होम डायरेक्टरी, या अन्य महत्वपूर्ण सिस्टम पथों को लक्ष्य करने वाले rm / rmdir फिर भी प्रॉम्प्ट करते हैं
  • Bash(git push *) जैसे सामग्री-केंद्रित ask नियम sandbox के भीतर भी प्रॉम्प्ट मजबूर करते हैं

दो भ्रामक रूप से मिलते-जुलते "auto" से सावधान। sandbox का auto-allow मोड, permission मोड के auto मोड से अलग है। पहला मतलब है "OS सीमा इसे सँभालती है इसलिए अपने आप स्वीकृत"; दूसरे का मतलब है "एक क्लासिफ़ायर कमांड की सुरक्षा परखता है और उसे गुज़रने देता है"। ये स्वतंत्र रूप से काम करते हैं और इन्हें मिलाया जा सकता है।

5. settings.json में इसे कॉन्फ़िगर करना

/sandbox पैनल में किए गए चुनाव प्रोजेक्ट की .claude/settings.local.json में लिखे जाते हैं (git में कमिट नहीं होती)। इसे सभी प्रोजेक्ट में हमेशा चालू रखने के लिए, अपनी यूज़र सेटिंग्स ~/.claude/settings.json में sandbox.enabled: true डालें। यह permission नियमों (allow/ask/deny) के समान settings.json परिवार में ही रहता है।

लेखन-लक्ष्य जोड़ें, पठन मना करें

डिफ़ॉल्ट रूप से आप केवल कार्यशील डायरेक्टरी और टेम्प फ़ोल्डर में लिख सकते हैं। अगर kubectl या terraform को कहीं और लिखने की ज़रूरत हो, तो allowWrite से पथ जोड़ें। इसके विपरीत, आप संवेदनशील फ़ोल्डरों के पठन को ब्लॉक कर सकते हैं।

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

ऊपर का उदाहरण पूरी होम डायरेक्टरी के पठन को मना करता है और साथ ही मौजूदा प्रोजेक्ट को अनुमति देता है (जब कॉन्फ़िग प्रोजेक्ट सेटिंग्स में रहता है तो . प्रोजेक्ट रूट में सुलझता है)। पथ OS स्तर पर लागू होते हैं, इसलिए वे npm और terraform जैसी चाइल्ड प्रोसेस पर भी बराबर लागू होते हैं।

क्रेडेंशियल्स की रक्षा करें

एक महत्वपूर्ण अड़चन: पठन के लिए डिफ़ॉल्ट "व्यापक रूप से अनुमत" है, इसलिए ~/.aws/credentials और ~/.ssh/ जैसे-हैं वैसे ही पठनीय हैं। समर्पित sandbox.credentials सेटिंग (एक अपेक्षाकृत हाल की सुविधा) उन फ़ाइलों को घोषित करती है जिनका पठन मना करना है और उन एनवायरनमेंट वेरिएबल्स को जिन्हें अनसेट करना है।

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

गंतव्य अनुमत करें

नेटवर्क शून्य गंतव्यों से शुरू होता है। कोई नया डोमेन पहली बार पहुँचने पर प्रॉम्प्ट करता है (लेखन के समय के हालिया संस्करणों में, एक बार स्वीकृत करने का मतलब है बाक़ी सेशन के लिए दोबारा प्रॉम्प्ट नहीं)। जिन होस्ट के बारे में आप नहीं पूछा जाना चाहते, उन्हें allowedDomains में पहले से पंजीकृत करें। संगठन-द्वारा-वितरित managed settings के साथ, आप प्रॉम्प्ट करने के बजाय allowlist के बाहर की हर चीज़ को अपने आप ब्लॉक भी कर सकते हैं।

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    }
  }
}

इसे संगठन-भर में अनिवार्य करने के लिए। managed settings में, sandbox.enabled: true के साथ-साथ, failIfUnavailable: true (अगर sandbox आरंभ न हो सके तो Claude Code को शुरू होने से मना करें) और allowUnsandboxedCommands: false (sandbox के बाहर दोबारा कोशिश करने का "बचाव-रास्ता" बंद करें — सख़्त मोड) जोड़ें। मिलकर ये इसे एक सुरक्षा-द्वार के रूप में लागू करते हैं।

6. permission मोड और नियमों से संबंध

इन्हें आपस में मिला देना आसान है, पर Claude Code की सुरक्षा-मशीनरी में अलग-अलग काम वाली तीन परतें हैं। sandbox उनमें से एक है — यह बाक़ी दो की जगह नहीं लेता; यह उन्हें पूरक करता है।

परत यह क्या नियंत्रित करती है किसके द्वारा लागू दायरा
Permission नियम कौन-से टूल/कमांड इस्तेमाल हो सकते हैं Claude Code (चलने से पहले) सभी टूल
Permission मोड कितने प्रॉम्प्ट दिखते हैं Claude Code (चलने से पहले) मोड पर निर्भर
Sandbox चलने के बाद यह क्या छू सकता है OS (कर्नेल) Bash और चाइल्ड प्रोसेस

निर्णायक अंतर है "कब और किसके द्वारा" हर एक प्रभावी होता है। Permission नियम और मोड चलने से पहले, Claude Code द्वारा, कमांड स्ट्रिंग से तय होते हैं। sandbox प्रोसेस को चलने के दौरान, OS द्वारा बाँधता है — इसलिए मॉडल ने जो भी चुना हो, और भले ही कोई अनुमत कमांड अपने नाम से ज़्यादा करे, सीमा नहीं हिलती।

यही --dangerously-skip-permissions (bypass) से भी निर्णायक फ़र्क़ है। bypass सिर्फ़ प्रॉम्प्ट हटाता है; वातावरण पूरी तरह खुला रहता है। इसके विपरीत sandbox का auto-allow प्रॉम्प्ट इसलिए छोड़ सकता है क्योंकि OS की दीवार मौजूद है। पुराना लौह-नियम — अगर आप bypass मोड इस्तेमाल करें, तो सिर्फ़ किसी अलग किए गए container या VM के भीतर — sandbox आपको इसे अपनी रोज़मर्रा की मशीन पर भी सुरक्षित पक्ष की ओर सरका देने देता है।

7. सीमाएँ और सावधानियाँ — इस पर हद से ज़्यादा भरोसा न करें

sandbox शक्तिशाली है, पर यह पूर्ण अलगाव नहीं है। इसे एक कड़ी सुरक्षा-सीमा के रूप में सहारा बनाने से पहले, दस्तावेज़ में स्पष्ट बताई गई सीमाएँ जान लें।

🔓 TLS की डिफ़ॉल्ट रूप से जाँच नहीं होती

प्रॉक्सी केवल होस्टनेम पर परखता है और एन्क्रिप्टेड सामग्री की जाँच नहीं करता (डिफ़ॉल्ट रूप से)। github.com जैसे व्यापक डोमेन को अनुमति देना, domain fronting आदि के ज़रिए डेटा बाहर निकालने की गुंजाइश छोड़ देता है। allowlist को संकीर्ण रखें।

🔌 Unix सॉकेट खोलना जोखिम भरा है

/var/run/docker.sock की अनुमति Docker सॉकेट के ज़रिए पूरा होस्ट सौंप देती है — असल में एक sandbox escape। ध्यान रखें कि आप कौन-से सॉकेट खोलते हैं।

📈 हद से ज़्यादा व्यापक लेखन-पहुँच

$PATH पर लिखने-योग्य executables या .bashrc जैसी फ़ाइलें किसी और संदर्भ में कोड निष्पादन में बदल सकती हैं। allowWrite को न्यूनतम रखें।

एक और बात मन में बैठा लें: दायरा केवल Bash है — अंतर्निहित Read/Edit/Write, MCP सर्वर, और hooks अलग हैं। Skills और MCP सहित पूरी प्रोसेस को अलग करने के लिए, Claude Code प्रोसेस को स्वयं आधिकारिक ओपन-सोर्स @anthropic-ai/sandbox-runtime से लपेटें (GitHub और npm पर प्रकाशित, अक्टूबर 2025 में जारी एक research preview)। इसकी व्यावहारिक भूमिका किसी ठाने हुए हमलावर के ख़िलाफ़ "दीवार" नहीं, बल्कि एक "सुरक्षा-हार्नेस" है जो दुर्घटनाओं और बेक़ाबू स्थितियों को कई गुना घटा देता है।

8. dev container या VM कब चुनें

sandbox Claude Code का इकलौता अलगाव विकल्प नहीं है। सुविधा और अलगाव की मज़बूती के बीच अदला-बदली होती है, इसलिए उद्देश्य के हिसाब से चुनें।

Sandbox (अंतर्निहित)

Bash और चाइल्ड प्रोसेस को अलग करता है। कोई Docker नहीं, न्यूनतम सेटअप। रोज़मर्रा के काम में प्रॉम्प्ट घटाने का मुख्य आधार।

sandbox-runtime

पूरी Claude Code प्रोसेस को लपेटता है। ऐसे बिना-निगरानी रन के लिए जहाँ आप MCP और hooks को भी बाड़ में रखना चाहते हैं। कोई Docker नहीं।

dev container

पूरे विकास वातावरण को कंटेनराइज़ करता है। किसी टीम के सेटअप को मानकीकृत करने के लिए। Docker चाहिए।

VM (वर्चुअल मशीन)

पूरे OS को अलग करती है। अविश्वसनीय कोड के लिए सबसे मज़बूत, कर्नेल-स्तरीय अलगाव। सबसे ज़्यादा मेहनत।

अनुभव का नियम: रोज़मर्रा के प्रॉम्प्ट घटाने के लिए अंतर्निहित sandbox को हमेशा चालू रखें, और सिर्फ़ तभी बढ़ें sandbox-runtime, container, या VM की ओर जब आप बिना-निगरानी चलाएँ या अविश्वसनीय डिपेंडेंसी संभालें। उत्पादन तक पहुँचने वाले काम के लिए — जैसे AI को क्लाउड चलाने देना — न्यूनतम-विशेषाधिकार क्रेडेंशियल्स को एक मज़बूत अलगाव-स्तर के साथ जोड़ना मन को शांति देता है।

सारांश

  • sandbox OS स्तर पर "क्या-क्या छुआ जा सकता है" की बाड़ लगाता है, प्रॉम्प्ट की थकान बनाम पूर्ण बायपास की दो-टूक स्थिति को ख़त्म करते हुए।
  • फ़ाइलसिस्टम और नेटवर्क अलगाव को एक जोड़ी के रूप में इस्तेमाल करें। लागूकरण: macOS = Seatbelt, Linux/WSL2 = bubblewrap।
  • /sandbox से शुरू करें। macOS सीधे काम करता है; Linux/WSL2 को bubblewrap+socat चाहिए; नेटिव Windows समर्थित नहीं (WSL2 इस्तेमाल करें)।
  • Auto-allow मोड प्रॉम्प्ट छोड़ता है फिर भी सुरक्षित रहता है क्योंकि सीमा OS-द्वारा-लागू है। deny नियम, जोखिम भरे rm, और सामग्री-केंद्रित ask नियम फिर भी लागू होते हैं।
  • यह permission नियमों/मोड से अलग एक पूरक परत है — sandbox प्रोसेस को चलने के बाद, OS के ज़रिए बाँधता है, इसलिए यह नहीं हिलता।
  • पर यह पूरी दीवार नहीं है — बिना-जाँचे TLS, Unix सॉकेट, और हद से ज़्यादा व्यापक अनुमतियों का ध्यान रखें। दायरा केवल Bash है।

sandbox उसी बुनियादी धारणा को तोड़ देता है कि सुरक्षा और स्वचालन के बीच अदला-बदली करनी ही होगी। बस एक बार /sandbox खोलें — इतना भर ही बदल देता है कि आप Claude Code की बागडोर कैसे थामते हैं। सटीक, ताज़ा कॉन्फ़िगरेशन संदर्भ के लिए, आधिकारिक sandbox settings documentation को अपना प्राथमिक स्रोत मानें।

FAQ

Q. sandbox --dangerously-skip-permissions से कैसे अलग है?

A. bypass सिर्फ़ प्रॉम्प्ट हटाता है और वातावरण को असुरक्षित छोड़ देता है। sandbox OS स्तर पर छुई जा सकने वाली चीज़ों की बाड़ लगाता है, इसलिए प्रॉम्प्ट छोड़ने पर भी कुछ भी बाहर नहीं पहुँचता। bypass सिर्फ़ अलग किए गए वातावरणों के लिए है; sandbox आपकी रोज़मर्रा की मशीन पर भी सुरक्षित है — यही निर्णायक फ़र्क़ है।

Q. क्या मैं इसे Windows पर इस्तेमाल कर सकता हूँ?

A. नेटिव Windows समर्थित नहीं है। Claude Code को WSL2 के भीतर चलाएँ तो यह काम करता है (WSL1 नहीं चलेगा)। WSL2 के अंतर्गत, sandbox वाले कमांड cmd.exe जैसे Windows बाइनरी नहीं बुला सकते; ज़रूरत हो तो उन्हें excludedCommands में जोड़कर sandbox के बाहर चलाएँ।

Q. क्या इसे सक्षम करने से चीज़ें धीमी हो जाएँगी?

A. Anthropic के अनुसार, ओवरहेड न्यूनतम है — कुछ फ़ाइलसिस्टम ऑपरेशन थोड़े धीमे हो सकते हैं। व्यवहार में, चूँकि प्रॉम्प्ट की संख्या तेज़ी से गिरती है, महसूस होने वाली काम की गति अक्सर बढ़ जाती है।

Q. sandbox चालू होने पर, क्या मेरी निजी कुंजियाँ पक्के तौर पर सुरक्षित हैं?

A. "पक्के तौर पर" नहीं। पठन के लिए डिफ़ॉल्ट व्यापक है, इसलिए ~/.ssh और ~/.aws/credentials डिफ़ॉल्ट रूप से पठनीय हैं। इन्हें sandbox.credentials या denyRead से स्पष्ट रूप से ब्लॉक करें, और नेटवर्क allowlist को संकीर्ण रखें। फ़ाइलसिस्टम और नेटवर्क अलगाव को हमेशा एक जोड़ी के रूप में काम करना चाहिए।

Q. क्या MCP सर्वर और hooks भी sandbox में हैं?

A. नहीं। अंतर्निहित sandbox केवल Bash कमांड और चाइल्ड प्रोसेस को कवर करता है। MCP, hooks, और अंतर्निहित Read/Edit/Write अलग हैं (permission नियमों द्वारा शासित)। इन सबकी बाड़ लगाने के लिए, पूरी प्रोसेस को @anthropic-ai/sandbox-runtime से लपेटें।