Claude Code परमिशन रूल्स और settings.json सेटिंग पूरी गाइड

Claude Code के परमिशन रूल्स आपको settings.json में allow / ask / deny एंट्रियाँ लिखने देते हैं ताकि आप बारीकी से तय कर सकें कि कौन-से टूल्स, कमांड्स, फ़ाइलें और डोमेन बिना पूछे चलें, हर बार पुष्टि माँगें, या पूरी तरह वर्जित रहें। इन्हें टीम भर में साझा किया जा सकता है, जिससे आप खतरनाक चीज़ें पक्के तौर पर ब्लॉक कर देते हैं और सुरक्षित, नियमित काम बिना रुकावट चलते रहते हैं।

यह गाइड बताती है कि परमिशन रूल्स क्या हैं (और वे परमिशन मोड्स से कैसे अलग हैं), allow/ask/deny की प्राथमिकता, रूल सिंटैक्स, settings.json की पदानुक्रम, और व्यावहारिक रेसिपी — सब आधिकारिक स्पेसिफ़िकेशन पर आधारित।

1. परमिशन रूल्स क्या हैं (मोड्स से अंतर)

Claude Code एक स्तरीय परमिशन सिस्टम का उपयोग करता है। पढ़ने के ऑपरेशन (फ़ाइल देखना, Grep आदि) को मंज़ूरी की ज़रूरत नहीं; Bash कमांड्स और फ़ाइल एडिट को ज़रूरत होती है — और इस आधारभूत स्तर के ऊपर, रूल्स आपको बारीक अपवाद तय करने देते हैं (स्रोत: Claude Code का आधिकारिक "Configure permissions")।

रूल्स को परमिशन मोड्स से गड्डमड्ड कर देना आसान है। मोड्स वह व्यापक आधार रेखा हैं कि "कितनी बार पूछा जाए" (default/acceptEdits/auto आदि); रूल्स प्रति-टूल, प्रति-कमांड स्तर के विनिर्देश हैं। ये साथ मिलकर काम करते हैं — मोड आधार रेखा तय करता है, और रूल्स उसे "इसे हमेशा allow करो" या "इसे कभी allow मत करो" के साथ ओवरराइड कर देते हैं।

2. allow / ask / deny और प्राथमिकता

तीन रूल प्रकार होते हैं। /permissions कमांड इन्हें सूचीबद्ध और संपादित करता है (और दिखाता है कि प्रत्येक किस settings.json से आ रहा है)।

रूल्स का मूल्यांकन deny → ask → allow क्रम में होता है। पहला मैच परिणाम तय करता है, और रूल की विशिष्टता इस क्रम को नहीं बदलती। एक व्यापक Bash(aws *) deny, अधिक विशिष्ट Bash(aws s3 ls) allow को हरा देता है। मतलब यह कि एक deny अपने साथ allowlist अपवाद नहीं ला सकता।

3. रूल सिंटैक्स (Tool(specifier))

प्रारूप है Tool (सब कुछ) या Tool(specifier) (विशिष्ट)। हर टूल की अपनी specifier शैली होती है।

Bash वाइल्डकार्ड कहीं भी आ सकते हैं। Bash(ls *) (स्पेस + *) ls -la से मैच करता है पर lsof से नहीं (शब्द-सीमा); Bash(ls*) (बिना स्पेस) दोनों से मैच करता है। अंत में :* लगाना * के समतुल्य है।

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

संयुक्त कमांड्स का ध्यान रखें। Claude Code && || ; | जैसे विभाजकों को समझता है, और हर उप-कमांड को स्वतंत्र रूप से मैच करना ज़रूरी है। Bash(safe-cmd *) safe-cmd && rm -rf . को अनुमति नहीं देता। ध्यान दें कि केवल-पढ़ने वाले कमांड्स (ls/cat/grep/find/pwd आदि) हर मोड में बिना पुष्टि के चलते हैं, और timeout/nice/nohup जैसे रैपर मैचिंग से पहले हटा दिए जाते हैं।

Read/Edit पथ gitignore शब्दार्थ का पालन करते हैं, जिनमें चार एंकर होते हैं:

※ /Users/... निरपेक्ष नहीं है — यह प्रोजेक्ट रूट के सापेक्ष है। निरपेक्ष पथ के लिए //Users/... (डबल स्लैश) का उपयोग करें। Read(.env) Read(**/.env) के बराबर है और नीचे की हर .env से मैच करता है।

4. settings.json की पदानुक्रम और प्राथमिकता

