Claude Code रोज़ सुरक्षित चलाना: Approval और Sandbox की लकीर खींचने का तरीका

“approval dialog तो आता ही है, तो ठीक ही चल रहा होगा।”

शुरू-शुरू में मैं यही सोचता था। Claude Code जब भी कुछ करता, एक confirmation आता। मैं पढ़ता, OK दबाता। मुझे लगता मैं संभलकर चला रहा हूँ।

दो हफ़्ते बाद मैंने अपनी ही उंगली पर ग़ौर किया और होश उड़ गए। मैं confirmation का text पढ़े बिना, reflex में Enter दबा रहा था। जो काम “रोज़ का flow” बन गया, उसे मैं अब देख ही नहीं रहा था। git push भी, बाहरी API पर लिखना भी — सब बिना देखे पास हो रहा था। हादसा नहीं हुआ, यह सिर्फ़ क़िस्मत थी।

approval dialog ऐसी चीज़ नहीं जिसे बढ़ाते जाओ तो safety बढ़ती जाए। बहुत ज़्यादा हों तो इंसान पढ़ना छोड़ देता है। बहुत कम हों तो वे काम भी पास हो जाते हैं जिन्हें वापस नहीं किया जा सकता। आज मैं इसी “लकीर खींचने” पर लिखूँगा — settings की बारीकियों पर नहीं, बल्कि रोज़ फ़ैसला कैसे लें इस पर।

मुख्य बातें

• Approval का मतलब “सब रोको” या “सब बहने दो” नहीं है। असल धुरी यह है: जो वापस हो सकता है उसे तेज़ करो, जो वापस नहीं हो सकता उसे धीमा करो। लकीर undo हो सकता है या नहीं — इसी पर खींचो।
• Permission mode (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) को काम के phase के हिसाब से बदलो। समझने के लिए plan, review करते हुए ठीक करने के लिए acceptEdits।
• --dangerously-skip-permissions (यानी bypassPermissions) रोज़मर्रा में मत इस्तेमाल करो। उसकी जगह auto mode या sandbox लो।
• Sandbox वह सिस्टम है जो Bash के “पहुँच के दायरे” को OS स्तर पर छोटा कर देता है। यह macOS / Linux / WSL2 पर चलता है, native Windows पर नहीं चलता।
• Team में “approval कहाँ रुके” यह इंसान के जोश पर मत छोड़ो — deny rules और hooks से उसे physically पक्का करो।

settings file का format ख़ुद बहन-लेख Claude Code परमिशन गाइड में है, और CLAUDE.md के साथ permission जोड़ने की ठोस recipe CLAUDE.md × परमिशन रेसिपी में। यह लेख सिर्फ़ “कहाँ रोकें” के operating फ़ैसले पर टिका है।

Approval की लकीर “वापस हो सकता है क्या” पर खींचो

लकीर खींचते वक़्त उलझन हो, तो technical risk के बड़े-छोटेपन से पहले सिर्फ़ एक सवाल ख़ुद से पूछो।

“क्या मैं इसे 5 मिनट बाद वापस ले सकता हूँ?”

File पढ़ना, grep करना, diff देखना, npm run build चलाना — ये जितनी बार करो, दोबारा कर सकते हो। सबसे बुरे हाल में git checkout से वापस आ जाता है। इसलिए इसे तेज़ चलाना है। उल्टा git push, production deploy, मेल भेजना, बाहरी DB पर लिखना — दबाते ही बाहर की दुनिया बदल जाती है। वापस नहीं होता। इसलिए जान-बूझकर धीमा करो।

मैं अक्सर तीन हिस्सों में बाँटता हूँ, ऐसे:

Action	फ़ैसला	वजह
पढ़ना / grep / diff / build / test / lint	allow	वापस हो सकता है। रफ़्तार गिराना नहीं
Branch पर code edit	ask या acceptEdits	repo कितना परिपक्व है उस पर निर्भर
push / deploy / publish / मेल भेजना / बाहरी API पर लिखना	ask	बाहरी दुनिया पर असर। वापस नहीं होता
.env पढ़ना / rm -rf / git reset --hard / curl | sh	deny	हादसे में नुक़सान बहुत बड़ा

