Claude Code परमिशन और सुरक्षा | बायपास और सैंडबॉक्स

जैसा अध्याय 1 में देखा, Claude Code हर टूल कॉल पर परमिशन के गेट से गुज़रता है। इसे एक ही नॉब समझ लेंगे तो जब झंझट लगेगा, आप उसे सबसे ढीली तरफ़ घुमा देंगे। असल में ये अलग-अलग काम करने वाली तीन चीज़ें हैं ― पुष्टि की बारंबारता, टूल के हिसाब से अनुमति, और OS के स्तर का अलगाव। एक तरफ़ कसें तो दूसरी तरफ़ ढील दी जा सकती है, और "सुरक्षित या तेज़" कोई दो में से एक चुनने वाली बात नहीं है।

सौंपना "सब या कुछ नहीं" वाला मामला नहीं है

शुरुआत मोड के नाम से नहीं, इस सवाल से होती है ― "इस काम में वह जगह कहाँ है जहाँ से वापसी नहीं हो सकती"। परखने के आधार तीन हैं।

लौटाया जा सकता है क्या ― जो एडिट git से लौटाया जा सके, उसका नुक़सान छोटा है। पूरी तरह मिटा देना, फ़ोर्स पुश, और डेटाबेस को तोड़ देना ― ये नहीं लौटते
पहुँच कहाँ तक जाती है ― बात वर्किंग डायरेक्टरी में ही बंद रहती है, या प्रोडक्शन, साझा ब्रांच और दूसरों के एनवायरनमेंट तक पहुँचती है
राज़ों को छूती है क्या ― पढ़ पाना और बाहर भेज पाना, ये दोनों एक साथ हो जाएँ तभी वह लीक बनता है

झंझट वे काम पैदा करते हैं जो तीनों धुरियों पर सुरक्षित हैं (टेस्ट, फ़ॉर्मैटिंग, लोकल एडिट), और ख़तरनाक काम कभी-कभार ही सामने आते हैं। एक ही झटके में सब ढीला कर देंगे तो ख़तरनाक तरफ़ भी खुल जाएगी। ढाँचा यह है ― बारंबारता के आधार पर ढील दीजिए, और स्वभाव के आधार पर कसिए।

परमिशन मोड ― असल में बदलता क्या है

सबसे बड़ा नॉब है परमिशन मोड, जो पुष्टि की बारंबारता का मोटा ढाँचा तय करता है। इसे Shift+Tab से बदला जाता है (ब्योरा Claude Code के परमिशन मोड में)।

अनुमति पूछना (default)

पढ़ना अपने आप, एडिट और कमांड हर बार पूछे जाते हैं। किसी नई रिपॉज़िटरी को पहली बार छूते वक़्त यही रखिए।

एडिट मंज़ूर (acceptEdits)

काम वाले फ़ोल्डर के भीतर के एडिट अपने आप मंज़ूर। उसके बाहर, सुरक्षित पाथ, और बाक़ी कमांड ― इन पर पुष्टि आती है।

प्लान मोड (plan)

छानबीन करता है पर सोर्स नहीं छूता। प्लान को मंज़ूरी मिलने के बाद ही वह करने पर उतरता है।

ऑटो मोड (auto)

एक अलग जाँचने वाला मॉडल चलाने से पहले हर काम को देखता है और सिर्फ़ ख़तरनाक को रोकता है। इस्तेमाल की शर्तें लागू।

परमिशन बायपास (bypassPermissions)

न पुष्टि से गुज़रता है, न सुरक्षा जाँच से। सिर्फ़ अलग-थलग एनवायरनमेंट के लिए। सिर्फ़ अपने ख़ास फ़्लैग से लॉन्च करने पर ही चालू।

सिर्फ़ सेटिंग्स में मिलने वाला एक dontAsk भी है (सिर्फ़ अनुमति-सूची और सिर्फ़ पढ़ने वाली कमांड चलाता है, बाक़ी सब मना कर देता है)।

