Claude Code auto mode: 14 August 2026 के बदलाव और सेटिंग्स

14 August 2026 को auto mode में क्या बदलाव होंगे

Claude Code का auto mode बिना पूछे tool calls चलाता है, और प्रत्येक action को पहले review के लिए एक अलग classifier model के पास भेजता है। 14 August 2026 से, Pro, Max और Team plans पर नए sessions इसी mode में शुरू होंगे। आप किसी भी समय mode बदल सकते हैं, और यदि आपने पहले से ही अपने लिए कोई default set किया है, तो वह overwrite नहीं होगा।

documentation में इस बदलाव को इस प्रकार बताया गया है:

14 August 2026 से, Pro, Max और Team plans पर नए sessions के लिए auto mode डिफ़ॉल्ट अनुमति मोड बन जाएगा। आप किसी भी समय मोड बदल सकते हैं। यदि आपने स्वयं कोई डिफ़ॉल्ट सेट किया है, तो वह तब तक बना रहेगा जब तक आप एक बार आने वाले स्विच प्रॉम्प्ट को स्वीकार नहीं करते, और आपके संगठन द्वारा प्रबंधित डिफ़ॉल्ट में कोई बदलाव नहीं होगा।

वहाँ दी गई दो शर्तें तारीख से अधिक महत्वपूर्ण हैं। आपके द्वारा अपनी settings file में सेट किया गया defaultMode इस बदलाव के बाद भी बना रहता है। आपके संगठन द्वारा managed settings के माध्यम से लागू किया गया डिफ़ॉल्ट भी सुरक्षित रहता है। announcement post में यह जोड़ा गया है कि rollout के पहले चरण के दौरान Enterprise plans और API का उपयोग करने वाले accounts के लिए auto mode वैकल्पिक बना रहेगा।

यदि आप VPS (virtual private server) पर Claude Code चलाते हैं, तो इस बदलाव के लागू होने से पहले इसे पढ़ना उपयोगी है। एक permission prompt वह checkpoint है जिसके लिए कीबोर्ड पर किसी व्यक्ति का होना आवश्यक है। remote box पर आप अक्सर वहां नहीं होते हैं, इसलिए जिस mode में session शुरू होता है, वह घंटों तक उसी में रहता है।

Claude Code के अनुमति मोड, सबसे अधिक निगरानी से सबसे कम तक

छह modes हैं। प्रत्येक पंक्ति की शुरुआत में दिया गया नाम वह value है जिसे आप settings में लिखते हैं या --permission-mode को pass करते हैं। सभी छह modes को model के बजाय Claude Code स्वयं लागू करता है, क्योंकि किसी tool call को क्या करने की अनुमति है, यह model के आसपास मौजूद harness का काम है।

• default: Claude प्रत्येक नए टूल के उपयोग से पहले पूछता है। आपकी working directory के भीतर की reads बिना किसी प्रॉम्प्ट के चलती रहती हैं। CLI (command line interface) इस मोड को Manual के रूप में लेबल करता है और Claude Code v2.1.200 से manual को alias के रूप में स्वीकार करता है।
• plan: Claude फाइलों को पढ़ता है और एक्सप्लोर करने के लिए commands चलाता है, लेकिन आपके source को edit नहीं करता है। जब तक आप plan को approve नहीं करते, edits ब्लॉक रहते हैं।
• acceptEdits: file edits बिना किसी प्रॉम्प्ट के चलते हैं, साथ ही filesystem commands mkdir, touch, rm, rmdir, mv, cp और sed भी। यह केवल आपकी working directory या आपके additionalDirectories के भीतर के paths पर लागू होता है। अन्य सभी shell commands के लिए अभी भी प्रॉम्प्ट आता है।
• auto: सब कुछ चलता है, जिसमें classifier प्रत्येक action की पहले जाँच करता है। स्पष्ट ask नियम अभी भी प्रॉम्प्ट के लिए बाध्य करते हैं।
• dontAsk: Claude Code किसी भी ऐसी चीज़ को auto-deny कर देता है जिसके लिए आपको प्रॉम्प्ट मिलता। केवल आपके allow नियम, इन-बिल्ट read-only Bash commands, और वे कॉल्स जिन्हें PreToolUse हुक approve करता है, वही चलेंगे। सेशन कभी भी इनपुट के लिए प्रतीक्षा नहीं करता है।
• bypassPermissions: प्रॉम्प्ट्स और सुरक्षा जाँचों को छोड़ दिया जाता है, जिसमें .git और .claude जैसे सुरक्षित paths पर लिखना भी शामिल है।

