अनुमतियाँ कॉन्फ़िगरेशन: कितना ढीला छोड़ना है, कितना कसना है, यह आप तय करते हैं

📚 श्रृंखला नेविगेशन: पिछला लेख 19 संदर्भ प्रबंधन आपको सिखाता है कि Claude के "कार्यक्षेत्र" (workspace) को कैसे प्रबंधित किया जाए और इसे अपनी मेमोरी (memory) भरने से कैसे रोका जाए। यह लेख एक अलग आयाम लेता है—यह प्रबंधित नहीं करता है कि "यह कितना याद रखता है", बल्कि "यह कितना छूने की हिम्मत करता है": एक पंक्ति (single line of command) के आदेश से लेकर आपके द्वारा पूछे जाने तक, पूरी तरह से स्वचालित (fully automatic) होने तक, यह आप पर निर्भर करता है कि आप अनुमतियों (permissions) की लगाम को कितनी कसकर पकड़ते हैं।

"तुम्हारी --dangerously-skip-permissions चालू करने की हिम्मत कैसे हुई? इस चीज़ के नाम में ही dangerous (खतरनाक) लिखा है।"

"मैं सैंडबॉक्स (sandbox) में हूँ, डर किस बात का? भले ही यह पूरी निर्देशिका (directory) को rm -rf कर दे, यह केवल एक डिस्पोजेबल कंटेनर (disposable container) को हटा रहा है, बस एक नया बनाएँ और यह वापस आ जाएगा।"

मैंने व्यक्तिगत रूप से इस संवाद के दोनों पक्ष लिए हैं: जब मैं क्लाउड में एक पृथक कंटेनर (isolated container) में बैच रिफैक्टरिंग (batch refactoring) चला रहा था, तो मैंने बिना किसी मनोवैज्ञानिक बोझ (psychological burden) के हटाए जाने और पुनरारंभ (restarting) के साथ, सबसे ढीले खतरे के मोड (danger mode) को चालू रखा; लेकिन जैसे ही मैं अपनी स्थानीय मशीन (local machine) पर वापस आया जिसमें टीम का वास्तविक कोड था, मुझे acceptEdits का उपयोग करने से पहले भी दो सेकंड के लिए सोचना पड़ा। सीधे शब्दों में कहें तो, अनुमतियों (permissions) के मामले में कोई "सही या गलत" नहीं है, केवल यह मायने रखता है कि "आप उनका उपयोग कहाँ करते हैं"। एक पृथक कंटेनर में सबसे ढीले खतरे के मोड (danger mode) को चालू करना एक "गति बढ़ाने वाला उपकरण" (speed booster) है, जबकि आपकी कंपनी के उत्पादन कोड (production code) वाली मशीन पर, यह एक "टाइम बम" (time bomb) है।

अध्याय 07 में हमने इसे थोड़ा अनुभव किया था—Claude फ़ाइल को संशोधित करने से पहले रुक जाएगा और आपसे पूछेगा। वह तो बस शुरुआत थी। आज हम पूरे सिस्टम को उजागर करेंगे: Claude Code में कौन से अनुमति मोड (permission modes) हैं, उनके बीच एक क्लिक (one click) से कैसे स्विच करें, और "यह किया जा सकता है, वह बिल्कुल निषिद्ध है" को सटीक रूप से निर्दिष्ट (specify) करने के लिए कॉन्फ़िगरेशन फ़ाइलों (configuration files) का उपयोग कैसे करें।

इस लेख को पढ़ने के बाद, आप जानेंगे:

• छह अनुमति मोड (permission modes) क्या हैं और उनका उपयोग किन परिदृश्यों (scenarios) में किया जाना चाहिए, इसे एक तालिका में स्पष्ट किया गया है
• मोड के बीच स्विच (switch) करने के लिए Shift+Tab की मांसपेशी स्मृति (muscle memory), और स्टार्टअप (startup) के दौरान सीधे मोड कैसे निर्दिष्ट (specify) करें
• टूल (tool) और कमांड (command) द्वारा सटीक अनुमति नियंत्रण (precise permission control) के लिए settings.json में allow / ask / deny नियम (rules) लिखने के लिए सिंटैक्स (syntax)
• दो कॉन्फ़िगरेशन टेम्पलेट (configuration templates) "टॉय प्रोजेक्ट्स (toy projects) के लिए आराम, उत्पादन प्रोजेक्ट्स (production projects) के लिए सख्त", प्रतिलिपि बनाएँ (copy) और उपयोग करें
• --dangerously-skip-permissions को चालू करने का साहस कब करें, और लाल रेखा (red line) कहाँ है

---

01 पहले समझें: अनुमति प्रणाली (permission system) क्या प्रबंधित कर रही है

सबसे पहले निष्कर्ष (conclusion): Claude Code डिफ़ॉल्ट रूप से एक "पहले पूछो, फिर काम करो" इंटर्न (intern) है, और अनुमति कॉन्फ़िगरेशन (permission configuration) वह "आचार संहिता" (code of conduct) है जो आप इस इंटर्न के लिए निर्धारित करते हैं।

यह सभी ऑपरेशनों को तीन श्रेणियों में विभाजित करता है, जिनके डिफ़ॉल्ट उपचार (default treatment) पूरी तरह से अलग हैं। आधिकारिक दस्तावेज़ (official documentation) में यह वर्गीकरण तालिका (classification table) वह आधार (foundation) है जिस पर बाकी सब कुछ बनाया गया है:

