Claude Code अनुमतियाँ: मोड, नियम और टीम सेटिंग्स

Claude Code में अनुमति नियम एजेंट रनटाइम द्वारा लागू किए जाते हैं, मॉडल द्वारा नहीं। यह अंतर जितना लगता है उससे अधिक मायने रखता है। आपके प्रॉम्प्ट या CLAUDE.md में निर्देश आकार देते हैं कि Claude क्या करने का प्रयास करता है, लेकिन वे नहीं बदलते कि Claude Code वास्तव में क्या अनुमति देता है, जैसा कि आधिकारिक अनुमति दस्तावेज स्पष्ट करता है। अनुमति देने या रद्द करने के लिए आप /permissions, नीचे वर्णित सेटिंग्स फाइलें, अनुमति मोड, या PreToolUse हुक का उपयोग करते हैं। यह पोस्ट हर स्तर को समझाती है: एक मोड चुनना, पूर्वता को समझना, कार्यशील नीति फाइल लिखना, इसका परीक्षण करना, और जानना कि पूरी प्रणाली आपकी कहाँ मदद नहीं कर सकती।

अनुमति मोड चुनें

आप जो मोड चुनते हैं वह बाकी सब कुछ के लिए आधारभूत निर्धारित करता है। पाँच हैं।

Manual Claude Code को अधिकांश फाइल संपादन, शेल कमांड, और नेटवर्क कॉल से पहले रोकता है। आप प्रत्येक की पुष्टि करते हैं। धीमा, लेकिन कुछ भी आपको आश्चर्य नहीं करता।

Auto एक वर्गीकरणकर्ता मॉडल को अनुमोदन सौंपता है जो आपकी ओर से कार्यों की समीक्षा करता है। Pro, Max, और Team योजनाओं पर यह अनुमति मोड दस्तावेज़ के अनुसार निर्मित प्रारंभिक मोड है। वर्गीकरणकर्ता के अपने नियम हैं कि कौन से कार्यों की यह समीक्षा करता है और कौन से को छोड़ता है, इसलिए auto "सब कुछ अनुमोदित करें" के समान नहीं है।

Accept Edits फाइल ऑपरेशन को स्वचालित रूप से अनुमोदित करता है लेकिन शेल कमांड के लिए अभी भी तत्पर करता है। एक कोडबेस पर एकल कार्य के लिए एक उचित मध्य मार्ग जिसे आप समझते हैं।

Plan फाइल संपादन और शेल लेखन को पूरी तरह से ब्लॉक करता है। Claude पढ़ सकता है, विचार कर सकता है, और एक योजना आउटपुट कर सकता है, लेकिन कार्य नहीं कर सकता। शुरुआती-चरण समीक्षाओं के लिए अच्छा जब आप कुछ भी बदलने से पहले दृष्टिकोण देखना चाहते हैं।

dontAsk आपकी स्पष्ट अनुमति सूची पर किसी भी उपकरण को स्वचालित रूप से अस्वीकार करता है। कोई तत्परता नहीं, बस निरंतर इनकार। यह CI/CD पाइपलाइनों के लिए सही मोड है जहाँ कोई नहीं देख रहा है।

bypassPermissions सभी जाँचों को छोड़ता है। Claude जो चाहे उसे निष्पादित करता है। सैंडबॉक्स किए गए अस्थायी वातावरण में उपयोगी; किसी उत्पादन रिपो के विरुद्ध चलाने वाली चीज़ नहीं।

VS Code में प्रारंभिक मोड को पिन करने के लिए, अपनी उपयोगकर्ता सेटिंग्स में claudeCode.initialPermissionMode को default, manual, acceptEdits, plan, या bypassPermissions में सेट करें। ध्यान दें: सेटिंग auto स्वीकार नहीं करती। Auto में शुरू करने के लिए, इसे अनसेट छोड़ दें और मोड संकेतक से एक बार इसे चुनें; एक्सटेंशन बाद की बातचीत के लिए उस पसंद को याद रखता है।

टर्मिनल सत्रों के लिए, ~/.claude/settings.json में या प्रबंधित सेटिंग्स में permissions.defaultMode सेट करें। यह मान Pro, Max, और Team योजनाओं पर लागू होता है जब सुविधा-झंडा प्रीक्षण उपलब्ध हो।