सेशन के दौरान Shift+Tab दबाकर default से acceptEdits और फिर plan तक साइकिल चलाएं। स्टेटस बार दिखाता है कि आप कहाँ पहुँचे हैं, जैसे कि ⏵⏵ auto mode on या ग्रे रंग का ⏸ manual mode on। अन्य मोड डिफ़ॉल्ट रूप से उस साइकिल में नहीं होते हैं। auto इसमें तब जुड़ता है जब आपका अकाउंट इसके लिए आवश्यकताओं को पूरा करता है। bypassPermissions इसमें केवल तब जुड़ता है जब सेशन --permission-mode bypassPermissions या --dangerously-skip-permissions के साथ शुरू किया गया हो। dontAsk वहाँ कभी दिखाई नहीं देता, इसलिए इसे claude --permission-mode dontAsk के साथ सेट करें।

Auto मोड के लिए एक हालिया मॉडल की भी आवश्यकता होती है, जो कि इसके दिखाई न देने का सामान्य कारण है। अगस्त 2026 तक, डॉक्यूमेंटेशन में Anthropic API पर Claude Opus 4.6 या बाद के संस्करण, Sonnet 4.6 या बाद के संस्करण, और Fable 5 सूचीबद्ध हैं, और यह कहता है कि Sonnet 4.5 जैसे पुराने मॉडल किसी भी प्रदाता पर समर्थित नहीं हैं। यदि Claude Code यह रिपोर्ट करता है कि auto मोड अनुपलब्ध है, तो इसका मतलब है कि उन आवश्यकताओं में से कोई एक पूरी नहीं हुई है। यह कोई अस्थायी आउटेज नहीं है, इसलिए प्रतीक्षा करने से यह ठीक नहीं होगा।

दो नियंत्रण हर मोड में बने रहते हैं, जिसमें bypassPermissions भी शामिल है: deny नियम और स्पष्ट ask नियम। ये वे नियंत्रण हैं जिन्हें आप बनाए रखते हैं, चाहे सेशन किसी भी मोड में शुरू हो।

ऑटो मोड क्लासिफायर क्या ब्लॉक करता है

क्लासिफायर एक दूसरा मॉडल है जो लंबित एक्शन को पढ़ता है और यह तय करता है कि क्या वह आपकी मांग के अनुरूप है। डॉक्यूमेंटेशन इसके काम को एक वाक्य में इस प्रकार बताता है:

एक अलग क्लासिफायर मॉडल एक्शन के चलने से पहले उनकी समीक्षा करता है, और किसी भी ऐसी चीज को ब्लॉक कर देता है जो आपके अनुरोध से आगे बढ़ती है, अज्ञात इंफ्रास्ट्रक्चर को लक्षित करती है, या Claude द्वारा पढ़े गए हानिकारक कंटेंट से प्रेरित लगती है।

डिफ़ॉल्ट रूप से ब्लॉक की गई श्रेणियां, जो एक सर्वर ऑपरेटर को सबसे अधिक मिलती हैं:

• कोड डाउनलोड और निष्पादित करना, जैसे कि curl | bash
• प्रोडक्शन डिप्लॉय और माइग्रेशन
• Force push
• साझा इंफ्रास्ट्रक्चर में बदलाव करना
• ऐसा टनल या रिवर्स शेल खोलना जो लोकल सर्विस को पब्लिक इंटरनेट से सुलभ बना दे
• ट्रांसक्रिप्ट या किसी फाइल में लाइव क्रेडेंशियल या टोकन प्रिंट करना

डिफ़ॉल्ट रूप से अनुमत:

• आपकी वर्किंग डायरेक्टरी में लोकल फाइल ऑपरेशंस
• आपकी लॉक फाइल्स या मैनिफेस्ट में घोषित डिपेंडेंसी इंस्टॉल करना
• Read-only HTTP अनुरोध
• जिस रिपॉजिटरी पर आप काम कर रहे हैं, उसकी किसी भी ब्रांच में पुश करना

ऊपर दिए गए सारांश के आधार पर काम न करें। पूरी नियम सूची को JSON के रूप में प्रिंट करने के लिए claude auto-mode defaults चलाएं, और उस सेट को पढ़ें जो आपके द्वारा इंस्टॉल किए गए वर्ज़न के साथ आया है।