टूल का प्रकार (Tool Type)	उदाहरण (Example)	क्या डिफ़ॉल्ट रूप से अनुमोदन की आवश्यकता है (Require approval by default)
रीड-ओनली (Read-only)	फ़ाइलें पढ़ें, Grep खोजें	नहीं, सीधे जाने दें
Bash कमांड (Bash command)	शेल कमांड (shell commands) निष्पादित करें	हाँ
फ़ाइल संशोधन (File modification)	Edit / Write फ़ाइलें संशोधित करें	हाँ

तुलना: क्या इंटर्न (intern) काम शुरू करने से पहले आपसे पूछता है। एक विश्वसनीय इंटर्न, यदि आप उसे "इस कोड को देखने" के लिए कहते हैं, तो वह इसे आसानी से देखेगा (केवल-पढ़ने के लिए, शून्य जोखिम); लेकिन यदि वह "उत्पादन कॉन्फ़िगरेशन (production configuration) को बदलना" चाहता है या "डिलीट कमांड (delete command) चलाना" चाहता है, तो वह सामान्य रूप से देखेगा और आपसे पूछेगा "बॉस, क्या मैं इसे छू सकता हूँ?"। डिफ़ॉल्ट रूप से, Claude Code इसी तरह का व्यक्ति है—बेझिझक पढ़ें (read freely), लेकिन कार्य करने से पहले रिपोर्ट (report before acting) करें।

यहाँ एक महत्वपूर्ण समझ (key understanding) है, जहाँ मैं खुद ठोकर खा चुका हूँ: अनुमतियाँ (Permissions) Claude Code प्रोग्राम (program) द्वारा लागू (enforced) की जाती हैं, न कि "मॉडल (model) द्वारा सचेत रूप से" (consciously by the model)।

मैंने एक बार CLAUDE.md में विशेष रूप से लिखा था "git push निष्पादित न करें", यह सोचकर कि इसने इसे बंद कर दिया है, लेकिन एक बार इसने बिना किसी हिचकिचाहट के धक्का (push) दे दिया—क्योंकि CLAUDE.md केवल एक नरम संकेत (soft prompt) है जो "यह क्या करना चाहता है" को प्रभावित करता है, वास्तविक कठिन बाधाएं (hard constraints) अनुमति नियमों (permission rules) में लिखी जानी चाहिए। बाद में जब मैंने इस नियम को deny में ले जाया, तो यह ईमानदार हो गया। अधिकारी (officials) इसे बहुत स्पष्ट रूप से कहते हैं:

अनुमति नियम (Permission rules) Claude Code द्वारा लागू किए जाते हैं, न कि मॉडल द्वारा। आपके संकेत (prompts) या CLAUDE.md में निर्देश प्रभावित करते हैं कि Claude क्या करने का प्रयास करता है, लेकिन वे यह नहीं बदलते कि Claude Code क्या अनुमति (allows) देता है।

इसे याद रखें, और आपको पता चल जाएगा कि "रक्षा की पंक्ति" (line of defense) कहाँ बनानी है।

💡 एक वाक्य में सारांश: डिफ़ॉल्ट रूप से स्वतंत्र रूप से (freely) पढ़ें, कार्य करने के लिए अनुमोदन (approval) की आवश्यकता है; यदि आप वास्तव में किसी ऑपरेशन (operation) को रोकना चाहते हैं, तो आपको अनुमति नियम (permission rules) लिखना होगा, केवल CLAUDE.md में पूछना काम नहीं करेगा।

---

02 छह अनुमति मोड (Six Permission Modes): "कदम-दर-कदम पूछने" (step-by-step asking) से लेकर "पूरी तरह से जाने देने" (fully letting go) तक

अनुमति मोड (permission mode) एक चीज़ को नियंत्रित करता है: "आवृत्ति" (frequency) जिसके साथ Claude काम शुरू करने से पहले आपको रुकने और पूछने के लिए कहता है। "प्रत्येक चरण (step) के लिए आपके सिर हिलाने की प्रतीक्षा करने के लिए रुकना" से लेकर "बिना कुछ पूछे सीधे काम करना", एक निरंतर स्पेक्ट्रम (continuous spectrum) है।

तुलना: अभी भी वही इंटर्न, मोड (mode) वह "स्वायत्तता स्तर" (autonomy level) है जो आप उसे देते हैं। पहले दिन, हर चीज़ के लिए निर्देश (instructions) माँगें (default); परिचित होने के बाद, कोड बदलने के लिए पूछने की आवश्यकता नहीं है, लेकिन लाइब्रेरी (library) को हटाने के लिए आपको कॉल (call) करना होगा (acceptEdits); आप व्यावसायिक यात्रा (business trip) पर हैं और उस पर पूरी तरह भरोसा करते हैं, उसे खुद ही तय करने दें (bypassPermissions)।

अधिकारियों (Officials) ने कुल छह मोड (modes) दिए हैं। उनके "क्या यह पहले आपसे पूछेगा" (will it ask you first) और "लागू परिदृश्यों" (applicable scenarios) को एक तालिका में व्यवस्थित करें—यह इस लेख में याद रखने के लिए सबसे महत्वपूर्ण है:

मोड (Mode)	बिना पूछे आप क्या कर सकते हैं (What you can do without asking)	क्या यह पहले आपसे पूछेगा (Will it ask you first)	के लिए सर्वाधिक उपयुक्त (Most suitable for)
default	केवल-पढ़ने के लिए (Read-only only)	फ़ाइलें बदलना, कमांड (commands) चलाना दोनों पूछेंगे	आरंभ करना, संवेदनशील (sensitive) कार्य
acceptEdits	रीड-ओनली (Read-only) + फ़ाइल एडिटिंग (file editing) + सामान्य फ़ाइल सिस्टम कमांड (common file system commands) (mkdir, mv, cp, आदि)	फ़ाइल संपादन और उपरोक्त फ़ाइल सिस्टम कमांड नहीं पूछेंगे, अन्य Bash कमांड अभी भी पूछेंगे	आपके द्वारा समीक्षा किए जा रहे कोड को पुनरावृत्त (Iterate) करना
plan	केवल-पढ़ने के लिए (केवल शोध (research), केवल योजनाएँ (plans), आपके स्रोत कोड (source code) को नहीं छुएगा)	default के समान संकेत (prompt) नियम	कुछ भी बदलने से पहले एक्सप्लोर (Explore) करें और योजना बनाएँ
auto	सभी ऑपरेशन्स (All operations), बैकग्राउंड क्लासिफायर (background classifier) सुरक्षा जांच (security checks) के साथ	मूल रूप से नहीं पूछता, सीमा से बाहर (out-of-bounds) क्लासिफायर द्वारा रोक दिया जाता है	लंबे कार्य (Long tasks), कम रुकावटें (research preview)
dontAsk	केवल पूर्व-अनुमोदित उपकरण (pre-approved tools)	यह न तो पूछता है और न ही रुकता है, जो स्वीकृत (approved) नहीं है उसे सीधे अस्वीकार कर दिया जाता है	लॉक किए गए CI, स्क्रिप्ट (scripts)
bypassPermissions	सभी ऑपरेशन्स (All operations), सभी जाँचों को छोड़ दें (skip all checks)	बिल्कुल नहीं पूछता	केवल पृथक कंटेनर (isolated containers) / VM

कुछ बिंदु जिन्हें शुरुआती लोग सबसे आसानी से भ्रमित करते हैं, उन्हें स्पष्ट करने के लिए चुना गया है:

plan (प्लान मोड, Plan Mode) "आरामदायक" (relaxing) नहीं है, बल्कि सबसे संयमित (restrained) है। यह Claude को केवल फ़ाइलें पढ़ने और स्थिति का पता लगाने के लिए केवल-पढ़ने (read-only) के आदेश चलाने देता है, और फिर आपको "मैं इसे कैसे बदलने की योजना बना रहा हूँ" की योजना लिखता है, लेकिन यह आपके स्रोत कोड (source code) का एक शब्द भी नहीं बदलेगा। किसी भी अपरिचित प्रोजेक्ट (unfamiliar project) को हाथ में लेते समय, यह अनुशंसा (recommended) की जाती है कि पहले उसे plan में स्विच (switch) करें ताकि उसे सब कुछ पढ़ने दिया जा सके, इसके बजाय कि उसे आते ही आँख बंद करके बदलने दिया जाए।

acceptEdits दैनिक विकास (daily development) के लिए स्वीट स्पॉट (sweet spot) है। यह स्वचालित रूप से (automatically) आपके काम करने वाली निर्देशिका (working directory) में फ़ाइल संपादनों (file edits) और कई सामान्य फ़ाइल सिस्टम कमांड (file system commands) (mkdir, touch, rm, rmdir, mv, cp, sed) को मंजूरी देता है, लेकिन अन्य शेल कमांड (shell commands) और काम करने वाली निर्देशिका (working directory) के बाहर लिखना, फिर भी रुक जाएगा और आपसे पूछेगा। यह "कोड बदलने के लिए हर बार सहमत (agree) होने के लिए क्लिक करने की आवश्यकता नहीं है, लेकिन खतरनाक कार्यों (dangerous actions) के लिए ब्रेक (brakes) चालू हैं" के बराबर है।

auto और bypassPermissions दोनों "न पूछने" (not asking) वाले लगते हैं, लेकिन सुरक्षा (security) पूरी तरह से अलग है। auto एक अनुसंधान पूर्वावलोकन (research preview) संस्करण है, इसके पीछे एक स्वतंत्र क्लासिफायर मॉडल (independent classifier model) है जो प्रत्येक ऑपरेशन (operation) की पहले से समीक्षा (review) करता है, और जो सीमा से बाहर (out-of-bounds) हैं (जैसे curl | bash, main को पुश करना, क्लाउड स्टोरेज (cloud storage) को हटाना) उन्हें रोक दिया जाएगा; bypassPermissions सच में नग्न चल रहा है (truly running naked), प्रॉम्प्ट इंजेक्शन (prompt injection) से भी बचाव नहीं कर रहा है। अधिकारी स्पष्ट रूप से लिखते हैं:

bypassPermissions प्रॉम्प्ट इंजेक्शन (prompt injections) या आकस्मिक कार्यों (accidental actions) के खिलाफ सुरक्षा प्रदान প্রতিবন্ধ नहीं करता है। बिना प्रॉम्प्ट (prompt) के पृष्ठभूमि सुरक्षा जाँच (background security checks) के लिए, कृपया auto mode का उपयोग करें।

इसलिए यदि आप "चिंता-मुक्त (worry-free) और एक निचली रेखा (bottom line) रखना" चाहते हैं, तो auto को प्राथमिकता दें, और आते ही bypassPermissions का उपयोग न करें।

