Claude Code परमिशन की सम्पूर्ण गाइड | settings.json, Hooks और Allowlist की विस्तृत व्याख्या

Claude Code में फ़ाइल ऑपरेशन और कमांड एग्जीक्यूशन की अत्यंत शक्तिशाली क्षमताएं हैं। इस शक्ति को सुरक्षित रूप से नियंत्रित करने का काम परमिशन (permissions) करते हैं। “बस किसी तरह चल रहा है” की स्थिति से बाहर निकलें और एक ऐसा Claude Code डिज़ाइन करें जो ठीक वैसे काम करे जैसा आप चाहते हैं।

इस लेख में .claude/settings.json की हर सेटिंग, Hooks के इम्प्लीमेंटेशन पैटर्न, और एनवायरनमेंट के अनुसार परमिशन डिज़ाइन को काम करने वाले कोड के साथ विस्तार से समझाया गया है।

परमिशन का अवलोकन

Claude Code की परमिशन 3 स्तरों पर नियंत्रित होती है।

स्तर	की	व्यवहार
अनुमति	`allow`	कन्फर्मेशन डायलॉग के बिना स्वचालित रूप से एग्जीक्यूट होता है
पूछना	`ask`	हर बार यूज़र की मंज़ूरी आवश्यक है
अस्वीकार	`deny`	बिल्कुल भी एग्जीक्यूट नहीं हो सकता (error के साथ ब्लॉक)

सेटिंग्स को आधिकारिक रूप से settings.json से मैनेज किया जाता है। यूज़र-लेवल सेटिंग के लिए ~/.claude/settings.json, टीम के साथ शेयर होने वाली प्रोजेक्ट सेटिंग के लिए .claude/settings.json, और व्यक्तिगत override के लिए .claude/settings.local.json उपयोग करें। ~/.claude.json में MCP जैसी कुछ state रह सकती है, लेकिन permission rules को settings.json configuration मानकर ही review करें।

प्राथमिकता (सबसे ऊंची पहले):
Managed settings
    > Command-line arguments
        > Local .claude/settings.local.json
            > Project .claude/settings.json
                > User ~/.claude/settings.json

permission rules scopes के बीच merge होती हैं और deny -> ask -> allow क्रम में evaluate होती हैं

settings.json की बुनियादी संरचना

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)"
    ]
  },
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

टूल के नाम और पैटर्न सिंटैक्स

परमिशन “ToolName(argument pattern)” फ़ॉर्मेट में लिखी जाती हैं।

मुख्य टूल की सूची

टूल का नाम	विवरण
`Read`	फ़ाइल पढ़ना
`Write`	नई फ़ाइलें बनाना
`Edit`	मौजूदा फ़ाइलों में आंशिक बदलाव
`Bash`	Shell कमांड एग्जीक्यूशन
`Glob`	फ़ाइल पैटर्न सर्च
`Grep`	कंटेंट सर्च
`WebFetch`	URL फ़ेच करना
`Agent`	Sub-agent लॉन्च करना

पैटर्न सिंटैक्स

"Read(**)"          // सभी फ़ाइलें पढ़ने की अनुमति
"Read(src/**)"      // केवल src/ के अंतर्गत अनुमति
"Read(*.md)"        // केवल .md फ़ाइलें अनुमति
"Bash(npm run *)"   // केवल npm run से शुरू होने वाले कमांड अनुमति
"Bash(git *)"       // सभी git कमांड अनुमति
"Bash(rm -rf *)"    // rm -rf अस्वीकार

** सभी पाथ (directories सहित) से मेल खाता है; * एकल सेगमेंट से मेल खाता है।

व्यावहारिक पैटर्न

पैटर्न 1: व्यक्तिगत डेवलपमेंट (अपेक्षाकृत उदार)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm *)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git add*)",
      "Bash(node *)",
      "Bash(echo *)",
      "Bash(cat *)",
      "Bash(ls *)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~*)",
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(rm *)"
    ]
  }
}