यहाँ सबसे ज़्यादा उलझन “edit” पर होती है। Edit हर हाल में ख़तरनाक नहीं है। जिस personal repo में test पूरे हों, वहाँ edit तेज़ चलाने में डर नहीं। असली डर तब है जब test कमज़ोर हों, repo production के क़रीब हो, और edit खुला छोड़ दिया जाए। इसलिए कसौटी “edit की इजाज़त दें या नहीं” नहीं, बल्कि edit के बाद verify किससे होगा है। Verify करने वाली command तैयार है तो edit तेज़ रखो। तैयार नहीं है तो ask में रहने दो।

deny को “एहतियातन” थोड़ा चौड़ा रखने में कोई नुक़सान नहीं। .env पढ़ना और destructive commands — मानकर चलो कि इन्हें allow में चढ़ाने का दिन कभी नहीं आएगा, इसलिए शुरू से बंद रखो। ख़तरनाक प्रॉम्प्ट्स की सूची में जिन “permissions छोड़कर सबसे तेज़” टाइप निर्देशों की बात है, वे इसी सीमा को जानबूझकर तोड़ने की कोशिश हैं। deny में डाल दो तो prompt की तरफ़ से चाहे जो कहा जाए, मुख्य tool रोक देगा।

Permission mode को phase के हिसाब से बदलो

अगर allow/ask/deny यह तय करता है कि “क्या” रोकना है, तो permission mode यह gear चुनना है कि “अभी कितना” रोकना है। Shift+Tab से default → acceptEdits → plan बदल सकते हो। आधिकारिक permission modes पेज पर सारे mode हैं, पर operating के लिए यह मेल याद रखो।

Mode	बिना confirmation जितना चलता है	कब
default	सिर्फ़ पढ़ना	नया repo, संभलकर बढ़ना हो
plan	सिर्फ़ पढ़ना (edit नहीं, सिर्फ़ plan)	codebase समझकर फिर हिलना हो
acceptEdits	पढ़ना + working folder के अंदर edit	ख़ुद review करते हुए ठीक करना हो
auto	लगभग सब (पीछे classifier safety जाँचता है)	लंबा काम, confirmation की थकान कम करनी हो
dontAsk	सिर्फ़ पहले से allow किया हुआ	CI या script का बंद environment
bypassPermissions	सब (कोई जाँच नहीं)	अलग container / VM के अंदर ही

मेरा तरीक़ा सीधा है। नए काम का दरवाज़ा हमेशा plan। पहले Claude से पढ़वाकर plan निकलवाओ, दिशा सही है यह पक्का करके फिर हिलाओ। दिशा तय हो जाए तो acceptEdits पर उतरकर एक साथ edit करवाओ और नतीजा git diff से इकट्ठा देखो। एक-एक लाइन approve करने से बेहतर है — बाद में इकट्ठा पढ़ने पर ध्यान ज़्यादा टिकता है। यह “आख़िर में ज़रूर देखना है” को सिस्टम बनाने की बात है, और हार्नेस इंजीनियरिंग में लिखे “दरबान को मशीन पर बिठाओ” वाले नज़रिए से जुड़ी हुई है।

एक सावधानी। bypassPermissions को छोड़कर किसी भी mode में, protected paths पर लिखना अपने-आप approve नहीं होता। .git, .claude, .bashrc, .npmrc जैसी जगहें — जो टूट जाएँ तो repo या settings ख़ुद मर जाते हैं। acceptEdits में मज़े से edit करते हुए भी, यहाँ confirmation आएगा ही। इसे रुकावट नहीं, आख़िरी safety net समझो।

--dangerously-skip-permissions के बिना काम चलाना

“confirmation बहुत ज़्यादा हैं, झंझट है” — इसे हल करने के लिए बहुत लोग --dangerously-skip-permissions (यानी bypassPermissions mode) की तरफ़ हाथ बढ़ाते हैं। नाम के मुताबिक़ ही, यह flag सारी जाँच बंद कर देता है।

अगर इसे रोज़ की बातचीत में लगातार इस्तेमाल करोगे, तो वह “निगरानी में चलने वाला agent” रहा ही नहीं। बस अब तक हादसा नहीं हुआ, इतना ही। आधिकारिक docs भी इस mode को साफ़ “अलग किए हुए container / VM के अंदर ही” बताते हैं — और rm -rf / या rm -rf ~ जैसे सबसे बुरे केस को छोड़कर कोई prompt नहीं आता। prompt injection से बचाव भी शून्य है।