इस पर निर्भर होने से पहले दो डॉक्यूमेंटेड सीमाएं महत्वपूर्ण हैं। पहला, क्लासिफायर आपके संदेशों, टूल कॉल्स और आपके CLAUDE.md कंटेंट को देखता है, और टूल के परिणाम हटा दिए जाते हैं, इसलिए फाइल या वेब पेज के अंदर का टेक्स्ट जिसे Claude ने पढ़ा है, वह सीधे क्लासिफायर को संबोधित नहीं कर सकता। दूसरा, जब क्लासिफायर लगातार 3 बार या एक सेशन में 20 बार किसी एक्शन को ब्लॉक करता है, तो ऑटो मोड रुक जाता है और Claude Code वापस आपको प्रॉम्प्ट करने लगता है। ये सीमाएं कॉन्फ़िगर करने योग्य नहीं हैं। -p फ्लैग के साथ नॉन-इंटरैक्टिव मोड में प्रॉम्प्ट करने के लिए कोई नहीं होता है, इसलिए बार-बार ब्लॉक होने पर सेशन समाप्त (abort) हो जाता है।

दूसरा व्यवहार remote box पर समस्या पैदा करता है। कोई unattended run limit पार करते ही रुक जाता है और ऐसे व्यक्ति की प्रतीक्षा करता है जो terminal नहीं देख रहा है। उसी box पर चल रहा दूसरा Claude Code session उस व्यक्ति का विकल्प नहीं है, क्योंकि एक session से दूसरे session को भेजा गया text तब तक रुका रहता है जब तक receiving session उसे उठा नहीं लेता, और permission prompt पर रुके session को अब भी human answer की जरूरत होती है। Agent का लक्ष्य सीमित करना इस समस्या का दूसरा समाधान है, और वह skill जो agent को काम करने वाले सबसे छोटे बदलाव की ओर निर्देशित करती है session को उन विस्तृत actions में भटकने से रोकती है जिन्हें classifier रोक देता है। Skill किसी एक task को दिशा देती है, जबकि output style स्वयं system prompt को edit करती है। इसलिए small, surgical changes मांगने वाली style session के हर turn पर लागू रहती है, केवल उस एक job पर नहीं जिसके लिए आपने उसे invoke किया है।

settings.json में मोड कहाँ स्थित होते हैं

ऊपर दी गई हर चीज़ settings फ़ाइल में एक ऑब्जेक्ट है।

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

नियमों का मूल्यांकन क्रमवार किया जाता है: पहले deny, फिर ask, और अंत में allow। इस क्रम में मिलने वाला पहला मैच परिणाम तय करता है, और कोई संकीर्ण (narrower) नियम पहले आने वाले व्यापक (broader) नियम को ओवरराइड नहीं करता है। Bash(aws *) के लिए एक deny नियम aws s3 ls को ब्लॉक कर देता है, भले ही आपने उस सटीक कमांड को allow किया हो, इसलिए deny नियम में कोई अपवाद (exception) नहीं हो सकता है।

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

Settings फ़ाइलें, निम्नतम प्राथमिकता से उच्चतम प्राथमिकता के क्रम में:

• ~/.claude/settings.json: आपकी user सेटिंग्स, जो हर प्रोजेक्ट पर लागू होती हैं।
• .claude/settings.json: प्रोजेक्ट सेटिंग्स, जो रिपॉजिटरी में कमिट की जाती हैं।
• .claude/settings.local.json: एक रिपॉजिटरी के लिए आपकी अपनी सेटिंग्स, जो git-ignored होती हैं।
• Managed सेटिंग्स, जिन्हें एक एडमिनिस्ट्रेटर द्वारा डिप्लॉय किया जाता है। Linux पर वह फ़ाइल /etc/claude-code/managed-settings.json है। कोई भी चीज़ managed अनुमति नियम को ओवरराइड नहीं कर सकती, यहाँ तक कि कमांड लाइन फ़्लैग भी नहीं।

यहाँ एक समस्या का कारण प्रलेखित (documented) है। Claude Code v2.1.142 के बाद से, जब defaultMode: "auto" को .claude/settings.json या .claude/settings.local.json से सेट किया जाता है, तो उसे अनदेखा कर दिया जाता है, ताकि कोई रिपॉजिटरी सेटिंग्स फ़ाइल भेजकर खुद को auto मोड न दे सके। यदि आप इसे वहाँ सेट करते हैं, तो सेशन बिना किसी त्रुटि के default मोड में शुरू हो जाएगा। उस लाइन को ~/.claude/settings.json में ले जाएँ। प्रत्येक सक्रिय नियम को उसकी फ़ाइल के साथ सूचीबद्ध करने के लिए /permissions चलाएँ।

