CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: सेटअप और ऑडिट

डेवलपमेंट मशीनों और साझा CI रनर पर CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS सेट न करें। Claude Code v2.1.311+ में यह केवल bypassPermissions सेशन के दौरान क्रिटिकल पाथ हटाने की पुष्टि बंद करता है। इसे सिर्फ ऐसी अस्थायी, अलग-थलग व्यवस्था में इस्तेमाल करें जहाँ लिखने की अनुमति वाली सभी फ़ाइलों का मिटना स्वीकार्य हो।

2026-10-28 तक, Anthropic के दस्तावेज़ इस विकल्प को लॉन्च के समय मिलने वाले एनवायरनमेंट की सेटिंग बताते हैं। यह अपने आप बायपास मोड चालू नहीं करता और न ही बाकी सभी अनुमति संबंधी नियंत्रण बंद करता है।

खतरनाक मोड अब भी rm -rf ~ को क्यों रोकता है?

Claude Code पहचाने गए rm और rmdir कमांड के लक्ष्य सामान्य टूल अनुमतियों से अलग जाँचता है। --dangerously-skip-permissions फ़्लैग से bypassPermissions चुना जाता है। नया विकल्प प्रभावी होने तक इस मोड में भी क्रिटिकल पाथ की जाँच बनी रहती है।

कोई allow नियम पहचाने गए क्रिटिकल पाथ को हटाने की अनुमति नहीं दे सकता। allow लौटाने वाला PreToolUse हुक भी ऐसा नहीं कर सकता। डिफ़ॉल्ट रूप से टर्मिनल अनुमति माँगता है और दो मिनट की उलटी गिनती दिखाता है।

-p के साथ चलाते समय कोई अनुमति टूल, SDK कॉलबैक या अनुमति देने वाला PermissionRequest हुक फैसला कर सकता है। इनके बिना अनुरोध डिफ़ॉल्ट रूप से अस्वीकार होता है।

क्रिटिकल पाथ की परिभाषा में ये स्थान आते हैं:

• फ़ाइल सिस्टम की रूट डायरेक्टरी, जैसे /।
• रूट के ठीक नीचे की डायरेक्टरी, जैसे /usr, /etc और /data।
• आपकी होम डायरेक्टरी, जिसमें उसका Windows 8.3 छोटा नाम भी शामिल है, जैसे C:\Users\LONGNA~1।
• Windows ड्राइव की रूट डायरेक्टरी और उनके ठीक नीचे की डायरेक्टरी, जैसे C:\ और C:\Windows। रूट लिखने के दूसरे रूप, जैसे \\?\C:\ और \\localhost\C$, भी शामिल हैं।
• आपकी वर्किंग डायरेक्टरी और उसके ऊपर की डायरेक्टरी।
• अतिरिक्त वर्किंग डायरेक्टरी और उनके ऊपर की डायरेक्टरी, लेकिन केवल जब लक्ष्य उनके भीतर का ग्लॉब यानी वाइल्डकार्ड वाला पैटर्न हो। उदाहरण: rm -rf <dir>/*।

अतिरिक्त डायरेक्टरी को सीधे rm -rf <dir> से हटाने पर उस अतिरिक्त डायरेक्टरी वाली जाँच लागू नहीं होती। कोई दूसरा नियम फिर भी लागू हो सकता है, जैसे वही डायरेक्टरी रूट के ठीक नीचे भी हो।

यह जाँच केवल उन कमांड पर लागू होती है जिन्हें Claude Code पहचानता है। छूट गए कमांड को खास सुरक्षा नहीं मिलती। दूसरे स्वीकृत प्रोग्राम भी फ़ाइलें हटा सकते हैं। PowerShell के Remove-Item और cmd में हटाने वाले कमांड की अलग जाँच होती है।

एक अलग-थलग टर्मिनल सेशन के लिए वेरिएबल सेट करें

वेरिएबल उस एनवायरनमेंट में सेट करें जिससे claude शुरू होता है, फिर स्पष्ट रूप से bypassPermissions चुनें। इसका उपयुक्त उपयोग ऐसा स्वचालित काम है जो जानबूझकर अस्थायी वर्किंग डायरेक्टरी खाली करता है।

काम कर रही CLI इस्तेमाल करें जिसमें खाते का प्रमाणीकरण हो चुका हो। उसका संस्करण v2.1.311 या बाद का होना चाहिए। macOS, Linux या WSL पर Bash में ये जाँच चलाएँ:

claude --version
claude auth status --text

प्रमाणीकरण विफल हो तो अपने स्वीकृत खाता सेटअप के साथ claude auth login चलाएँ। गलत बाइनरी चल रही हो तो Claude Code की स्थापना और PATH की जाँच देखें। आगे बढ़ने से पहले पुरानी स्थापना अपडेट करें।

Bash में अस्थायी रूप से मान देकर सेशन शुरू करें:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

यह मान इसी कमांड और उससे शुरू होने वाली प्रक्रियाओं को मिलता है। यह मूल शेल में बना नहीं रहता। आप --permission-mode bypassPermissions की जगह --dangerously-skip-permissions इस्तेमाल कर सकते हैं।

अलग-थलग व्यवस्था में ऐसा उपयोगकर्ता लें जो रूट न हो। Linux और macOS पर बायपास मोड आम तौर पर रूट या sudo से किए गए लॉन्च रोकता है। पहचाने गए सैंडबॉक्स इसके अपवाद हैं।

यह वेरिएबल ~/.claude/settings.json, .claude/settings.json या .claude/settings.local.json के env ब्लॉक में न रखें। एनवायरनमेंट वेरिएबल का संदर्भ पुष्टि करता है कि Claude Code इसे वहाँ अनदेखा करता है। इसे किसी दूसरी सेटिंग्स फ़ाइल में रखने से समस्या हल नहीं होगी।

यह विकल्प केवल तब लागू होता है जब सेशन वास्तव में bypassPermissions में हो, plan में नहीं। इसका दायरा Bash और Monitor टूल की क्रिटिकल पाथ संबंधी जाँच है। इसमें वे कमांड भी आते हैं जिन्हें यह जाँच पूरी तरह पार्स नहीं कर पाती।

पहले से एक्सपोर्ट की गई सेटिंग हटाने के लिए प्रभावित सेशन बंद करें। फिर उस स्रोत से मान हटाएँ जो लॉन्च के समय इसे सेट करता है। अपने शेल में unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS चलाएँ और नया सेशन शुरू करें।

बिना कुछ हटाए स्टार्टअप संदेश जाँचें

Claude Code शुरू होने पर दिखने वाला संदेश पढ़ें। इससे पता चलता है कि पुष्टि हटाने वाला विकल्प लागू हो सकता है या नहीं। केवल मॉडल से सही जवाब मिलना अनुमतियों की स्थिति साबित नहीं करता।

अलग-थलग व्यवस्था में छोटी जाँच के लिए Bash में यह चलाएँ:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

इस जाँच में CLI फ़्लैग मॉडल की उपलब्ध सूची से अंतर्निहित टूल हटाते हैं और MCP टूल रोकते हैं। शुरू होते समय चलने वाले हुक और एक्सटेंशन फिर भी लोड होते हैं।

कमांड stdout पर READY जवाब माँगता है। यह कुछ हटाने का अनुरोध किए बिना स्टार्टअप का stderr आउटपुट claude-startup.log में सहेजता है।

दस्तावेज़ों में दिए गए संदेशों में इन तीन वाक्यांशों में से एक मिलता है:

संदेश का अंश	मतलब
is set, so dangerous rm commands can run without a prompt	प्रशासक द्वारा लागू मैनेज्ड सेटिंग्स और प्लगइन हुक लोड होने के बाद विकल्प प्रभावी हो सकता है। संबंधित नियम या हुक फिर भी इसे रोक सकते हैं।
has no effect in this session	इस पूरे सेशन में सामान्य पुष्टि या अस्वीकृति लागू रहेगी। कारण ठीक करें और दोबारा शुरू करें।
has no effect while the Windows registry cannot be read for managed settings	रजिस्ट्री की जाँच विफल रहने तक सामान्य जाँच जारी रहेगी। रजिस्ट्री बाद में सफलतापूर्वक पढ़ी जाए तो बिना दोबारा शुरू किए विकल्प सक्रिय हो सकता है।

Agent SDK वाले ऐप में संदेश पाने के लिए stderr विकल्प दें। आउटपुट न दिखना इस बात का प्रमाण नहीं है कि क्रिटिकल पाथ के लिए पुष्टि अब भी सक्रिय है। देखें कि लॉन्च का वेरिएबल सेशन तक पहुँचा या नहीं। सक्रिय अनुमति मोड और सेशन सीधे शुरू हुआ था या नहीं, यह भी जाँचें।

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

वेरिएबल का असर न होने की नौ वजहें

दूसरी सेटिंग बदलने से पहले संस्करण, लॉन्च के समय का एनवायरनमेंट और सक्रिय मोड जाँचें। फिर अपनी स्थिति को दस्तावेज़ों में दिए अपवादों से मिलाएँ।

ये अलग-अलग संभावित कारण हैं। टीम ने जिन सुरक्षा नियंत्रणों को जानबूझकर लगाया है, उन्हें बनाए रखें।

कारण	क्या जाँचें और क्या करें
1. कोई दूसरा घटक अनुमति के अनुरोध संभालता है	--permission-prompt-tool या SDK के canUseTool कॉलबैक को देखें, जब --permission-prompts none न दिया गया हो। कोई भी PermissionRequest हुक जाँचें, चाहे उसके मिलान की शर्त कुछ भी हो। उस घटना को संभालने वाला मॉड भी देखें। अनजाने में जुड़े हैंडलर को हटाएँ और दोबारा शुरू करें।
2. सेशन ग्राफ़िकल चैट पैनल में चल रहा है	VS Code एक्सटेंशन का चैट पैनल और Desktop ऐप यह विकल्प लागू नहीं करते। CLI अपने टर्मिनल से शुरू करें। IDE में मौजूद टर्मिनल भी ठीक है।
3. कोई deny या ask नियम Bash, Edit या Read पर लागू है	ऐसा कोई भी नियम इस विकल्प को निष्क्रिय करता है, भले ही उसका फ़ाइलें हटाने से संबंध न हो। नियम पढ़ने के बाद विकल्प पूरे सेशन में निष्क्रिय रहता है, नियम हटा देने के बाद भी। स्वीकृत बदलाव के बाद दोबारा शुरू करें। किसी टूल को छोड़ने के लिए deny नियम की जगह --tools इस्तेमाल करें।
4. वर्किंग डायरेक्टरी के बाहर पढ़ना बंद है	permissions.blockReadsOutsideWorkingDirectories जाँचें। अगर इसे बंद करना ही उद्देश्य है, तो इसे true करने वाली हर सेटिंग हटाएँ और दोबारा शुरू करें।
5. Claude Code दूसरे सेशन के भीतर शुरू हुआ था	दूसरे सेशन के Bash टूल या हुक से शुरू करने पर सामान्य जाँच बनी रहती है। कमांड लाइन में वेरिएबल देने पर भी यही होता है। अपने शेल से शुरू करें। एक सेशन के भीतर दूसरा सेशन चलाने की यह रोक सुरक्षा सीमा नहीं है।
6. कोई PreToolUse हुक ask लौटाता है	हटाने की उस कार्रवाई के लिए हुक का फैसला जाँचें। अनचाहा ask जवाब ठीक करें। अकेला allow जवाब क्रिटिकल पाथ की सामान्य जाँच नहीं हटा सकता।
7. सेशन Claude Code ने बनाया था	Claude Code पृष्ठभूमि में चलाने के लिए जो सेशन बनाता है, उन्हें यह वेरिएबल नहीं मिलता। अलग पैनलों में चलने वाले एजेंट टीम के साथियों के सेशन भी इसके बिना शुरू होते हैं। यही बात Remote Control सर्वर के बनाए सेशन पर लागू है। विकल्प चाहिए तो टर्मिनल से सीधे सेशन शुरू करें।
8. मैनेज्ड सेटिंग्स सफलतापूर्वक लोड नहीं हुई हैं	प्रशासक से विफल सेटिंग्स स्रोत ठीक करवाएँ। सर्वर से मैनेज्ड सेटिंग्स प्राप्त करने की विफलता जाँचने के लिए claude doctor चलाएँ। रजिस्ट्री की जाँच विफल होने का अलग व्यवहार अगली पंक्ति में है।
9. Windows रजिस्ट्री पढ़ने की कोशिश विफल है	यह Windows और WSL दोनों पर लागू है, तब भी जब WSL रजिस्ट्री की सेटिंग्स इस्तेमाल नहीं करता। कारणों में इंटरऑपरेबिलिटी बंद होना, अंग्रेज़ी के अलावा दूसरी भाषा वाला Windows और WSL2 कर्नेल पर चलता कंटेनर शामिल हैं। अनुमति हो तभी इंटरऑपरेबिलिटी बहाल करें। वरना जरूरी सफ़ाई खुद करें।

अधिकृत बदलाव के बाद स्टार्टअप संदेश की जाँच दोहराएँ। Windows हुक अप्रत्याशित व्यवहार करे तो अनुमति नीति बदलने से पहले सक्रिय बाइनरी और Windows हुक की जाँच करें।

लॉन्च के स्रोतों का ऑडिट करें और टीम की नीति लागू करें

कॉन्फ़िगरेशन फ़ाइलों और Claude Code शुरू करने वाली प्रक्रिया के एनवायरनमेंट, दोनों का ऑडिट करें। रिपॉज़िटरी में कुछ न मिलना यह साबित नहीं करता कि होस्ट की गई CI सेवा कोई वेरिएबल नहीं जोड़ती।

सहेजी गई सेटिंग्स खोजें और CI में वेरिएबल रोकें

फ़ाइलों की सामग्री दिखाए बिना रिपॉज़िटरी और आम शेल प्रोफ़ाइल में खोजें। यह Bash उदाहरण ripgrep पर निर्भर है और मेल वाली फ़ाइलों के सिर्फ नाम दिखाता है:

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

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

CI वेरिएबल को संगठन, रिपॉज़िटरी, एनवायरनमेंट और जॉब, सभी स्तरों पर देखें। रनर सेवा का एनवायरनमेंट और Claude Code शुरू होने से पहले वेरिएबल बदलने वाले हर चरण की जाँच करें। पूरा एनवायरनमेंट लॉग में न डालें।

नियंत्रित CI लॉन्चर में Claude Code चलाने से ठीक पहले यह Bash जाँच रखें:

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

यह खाली मान या 0 समेत वेरिएबल की किसी भी मौजूदगी पर लॉन्च रोकता है। यह लॉन्चर की जानबूझकर सख्त रखी गई नीति है। इसका मतलब यह नहीं कि हर मान से सुविधा चालू होती है। इससे केवल वे तरीके सुरक्षित होते हैं जिनसे Claude Code शुरू करते समय वास्तव में यह जाँच चलती है।

मैनेज्ड सेटिंग्स से बायपास मोड बंद करें

टीम को बायपास मोड की जरूरत न हो तो उसे रोक दें। पुष्टि हटाने वाला विकल्प उसी मोड पर निर्भर है, इसलिए उसकी जरूरी शर्त हट जाती है। मैनेज्ड सेटिंग्स के env ब्लॉक से केवल लॉन्च पर पढ़े जाने वाले इस वेरिएबल को निष्क्रिय नहीं किया जा सकता।

यह नियंत्रण संगठन की सक्रिय मैनेज्ड सेटिंग्स में मौजूदा कॉन्फ़िगरेशन के साथ जोड़ें:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

फ़ाइल के ज़रिए सेटिंग्स लागू करने के लिए ये पाथ इस्तेमाल करें:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux और WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Claude Code दोबारा शुरू करें और /status देखें। पुष्टि करें कि Setting sources में वही मैनेज्ड स्रोत है जिसे लागू करना था। bypassPermissions में जाने की नई कोशिश अस्वीकार होनी चाहिए।

लागू करने से पहले चुना हुआ स्रोत जाँचें। अधिक प्राथमिकता वाला मैनेज्ड स्रोत तैनात की गई फ़ाइल की जगह ले सकता है। मशीनों के प्रशासन से नीति सुरक्षित रखें। स्थानीय प्रशासक अधिकार वाला व्यक्ति फ़ाइल में रखी नीति बदल सकता है।

कौन सी सुरक्षा अधिक भरोसेमंद है: deny नियम या सैंडबॉक्स?

फ़ाइल सिस्टम तक पहुँच सीमित करने के लिए ऑपरेटिंग सिस्टम के स्तर पर अलगाव लागू करें। अलग-अलग टूल कॉल को अनुमति नियमों से नियंत्रित करें। क्रिटिकल पाथ की पुष्टि एक अतिरिक्त जाँच है, पूरे फ़ाइल सिस्टम की सुरक्षा नहीं।

उपयोगी deny नियम बनाए रखें। लेकिन Bash के नियम कमांड के टेक्स्ट से मिलान करते हैं। Bash(rm *) कमांड चलाने के हर तरीके या फ़ाइलें हटाने वाले दूसरे प्रोग्राम पर लागू नहीं होता। इंस्टॉल किए गए हुक और मॉड भी जाँचें, क्योंकि एक्सटेंशन अनुमति के फैसले प्रभावित कर सकते हैं।

समर्थित macOS, Linux और WSL2 सिस्टम पर ये सैंडबॉक्स सेटिंग्स मैनेज्ड नीति में जोड़ें:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

यह कॉन्फ़िगरेशन सैंडबॉक्स उपलब्ध न होने पर लॉन्च रोकता है और सैंडबॉक्स के बाहर दोबारा कोशिश बंद करता है। नेटिव Windows में यह सैंडबॉक्स समर्थित नहीं है, इसलिए यह नीति वहाँ लॉन्च रोक देगी।

प्रभावी कॉन्फ़िगरेशन और जरूरी निर्भरताओं के लिए /sandbox देखें। excludedCommands और लिखने की अनुमति वाले पाथ का ऑडिट करें। सख्त मोड अब भी अपवादों की अनुमति देता है। उपयोगकर्ता की सेटिंग्स या --settings कुछ सूचियों का दायरा बढ़ा सकते हैं।

सैंडबॉक्स में चलने वाले कमांड अब भी लिखने की अनुमति वाला प्रोजेक्ट डेटा हटा सकते हैं। अंतर्निहित सीमा हर हुक, स्थानीय रूप से शुरू किए गए MCP सर्वर या फ़ाइल टूल को नहीं समेटती।

बिना निगरानी वाले काम में व्यापक सीमा चाहिए तो पूरे Claude Code प्रोसेस को कंटेनर, VM या सैंडबॉक्स रनटाइम में अलग रखें। होस्ट के मूल्यवान पाथ लिखने की अनुमति के साथ माउंट न करें। वर्किंग कॉपी ऐसी रखें जिसे दोबारा बनाया जा सके।