💡 एक वाक्य में सारांश: default कदम दर कदम पूछता है, acceptEdits कोड बदलने के लिए नहीं पूछता है, plan केवल देखता है और आगे नहीं बढ़ता है, auto में क्लासिफायर (classifier) का समर्थन है, और bypassPermissions पूरी तरह से नग्न चल रहा है—सख्त (strict) से ढीले (loose) तक इस स्पेक्ट्रम (spectrum) को याद रखें, और बस अपनी सीट लें।

यह चित्र छह मोडों को "सबसे सख्त से सबसे ढीले" स्पेक्ट्रम (spectrum) में व्यवस्थित करता है: बाईं ओर का हरा क्षेत्र plan / default (केवल-पढ़ें (read-only), चरण-दर-चरण पूछें, सबसे सुरक्षित) है, दाईं ओर जाते हुए acceptEdits (कोड बदलें, न पूछें), auto (क्लासिफायर का समर्थन) से होते हुए, सबसे दाईं ओर लाल क्षेत्र में bypassPermissions (पूरी तरह से नग्न) तक—जितना अधिक दाईं ओर, रंग उतना ही लाल होता है, जो आपको याद दिलाता है कि "जितना ढीला होगा, आपको उतना ही स्पष्ट रूप से देखना होगा कि आप इसका उपयोग कहाँ कर रहे हैं"।

---

03 मोड स्विच करें (Switch modes): एक-क्लिक चक्र के लिए Shift+Tab

मोड को जानने के बाद, इसे कैसे स्विच (switch) करें? सबसे अधिक उपयोग किया जाने वाला शॉर्टकट (shortcut) कुंजी है: Shift+Tab।

सत्र (session) में किसी भी समय Shift+Tab दबाएं, और यह तीन मोडों (modes) के बीच घूमेगा:

default → acceptEdits → plan → (default पर वापस जाने के लिए फिर से दबाएँ)

वर्तमान मोड (mode) क्या है, बस स्टेटस बार (status bar) देखें। उदाहरण के लिए, जब आप acceptEdits पर स्विच करते हैं, तो स्टेटस बार (status bar) ⏵⏵ accept edits on प्रदर्शित करेगा।

एक आधिकारिक (official) विवरण पर ध्यान दें, ऐसा न हो कि आप लंबे समय तक दबाने के बाद कोई निश्चित मोड (mode) न पा सकें: डिफ़ॉल्ट लूप (default loop) में केवल default / acceptEdits / plan ये तीन होते हैं। अन्य तीन में प्रवेश करने के तरीके अलग-अलग हैं: जब खाता (account) शर्तों को पूरा करता है तो auto स्वचालित रूप से लूप (loop) में दिखाई देगा; bypassPermissions को लूप में प्रवेश करने के लिए --permission-mode bypassPermissions जैसे झंडे (flags) के साथ शुरू किया जाना चाहिए; dontAsk कभी भी लूप में प्रकट नहीं होता है, और केवल --permission-mode dontAsk स्टार्टअप पैरामीटर (startup parameter) का उपयोग करके सेट किया जा सकता है (नीचे वर्णित)।

तुलना: मोबाइल फोन का "रिंग / वाइब्रेट / म्यूट" (Ring / Vibrate / Mute) तीन-चरण स्विच (three-stage switch)। आप वॉल्यूम बटन (volume button) के बगल में स्थित डायल को दबाते हैं, और यह इन तीन गियर (gears) के बीच मुड़ता है। Shift+Tab Claude Code का डायल है, और एक मोड़ है "कदम दर कदम पूछें / कोड बदलने के लिए कोई पूछ-ताछ नहीं / केवल देखें, हिलें नहीं"।

यदि आप हर बार आने पर मैन्युअल रूप से स्विच (switch) नहीं करना चाहते हैं, तो मोड को "नेल" (nail) करने के दो तरीके हैं:

विधि 1: स्टार्टअप (startup) के दौरान मापदंडों (parameters) का उपयोग करके निर्दिष्ट करें (केवल इस सत्र (session) के लिए काम करता है):

claude --permission-mode plan

आप plan को acceptEdits, dontAsk और अन्य मनमाने मोड नामों (mode names) से बदल सकते हैं। bypassPermissions अपेक्षाकृत विशेष है—--permission-mode bypassPermissions और --dangerously-skip-permissions समतुल्य (equivalent) हैं, लेकिन दैनिक उपयोग के लिए "अंतर्निहित चेतावनी" (built-in warning) वाले नाम का उपयोग किया जाता है, जिसे अनुभाग 05 में विस्तार से समझाया गया है।

विधि 2: डिफ़ॉल्ट के रूप में settings.json में लिखें (हर बार स्टार्टअप पर प्रभावी होता है)। आपके प्रोजेक्ट के .claude/settings.json में:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

⚠️ एक आधिकारिक तौर पर (officially) स्पष्ट प्रतिबंध (restriction): जब defaultMode को "auto" पर सेट किया जाता है, प्रोजेक्ट और स्थानीय सेटिंग्स (local settings) में वालों को अनदेखा (ignored) कर दिया जाएगा (किसी निश्चित रिपॉजिटरी को अपने लिए स्वचालित मोड चालू करने से रोकने के लिए), और यदि आप इसे डिफ़ॉल्ट रूप से auto करना चाहते हैं, तो आपको इसे उपयोगकर्ता स्तर (user-level) के ~/.claude/settings.json में लिखना होगा।