पर “झंझट है” वाली भावना अपने-आप में सही है। इसलिए मिटाना confirmation की गिनती को है, safety net को नहीं। दो विकल्प हैं।

एक है auto mode। यह confirmation मिटा देता है, पर पीछे एक अलग classifier model हर action को देखता रहता है और curl | bash, production deploy, main पर सीधा push, force push जैसे ख़तरनाक काम block करता है। बातचीत में “push मत करना” कहो तो वह भी एक अस्थायी block signal की तरह असर करता है। Confirmation घटते हैं, फिर भी ख़तरनाक काम रुकते हैं। यह bypassPermissions से बिलकुल अलग चीज़ है। हाँ, auto mode research preview है, इसलिए यह संवेदनशील कामों की पूरी review छोड़ने का औज़ार नहीं — “जिसकी दिशा पर भरोसा है” ऐसे काम के लिए है।

दूसरा है sandbox। उसे अगले हिस्से में समझाता हूँ।

Confirmation घटाना है तो पहले acceptEdits या auto, फिर भी कम न पड़े तो sandbox। bypassPermissions को सिर्फ़ container का मानकर अलग रखो। इस क्रम में सोचो तो safety net पूरी तरह उतारने की वजह लगभग बचती ही नहीं।

Sandbox “पहुँच के दायरे” को OS से बाँधता है

अगर approval यह पूछने का सिस्टम है कि “यह action करना चाहिए या नहीं”, तो sandbox Bash जिन files और network तक पहुँच सकता है, उस दायरे को ही OS स्तर पर छोटा करने का सिस्टम है। Approval “चलाने से पहले की जाँच” है, sandbox “चलने के दौरान की दीवार”। दोनों की layer अलग है।

यह यहाँ काम का है क्योंकि यह approval की कमज़ोरी भरता है। Approval command के text को देखकर फ़ैसला करता है, इसलिए npm run build पीछे कुछ अनचाहा करे तो उसे पता ही नहीं चलता। पर sandbox में वह command default में सिर्फ़ working folder के अंदर लिख सकती है। नाम के मुताबिक़ न भी चले, तो OS उसे physically रोक देता है।

/sandbox चलाओ तो एक settings panel खुलता है, जहाँ दो mode चुन सकते हो।

• auto-allow: sandbox के अंदर हो तो Bash बिना confirmation चलता है (दायरा बँधा हुआ है, इसलिए सुरक्षित)। सिर्फ़ दायरे से बाहर जाने वाले काम सामान्य approval पर लौटते हैं।
• regular permissions: sandbox के अंदर भी, हमेशा की तरह approval आता है। control मज़बूत, पर confirmation ज़्यादा।

यानी “confirmation तो घटाना है, पर कुछ भी चल जाना डरावना है” वाले के लिए यह एकदम सही है। दायरे से बचाव होता है, इसलिए बार-बार पूछना नहीं पड़ता।

पर एक अहम पाबंदी है। Sandbox चलता है सिर्फ़ macOS / Linux / WSL2 पर, native Windows पर नहीं। Windows users को WSL2 के अंदर Claude Code चलाना पड़ेगा। WSL इस्तेमाल नहीं कर सकते, या सादे Windows पर चलाना है, तो sandbox की उम्मीद छोड़कर allow/ask/deny का बँटवारा थोड़ा सख़्त रखो। deploy, publish और secret वाले कामों को ख़ासकर ask की तरफ़ झुकाओ। Windows पर यही असली व्यावहारिक हल है।

Sandbox की settings ऐसी दिखती हैं। सिर्फ़ उन्हीं tools के लिए जिन्हें working folder के बाहर लिखना ज़रूरी है (जैसे kubectl को ~/.kube छूना पड़ता है), साफ़-साफ़ छेद खोलो।

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false का मतलब है “sandbox न चल सके ऐसे environment में सिर्फ़ warning देकर सामान्य execution पर गिर जाओ”। उल्टा, संगठन में sandbox ज़रूरी बनाना हो तो इसे true करो, ताकि startup ही रुक जाए। और एक चीज़ चुपके से अहम है — denyRead। Sandbox का default लगभग सारी files पढ़ सकता है, इसलिए ~/.aws और ~/.ssh जैसे secrets को साफ़ बंद कर दो तो निश्चिंती रहती है।

