Claude Code permissions guide: सुरक्षित settings.json कैसे लिखें

आप Claude Code से केवल टेस्ट चलवाना चाहते हैं, लेकिन हर कमांड पर अनुमति का सवाल आ जाता है। दूसरी ओर, पूरे Bash को अनुमति देना भी ठीक नहीं है: इससे delete, hard reset या force push जैसे काम बिना पुष्टि के चल सकते हैं।

इसका हल “सब रोकें” या “सब खोल दें” नहीं है। पढ़ने और टेस्ट चलाने वाले काम अपने-आप होने दें, बदलाव से पहले पूछें, और secrets तथा नुकसान करने वाले command हमेशा रोकें। यही तीन स्तर .claude/settings.json में लिखे जाते हैं।

इस गाइड से क्या मिलेगा

नियम deny → ask → allow के क्रम में जांचे जाते हैं: पहले रोकना, फिर पूछना, फिर स्वतः अनुमति।
Project के अंदर read पहले से बिना prompt चलता है। केवल जांचे हुए tests को allow, edit, external access और push को ask, तथा secrets और destructive commands को deny रखें।
Bash(git *) बहुत बड़ा दायरा है। इसमें git reset --hard और git push --force भी आ सकते हैं, इसलिए सुरक्षित commands अलग-अलग लिखें।
केवल Read(.env) से child process पूरी तरह नहीं रुकता। मजबूत अलगाव के लिए sandbox और OS permissions भी चाहिए।
बदलाव के बाद /permissions और /status से देखें कि कौन-सी settings file लागू हुई है।

Claude Code क्या करे और इंसान क्या तय करे

Claude Code को दें	इंसान से पुष्टि लें	हमेशा रोकें
फाइल खोजना, diff देखना, टेस्ट चलाना	फाइल बदलना, commit, push, dependency जोड़ना	secrets पढ़ना, force push, hard reset, बड़ी संख्या में फाइलें मिटाना
`Read`, `Grep`, `git diff`	`Edit`, `git commit`, `npm install`	`.env`, `git push --force`, `git reset --hard`, `rm -rf`

जिस काम को आसानी से वापस न लिया जा सके, जो बाहर डेटा भेजता हो, या credentials तक पहुंचता हो, उसे ask या deny में रखें।

शुरुआत के लिए settings.json

Project root में .claude/settings.json बनाकर यह configuration रखें। यह टीम में साझा करने योग्य, सावधानी वाला शुरुआती ढांचा है।

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Edit",
      "WebFetch",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git clean *)",
      "Bash(git restore *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/secrets/**)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

यह baseline उसी repository के लिए है जिसके package.json scripts आपने पढ़ लिए हैं। अनजान repository में allow खाली रखें और test command का असली काम देखने के बाद rule जोड़ें। Bash(npm test *) npm test और arguments वाले रूप से मेल खाता है।

settings.json कहां रखें

प्रकार	स्थान	उपयोग
User	`~/.claude/settings.json`	आपके सभी projects की साझा settings
Project	`.claude/settings.json`	Git में रखी जाने वाली team policy
Local	`.claude/settings.local.json`	केवल इस computer की personal settings; इसे Git में न डालें
Managed	administrator द्वारा बांटी गई settings	संगठन की ऐसी policy जिसे project से बदला न जा सके

प्राथमिकता Managed, command line, Local, Project और User के क्रम में होती है। permissions.allow जैसे arrays अलग scopes में जुड़ते हैं; वे पूरी तरह replace नहीं होते। किसी भी scope का deny, ask और allow से पहले लागू होता है। साझा rules Project में और अनिवार्य policy Managed settings में रखें।

allow, ask और deny नियम कैसे पढ़ें