मोड को बंद करने वाले दो स्विच

एडमिनिस्ट्रेटर के पास दो किल स्विच होते हैं, और दोनों ही बूलियन के बजाय "disable" स्ट्रिंग का उपयोग करते हैं।

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

डॉक्यूमेंटेशन में स्पष्ट रूप से बताया गया है कि इन्हें कहाँ रखना है:

bypassPermissions या auto मोड के उपयोग को रोकने के लिए, किसी भी सेटिंग्स फ़ाइल में permissions.disableBypassPermissionsMode या permissions.disableAutoMode को "disable" पर सेट करें। ये प्रबंधित सेटिंग्स में सबसे अधिक उपयोगी होते हैं जहाँ इन्हें ओवरराइड नहीं किया जा सकता है।

disableAutoMode, auto को Shift+Tab चक्र से हटा देता है और स्टार्टअप पर --permission-mode auto को अस्वीकार कर देता है। disableBypassPermissionsMode बाईपास मोड के लिए भी यही काम करता है, और यह किसी भी स्कोप से काम करता है। इसलिए आप इसे अपनी खुद की ~/.claude/settings.json में सेट कर सकते हैं ताकि आप उस मोड का उपयोग न कर सकें जिसे आप सुबह 2 बजे लाइव सर्वर पर इस्तेमाल नहीं करना चाहते। जिस सर्वर का उपयोग अन्य लोग भी करते हैं, वहाँ इन दोनों को /etc/claude-code/managed-settings.json में रखें, क्योंकि यूजर सेटिंग्स फ़ाइल यूजर की होती है और प्रबंधित फ़ाइल नहीं।

VPS पर auto mode के लिए isolation boundary की आवश्यकता क्यों है

Classifier एक बार में एक action की समीक्षा करता है। इसमें यह जानकारी नहीं होती कि स्वीकृत action बाद में क्या करेगा। Documentation में यह स्पष्ट रूप से बताया गया है:

Classifier प्रति-action नियंत्रण है, न कि कोई isolation boundary। इसलिए, unattended runs के लिए isolation boundary सुरक्षा की एक अतिरिक्त परत जोड़ती है, और यह उस तरह आवश्यक नहीं है जैसे --dangerously-skip-permissions के लिए है।

अतः, remote box के लिए सही संयोजन auto mode और एक ऐसा environment है जिसे खोने में आपको कोई आपत्ति न हो, न कि bypassPermissions और उम्मीद। Bypass mode केवल isolated environments के लिए ही document किया गया है: containers, virtual machines, या बिना internet access वाले dev containers, जहाँ Claude Code आपके host system को नुकसान नहीं पहुँचा सकता। आपका VPS, जिस पर database और reverse proxy चल रहे हैं, इनमें से कुछ भी नहीं है।

सर्वर पर तीन चीजें सबसे अधिक महत्व रखती हैं। Claude Code को हमेशा एक normal user के रूप में चलाएं, कभी भी root के रूप में नहीं। उस user को केवल एक working directory दें और कुछ भी ऐसा न दें जिसे पढ़ना महत्वपूर्ण हो। Box को repair करने के बजाय उसे rebuild करें, जो प्रत्येक job के बाद नष्ट की जाने वाली disposable VM के पक्ष में तर्क है। इनके पीछे की hardening detail, user creation से लेकर firewall rules तक, VPS पर Claude Code चलाने के लिए पूर्ण सुरक्षा गाइड में दी गई है, इसलिए यहाँ उसे दोहराया नहीं गया है।

Claude Code स्वयं root rule को लागू करता है। Linux और macOS पर यह sudo के अंतर्गत या root के रूप में bypass mode में शुरू होने से मना कर देता है:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

यह जाँच एक पहचाने गए sandbox के अंदर छोड़ दी जाती है, इसीलिए autonomous container कार्य के लिए document किया गया उत्तर एक ऐसा dev container है जो Claude Code को non-root user के रूप में चलाता है। यदि आप agent को phone या laptop से SSH के माध्यम से चलाते हैं, तो यही तर्क tmux में खुले रखे गए लंबे समय तक चलने वाले Claude Code session पर भी लागू होता है: session चलने के दौरान prompt को कोई नहीं देख रहा होता है। इनमें से कुछ भी तब तक शुरू नहीं होता जब तक login सफल न हो जाए, इसलिए यदि box आपको Permission denied (publickey) के साथ मना कर देता है, तो verbose SSH output आपको बताएगा कि वास्तव में पाँच दोषों में से कौन सा दोष आपके पास है।