एक किनारे का मामला जो जानने लायक है: यदि आपकी संगठन ने claude.ai कनेक्टर उपकरण को ask में सेट किया है, तो उस उपकरण के लिए अनुमति नियम auto या bypassPermissions मोड में भी प्रभावी नहीं होते। Claude Code हर कॉल पर तत्पर करता है। dontAsk मोड में, यह तत्पर करने के बजाय कॉल को अस्वीकार करता है।

नियम और सेटिंग्स पूर्वता कैसे काम करती है

पाँच स्तर, ऊपर से नीचे का मूल्यांकन। एक उच्च स्तर जीतता है।

1. प्रबंधित सेटिंग्स (managed-settings.json): IT-तैनात, अपरिवर्तनीय। यदि आपकी संगठन यहाँ SSH को ब्लॉक करती है, तो यह अंतिम है।
2. स्थानीय सेटिंग्स (.claude/settings.local.json): प्रति-मशीन, डिफ़ॉल्ट रूप से gitignored। व्यक्तिगत या सुरक्षा-संवेदनशील ओवरराइड यहाँ जाते हैं।
3. प्रोजेक्ट सेटिंग्स (.claude/settings.json): रेपो में कमिट किए गए। उस प्रोजेक्ट के पूरे टीम के लिए साझा किए गए।
4. यूज़र सेटिंग्स (~/.claude/settings.json): ग्लोबल डिफ़ॉल्ट, हर प्रोजेक्ट पर लागू होते हैं जब तक कोई उच्चतर लेयर उन्हें ओवरराइड न करे।
5. सेशन फ़्लैग्स: --dangerously-skip-permissions और इसी तरह के रनटाइम आर्ग्यूमेंट्स।

admin setup documentation में दो लॉकडाउन कंट्रोल हैं जो जानने लायक हैं: allowManagedPermissionRulesOnly (मैनेज्ड सेटिंग्स को परमिशन रूल्स का एकमात्र स्रोत बनाता है, यूज़र और प्रोजेक्ट फ़ाइलों को अनदेखा करता है) और permissions.disableBypassPermissionsMode (बाइपास विकल्प को पूरी तरह हटा देता है)। अगर आप एजेंसी चला रहे हैं और कॉन्ट्रैक्टर क्लाइंट रेपो छू रहे हैं, ये दोनों सेटिंग्स मिलकर एक कठोर सीमा देती हैं जिसे कोई डेवलपर चुप्पी से पूर्ववत नहीं कर सकता।

हर लेयर तीन रूल टाइप स्वीकार करता है: allow, deny, और ask। एक लेयर के भीतर, deny को allow पर प्राथमिकता है। शेल-पैटर्न मैचिंग सपोर्ट की जाती है (उदाहरण के लिए Bash(git *)), लेकिन सटीक रहें: एक पैटर्न जो टेस्टिंग में वाटरटाइट दिखता है, अक्सर तब खामियां रखता है जब असली कमांड स्ट्रिंग्स वह नहीं होती जो आप उम्मीद करते हैं।

डॉक्स एक चीज़ स्पष्ट रूप से फ्लैग करते हैं: WebFetch को deny करने से Claude का fetch टूल ब्लॉक हो जाता है, लेकिन अगर Bash की अनुमति है, तो curl और wget अभी भी किसी भी URL तक पहुंच सकते हैं। सैंडबॉक्सिंग (/sandbox के जरिए) उस अंतराल को बंद करता है जिसमें एक डोमेन allowlist OS लेवल पर लागू की जाती है। परमिशन्स और सैंडबॉक्सिंग अलग-अलग लेयर्स को कवर करते हैं और किसी भी गंभीर चीज़ के लिए आप आमतौर पर दोनों चाहते हैं।

एक क्लाइंट-रेपोज़िटरी पॉलिसी उदाहरण

यहां एक क्लाइंट प्रोजेक्ट के लिए एक स्पष्टीकरणीय .claude/settings.json है जहां टीम बिल्ड्स चला सकती है और डेटाबेस पढ़ सकती है लेकिन डिप्लॉयमेंट स्क्रिप्ट्स या सीक्रेट्स को नहीं छूनी चाहिए। यह एक प्रतिनिधि संरचना है, कॉपी-पेस्ट प्रोडक्शन पॉलिसी नहीं।