रूल्स settings.json में रहते हैं। कई फ़ाइलें होती हैं, और ऊँचे स्तर अधिक मज़बूत होते हैं। मुख्य नियम: किसी भी स्तर का deny हमेशा किसी भी अन्य स्तर के allow को हरा देता है।

// .claude/settings.json (team-shared)
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)", "WebFetch(domain:docs.example.com)"],
    "deny": ["Read(.env)", "Read(**/secrets/**)", "Bash(git push *)"],
    "additionalDirectories": ["../shared-lib"]
  }
}

डिफ़ॉल्ट परमिशन मोड भी यहीं defaultMode के रूप में सेट होता है (मोड विवरण)। कार्यशील डायरेक्टरी के बाहर पढ़ने/संपादित करने के लिए, पथ additionalDirectories में जोड़ें।

5. व्यावहारिक रेसिपी

आम संयोजन। बुनियादी ढाँचा: खतरनाक चीज़ें पक्के तौर पर deny करो, सुरक्षित नियमित काम को allow करके स्वचालित कर दो।

URL को Bash आर्ग्युमेंट पैटर्न के ज़रिए सीमित करना नाज़ुक है (curl http://github.com/ * को -X GET या वेरिएबल विस्तार से आसानी से बायपास किया जा सकता है)। इसके बजाय, curl/wget को deny करें और विशिष्ट डोमेन को WebFetch(domain:...) से allow करें। अधिक सख़्त नियंत्रण के लिए, किसी PreToolUse हुक में URL की जाँच करें।

6. सावधानियाँ और आम गलतफहमियाँ

• deny को Claude Code लागू करता है, मॉडल नहीं। अपने प्रॉम्प्ट या CLAUDE.md में "इसे मत पढ़ो" लिखने से रूल के बिना यह नहीं रुकेगा।
• Read/Edit deny अप्रत्यक्ष एक्सेस नहीं रोक सकता। यह बिल्ट-इन फ़ाइल टूल्स और cat/head/sed पर लागू होता है, पर ऐसी Python या Node स्क्रिप्ट पर नहीं जो खुद फ़ाइलें खोलती है। OS-स्तरीय प्रवर्तन के लिए, सैंडबॉक्सिंग का भी उपयोग करें।
• एनवायरनमेंट रनर्स से सावधान रहें। devbox run *, npx, और docker exec अपने आर्ग्युमेंट्स को एक कमांड के रूप में चलाते हैं, इसलिए Bash(devbox run *) devbox run rm -rf . को भी अनुमति दे देता है। ऐसे रूल लिखें जिनमें भीतरी कमांड शामिल हो।
• हुक्स रूल्स को ओवरराइड नहीं करते। एक PreToolUse हुक परमिशन का विस्तार कर सकता है, पर deny/ask का मूल्यांकन इस बात की परवाह किए बिना होता है कि हुक क्या लौटाता है (deny-पहले वाला नियम अपरिवर्तित रहता है)।

※ व्यवहार Claude Code के आधिकारिक दस्तावेज़ (Configure permissions / Settings) के अनुसार है, जून 2026 तक। यह बदल सकता है — नवीनतम जानकारी के लिए आधिकारिक दस्तावेज़ देखें।

सारांश

Claude Code परमिशन रूल्स पर तीन मुख्य बातें।

• ये क्या हैं: settings.json में allow/ask/deny, जिनसे प्रति टूल, कमांड, फ़ाइल और डोमेन के स्तर पर अनुमति दें/पुष्टि माँगें/वर्जित करें। मोड्स आधार रेखा तय करते हैं; रूल्स बारीकियाँ संभालते हैं।
• प्राथमिकता: deny → ask → allow (पहला मैच जीतता है; विशिष्टता अप्रासंगिक है)। किसी भी स्तर का deny हमेशा जीतता है। स्तर: managed > CLI > local > project > user.
• सिंटैक्स: Tool(specifier). Bash वाइल्डकार्ड का उपयोग करता है (स्पेस + * एक शब्द-सीमा है), Read/Edit gitignore-शैली पथ का, WebFetch domain: का। संयुक्त कमांड्स में हर उप-कमांड का मैच होना ज़रूरी है।

"खतरनाक चीज़ें पक्के तौर पर ब्लॉक करो, सुरक्षित नियमित काम को स्वचालित करो" — यही रूल डिज़ाइन का मर्म है। इसे परमिशन मोड्स, हुक्स, और effort सेटिंग के साथ जोड़कर Claude Code को सुरक्षित और सुचारु रूप से चलाएँ।

FAQ