Ubuntu VPS पर Bash sandbox सेट अप करें

इन-बिल्ट sandbox हर उस Bash command के filesystem और network access को प्रतिबंधित करता है जिसे Claude चलाता है, और operating system इसे child processes पर भी लागू करता है। Linux पर इसके लिए दो packages की आवश्यकता होती है।

sudo apt-get install bubblewrap socat

Claude Code शुरू करें और /sandbox चलाएँ। पैनल एक Mode tab और एक Overrides tab के साथ खुलता है, साथ ही एक Dependencies tab भी होता है जो किसी भी missing dependency को सूचीबद्ध करता है। dependency check startup पर चलता है, इसलिए packages install करने के बाद Claude Code को restart करें, अन्यथा पैनल अभी भी उन्हें अनुपस्थित दिखाएगा।

Ubuntu 24.04 और उसके बाद के versions पर, default AppArmor policy bubblewrap को उन user namespaces को बनाने से रोकती है जिनकी उसे आवश्यकता होती है, इसलिए sandbox start होने में विफल हो जाता है। जाँचें कि क्या यह आपके box पर लागू होता है:

sysctl kernel.apparmor_restrict_unprivileged_userns

0, या यह error कि key मौजूद नहीं है, का मतलब है कि कुछ भी करने की आवश्यकता नहीं है। 1 का मतलब है कि bwrap को अपने स्वयं के profile की आवश्यकता है:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

यह profile स्वयं bwrap पर लागू होता है, न कि उन commands पर जिन्हें वह sandbox के अंदर चलाता है। फिर settings में boundary को सीमित करें:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

वह block project की .claude/settings.json में होना चाहिए, क्योंकि . केवल project settings से ही project root पर resolve होता है। वही lines ~/.claude/settings.json में डालें और . इसके बजाय ~/.claude पर resolve होगा, इसलिए denyRead rule आपके project files को blocked रखेगा और हर command उस code को पढ़ने में विफल हो जाएगी जिसे उसे edit करना है।

जानें कि यह क्या कवर नहीं करता है। sandbox Bash और उसकी child processes को सीमित करता है। इन-बिल्ट file tools Claude Code process के अंदर चलते हैं, और MCP (model context protocol) servers तथा hooks अलग processes हैं जो host पर बिना किसी प्रतिबंध के चलते हैं। उन सभी को एक boundary के पीछे रखने के लिए, पूरी Claude Code process को एक container, एक virtual machine, या @anthropic-ai/sandbox-runtime package के अंदर चलाएँ, जो लिखते समय एक beta research preview है।

प्रत्येक सेटअप के लिए कौन सा मोड उपयुक्त है?

आपके अपने लैपटॉप पर एक सोलो रिपॉजिटरी

auto का उपयोग करें, उन क्रियाओं पर ask नियमों के साथ जिन्हें आप होते हुए देखना चाहते हैं। आप कीबोर्ड पर हैं, क्लासिफायर फॉलबैक आप तक पहुँच सकता है, और नुकसान आपके द्वारा नियंत्रित एक मशीन तक सीमित है। यह वह स्थिति है जिसके लिए 14 अगस्त का डिफ़ॉल्ट लिखा गया था।

एक साझा VPS

प्रति उपयोगकर्ता auto का उपयोग करें, जिसे प्रत्येक उपयोगकर्ता की अपनी ~/.claude/settings.json में सेट किया गया हो, ऐसे बॉक्स पर जहाँ Claude Code चलाने वाला अकाउंट root न हो और अन्य उपयोगकर्ताओं के काम को न पढ़ सके। disableBypassPermissionsMode को "disable" के रूप में /etc/claude-code/managed-settings.json में तैनात करें, साथ ही उन deny नियमों के साथ जो साझा पथों (shared paths) की सुरक्षा करते हैं। एक साझा बॉक्स सबसे स्पष्ट स्थिति है जहाँ bypassPermissions गलत है, क्योंकि वह आइसोलेशन बाउंड्री जो यह मोड मानकर चलता है, मौजूद ही नहीं होती: अन्य टेनेंट्स इसके अंदर होते हैं।

CI और अनअटेंडेड सेशन

