Claude Code auto mode डिफ़ॉल्ट सेटिंग कैसे बदलें

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

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

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

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

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

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

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

इसमें छह मोड हैं। प्रत्येक पंक्ति की शुरुआत में दिया गया नाम वह मान है जिसे आप सेटिंग्स में लिखते हैं या --permission-mode को पास करते हैं।

• default: Claude प्रत्येक नए टूल के उपयोग से पहले पूछता है। आपकी वर्किंग डायरेक्टरी के अंदर की रीड कमांड्स बिना प्रॉम्प्ट के चलती रहती हैं। CLI (कमांड लाइन इंटरफेस) इस मोड को Manual के रूप में लेबल करता है और Claude Code v2.1.200 से manual को एक उपनाम (alias) के रूप में स्वीकार करता है।
• plan: Claude फाइलों को पढ़ता है और एक्सप्लोर करने के लिए कमांड्स चलाता है, लेकिन आपके सोर्स कोड में बदलाव नहीं करता है। जब तक आप प्लान को मंजूरी नहीं देते, तब तक संपादन (edits) ब्लॉक रहते हैं।
• acceptEdits: फाइल संपादन बिना प्रॉम्प्ट के चलते हैं, साथ ही फाइलसिस्टम कमांड्स mkdir, touch, rm, rmdir, mv, cp और sed भी। यह केवल आपकी वर्किंग डायरेक्टरी या आपके additionalDirectories के अंदर के पाथ्स पर लागू होता है। अन्य सभी शेल कमांड्स के लिए अभी भी प्रॉम्प्ट आता है।
• auto: सब कुछ चलता है, जिसमें क्लासिफायर पहले प्रत्येक क्रिया की जांच करता है। स्पष्ट ask नियम अभी भी प्रॉम्प्ट के लिए बाध्य करते हैं।
• dontAsk: Claude Code किसी भी ऐसी चीज़ को स्वतः अस्वीकार (auto-denies) कर देता है जिसके लिए आपको प्रॉम्प्ट मिलता। केवल आपके allow नियम, इन-बिल्ट रीड-ओनली Bash कमांड्स, और वे कॉल्स जिन्हें PreToolUse हुक मंजूरी देता है, वही चलेंगे। सेशन कभी भी इनपुट का इंतजार नहीं करता है।
• bypassPermissions: प्रॉम्प्ट और सुरक्षा जांच को छोड़ दिया जाता है, जिसमें .git और .claude जैसे सुरक्षित पाथ्स पर राइट ऑपरेशन्स भी शामिल हैं।

सेशन के दौरान 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 ऑटो मोड को अनुपलब्ध बताता है, तो इसका मतलब है कि उन आवश्यकताओं में से कोई एक पूरी नहीं हुई है। यह कोई अस्थायी आउटेज नहीं है, इसलिए इंतजार करने से यह ठीक नहीं होगा।

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

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

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

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

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

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

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

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

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

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

वह दूसरा व्यवहार रिमोट बॉक्स पर समस्या पैदा करता है। एक अनअटेंडेड रन जो लिमिट को पार कर जाता है, वह रुक जाता है और किसी ऐसे व्यक्ति का इंतजार करता है जो टर्मिनल नहीं देख रहा है। एजेंट जो करने वाला है उसे सीमित करना समाधान का दूसरा हिस्सा है, और एक कौशल जो एजेंट को सबसे छोटे काम करने वाले बदलाव की ओर धकेलता है सेशन को उन विस्तृत एक्शन्स में भटकने से रोकता है जिन्हें क्लासिफायर रोक देता है।

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: आपकी यूज़र सेटिंग्स, जो हर प्रोजेक्ट में लागू होती हैं।
• .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 चलाएँ।

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

Administrators के पास दो kill switches होते हैं, और दोनों ही boolean के बजाय "disable" स्ट्रिंग का उपयोग करते हैं।

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

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

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

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

VPS पर ऑटो मोड को आइसोलेशन बाउंड्री की आवश्यकता क्यों है

क्लासिफायर एक बार में एक ही एक्शन की समीक्षा करता है। इसमें यह शामिल नहीं होता कि एक स्वीकृत एक्शन बाद में क्या करता है। डॉक्यूमेंटेशन इस सीमा को स्पष्ट रूप से निर्धारित करता है:

क्लासिफायर प्रति-एक्शन नियंत्रण है, न कि आइसोलेशन बाउंड्री। इसलिए, अनअटेंडेड रन (बिना निगरानी के चलने वाले कार्यों) के लिए आइसोलेशन बाउंड्री सुरक्षा की एक अतिरिक्त परत जोड़ती है, और यह --dangerously-skip-permissions की तरह अनिवार्य नहीं है।