{

"permissions": {

"defaultMode": "auto",

"allow": [

"Bash(npm run build)",

"Bash(npm run test*)",

"Bash(git log*)",

"Bash(git diff*)",

"Bash(git status)",

"Read(**)"

],

"deny": [

"Bash(rm -rf*)",

"Bash(git push*)",

"Bash(kubectl*)",

"Edit(.env*)",

"Edit(deploy/**)"

]

}

}

इसके साथ-साथ, हर डेवलपर की मशीन पर ~/.claude/settings.json व्यक्तिगत ग्लोबल ट्रस्ट को संभालता है, जैसे curl को सामान्य उपयोग के लिए अनुमति देना। संवेदनशील क्रेडेंशियल्स या मशीन-विशिष्ट पाथ .claude/settings.local.json में जाते हैं, जिसे git कमिट नहीं करेगा।

CLAUDE.md की ओर से, जहां आप एन्फोर्समेंट रूल्स के बजाय कन्वेंशन्स और प्रोजेक्ट कॉन्टेक्स्ट सेट करते हैं, agency guide to CLAUDE.md ऑथरिंग वर्कफ़्लो को विस्तार से कवर करता है।

पॉलिसी को यथार्थवादी कमांड्स के साथ टेस्ट करें

पॉलिसी को एक डिस्पोज़ेबल रेपोज़िटरी में रखें (एक बेयर git init एक टेम्प डायरेक्टरी में अच्छी तरह काम करता है), फिर कुछ कमांड्स चलाएं जो तीनों रूल कैटेगरीज़ का व्यायाम करें। लक्ष्य यह देखना है कि कौन से को प्रॉम्प्ट करते हैं, कौन से साइलेंटली एक्सीक्यूट होते हैं, और कौन से प्रॉम्प्ट के बिना डिनाई होते हैं।

एक प्रतिनिधि टेस्ट सीक्वेंस:

1. npm run build (ऑटो-अप्रूव होना चाहिए, यह allow लिस्ट में है)
2. git diff HEAD~1 (ऑटो-अप्रूव होना चाहिए)
3. git push origin main (डिनाई होना चाहिए)
4. rm -rf node_modules (डिनाई होना चाहिए)
5. deploy/ के अंदर एक फ़ाइल एडिट करें (डिनाई होना चाहिए)
6. src/index.js एडिट करें (कोई deny रूल नहीं, कोई explicit allow नहीं: व्यवहार मोड पर निर्भर है)
7. एक बाहरी URL के लिए curl कॉल (टेस्ट करें कि Bash allow रूल्स और sandbox कैसे इंटरैक्ट करते हैं)

विशेष रूप से केस 6 को देखें। auto मोड में क्लासिफायर इसकी समीक्षा करता है। dontAsk मोड में यह साइलेंटली डिनाई होता है क्योंकि यह allow लिस्ट पर नहीं है। वह अंतर डेवलपर्स को आश्चर्यचकित करेगा जो एक मोड में टेस्ट करते हैं और दूसरे में डिप्लॉय करते हैं।

अगर आप इसके ऊपर इवेंट-लेवल ऑटोमेशन जोड़ रहे हैं (फ़ाइल सेव्स पर लिंटर्स चलाना, विशिष्ट टूल कॉल्स पर नोटिफिकेशन्स ट्रिगर करना), वह एक hooks कंसर्न है, परमिशन्स नहीं। hooks guide PreToolUse और PostToolUse को पूरी तरह कवर करता है।

उन टीमों के लिए जो बिना निगरानी के चलने वाली या CI इंटीग्रेशन की जरूरत रखती हैं, Claude Code agency setup का उपयोग करके शुरुआत से ही कॉन्फ़िगरेशन बेसलाइन सही रखने पर विचार करें।

प्रबंधित सेटिंग्स और बिना निगरानी के जॉब्स