dontAsk का उपयोग करें, जिसमें उन कमांड्स की एक स्पष्ट allow सूची हो जिनकी जॉब को आवश्यकता है। जब कोई व्यक्ति प्रॉम्प्ट नहीं देख रहा हो, तो Auto-deny ही सही फेल्योर मोड है। Auto मोड भी नॉन-इंटरैक्टिव रूप से चलता है, लेकिन बार-बार क्लासिफायर ब्लॉक होने से -p सेशन रुक जाता है, इसलिए जो जॉब इनसे टकराती है, वह बीच में ही अधूरे काम के साथ विफल हो जाती है। bypassPermissions को केवल ऐसे कंटेनर या वर्चुअल मशीन के लिए रखें जिसे आप इमेज से फिर से बनाते हैं, और इसे किसी ऐसे होस्ट से दूर रखें जिस पर आप कोई महत्वपूर्ण काम चला रहे हों।

FAQ

Claude Code में auto mode डिफ़ॉल्ट कब बनता है?

14 अगस्त 2026 से, Pro, Max और Team plans पर नए sessions के लिए। दस्तावेज़ीकरण में यह जोड़ा गया है कि आप किसी भी समय modes बदल सकते हैं, आपके द्वारा सेट किया गया डिफ़ॉल्ट तब तक बना रहता है जब तक आप वन-टाइम स्विच प्रॉम्प्ट स्वीकार नहीं करते, और आपके संगठन द्वारा प्रबंधित डिफ़ॉल्ट में कोई बदलाव नहीं होता है। घोषणा में उल्लेख है कि रोलआउट के पहले भाग के दौरान Enterprise plans और API का उपयोग करने वाले खातों के लिए auto mode वैकल्पिक रहता है। यह जाँचने के लिए कि session वर्तमान में किस mode में है, status bar देखें, जो auto mode में ⏵⏵ auto mode on दिखाता है।

क्या मुझे VPS पर auto mode या bypassPermissions का उपयोग करना चाहिए?

Auto mode का उपयोग करें, साथ ही एक isolation boundary भी रखें। classifier प्रत्येक action के चलने से पहले उसकी समीक्षा करता है, लेकिन दस्तावेज़ीकरण स्पष्ट है कि यह प्रति-action नियंत्रण है, न कि isolation boundary। इसलिए, unattended run के लिए अभी भी एक container, virtual machine, या ऐसा box चाहिए जिसे आप फिर से बनाने के लिए तैयार हों। bypassPermissions पूरी तरह से जाँच को छोड़ देता है और इसे केवल isolated environments के लिए प्रलेखित किया गया है। Claude Code Linux पर root के रूप में उस mode में शुरू होने से इनकार करता है और --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons प्रिंट करता है।

मैं अपने सर्वर पर किसी को भी auto mode या bypass mode का उपयोग करने से कैसे रोकूँ?

/etc/claude-code/managed-settings.json में permissions.disableAutoMode और permissions.disableBypassPermissionsMode को "disable" स्ट्रिंग पर सेट करें। प्रबंधित सेटिंग्स अन्य सभी scopes से ऊपर होती हैं, इसलिए कोई भी उपयोगकर्ता सेटिंग्स फ़ाइल और कोई भी कमांड लाइन फ़्लैग उन्हें ओवरराइड नहीं कर सकता है। disableAutoMode, Shift+Tab चक्र से auto को हटा देता है और स्टार्टअप पर --permission-mode auto को अस्वीकार कर देता है। disableBypassPermissionsMode भी किसी भी scope से काम करता है, इसलिए एक उपयोगकर्ता इसे अपने स्वयं के ~/.claude/settings.json में सेट कर सकता है।

मेरी defaultMode: "auto" सेटिंग को अनदेखा क्यों किया जा रहा है?

क्योंकि यह गलत फ़ाइल में है। Claude Code v2.1.142 से, जब defaultMode: "auto", .claude/settings.json या .claude/settings.local.json से आता है तो उसे अनदेखा कर दिया जाता है, ताकि कोई रिपॉजिटरी सेटिंग्स फ़ाइल भेजकर खुद को auto mode प्रदान न कर सके। session default mode में शुरू होता है और कोई त्रुटि प्रिंट नहीं करता है। सेटिंग को ~/.claude/settings.json में ले जाएँ, फिर यह पुष्टि करने के लिए /permissions चलाएँ कि प्रत्येक सक्रिय नियम किस फ़ाइल से आया है। यदि auto mode अभी भी अनुपलब्ध है, तो मॉडल की आवश्यकता की जाँच करें: Sonnet 4.5 जैसे पुराने मॉडल किसी भी प्रदाता पर समर्थित नहीं हैं।