इसलिए, रिमोट बॉक्स के लिए सही तरीका ऑटो मोड के साथ एक ऐसा एनवायरनमेंट है जिसे खोने का जोखिम आप उठा सकते हैं, न कि केवल bypassPermissions पर भरोसा करना। बाईपास मोड केवल आइसोलेटेड एनवायरनमेंट के लिए डॉक्यूमेंटेड है: कंटेनर, वर्चुअल मशीन, या बिना इंटरनेट एक्सेस वाले डेव कंटेनर, जहाँ Claude Code आपके होस्ट सिस्टम को नुकसान नहीं पहुँचा सकता। एक VPS जो आपका डेटाबेस और रिवर्स प्रॉक्सी चला रहा है, वह इनमें से कुछ भी नहीं है।

सर्वर पर तीन चीजें सबसे अधिक महत्वपूर्ण हैं। Claude Code को हमेशा एक सामान्य यूजर के रूप में चलाएं, कभी भी root के रूप में नहीं। उस यूजर को केवल एक वर्किंग डायरेक्टरी दें और उसके अलावा कुछ भी ऐसा न दें जिसे पढ़ना महत्वपूर्ण हो। बॉक्स को रिपेयर करने के बजाय उसे रीबिल्ड करें, जो कि प्रत्येक कार्य के बाद नष्ट की जाने वाली डिस्पोजेबल VM का मुख्य तर्क है। इनके पीछे की हार्डनिंग डिटेल, यूजर क्रिएशन से लेकर फायरवॉल रूल्स तक, VPS पर Claude Code चलाने के लिए पूर्ण सुरक्षा गाइड में कवर की गई है, इसलिए इसे यहाँ दोहराया नहीं गया है।

Claude Code स्वयं root नियम को लागू करता है। Linux और macOS पर यह sudo के तहत या root के रूप में बाईपास मोड में शुरू होने से इनकार कर देता है:

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

यह जांच एक पहचाने गए सैंडबॉक्स के अंदर छोड़ दी जाती है, यही कारण है कि ऑटोनॉमस कंटेनर वर्क के लिए डॉक्यूमेंटेड उत्तर एक ऐसा डेव कंटेनर है जो Claude Code को नॉन-root यूजर के रूप में चलाता है। यदि आप SSH के माध्यम से फोन या लैपटॉप से एजेंट को नियंत्रित करते हैं, तो यही तर्क tmux में खुले रहने वाले लंबे Claude Code सेशन पर भी लागू होता है: सेशन चलने के दौरान प्रॉम्प्ट पर कोई निगरानी नहीं रख रहा होता है।

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 और उसके बाद के संस्करणों पर, डिफ़ॉल्ट AppArmor policy bubblewrap को उन user namespaces को बनाने से रोकती है जिनकी उसे आवश्यकता होती है, इसलिए sandbox शुरू होने में विफल हो जाता है। जांचें कि क्या यह आपके 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 को block रखता है और हर 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 प्लान के नए सत्रों (sessions) के लिए। दस्तावेज़ीकरण में कहा गया है कि आप किसी भी समय मोड बदल सकते हैं। यदि आप स्वयं कोई डिफ़ॉल्ट सेट करते हैं, तो वह तब तक बना रहता है जब तक आप वन-टाइम स्विच प्रॉम्प्ट स्वीकार नहीं करते। यदि आपकी संस्था द्वारा कोई डिफ़ॉल्ट सेट किया गया है, तो वह अपरिवर्तित रहता है। घोषणा में उल्लेख है कि Enterprise प्लान और रोलआउट के पहले चरण के दौरान API का उपयोग करने वाले खातों के लिए auto mode वैकल्पिक बना रहेगा। यह देखने के लिए कि सत्र किस मोड में है, स्टेटस बार देखें; auto mode में यह ⏵⏵ auto mode on दिखाता है।

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

Auto mode का उपयोग करें, साथ ही एक isolation boundary भी रखें। क्लासिफायर प्रत्येक क्रिया को चलाने से पहले उसकी समीक्षा करता है, लेकिन दस्तावेज़ीकरण स्पष्ट करता है कि यह प्रति-क्रिया नियंत्रण है, न कि isolation boundary। इसलिए, unattended रन के लिए अभी भी एक container, virtual machine या ऐसे box की आवश्यकता होती है जिसे आप फिर से बनाने के लिए तैयार हों। bypassPermissions पूरी तरह से जांच को छोड़ देता है और इसे केवल isolated वातावरण के लिए अनुशंसित किया गया है। Claude Code Linux पर root के रूप में इस मोड में शुरू होने से इनकार कर देता है और --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" स्ट्रिंग पर सेट करें। प्रबंधित सेटिंग्स (managed settings) अन्य सभी स्कोप से ऊपर होती हैं, इसलिए कोई भी उपयोगकर्ता सेटिंग्स फ़ाइल या कमांड लाइन फ्लैग उन्हें ओवरराइड नहीं कर सकता है। disableAutoMode, Shift+Tab चक्र से auto को हटा देता है और स्टार्टअप पर --permission-mode auto को अस्वीकार कर देता है। disableBypassPermissionsMode किसी भी स्कोप से काम करता है, इसलिए एक उपयोगकर्ता इसे अपने स्वयं के ~/.claude/settings.json में सेट कर सकता है।

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

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