“रोज़ के operating” में उतारने वाली शुरुआती settings

यहाँ तक के फ़ैसलों को एक file में रखो, तो रोज़मर्रा operating की शुरुआत के लिए इतना काफ़ी है। Format के बारीक मतलब (Bash(npm run build) और Bash(npm*) का फ़र्क़ वग़ैरह) परमिशन गाइड पर छोड़ देता हूँ।

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

यह तीन ही काम कर रहा है। पढ़ना और verify करना तेज़ चलाओ। बाहर असर डालने वाले काम हमेशा रोको। जो साफ़ ख़तरनाक हैं उन्हें शुरू से मना करो। defaultMode: "plan" इसलिए रखा है क्योंकि हर नई session को “पहले पढ़ो और plan बनाओ” से शुरू करना चाहता हूँ। बाक़ी काम करते-करते Shift+Tab से acceptEdits पर चढ़ते जाओ।

Edit (Edit / Write) को न allow में न ask में लिखना जान-बूझकर है। उसे mode (acceptEdits) की तरफ़ से control करना है। rules और mode दोनों में edit बाँधो तो पता ही नहीं चलता कौन-सा असर कर रहा है। edit को mode से, बाहरी side effect को rule से — यूँ ज़िम्मेदारी बाँटो तो दिमाग़ साफ़ रहता है।

Team में “approval कहाँ रुके” यह physically पक्का करो

अब तक बात अकेले की थी। Team बनते ही एक और मुसीबत जुड़ती है — हर इंसान की लकीर अलग जगह खिंचती है। कोई संभलकर चलता है, तो कोई bypassPermissions से चलाना चाहता है। जोश और समझ पर छोड़ोगे, तो सबसे ढीले इंसान का तरीक़ा team की असली लकीर बन जाता है।

इसलिए जहाँ रोकना है उसे इंसान के फ़ैसले पर मत छोड़ो, physically पक्का करो। तीन ठोस मिसालें।

1. commit से पहले secret घुसना रोको। PreToolUse hook से git add के पहले जाँचो कि .env stage तो नहीं हुई। इंसान को “अरे, यह तो डालना मना था” समझ आने से पहले ही commit रुक जाता है।

2. deploy से पहले build ज़बरदस्ती कराओ। “local पर build पास कर लिया था” पर भरोसा मत करो। deploy command के पहले hook से npm run build ज़रूर चलवाओ।

3. edit के बाद verification अपने-आप चलाओ। Edit / Write के बाद npm run test बहाओ। पतले फ़िक्स पर भी verify चलता है, इसलिए टूटी हुई हालत में आगे नहीं बढ़ते।

सबसे छोटा रूप इतना है। Hooks जितने ज़्यादा हों उतने अच्छे — ऐसा नहीं है। रोकने वाला 1 hook, verify वाला 1 hook — इतने से operating जल्दी नहीं टूटता।

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Windows पर grep वाले हिस्से को findstr या किसी छोटे Node script से बदल दो तो चल जाएगा। अहम बात command से ज़्यादा यह है कि “commit से पहले रोको / deploy से पहले build / edit के बाद verify” — ये तीन रूप बने रहें। संगठन स्तर पर बाँधना हो तो managed settings में bypassPermissions को disable करके sandbox को ज़रूरी बनाने का रास्ता भी है। Team के पैमाने पर पहुँचने पर consultation पेज से operating rules समेत design करवाना आख़िरकार सबसे तेज़ पड़ता है।

आम ग़लतियाँ

तीनों, या तो मैंने या मेरे आसपास किसी ने सचमुच की हुई हैं।

सब कुछ ask करके निश्चिंत हो जाना

पहले एक दिन सुरक्षित दिखता है। पर एक हफ़्ते बाद confirmation का text पढ़े बिना OK दबाना शुरू हो जाता है। यह deny कमज़ोर होने से भी ख़तरनाक है — क्योंकि “देख लिया था” वाला भ्रम बचा रहता है। ask की क़तार लगाने से पहले, पहले deny को पक्का करो।

--dangerously-skip-permissions ज़बान पर चढ़ जाना

“अरे यह तो तेज़ है” का स्वाद एक बार लग गया तो लौटना मुश्किल हो जाता है। पर वह तो बस निगरानी हटाना था। Confirmation झंझट लगे तो auto mode या sandbox का auto-allow इस्तेमाल करो। safety net समेत हटाने की ज़रूरत कहीं नहीं है।