जब कोई इंसान "approve" बटन दबाने के लिए मौजूद नहीं होता, तो परमिशन मॉडल को पूरी तरह पहले से घोषित होना चाहिए। यह dontAsk मोड और प्रबंधित सेटिंग्स में एक स्पष्ट allow लिस्ट की ओर इशारा करता है।

एडमिन सेटअप डॉक्स आपको permissions.defaultMode को इस प्रबंधित कुंजी के रूप में देता है। इसे dontAsk पर सेट करें, फिर बिल्कुल यह निर्दिष्ट करें कि जॉब को permissions.allow में क्या चाहिए। जो कुछ भी सूचीबद्ध नहीं है वह चुप चाप अस्वीकृत हो जाता है। यही है जो आप एक पाइपलाइन में चाहते हैं।

कुछ चीजें जो आधिकारिक डॉक्स agent-team परिदृश्यों के लिए नोट करते हैं (जहां एक लीड सेशन टीममेट्स को शुरू करता है):

• टीममेट्स लीड की परमिशन सेटिंग्स के साथ शुरू होते हैं। अगर लीड --dangerously-skip-permissions के साथ चलता है, तो सभी टीममेट्स भी ऐसा करते हैं।
• आप स्पॉन करने के बाद व्यक्तिगत टीममेट मोड्स बदल सकते हैं, लेकिन स्पॉन करते समय नहीं।
• टीममेट परमिशन प्रॉम्प्ट्स लीड सेशन में सामने आते हैं। Plan approvals डिज़ाइन किया गया अपवाद हैं: लीड इन्हें बिना अलग प्रॉम्प्ट के मंजूरी देता है।

Managed Agents (प्लेटफॉर्म-स्तरीय ऑर्केस्ट्रेशन सेवा) वर्तमान में Managed Agents overview के अनुसार बीटा में है। बीटा फीचर्स के चारों ओर प्रोडक्शन पाइपलाइनों को बिना फॉलबैक के आर्किटेक्ट न करें।

permissions.disableAutoMode फ्लैग के लिए: इसे सेट करने से उस संगठन में डेवलपर्स के लिए auto mode एक विकल्प के रूप में हटा दिया जाता है। उपयोगी जब आप चाहते हैं कि सभी सेशन उस मोड में रहें जहां एक इंसान या एक स्पष्ट allow लिस्ट हर कॉल को बना रही है, किसी क्लासिफायर के बजाय।

परमिशन क्या गारंटी नहीं दे सकते

ईमानदार जवाब: बहुत कुछ।

Shell-pattern deny नियम सुरक्षा की सीमा नहीं हैं। वे Claude Code द्वारा बनाई गई कमांड स्ट्रिंग के विरुद्ध मेल खाते हैं, लेकिन पर्याप्त रूप से रचनात्मक प्रॉम्प्ट इंजेक्शन या शेल कमांड की चतुराई से की गई पुनः व्याख्या ऐसी स्ट्रिंग्स बना सकते हैं जो आपके पैटर्न नहीं पकड़ते। परमिशन डॉक्यूमेंटेशन स्पष्ट है: deny नियम और सैंडबॉक्सिंग विभिन्न परतों को कवर करते हैं। आपको दोनों की जरूरत है, और फिर भी आप जोखिम को कम कर रहे हैं, इसे खत्म नहीं कर रहे।

bypassPermissions मोड अनुमत कोड को हानिरहित नहीं बनाता। अगर Claude ऐसा कोड निष्पादित करता है जिसमें एक बग है या कुछ अप्रत्याशित करता है, तो परमिशन चेक्स को छोड़ना मतलब है कि "Claude ने इसे करने का फैसला किया" और "यह हुआ" के बीच कोई गेट नहीं था।

परमिशन यह भी नहीं जांचते कि Claude द्वारा लिखे या निष्पादित कोड के अंदर क्या है। एक निर्भरता जिसे यह स्थापित करता है, एक स्क्रिप्ट जो यह चलाता है, एक फाइल की सामग्री जो यह बनाता है: कोई भी परमिशन सिस्टम द्वारा निरीक्षण नहीं किया जाता। यह एक अलग चिंता है, रनटाइम नीति की तुलना में सप्लाई-चेन स्वच्छता के करीब।