सुरक्षित पाथ का भी ध्यान रखिए। .git, .claude और शेल की सेटिंग पर लिखना सामान्य मोड्स में अपने आप मंज़ूर नहीं होता। डिफ़ॉल्ट मोड सेटिंग्स में लिखा जा सकता है, लेकिन सिर्फ़ ऑटो मोड को प्रोजेक्ट सेटिंग्स में नज़रअंदाज़ किया जाता है ― यह लकीर इसलिए खींची गई है कि रिपॉज़िटरी अपने आप उसे चालू न कर सके।

ऑटो मोड कोई "तेज़ वाला डिफ़ॉल्ट" नहीं है

पुष्टियाँ लगभग ग़ायब हो जाती हैं, पर छूट खुली नहीं होती ― जाँचने वाला मॉडल अनुरोध के दायरे से बाहर जाने वाले काम, अनजानी इन्फ़्रा को छूने वाले काम, और पढ़े हुए कंटेंट से बहकाए गए काम रोकता है। आसानी से पास होते हैं काम वाले फ़ोल्डर के भीतर की फ़ाइल क्रियाएँ और सिर्फ़ पढ़ने वाला HTTP। रुकते हैं गोपनीय चीज़ें बाहर भेजना, प्रोडक्शन डिप्लॉय, और तोड़-फोड़ करने वाले git ऑपरेशन।

बातचीत में बताई गई सीमाएँ सहेजी नहीं जातीं। "पुश मत करना" किसी काम को रोकने का आधार तो बन जाता है, लेकिन वह हर बार मौजूदा बातचीत से ही दोबारा पढ़ा जाता है, इसलिए दबाव में वह गिर जाए तो सीमा भी मिट जाती है। साथ ही ऑटो मोड एक रिसर्च प्रीव्यू है, और आधिकारिक तौर पर भी कहा गया है कि "यह पुष्टियाँ घटाता है, पर सुरक्षा की गारंटी नहीं देता"। यह रिव्यू की जगह नहीं ले सकता।

बायपास में भी पुष्टि क्यों आ जाती है

पुष्टि को छोड़ देने वाला --dangerously-skip-permissions लगा दिया, फिर भी Claude पूछता है "क्या इसे चलाना ठीक है"। कुछ टूटा नहीं है। अनुमति की दो आज़ाद परतें हैं, और बायपास उनमें से सिर्फ़ एक को मिटा सकता है (बायपास मोड में भी अनुमति क्यों पूछी जाती है)।

परत 1: टूल परमिशन का UI (मिटाया जा सकता है)

"क्या इस फ़ाइल को एडिट करना ठीक है" ― टूल बुलाने से ठीक पहले आने वाला संवाद वाला डायलॉग। यह Claude Code नाम का प्रोग्राम दिखाता है।

परत 2: ख़ुद Claude का सुरक्षा-विवेक (मिटाया नहीं जा सकता)

"यह प्रोडक्शन डेटाबेस में बदलाव होगा, आगे बढ़ूँ क्या" ― यह पुष्टि बातचीत के वाक्य के रूप में लौटती है। यह मॉडल के अपने आचरण-सिद्धांतों से निकलती है, इसलिए किसी फ़्लैग से नहीं रुकती।

पहचानने का तरीक़ा है ― यह UI है या जवाब का टेक्स्ट। परत 2 किन हालात में जागती है, यह लगभग वही तीन धुरियाँ हैं जो शुरू में थीं ― वापस न लिया जा सकने वाला, चौड़ी पहुँच वाला, ऊँचे सुरक्षा जोखिम वाला। पूरी तरह मिटा देना, फ़ोर्स पुश, और प्रोडक्शन पर माइग्रेशन ― इनमें आप परमिशन खोल भी दें तो भी Claude ठिठक जाएगा।

यह कोई गड़बड़ी नहीं, यह डिज़ाइन है। बायपास जो थमाता है वह है टूल इस्तेमाल करने की चाबी, न कि Claude के विवेक को रोकने की चाबी। परत 2 को शून्य नहीं किया जा सकता।