एक अनुशंसित (recommended) आदत: प्रोजेक्ट में मोड (mode) को पिन (pin) न करें, मैन्युअल रूप से स्विच करने के लिए Shift+Tab पर भरोसा करें। क्योंकि एक ही प्रोजेक्ट के लिए, कभी-कभी आप इसे जाने देना चाहते हैं और इसे करने देना चाहते हैं (acceptEdits पर स्विच करें), और कभी-कभी आप केवल चाहते हैं कि यह एक योजना (plan) के साथ आए (plan पर स्विच करें), इसे हार्ड-कोडिंग (hard-coding) करना और भी अजीब है। defaultMode को आम तौर पर केवल default के रूप में सेट किया जाता है जब "यह प्रोजेक्ट सख्त होना चाहिए" नीचे की रेखा के रूप में।

💡 एक वाक्य में सारांश: सत्र (session) में Shift+Tab "कदम-दर-कदम पूछें / कोड बदलें और न पूछें / केवल देखें और न हिलें" के तीन गियर (gears) में घूमता है, वर्तमान गियर देखने के लिए स्टेटस बार (status bar) देखें; यदि आप इसे पिन (pin) करना चाहते हैं, तो --permission-mode स्टार्टअप पैरामीटर (startup parameter) या settings.json के defaultMode का उपयोग करें।

---

04 फाइन-ग्रेन्ड कंट्रोल (Fine-grained control): allow / ask / deny तीन नियम (rules)

मोड (Mode) "मोटे समायोजन" (coarse tuning) है, जो एक बड़ा स्वर (tone) सेट (set) करता है। वास्तव में सटीक (precise) "इस कमांड को चलाया जा सकता है, वह कमांड बिल्कुल निषिद्ध (forbidden) है" का "फाइन-ट्यूनिंग" (fine-tuning) settings.json में तीन नियमों पर निर्भर करता है।

प्रत्येक नियम अंततः तीन क्रियाओं में से एक पर आता है:

कार्य (Action)	प्रभाव (Effect)	विशिष्ट उपयोग (Typical Use)
allow	बिना अनुमोदन (approval) के स्वचालित (automatic) रिलीज़ (release)	कम जोखिम (Low-risk) और उच्च आवृत्ति (high-frequency) वाले कार्य, जैसे git status, npm run build
ask	प्रॉम्प्ट (Prompt) आपको निर्णय लेने के लिए	थोड़ा जोखिम है और पुष्टि छोड़ना चाहते हैं, जैसे git push
deny	सीधे ब्लॉक करें, न निष्पादित (execute) करें और न ही प्रॉम्प्ट करें	स्पष्ट रूप से निषिद्ध खतरनाक (dangerous) संचालन, जैसे rm -rf, पढ़ने में .env

प्राथमिकता एक लोहे का नियम (iron rule) है: deny → ask → allow, पहला मिलान (matching) नियम जीतता है। इसलिए deny हमेशा अन्य दो को ओवरराइड (overrides) करता है—यदि आप allow और deny दोनों लिखते हैं, तो deny का अंतिम कहना है। यह डिज़ाइन (design) बहुत उचित (reasonable) है: "निषिद्ध" (Prohibited) का वजन "अनुमति" (allowed) से अधिक होना चाहिए।

नियम कैसे लिखें, यह टूल का नाम (Tool Name) या टूल का नाम (विशेषक) (Tool Name (Specifier)) है। कुछ उदाहरण देखें और आप समझ जाएंगे:

नियम (Rule)	क्या मेल खाता है (What it matches)
Bash	सभी Bash कमांड (commands)
Bash(npm run build)	केवल npm run build इस सटीक (exact) कमांड से मेल खाता है
Bash(npm run *)	उन कमांड से मेल खाता है जो npm run से शुरू होते हैं (build, test...)
Read(./.env)	वर्तमान निर्देशिका (current directory) में .env फ़ाइल पढ़ें
WebFetch(domain:github.com)	github.com के लिए वेब अनुरोध (web requests) प्राप्त करें

वाइल्डकार्ड (wildcard) * में एक शुरुआती लोगों के लिए गड्ढा है, जिस पर अधिकारी ने विशेष रूप से जोर दिया है:

Bash(ls *) ls -la से मेल खाता है लेकिन lsof से नहीं, जबकि Bash(ls*) दोनों से मेल खाता है।

यदि एक स्थान (space) छूट जाता है, तो अर्थ बदल जाता है। ls * (स्थान के साथ) के लिए ls के बाद एक स्थान की आवश्यकता होती है, इसलिए lsof छूट जाता है; ls* (स्थान के बिना) lsof से भी मेल खाता है। यदि आप सटीक होना चाहते हैं, तो रिक्त स्थान (spaces) लाएं।

एक पूर्ण (complete) कॉन्फ़िगरेशन इस तरह दिखता है - npm और git commit की अनुमति दें, लेकिन git push को रोकें:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

अंतिम सुरक्षा बिंदु (security point) को हाइलाइट किया जाना चाहिए: Read / Edit के deny नियम Bash सबप्रोसेस (subprocesses) में "चक्करदार पढ़ने और लिखने" (detour reading and writing) को नहीं रोक सकते।

इसका क्या मतलब है? आपने Claude को सीधे .env पढ़ने से रोकने के लिए deny: Read(./.env) लिखा, लेकिन अगर यह एक पायथन (Python) स्क्रिप्ट open('.env').read() चलाता है, तो यह deny पूरी तरह से शक्तिहीन (powerless) हो जाएगा—क्योंकि यह वह सबप्रोसेस (subprocess) है जो फ़ाइल को पढ़ रहा है, और यह Claude के अंतर्निहित (built-in) फ़ाइल टूल (file tools) से नहीं गुजरता है। आधिकारिक अनुस्मारक (Official reminder):