और मॉडल ही प्रवर्तन परत नहीं है। आप CLAUDE.md निर्देश लिख सकते हैं जो कहते हैं "कभी प्रोडक्शन सीक्रेट्स को न छुएं।" वे निर्देश Claude के इरादे को आकार देते हैं। वे एक गलत कॉन्फ़िगर की गई allow नियम को ऐसा होने से नहीं रोकते। रनटाइम प्रवर्तन परत है। सेटिंग्स फाइलें यह हैं कि आप रनटाइम को कैसे कॉन्फ़िगर करते हैं। तदनुसार उनका व्यवहार करें।

FAQ

क्या परमिशन सेटिंग्स मशीनों में स्वचालित रूप से सिंक होती हैं?

नहीं। यूजर सेटिंग्स (~/.claude/settings.json) प्रत्येक मशीन के लिए स्थानीय हैं। प्रोजेक्ट सेटिंग्स (.claude/settings.json) git के माध्यम से सिंक होती हैं। प्रबंधित सेटिंग्स आपके IT इंफ्रास्ट्रक्चर द्वारा वितरित की जाती हैं। यूजर-स्तरीय फाइलों के लिए कोई बिल्ट-इन सिंक नहीं है; प्रत्येक डेवलपर को अपनी खुद की कॉन्फ़िगर करनी चाहिए।

क्या डेवलपर्स प्रबंधित सेटिंग्स को ओवरराइड कर सकते हैं?

केवल प्रबंधित सेटिंग्स द्वारा अनुमत सीमाओं के भीतर। यदि allowManagedPermissionRulesOnly सेट है, तो यूजर और प्रोजेक्ट परमिशन नियम पूरी तरह अनदेखे कर दिए जाते हैं। उस फ्लैग के बिना, यूजर और प्रोजेक्ट सेटिंग्स allow नियम जोड़ सकते हैं, लेकिन वे प्रबंधित deny को ओवरराइड नहीं कर सकते।

headless या CI वातावरण में परमिशन प्रॉम्प्ट्स का क्या होता है?

dontAsk मोड में, allow list में न होने वाली कोई भी चीज़ चुप्पे से अस्वीकृत हो जाती है। कोई prompt नहीं दिखता क्योंकि इसे दिखाने के लिए कोई terminal नहीं होता। यह जानबूझकर डिज़ाइन किया गया है। headless environment में auto मोड में, classifier अभी भी चलता है, लेकिन अगर वह prompt को resolve नहीं कर सकता (कोई TTY नहीं), तो behavior runner configuration पर निर्भर करता है। unattended jobs के लिए explicit allow list के साथ dontAsk का उपयोग करें।

क्या permission mode उसी तरह MCP tools पर लागू होता है जिस तरह built-in tools पर?

ज्यादातर, लेकिन अंतर के साथ। Claude Code द्वारा सीधे fetch किए गए MCP tools mcp__claude_ai_<server>__<tool> के रूप में दिखाई देते हैं। Allow और deny नियम इन्हें उस नाम से target कर सकते हैं। आपके organization द्वारा ask पर सेट किए गए connectors से tools हमेशा prompt करते हैं, mode के बावजूद, dontAsk mode के अपवाद के साथ, जहाँ उन्हें इसके बजाय अस्वीकृत कर दिया जाता है।

क्या `.claude/settings.json` को public repository में commit करना सुरक्षित है?

फाइल खुद बस tool names और patterns के साथ JSON है, कोई secrets नहीं। लेकिन एक public allow list किसी को भी आपके repo को पढ़ने वाले को बिल्कुल बता देता है कि Claude Code कौन से operations बिना prompt किए चलाएगा। open-source projects के लिए वह शायद ठीक है। कुछ भी proprietary के लिए, review करें कि आप क्या commit कर रहे हैं। Secrets और API keys कभी भी किसी भी settings file में नहीं होने चाहिए; वे Claude Code के config के बाहर environment variables में होने चाहिए।

सबसे मज़बूत बात यह है: deny rules और sandboxing अलग-अलग समस्याओं को solve करते हैं, और न ही एक दूसरे का substitute है। अगर आप Claude Code को किसी ऐसे environment में चला रहे हैं जहाँ एक mistake की cost real है, तो दोनों को set up करें।