नियम	अर्थ
`Read`	सभी built-in reads; project के अंदर global allow आमतौर पर जरूरी नहीं
`Bash(npm test)`	केवल `npm test` से पूरा match
`Bash(npm test *)`	`npm test` और उसके बाद arguments वाले commands
`Bash(ls*)`	`ls -la` के साथ `lsof` भी match हो सकता है; इसलिए बहुत व्यापक है
`Read(//Users/me/secrets/**)`	filesystem के absolute path से match
`Edit(/src/*/.ts)`	Project settings में project के `src` के नीचे की TypeScript files
`WebFetch(domain:docs.anthropic.com)`	दिए गए domain के लिए WebFetch

Bash(git *) में git push origin main और git reset --hard दोनों शामिल हो सकते हैं। जिन commands को आप सुरक्षित मानते हैं, उन्हें अलग-अलग allow करें।

केवल Read और Edit से secrets पूरी तरह सुरक्षित क्यों नहीं होते

Read और Edit के path patterns gitignore जैसी syntax इस्तेमाल करते हैं।

लिखावट	आधार	उदाहरण
`//path`	filesystem root	`Read(//Users/me/secrets/**)`
`~/path`	home directory	`Read(~/.ssh/**)`
`/path`	settings file का base path	Project settings में `Edit(/src/**)`
`path` या `./path`	current working directory	`Read(.env)`

शुरू का एक slash absolute filesystem path नहीं है। Read(.env) built-in file tool के उस access को रोकता है जिसे Claude Code पहचानता है, लेकिन node, Python या किसी दूसरे child process से होने वाली indirect file access अलग रास्ता है।

Credentials वाले project में Claude Code sandbox guide भी लागू करें और OS level पर access सीमित रखें।

3 उपयोग के मामले

Use case 1: Personal project में केवल टेस्ट automate करना

Input: source files, tests और Git diff। Output: बदलाव का सुझाव और test result। इंसानी जांच: edit, dependency install, commit और push।

ऊपर वाला minimal configuration लगाएं और edit को ask में रहने दें। जो read-only या test command बार-बार सुरक्षित साबित हो, केवल उसी को बाद में allow में ले जाएं।

Use case 2: Team में destructive commands सभी के लिए रोकना

Input: approved commands और प्रतिबंधित operations की सूची। Output: Git में रखी गई shared settings। इंसानी जांच: deny में बदलाव और अस्थायी exception।

Project settings में .env, force push और hard reset के deny rules रखें। जिस नियम को project member बदल न सके, उसे Managed settings में ले जाएं।

Use case 3: Production repository की केवल जांच करना

Input: incident logs और Git history। Output: संभावित कारण और remediation plan। इंसानी जांच: edit, deploy और कोई भी external transmission।

Session को Plan Mode में शुरू करें।

claude --permission-mode plan

बदलाव जरूरी हो जाए, तो पहले work branch या isolated environment में जाएं; उसके बाद ही write permission दें।

चार ठोस गलतियां और उनके सुधार

गलती	कारण	सुधार
`Bash(git *)` को allow करना	यही pattern push और hard reset भी शामिल करता है	केवल जांचे हुए side effects वाले commands allow करें
`deny: Bash(aws *)` के साथ `allow: Bash(aws s3 ls)` जोड़ना	deny → ask → allow क्रम में specificity exception नहीं बनाती	deny छोटा करें या safe operation को अलग command में रखें
`Read(.env)` को OS isolation मानना	मनमाना Node.js या Python process पूरी तरह नहीं रुकता	sandbox `denyRead` या credentials rules जोड़ें
Local allow हटाने के बाद भी command चलना	User, Project और Local arrays जुड़ते हैं	`/permissions` में source और `/status` में loaded scopes देखें

Incident examples के लिए Claude Code security failure cases और पूरी deployment checklist के लिए security best practices पढ़ें।

सही permission mode चुनें