पैटर्न 2: टीम डेवलपमेंट (सुरक्षा-केंद्रित)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run typecheck)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase *main*)",
      "Bash(git rebase *master*)",
      "Bash(DROP *)",
      "Bash(TRUNCATE *)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(git add*)",
      "Bash(npm install*)",
      "Bash(*deploy*)"
    ]
  }
}

पैटर्न 3: प्रोडक्शन एनवायरनमेंट (केवल पढ़ने योग्य)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git show*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(ps *)",
      "Bash(df *)",
      "Bash(top *)"
    ],
    "deny": [
      "Write(**)",
      "Edit(**)",
      "Bash(git push*)",
      "Bash(git commit*)",
      "Bash(git reset*)",
      "Bash(rm *)",
      "Bash(mv *)",
      "Bash(*deploy*)",
      "Bash(*restart*)",
      "Bash(*kill *)"
    ],
    "ask": []
  }
}

प्रोडक्शन या production-like worktree में इस configuration को active .claude/settings.json के रूप में रखें और claude --permission-mode plan या पहले से मंज़ूर dontAsk से शुरू करें। यह environment variable से अलग settings file बदलने की तुलना में official scopes और permission modes के मॉडल के अधिक करीब है।

पैटर्न 4: केवल कंटेंट जनरेशन (इस साइट पर उपयोग होने वाला पैटर्न)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Write(site/src/content/**)",
      "Write(content/**)",
      "Edit(site/src/content/**)",
      "Edit(content/**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(node scripts/*)",
      "Bash(QIITA_TOKEN=* node scripts/qiita-publish.mjs)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Edit(.env*)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(bash scripts/deploy.sh*)"
    ]
  }
}

मुख्य बात यह है कि Write(site/src/content/**) जैसे राइट को किसी खास डायरेक्टरी तक सीमित करना है।

Hooks: परमिशन से पहले और बाद में प्रोसेस चलाना

Hooks एक ऐसा मेकेनिज़्म है जो टूल एग्जीक्यूशन से पहले और बाद में स्वचालित रूप से कमांड चलाता है। इसे सिक्योरिटी चेक और ऑटो-फ़ॉर्मेटिंग के लिए इस्तेमाल किया जा सकता है।

PreToolUse: एग्जीक्यूशन से पहले Hook

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo '🚨 .env जोड़ने का पता चला!' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "node scripts/secret-scan.mjs"
        }]
      },
      {
        "matcher": "Bash(rm*)",
        "hooks": [{
          "type": "command",
          "command": "echo '⚠️ डिलीट कमांड मिला। 5 सेकंड में एग्जीक्यूट होगा। रोकने के लिए Ctrl+C दबाएं।' && sleep 5"
        }]
      }
    ]
  }
}

अगर hook कमांड exit code 1 रिटर्न करती है, तो टूल एग्जीक्यूशन ब्लॉक हो जाता है। यही सबसे महत्वपूर्ण बिंदु है।

PostToolUse: एग्जीक्यूशन के बाद Hook

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit 2>&1 | head -20 || true"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git log --oneline -3"
        }]
      }
    ]
  }
}

PostToolUse का उपयोग एग्जीक्यूशन के बाद की जांच और साइड इफेक्ट्स के लिए होता है — जैसे फ़ाइल एडिट के बाद स्वचालित टाइप चेक, या commit के बाद नवीनतम 3 लॉग एंट्री दिखाना।

व्यावहारिक Hooks रेसिपी संग्रह

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "hooks": [{
          "type": "command",
          "command": "echo '📦 पैकेज जोड़ा जा रहा है। कृपया package.json चेक करें।'"
        }]
      },
      {
        "matcher": "Bash(*deploy*)",
        "hooks": [{
          "type": "command",
          "command": "read -p '🚀 डिप्लॉय होने वाला है। जारी रखें? [y/N] ' ans && [ \"$ans\" = 'y' ] || exit 1"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write(*.ts)|Edit(*.ts)",
        "hooks": [{
          "type": "command",
          "command": "npx eslint --fix $CLAUDE_TOOL_INPUT_FILE_PATH 2>/dev/null || true"
        }]
      }
    ]
  }
}

Permission Modes: लॉन्च पर परमिशन स्तर

claude कमांड लॉन्च करते समय मोड भी स्पेसिफाई किया जा सकता है।

# सामान्य मोड (settings.json के अनुसार)
claude

# सभी ऑपरेशन ऑटो-अप्रूव (खतरनाक! केवल विश्वसनीय एनवायरनमेंट के लिए)
claude --dangerously-skip-permissions

# केवल खास ऑपरेशन स्किप करें
claude --allowedTools "Read,Grep,Glob"

# नॉन-इंटरैक्टिव मोड (CI/CD में उपयोग)
claude -p "टेस्ट चलाएं और परिणाम रिपोर्ट करें" --dangerously-skip-permissions

--dangerously-skip-permissions का उपयोग केवल CI/CD ऑटोमेशन या पूरी तरह समझे हुए ऑटोमेशन स्क्रिप्ट के लिए करें, और दैनिक इंटरैक्टिव उपयोग में इससे बचें।

2026: सुरक्षित permission budget और टीम review

यहां permission budget कोई official feature name नहीं है। इसका मतलब है कि पहले सप्ताह में Claude Code को अपने आप कौन से action चलाने की अनुमति है। 1 जून 2026 की official Docs के अनुसार permission rules deny -> ask -> allow क्रम में evaluate होती हैं। PreToolUse hooks runtime checks जोड़ सकते हैं, लेकिन वे match हो चुके deny या ask को अपने allow से override नहीं करते। इसलिए पहला budget speed से ज्यादा rollback को प्राथमिकता देना चाहिए।

सुरक्षित starter budget छोटा रखें। allow में सिर्फ read और verification रखें: Read, Glob, Grep, git status, git diff, git log, npm run lint, npm run test। ask में intent बदलने वाले काम रखें: Edit, Write, git add, git commit, git push, npm install, deploy commands। deny में irreversible या sensitive काम रखें: .env, secrets/**, rm -rf, git reset --hard, git push --force, curl | bash, wget | sh, production database commands। bypassPermissions केवल disposable container, VM या devcontainer में उपयोग करें।

टीम में .claude/settings.json को application code की तरह PR में review करें। Reviewer को तीन सवाल पूछने चाहिए: क्या हर allow बार-बार चलने पर भी safe है, क्या हर ask सच में human intent checkpoint है, और क्या deny secrets, force push, delete और production operation को cover करता है? Managed organization में admin server-managed settings से disableBypassPermissionsMode और disableAutoMode को "disable" कर सकता है, और allowManagedPermissionRulesOnly से user या project permission rules को रोक सकता है।

खतरनाक failure example है Bash(git *) या Bash(node *) को broad allow करना और यह मान लेना कि Read(.env*) secrets बचा लेगा। Official Docs बताती हैं कि Read/Edit deny Claude Code file tools और पहचाने गए file commands पर लागू होता है, लेकिन arbitrary subprocess, जैसे Node या Python script, direct file open करे तो उसे OS-level enforcement के बिना नहीं रोकता। Secrets बचाने हों तो broad Bash allow से बचें और sandbox, OS permissions, तथा PreToolUse checks साथ लगाएं।

Recovery path पहले लिखें। गलती से edit आ जाए तो पहले /permissions से active rule और source देखें, फिर git diff inspect करें। Rollback के लिए git restore -p से hunk चुनें ताकि अच्छे changes बचें। Untracked files हटाने से पहले git clean -n चलाएं। अगर secret पढ़ा गया हो या transcript में गया हो सकता है, तो सिर्फ .claude/settings.json सुधारना काफी नहीं है; token rotate करें।

इस लेख को repo policy में बदलना हो तो पहले permission budget loop और permission audit checklist से inventory करें। Copy-paste templates और सीखने की सामग्री चाहिए तो Claude Code products देखें। Team rollout, permission review और सुरक्षित onboarding के लिए consultation अकेले नियम अनुमान लगाने से बेहतर रास्ता है।

कॉन्फ़िगरेशन फ़ाइल की प्राथमिकता और ओवरराइड

जब कई कॉन्फ़िगरेशन फ़ाइलें मौजूद हों:

~/.claude/settings.json     ← User (सभी projects के लिए)
.claude/settings.json       ← Project (git-managed)
.claude/settings.local.json ← Local (personal, gitignore)
managed-settings.json       ← Managed (organization policy, highest priority)

permission rules merge होती हैं, और deny हमेशा allow से पहले evaluate होता है

व्यक्तिगत अतिरिक्त सेटिंग्स .claude/settings.local.json में लिखें और इसे gitignore में जोड़ें। टीम की deny list को व्यक्तिगत सेटिंग्स से ओवरराइड न होने देने के लिए, deny नियम केवल settings.json में लिखना सुरक्षित डिज़ाइन है।

# .gitignore में जोड़ें
.claude/settings.local.json

5 आम गलतियां

1. Wildcard पैटर्न गलत लिखना

// ❌ यह केवल एकल कमांड "git" से मेल खाता है
"Bash(git)"

// ✅ git के बाद arguments से भी मेल खाता है
"Bash(git *)"
"Bash(git*)"  // बिना स्पेस के भी काम करता है, लेकिन * स्पष्ट करना ज़्यादा सुरक्षित है

2. यह भूलना कि deny, ask से ज़्यादा प्राथमिकता रखता है

// इस कॉन्फ़िगरेशन में Bash(rm -rf /tmp/test) deny से पकड़ा और ब्लॉक किया जाता है
// यह ask तक कभी नहीं पहुंचता
{
  "deny": ["Bash(rm -rf*)"],
  "ask": ["Bash(rm*)"]  // ← rm -rf deny से हैंडल होता है
}

3. Hook के exit code पर ध्यान न देना

# अगर PreToolUse hook कमांड हमेशा exit 0 रिटर्न करती है,
# तो स्कैन फेल होने पर एग्जीक्यूशन ब्लॉक नहीं होगा

# ❌ Error होने पर भी चलता रहता है
"command": "node scan.mjs"

# ✅ Exit code को स्पष्ट रूप से नियंत्रित करें
"command": "node scan.mjs || exit 1"

4. settings.json को गलती से gitignore करना

कुछ टीमें settings.json—जिसे वे शेयर करना चाहती हैं—को गलती से .gitignore में डाल देती हैं। सही तरीका है प्रोजेक्ट सेटिंग्स git में, केवल settings.local.json gitignore में।

5. प्रोडक्शन कॉन्फ़िगरेशन बदलना भूलना

# ❌ रोज़मर्रा की सेटिंग के साथ प्रोडक्शन में काम करना

# ✅ production work से पहले plan mode में शुरू करें और worktree का .claude/settings.json production-safe रखें
claude --permission-mode plan

एक alias रजिस्टर करने से भूलना मुश्किल हो जाता है:

# ~/.bashrc or ~/.zshrc
alias claude-prod='claude --permission-mode plan'

कॉन्फ़िगरेशन डिबग करना

जब यह स्पष्ट न हो कि “यह कमांड क्यों ब्लॉक हो रहा है”:

# मौजूदा सेटिंग्स चेक करें
claude --print-settings 2>/dev/null || cat .claude/settings.json

# कौन सा नियम मेल खा रहा है यह देखें (verbose मोड)
claude --verbose -p "git push चलाएं"

सारांश: परमिशन डिज़ाइन के लिए बेस्ट प्रैक्टिस

1. पहले deny तय करें
   → वे कमांड सूचीबद्ध करें जो कभी नहीं चलने चाहिए
   → rm -rf, git push --force, DROP TABLE अनिवार्य हैं

2. फिर ask कॉन्फ़िगर करें
   → राइट ऑपरेशन और डिप्लॉय ऑपरेशन जिन्हें कन्फर्मेशन चाहिए

3. बाकी सब को allow करें
   → रीड ऑपरेशन और CI ऑपरेशन: सब allow करें एफिशिएंसी के लिए

4. Hooks से सिक्योरिटी ऑटोमेट करें
   → Pre-commit स्कैनिंग, एडिट के बाद ऑटो टाइप चेक

5. एनवायरनमेंट के अनुसार कॉन्फ़िग फ़ाइलें तैयार करें
   → settings.json (डेवलपमेंट), settings.production.json (प्रोडक्शन)

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