वे अप्रत्यक्ष रूप से (indirectly) फ़ाइलों को पढ़ने या लिखने वाले मनमाने ढंग से उप-प्रक्रियाओं (arbitrary subprocesses) पर लागू नहीं होते हैं, जैसे कि पायथन या नोड (Node) स्क्रिप्ट जो स्वयं फ़ाइल खोलते हैं। सभी प्रक्रियाओं को किसी पथ (path) तक पहुँचने से रोकने वाले OS-स्तर (OS-level) के प्रवर्तन (enforcement) को प्राप्त करने के लिए, कृपया सैंडबॉक्स (sandbox) सक्षम करें।

इस बात से आसानी से आश्चर्यचकित हो सकते हैं—यह सोचकर कि deny .env मूर्खतापूर्ण (foolproof) है। इसलिए यदि आप वास्तव में संवेदनशील (sensitive) फ़ाइलों को लॉक करना चाहते हैं, तो अनुमति नियम (permission rules) + सैंडबॉक्स (Sandbox) एक साथ काम करते हैं इसे गहराई से रक्षा (defense in depth) कहा जाता है (सैंडबॉक्स OS-स्तर का अलगाव है, जिसे अगले लेख "सुरक्षा" में विस्तारित किया जाएगा)।

💡 एक वाक्य में सारांश: deny → ask → allow इस प्राथमिकता के अनुसार मेल खाते हैं, deny हमेशा सबसे बड़ा होता है; नियमों में रिक्त स्थान (spaces) के अलग-अलग अर्थ होते हैं; लेकिन deny स्क्रिप्ट को चक्करदार पढ़ने और लिखने से नहीं रोक सकता, संवेदनशील फ़ाइलों को सैंडबॉक्स (sandbox) से सुसज्जित किया जाना चाहिए।

---

05 टॉय प्रोजेक्ट्स के लिए छूट (Relaxation for toys), प्रोडक्शन के लिए सख्ती (tightening for production): दो टेम्पलेट (templates) + "खतरे की मोड" (danger mode) लाल रेखा

बहुत सारे तंत्रों (mechanisms) के बारे में बात करने के बाद, इसे एक वाक्य में संक्षेप में प्रस्तुत किया जा सकता है: प्रोजेक्ट जितना अधिक "टॉय" (toy) होगा, उतना ही अधिक आरामदेह (relaxing) हो सकता है, और जितना अधिक "उत्पादन" (production) होगा, उतना ही कड़ा (tightened) होना चाहिए।

यहाँ दो स्टैंडबाय कॉन्फ़िगरेशन (standby configurations) दिए गए हैं, प्रोजेक्ट की प्रकृति के अनुसार दोनों में से किसी एक को चुनें।

टेम्पलेट 1: टॉय / व्यक्तिगत छोटा प्रोजेक्ट (छूट और गतिवर्धन (Relaxation and acceleration))। यदि आप इसे खराब कर देते हैं, तो बस इसे फिर से बनाएं (rebuild), हर कदम पर रुकने की जरूरत नहीं है। इसे बिना पूछे कोड (code) बदलने के लिए acceptEdits पर सेट करें, और केवल कुछ ही खतरनाक (dangerous) चीजों को पकड़ें:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

टेम्पलेट 2: उत्पादन / कंपनी प्रोजेक्ट (सख्त और गेटकीपिंग (Tightening and gatekeeping))。 डिफ़ॉल्ट रूप से (By default), हर कदम पर पूछें। कोड की जांच करने की सुविधा के लिए रीड ऑपरेशंस (Read operations) खुले हैं। फ़ाइलें लिखने (Writing files) और खतरनाक कमांड (dangerous commands) आपके हाथों से गुजरने चाहिए, और संवेदनशील फ़ाइलों (sensitive files) को सीधे रोक दिया जाना चाहिए:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

इन दोनों deny को लिखते समय याद रखें: जैसा कि पिछले भाग में बताया गया है, .env को ब्लॉक (block) करने वाला deny स्क्रिप्ट को बायपास करने से नहीं रोक सकता है। यदि उत्पादन वातावरण (production environment) वास्तव में स्थिर होना है, तो इस परत के बाहर एक सैंडबॉक्स (sandbox) होना चाहिए। सिंगल-लेयर (single-layer) deny को लोहे की दीवार (iron wall) न मानें।

अंत में, वह लाल रेखा (red line) है, जो शुरुआती बातचीत का नायक भी है—--dangerously-skip-permissions (bypassPermissions मोड के समतुल्य)।

यह चीज़ सभी अनुमति जाँचों और सुरक्षा जाँचों को छोड़ देती है, और टूल कॉल (tool calls) तुरंत निष्पादित (executed) हो जाते हैं। इसके नाम में dangerously (खतरनाक रूप से) शब्द लोगों को डराने के लिए नहीं है। अधिकारी (Officials) ने इसके लिए उपयोग की सीमाएँ (boundaries of use) निर्धारित की हैं:

इस मोड (mode) का उपयोग केवल अलग-थलग वातावरण (isolated environments) (जैसे कंटेनर, वीएम (VMs), या इंटरनेट एक्सेस के बिना देव कंटेनर (dev containers)) में करें, जहां Claude Code आपके होस्ट सिस्टम को नुकसान नहीं पहुंचा सकता है।

निम्नलिखित सख्त नियमों (iron rules) को सीधे कॉपी (copied) किया जा सकता है:

परिदृश्य (Scenario)	क्या आप --dangerously-skip-permissions खोलने की हिम्मत करते हैं
पृथक कंटेनर (Isolated container) / VM / देव कंटेनर (dev container)	✅ हिम्मत है, हटाए गए वाले भी डिस्पोजेबल वातावरण (disposable environments) हैं
CI में एक बार का कार्य (One-time task) चलाएं	✅ हिम्मत है, लेकिन परत को पकड़ने के लिए deny के साथ सहयोग करें
अपनी खुद की मशीन जिस पर आप रोज डेवलप (develop) करते हैं	❌ न खोलें, अगर यह धीमा है तो भी ब्रेक (brake) छोड़ना बेहतर है
कंपनी प्रोडक्शन कोड (production code) वाली मशीनें	❌ बिल्कुल खुला नहीं, यह एक बम (bomb) है

अधिकारी द्वारा डिज़ाइन किए गए दो "बीमा" (insurance) आपको थोड़ा आश्वस्त करते हैं: पहला यह है कि इस मोड (mode) में भी, रूट डायरेक्टरी / होम डायरेक्टरी (root directory / home directory) को हटाने जैसे ऑपरेशन (operations) जैसे rm -rf / और rm -rf ~ अभी भी प्रॉम्प्ट (prompt) करेंगे, हाथ फिसलने को रोकने के लिए सर्किट ब्रेकर (circuit breaker) के रूप में; दूसरा यह है कि लिनक्स / मैकओएस (Linux / macOS) पर, रूट (root) या sudo के रूप में इस मोड को शुरू करने से सीधे इनकार कर दिया जाता है। लेकिन बीमा (insurance) पर भरोसा न करें—मुख्य बात यह है कि "इसे केवल एक पृथक वातावरण (isolated environment) में खोलें जहां यदि आप इसे हटाते हैं तो आपको बुरा नहीं लगेगा"।

💡 एक वाक्य में सारांश: टॉय प्रोजेक्ट (Toy projects) गति बढ़ाने के लिए acceptEdits का उपयोग करते हैं, उत्पादन प्रोजेक्ट गेटकीपिंग के लिए default का उपयोग करते हैं, और दो टेम्पलेट (templates) कॉपी करने के लिए तैयार हैं; --dangerously-skip-permissions केवल अलग-थलग कंटेनरों में खोले जाते हैं, और स्थानीय और उत्पादन मशीनों पर चर्चा (discussion) नहीं की जाती है।

---

06 इसे करें (Hands-on): 5 मिनट में नियमों का अपना पहला सेट सेट (set) करें

सिर्फ बात करना और अभ्यास न करना बकवास है। नीचे मैं आपको एक टॉय प्रोजेक्ट के लिए अनुमति नियमों का एक सेट कॉन्फ़िगर करने के लिए मार्गदर्शन करूंगा, और अपनी आंखों से देखूंगा कि allow और deny कैसे प्रभावी होते हैं। पूरी प्रक्रिया किसी जटिल वातावरण पर निर्भर नहीं है।

चरण 1: टॉय प्रोजेक्ट और कॉन्फ़िगरेशन फ़ाइलें (configuration files) बनाएं (Mac / Linux)

mkdir perm-demo
cd perm-demo
mkdir .claude

अपेक्षा (Expectation): perm-demo फ़ोल्डर (folder) में एक खाली .claude निर्देशिका है। .claude मौजूद है यह देखने के लिए ls -a टाइप करें।

चरण 2: एक settings.json लिखें

अपने उपयोगी संपादक (editor) का उपयोग करके, perm-demo/.claude/settings.json में पेस्ट करें:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

नियमों के इस सेट का अर्थ: डिफ़ॉल्ट रूप से, हर चरण (step) के लिए पूछें, लेकिन git status को बिना पूछे जाने दें, और git push को सीधे ब्लॉक (block) करें।

चरण 3: Claude प्रारंभ करें और नियमों की जांच करें

claude

अंदर जाने के बाद दस्तक (knock) दें:

/permissions

अपेक्षा: अनुमति प्रबंधन इंटरफ़ेस (permission management interface) पॉप अप (pops up) होता है, और आप अपने द्वारा अभी-अभी लिखे गए नियमों को देख सकते हैं—git status * Allow (अनुमति दें) सूची में है, git push * Deny (अस्वीकार करें) सूची में है, और उन्हें चिह्नित किया गया है कि वे किस settings.json फ़ाइल से आए हैं। इन दो आइटम (items) को देखना = कॉन्फ़िगरेशन (configuration) सही ढंग से लोड हो गया है।

चरण 4: सत्यापित (Verify) करें कि deny वास्तव में ब्लॉक कर सकता है

इनपुट बॉक्स (input box) में, इसे निषिद्ध (forbidden) कुछ करने दें:

git push origin main निष्पादित (execute) करने में मेरी सहायता करें

अपेक्षा: Claude निष्पादित नहीं करेगा (will not execute), न ही यह प्रॉम्प्ट पॉप अप करेगा कि "क्या इसे स्वीकृत (approve) करना है" - यह सीधे आपको बताएगा कि यह ऑपरेशन अनुमति नियम (permission rule) द्वारा अस्वीकार (rejected) कर दिया गया है। यह deny की शक्ति है: कोई निष्पादन नहीं, कोई संकेत नहीं, और यह इसे अंत तक अवरुद्ध करता है।

चरण 5: allow की चिकनाई (smoothness) की तुलना करें

इसे फिर से वह काम करने दें जो इसे जाने दिया गया था:

मुझे git status जांचने में मदद करें

अपेक्षा: क्योंकि यह allow: Bash(git status *) से टकराता है, यह अनुमोदन संकेत (approval prompt) के बिना सीधे चलता है (इस निर्देशिका में अभी तक git init नहीं हुआ है, और कमांड (command) स्वयं रिपोर्ट करेगा "गिट रिपॉजिटरी नहीं", लेकिन यह git का व्यवसाय (business) है—बात यह है कि यह आपको पूछने के लिए नहीं रुका, यह दर्शाता है कि allow प्रभावी हो गया है)।

इन पाँच चरणों (steps) को पूरा करने के बाद, आपने व्यक्तिगत रूप से संपूर्ण लिंक (complete link) को सत्यापित किया है "नियम (rules) लिखना → लोड करना → deny ब्लॉक टू डेथ (block to death) → allow पास (pass)"। भविष्य में, किसी भी अनुमति कॉन्फ़िगरेशन (permission configuration) का सार इस तंत्र (mechanism) में नियम जोड़ना है।

💡 एक वाक्य में सारांश: नियम लिखने के लिए .claude/settings.json बनाएं, यह देखने के लिए /permissions करें कि क्या यह लोड है, और फिर Claude को एक निषिद्ध (forbidden) और एक स्वीकृत (released) कमांड चलाने दें—पूरी तरह से दस सिंटैक्स नियमों (syntax rules) को याद रखने की तुलना में इस लिंक को व्यक्तिगत रूप से चलाना अधिक उपयोगी है।

---

07 सारांश

इस लेख में, हमने Claude Code की "अनुमति की बागडोर" (reins of permissions) को शुरू से अंत तक सुलझाया—यह कितना ढीला हो सकता है और कितना कस सकता है, यह सब आपके विचारों और कॉन्फ़िगरेशन की कुछ पंक्तियों में है।

समीक्षा (review) करने के लिए मुख्य बिंदुओं (key points) को एक साथ रखें:

तुम्हें क्या करना चाहिए (What you have to do)	क्या इस्तेमाल करे (Use what)	मुख्य बिंदु (Key points)
"आपसे पूछने की आवृत्ति" (frequency of asking you) समायोजित करें	छह अनुमति मोड (Six permission modes)	default (स्टेप-बाय-स्टेप पूछें) से bypassPermissions (स्ट्रीकिंग) के स्पेक्ट्रम (spectrum) तक
सत्रों में मोड (modes) को शीघ्रता से स्विच करें	Shift+Tab	default / acceptEdits / plan के तीन गियर (gears) में लूप (loop) करें
पिन (pin) डिफ़ॉल्ट मोड	defaultMode	settings.json में लिखें; auto को उपयोगकर्ता स्तर (user level) पर रखा जाना चाहिए
एकल संचालन (single operations) का सटीक नियंत्रण	allow / ask / deny	प्राथमिकता deny → ask → allow, deny सबसे बड़ा है
संवेदनशील फ़ाइलें (sensitive files) लॉक करें	deny + सैंडबॉक्स	लाइट (light) deny स्क्रिप्ट (script) को बायपास (bypass) करने से नहीं रोक सकता

अब आपको सक्षम होना चाहिए: समझें कि छह अनुमति मोड (permission modes) का उपयोग किन परिदृश्यों (scenarios) में किया जाता है, अपनी सुविधानुसार स्विच करने के लिए Shift+Tab का उपयोग करें, settings.json में उपकरण (tool) और कमांड (command) के अनुसार allow / deny नियम (rules) लिखें, कॉन्फ़िगर करें टॉय प्रोजेक्ट्स (toy projects) और प्रोडक्शन प्रोजेक्ट्स (production projects) के लिए उपयुक्त अनुमतियाँ, और जानें कि --dangerously-skip-permissions की लाल रेखा (red line) को केवल पृथक वातावरण (isolated environments) में ही छुआ जा सकता है। नियंत्रण शक्ति (control power) का यह सेट "स्वतंत्र रूप से पीछे हटने" (retreat freely) की आपकी क्षमता है कि आप Claude को काम करने दें और पलटें (overturn) नहीं।

---

अगला लेख 21 "सुरक्षा और जोखिम सीमाएं" (Security and Risk Boundaries)—यह लेख आपको सिखाता है कि "अनुमतियों को कैसे कॉन्फ़िगर (configure) करें", लेकिन कॉन्फ़िगरेशन (configuration) केवल एक उपकरण (tool) है। उच्च-स्तरीय प्रश्न (higher-level question) यह है: क्या आपको वास्तव में अपने कोड और सिस्टम (systems) को छूने के लिए AI पर भरोसा करना चाहिए? असली उच्च जोखिम वाले क्षेत्र (high-risk areas) कौन से हैं? प्रॉम्प्ट इंजेक्शन (Prompt injection) और संवेदनशील डेटा (sensitive data) का रिसाव कैसा दिखता है? लगाम आपके हाथों में है। अगले लेख में, हम "कब पीछे हटना है और कब जाने देना है" (when to close and when to open) के निर्णय के बारे में बात करेंगे।

---

अनुशंसित पाठन

• CLAUDE.md उपयोग मार्गदर्शिका: अपने प्रोजेक्ट के नियमों को इसकी मेमोरी में लिखें
• सामान्य समस्या निवारण (FAQ / Troubleshooting)
• Agent Skills: Claude को ऑन-कॉल विशिष्ट कौशल (on-call specific skills) के सेट (set) से लैस करें