Mode	कब उपयोग करें	सावधानी
`default`	नया या अनजान repository	जरूरत पड़ने पर confirmation दिखाई देगा
`acceptEdits`	जब बदलाव का दायरा समझ में आ गया हो	edits और सामान्य file operations अपने-आप approve हो सकते हैं
`plan`	investigation, design या production incident की read-only जांच	source code नहीं बदलता
`auto`	background safety checks वाले tasks	classifier request से मेल जांचता है; explicit deny साथ रखें
`dontAsk`	केवल पहले से अनुमति पाए operations को unattended चलाना	अनुमति न मिला काम पूछे बिना reject होता है
`bypassPermissions`	फेंकी जा सकने वाली container या VM	सामान्य PC और production environment में न चलाएं

sandbox.autoAllowBashIfSandboxed का default true है। Sandbox में bare Bash ask skip हो सकता है, लेकिन Bash(git push *) जैसा content-specific ask, explicit deny और Plan Mode restrictions लागू रहते हैं।

Pitfall: बड़े allow को केवल hook से सुरक्षित मान लेना

यदि पूरे Bash को allow कर दें और केवल PreToolUse hook से खतरनाक commands रोकें, तो hook की गलत जगह, error या अधूरा pattern सुरक्षा की एकमात्र सीमा तोड़ सकता है।

कारण: अनुमति का दायरा बहुत बड़ा है और एक hook ही आखिरी सुरक्षा बन गया है।

सुधार: पहले deny और छोटे, command-specific allow rules लिखें। Hook को केवल dynamic check की अतिरिक्त परत मानें। deny और ask, hook से मिले allow result पर प्राथमिकता रखते हैं।

Copy-paste करने योग्य configuration check

यह script देखती है कि .claude/settings.json valid JSON है और कम-से-कम चार जरूरी deny rules मौजूद हैं।

// scripts/check-claude-permissions.mjs
import { readFileSync } from "node:fs";

const path = ".claude/settings.json";
const settings = JSON.parse(readFileSync(path, "utf8"));
const deny = new Set(settings.permissions?.deny ?? []);
const required = [
  "Read(.env)",
  "Edit(.env)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(rm *)",
  "PowerShell(Remove-Item *)",
];

const missing = required.filter((rule) => !deny.has(rule));
if (missing.length > 0) {
  console.error(`ये deny नियम मौजूद नहीं हैं: ${missing.join(", ")}`);
  process.exit(1);
}

console.log("Claude Code permissions की शुरुआती जांच: OK");

node scripts/check-claude-permissions.mjs

यह सुरक्षा का प्रमाण नहीं है। इसका काम CI में यह पकड़ना है कि जरूरी deny rule गलती से हट गया है।

Settings लागू न हों तो इस क्रम में जांचें

/permissions में लागू rules और उनकी source file देखें।
/status में loaded settings scopes देखें।
Bash(ls *) और Bash(ls*), तथा /path और //path जैसे space और path anchors दोबारा जांचें।
Sandbox auto-approval और higher scope के deny या ask rules देखें।
Shared rule को temporary CLI option में छोड़ने के बजाय .claude/settings.json में वापस लिखें।

निष्कर्ष

पहला कदम .claude/settings.json में minimal configuration डालना और /permissions से उसे जांचना है।

केवल जांचे हुए tests को allow, edits और external operations को ask, तथा secrets और destructive operations को deny रखें। इसके बाद वही command जोड़ें जिसका असर आप समझते हैं।

इसी permission template को बाकी development rules के साथ अपनाने के लिए Claude Code learning resources में examples और checklists देखें।

आधिकारिक संदर्भ

वास्तव में किए गए परीक्षण का परिणाम

22 जुलाई 2026 को दसों भाषाओं के JSON blocks को JSON.parse किया गया और temporary project में Node.js check चलाया गया। छह जरूरी deny rules पर exit code 0 मिला; Bash(git reset --hard *) हटाने पर code 1 और missing rule मिला। यह configuration drift पकड़ता है, policy की सुरक्षा साबित नहीं करता। अपने environment में /permissions और /status भी जांचें।