build पास को release पास समझ लेना

यह content operating में भी और development में भी बार-बार होता है। Local build पास हो गया, पर public URL पुराना है, एक ही language unreflected है, CTA mobile पर बिगड़ा हुआ है। Approval या sandbox इस failure को नहीं रोक सकते। ज़रूरत publish के बाद की जाँच की है। मैंने इसी से कई बार “निकाल दिया था” वाली ग़लती की है।

अक्सर पूछे जाने वाले सवाल

Q. auto mode और sandbox का auto-allow, इनमें फ़र्क़ क्या है? A. बचाव का तरीक़ा अलग है। auto mode में classifier model फ़ैसला करता है कि “यह action ख़तरनाक है क्या” और block करता है। sandbox का auto-allow action के भीतर देखने के बजाय “पहुँच का दायरा” OS से बाँधकर safety पक्की करता है। फ़ैसले से बचाव पहला, दायरे से बचाव दूसरा। दोनों को साथ भी जोड़ सकते हो।

Q. Windows पर sandbox चलता है क्या? A. native Windows पर नहीं चलता। WSL2 के अंदर Claude Code चलाओ तो चलता है। सादे Windows पर चलाना हो तो sandbox पर भरोसा छोड़कर deploy, publish और secret वाले कामों को ask की तरफ़ झुकाओ और deny थोड़ा सख़्त रखो।

Q. plan mode और acceptEdits mode कब-कब इस्तेमाल करूँ? A. plan “सिर्फ़ पढ़ो, edit मत करो” वाला है — codebase समझकर plan बनाने वाले phase के लिए। acceptEdits “working folder के अंदर edit बिना confirmation पास करो” वाला है — दिशा तय होने पर एक साथ ठीक करने वाले phase के लिए। मैं plan से शुरू करता हूँ और सहमति बनने पर acceptEdits पर उतर जाता हूँ।

Q. deny में डाला हुआ action, सिर्फ़ एक बार हर हाल में चलाना हो तो? A. deny को Claude Code का मुख्य tool ज़बरदस्ती लागू करता है, इसलिए prompt से उसे ढीला नहीं किया जा सकता (यही deny की क़ीमत है)। सचमुच ज़रूरत हो तो उसी वक़्त settings से हटाकर चलाओ और हो जाने पर वापस डाल दो। “अस्थायी रूप से हटाया” वाली यह मेहनत ख़ुद ख़तरनाक action पर brake बन जाती है।

Q. Hook और permission, इनका काम आपस में नहीं टकराता? A. नहीं टकराता। permission यह control करता है कि “वह action चलाना चाहिए या नहीं”, और hook यह कि “execution के पहले-बाद क्या ज़रूर चलाना है”। secret घुसना रोकना, deploy से पहले build करना — ऐसी deterministic जाँचें hook के ज़िम्मे हैं।

इसे सचमुच आज़माने पर क्या हुआ

इस नज़रिए को मैंने इसी site के daily automation में जस-का-तस दोबारा डाला। सबसे बड़ा बदलाव AI के output की क्वालिटी में नहीं, बल्कि इसमें आया कि “किस मोड़ पर इंसान रुकता है” यह साफ़ हो गया।

पहले “कुछ एक चीज़ आगे बढ़ाओ” वाला धुँधला operating था, और कभी-कभी किसी पुराने article को थोड़ा ठीक करके ही run ख़त्म हो जाता था। अब plan से plan → acceptEdits से edit → deploy से पहले hook से build → publish के बाद सारी languages mobile पर जाँच वाला flow पक्का है। bypassPermissions इस्तेमाल करना छोड़कर acceptEdits + sandbox पर आने के बाद, “पता ही नहीं चला कब बाहर कुछ कर दिया” वाली घबराहट ख़त्म हो गई।

समझदार AI को सब सौंपने से बेहतर — जो वापस नहीं हो सकता उसके ठीक पहले एक साँस ठहराना। लंबा रास्ता लगता है, पर रोज़ निश्चिंत होकर चलाने के लिए यही सही निकला। पहले मुफ़्त चीटशीट बग़ल में रखो और अपनी deny list को एक-एक लाइन भरने से शुरुआत करो।