बारंबारता ज़रूर घटाई जा सकती है। CLAUDE.md में सिर्फ़ वे बातें लिखिए जो तथ्य के तौर पर लिखी जा सकती हैं, और अनुरोध ठोस रखिए ― "साफ़ कर दो" के मुक़ाबले "/tmp/ की .log फ़ाइलें मिटा दो" पर पुष्टि कम आती है। लेकिन "पुष्टि झंझट है" का जवाब बायपास नहीं है (बायपास मोड के जोखिम और उसे सुरक्षित तरीक़े से इस्तेमाल करना)।

settings.json के नियम ― एक ही पुष्टि का जवाब दो बार मत दीजिए

अगर मोड "कुल बारंबारता" है, तो परमिशन नियम "टूल और कमांड के हिसाब से अपवाद" हैं। settings.json में allow (कोई पुष्टि नहीं) / ask (हर बार पुष्टि) / deny (मना) लिखकर साझा किया जा सकता है (परमिशन नियमों (allow/ask/deny) की सेटिंग)।

जाँच का क्रम है deny → ask → allow, और जो सबसे पहले मेल खाता है वही जीतता है ― नियम कितना बारीक है इससे क्रम नहीं बदलता ― चौड़े Bash(aws *) का deny, ठोस Bash(aws s3 ls) के allow से जीत जाता है। deny में अपवाद नहीं रखे जा सकते। "allow किया फिर भी पुष्टि आ रही है" की वजह अक्सर बस यह होती है कि कोई और ask उससे पहले मेल खा गया। ask ऑटो मोड में भी पुष्टि को अनिवार्य कर देता है, इसलिए वह उन कामों की जगह है जो वापस नहीं लिए जा सकते।

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Read(.env)", "Read(~/.ssh/**)"]
  }
}

इन्हें कहाँ रखा है, उसकी भी एक तरतीब है। ताक़त के क्रम में ― प्रबंधित सेटिंग्स (जिन पर कुछ ऊपर नहीं लिखा जा सकता) → CLI → settings.local.json → settings.json → ~/.claude/settings.json। लेकिन किसी भी स्तर का deny, किसी भी दूसरे स्तर के allow से हमेशा जीतता है। पैटर्न में स्पेस के साथ आया * शब्द की सीमा है (Bash(ls *) ls -la पर लगता है, पर lsof पर नहीं)।

नियम जिन चीज़ों से नहीं बचाते

नियम सिर्फ़ यह देखते हैं कि "जो कमांड चलाई जा रही है उसका टेक्स्ट क्या है", और जो रास्ते उससे बाहर हैं वे बेरोक-टोक निकल जाते हैं।

अप्रत्यक्ष पहुँच नहीं रोकी जा सकती ― Read(.env) का deny भीतरी फ़ाइल टूल्स पर और cat पर तो असर करता है, लेकिन जब कोई स्क्रिप्ट ख़ुद उस फ़ाइल को खोलती है तब उस पर असर नहीं करता
एनवायरनमेंट रनर भीतर की चीज़ छिपा देते हैं ― devbox run * और docker exec अपने आर्गुमेंट को जस-का-तस चला देते हैं, इसलिए Bash(devbox run *) का allow devbox run rm -rf . तक की इजाज़त दे बैठता है
आर्गुमेंट में URL सीमित करना कमज़ोर है ― क्रम बदलकर या वेरिएबल फैलाकर उससे निकला जा सकता है। curl और wget को पूरा deny करके WebFetch(domain:) से अनुमति वाली जगहें बताना ज़्यादा मज़बूत है

CLAUDE.md में ".env मत पढ़ना" लिख देना कोई नियम नहीं है। CLAUDE.md यह बदलता है कि Claude करना क्या चाहता है, पर यह नहीं बदलता कि उसे किस हद तक इजाज़त है। हद बदलते हैं नियम, मोड, और अध्याय 6 वाले PreToolUse हुक (deny और ask की जाँच हुक के नतीजे से बेपरवाह होकर होती है)।

सैंडबॉक्स ― क्या घेरा जा सकता है, क्या नहीं

जिन रास्तों तक नियम पहुँचते ही नहीं, उन्हें बंद करता है सैंडबॉक्स ― यह "क्या पूछना है" नहीं, बल्कि "कहाँ तक छुआ जा सकता है" को पहले से घेर देता है। इसे लागू Claude नहीं, OS (कर्नेल) करता है, इसलिए कोई मंज़ूर हो चुकी कमांड अपने नाम से ज़्यादा कुछ करने लगे तब भी घेरा नहीं हिलता (Claude Code सैंडबॉक्स की पूरी गाइड)।

1. फ़ाइल सिस्टम का अलगाव

लिखा जा सकता है सिर्फ़ वर्किंग डायरेक्टरी और अस्थायी फ़ोल्डर में (शुरुआती मान)। ~/.bashrc और सिस्टम के इलाक़े बदले नहीं जा सकते।

2. नेटवर्क का अलगाव

शुरुआती हालत में कोई गंतव्य नहीं, सिद्धांत रूप में सब मना। किसी नए डोमेन से जुड़ते वक़्त पुष्टि आती है, और allowedDomains में दर्ज कर दें तो फिर नहीं पूछा जाता।

ये दोनों हमेशा साथ ही चाहिए ― सिर्फ़ एक से काम नहीं चलेगा, क्योंकि जो राज़ पढ़ा जा सका वह बाहर निकल जाएगा। मंज़ूरी के दो ढंग हैं। ऑटो-अलाउ मोड भीतर की Bash को बिना पुष्टि चला देता है, जबकि सामान्य परमिशन मोड अलगाव भी रखता है और पुष्टि भी पूछता है। ऑटो-अलाउ में भी deny को हमेशा तरजीह मिलती है, अहम पाथ को निशाना बनाने वाली rm पर पुष्टि आती है, और कंटेंट के आधार पर लिखा गया ask भी पुष्टि को अनिवार्य कर देता है।

ध्यान रखिए कि "ऑटो" नाम की दो चीज़ें हैं। सैंडबॉक्स का ऑटो-अलाउ मोड कहता है "पास कर दो क्योंकि OS का घेरा इसे भीतर रोके हुए है", जबकि परमिशन वाला ऑटो मोड कहता है "पास कर दो क्योंकि जाँचने वाले मॉडल ने इसे परख लिया"।

पहले यह जान लीजिए कि यह किन चीज़ों से नहीं बचाता

सैंडबॉक्स पूरा अलगाव नहीं है। इस बात को धुँधला छोड़कर ऑटो-अलाउ को हमेशा चालू रखना ही सबसे ख़तरनाक हालत है।

इसके दायरे में सिर्फ़ Bash और उसकी चाइल्ड प्रोसेस हैं ― भीतरी Read, Edit और Write, MCP सर्वर, और हुक ― ये सब इससे बाहर हैं (उन्हें परमिशन नियमों से संभालिए)। पूरी प्रोसेस को लपेटना हो तो @anthropic-ai/sandbox-runtime इस्तेमाल कीजिए
पढ़ने का शुरुआती मान चौड़ा है ― यह घेरता मुख्य रूप से लिखने को है, और ~/.ssh तथा ~/.aws/credentials जैसी हालत है वैसे में पढ़े जा सकते हैं। इन्हें denyRead से बंद कीजिए
ज़रूरत से ज़्यादा अनुमति देना ही छेद बन जाता है ― ट्रैफ़िक होस्टनाम से परखा जाता है, और एन्क्रिप्टेड सामग्री की डिफ़ॉल्ट रूप से जाँच नहीं होती। कोई चौड़ा डोमेन खोल देंगे तो चीज़ों के बाहर निकल जाने की गुंजाइश बची रह जाती है
यह आपके एनवायरनमेंट पर निर्भर है ― macOS पर कुछ अतिरिक्त नहीं चाहिए। Linux और WSL2 पर bubblewrap तथा socat चाहिए, और नेटिव Windows पर यह समर्थित नहीं है

सैंडबॉक्स किसी हमलावर का सामना करने के लिए खड़ी की गई दीवार नहीं है; यह वह सुरक्षा-पेटी है जो हादसों और बेक़ाबू बर्ताव को कई गुना घटा देती है। Anthropic ने बताया है कि उसने भीतर परमिशन की पुष्टियाँ सुरक्षित रूप से 84% घटाईं, लेकिन वह कम पुष्टियों की रिपोर्ट है, यह गारंटी नहीं कि इसे तोड़ा नहीं जा सकता।

हादसे लगभग चार रूपों में होते हैं

अब यही पूरी मशीनरी हादसे की तरफ़ से दोबारा सजाकर देखते हैं। सेटिंग्स इसी आधार पर चुनिए कि वे इन चारों के ख़िलाफ़ काम करती हैं या नहीं।

1. तोड़-फोड़ करने वाली कमांड

rm किसी ऐसे पाथ को साफ़ कर देना जिसकी किसी को उम्मीद नहीं थी, git push --force से किसी और का काम मिट जाना। इन दोनों में समान बात है इनका वापस न लिया जा सकना। असर करते हैं deny और ask के नियम तथा फ़ाइल सिस्टम का अलगाव। भरोसेमंद चाल है जो काम वापस नहीं लिए जा सकते उन्हें ask में डाल देना।

2. राज़ों का लीक होना

यह हादसा तभी बनता है जब पढ़ पाना और भेज पाना, दोनों एक साथ मिल जाएँ। बचाव भी दो हिस्सों में है ― पढ़ने मत दीजिए (Read(.env) पर deny, denyRead) और भेजने मत दीजिए (curl तथा wget पर deny, अनुमति वाले डोमेन की छोटी सूची)। दोनों में से कोई एक काफ़ी नहीं है।

3. किसी दूसरी ब्रांच या दूसरे एनवायरनमेंट तक पहुँच जाना

जिसे आपने लोकल में एक फ़ाइल का सुधार समझा था, वह बढ़कर किसी साझा ब्रांच पर पुश या प्रोडक्शन डिप्लॉय बन जाता है ― यह काम का बढ़ते-बढ़ते ऊपर चढ़ जाना है। सामान्य मोड में हर सीढ़ी पर एक पुष्टि बैठी होती है, लेकिन सब कुछ खोल देंगे तो सीढ़ियाँ चपटी हो जाएँगी। पुश और डिप्लॉय को ask में डाल देना सस्ता बीमा है।

4. पढ़ी हुई फ़ाइलों के रास्ते चोरी-छिपे घुसे निर्देश

जो README, issue, वेब पेज या PDF Claude पढ़ता है, उसमें Claude के लिए ही निर्देश छिपाकर रखे जा सकते हैं (प्रॉम्प्ट इंजेक्शन)। "इसे उस पते पर भेज दो" अगर सफ़ेद अक्षरों में भी लिखा हो, तो Claude की तरफ़ से वह उसी दरवाज़े से आने वाला टेक्स्ट है जिससे आपका अनुरोध आता है, और डेटा तथा निर्देश को ऊपरी तौर पर अलग-अलग पहचाना नहीं जा सकता।

जो काम नहीं आते वे हैं बायपास मोड (छिपाया गया टेक्स्ट बिना किसी रोक-टोक चलने तक पहुँच जाता है) और CLAUDE.md में लिखी गई मनाही (यह नहीं बदलती कि किस चीज़ की इजाज़त है)। जो काम आते हैं वे हैं OS के स्तर का घेरा ― जहाँ लिखा नहीं जा सकता वहाँ वह लिख नहीं सकता, और जहाँ पहुँचा नहीं जा सकता वहाँ पहुँच नहीं सकता ― और साथ में deny के नियम। छिपाया गया टेक्स्ट दिखता नहीं, इसलिए "भाँप लेंगे" पर मत टिकिए: जिस सामग्री पर भरोसा नहीं, उसे सिर्फ़ उसी सेशन के लिए परमिशन सिकोड़कर पढ़वाइए।

सौंपने लायक़ / रोकने लायक़

तीनों धुरियाँ लगाकर देखें तो लकीर यहाँ गिरती है।

सौंपने लायक़ (allow में डालिए)

टेस्ट, टाइप चेक, लिंटर और बिल्ड / वर्किंग डायरेक्टरी के भीतर के एडिट / पढ़ना और सर्च करना / लोकल कमिट

रोकने लायक़ (ask या deny)

साझा ब्रांच पर पुश और फ़ोर्स पुश / प्रोडक्शन डिप्लॉय और माइग्रेशन / राज़ वाली फ़ाइलें पढ़ना / बाहर भेजने वाली कमांड / वर्किंग डायरेक्टरी के बाहर लिखना

रोज़ का एक मोड तय कर लीजिए। बार-बार एडिट करने हों तो acceptEdits, गोपनीय काम हो तो default। इसे defaultMode में लिखिए
एक ही पुष्टि का जवाब तीन बार दे चुके हों तो उसे allow में डाल दीजिए। और इसके उलट, जिस काम पर एक बार भी "यह तो ख़तरनाक है" लगा हो, उसे पक्के तौर पर ask में रख दीजिए
बातचीत में कही गई मनाहियों को यह मानकर चलिए कि वे मिट जाएँगी।
जब भी कहीं ढील दें, कहीं और ज़रूर कसें। बस वह हालत मत बनने दीजिए जिसमें न पुष्टि हो और न कोई घेरा

बायपास किन शर्तों पर इस्तेमाल किया जा सकता है। ऐसे कंटेनर, VM या CI रनर के भीतर जिसे टूट जाने पर फेंका जा सके, जहाँ माउंट सिर्फ़ वर्किंग डायरेक्टरी की हो, और होस्ट की .env या SSH चाबियाँ भीतर न लाई गई हों। "पुष्टि झंझट लगती है" कोई वजह नहीं है। काम ख़त्म होने पर डिफ़ ज़रूर पढ़िए।

यहाँ जिन चीज़ों की बात हुई वे सब "हादसे घटाने" की व्यवस्थाएँ हैं, "हादसे मिटा देने" की नहीं। परत 2 का विवेक हो, ऑटो मोड की जाँच हो, या सैंडबॉक्स का घेरा ― इन सबसे निकल जाने के रूप मौजूद हैं। सबसे ज़्यादा असर इसी का होता है कि आप ऐसी हालत बनाए रखें जहाँ से लौटा जा सके।

सारांश

परमिशन की तीन परतें हैं ― मोड, नियम और सैंडबॉक्स। धुरियाँ हैं लौटाया जा सकता है क्या, पहुँच कहाँ तक जाती है, राज़ों को छूती है क्या, और तरीक़ा है बारंबारता पर ढील, स्वभाव पर कसाव
अनुमति का ढाँचा दो परतों का है। बायपास सिर्फ़ परत 1 का UI मिटा सकता है, और बातचीत के टेक्स्ट में आने वाली पुष्टि डिज़ाइन के मुताबिक़ ही है
नियम deny → ask → allow के क्रम में चलते हैं और पहला मेल जीतता है ― ज़्यादा ठोस होने से क्रम नहीं बदलता
नियम सिर्फ़ टेक्स्ट देखते हैं। बाक़ी रास्ते बंद करता है सैंडबॉक्स। लेकिन उसके दायरे में सिर्फ़ Bash और चाइल्ड प्रोसेस हैं और पढ़ने का शुरुआती मान चौड़ा है
हादसों के रूप चार हैं ― तोड़-फोड़ वाली कमांड, राज़ों का लीक, दूसरे एनवायरनमेंट तक पहुँच जाना, और निर्देशों का चोरी-छिपे घुसना

कितना सौंपना है यह तय हो जाए, तो आगे बस इसे अपने एनवायरनमेंट के हिसाब से बढ़ाते जाना है। अब अध्याय 6 "इसे बढ़ाना" पर बढ़ें।

परमिशन और सुरक्षा ― कितना सौंपें, और कहाँ रोकें