Claude Code auto mode: 14 August 2026 पासून default

14 August 2026 रोजी auto mode मध्ये होणारे बदल

Claude Code मधील auto mode टूल कॉल्स थांबवून तुमची परवानगी मागत नाही. त्याऐवजी प्रत्येक कृती आधी स्वतंत्र classifier model कडे पुनरावलोकनासाठी पाठवली जाते. 14 August 2026 पासून Pro, Max आणि Team plans वरील नवीन sessions याच mode मध्ये सुरू होतील. तुम्ही कोणत्याही वेळी mode बदलू शकता. तुम्ही स्वतः आधीच सेट केलेला default बदलला जाणार नाही.

दस्तऐवजीकरण या बदलाचे वर्णन पुढीलप्रमाणे करते:

14 August 2026 पासून Pro, Max आणि Team plans वरील नवीन sessions साठी auto mode हा default permission mode होईल. तुम्ही कोणत्याही वेळी mode बदलू शकता. तुम्ही स्वतः सेट केलेला default कायम राहील, जोपर्यंत तुम्ही एकदाच दाखवली जाणारी mode बदलण्याची सूचना स्वीकारत नाही. तुमची संस्था व्यवस्थापित करत असलेला default बदलणार नाही.

यातील तारखेपेक्षा दोन मुद्दे अधिक महत्त्वाचे आहेत. तुमच्या स्वतःच्या settings file मध्ये सेट केलेला defaultMode हा बदल झाल्यानंतरही कायम राहतो. तुमची संस्था managed settings द्वारे लागू करत असलेला default देखील कायम राहतो. घोषणा पोस्ट नुसार rollout च्या सुरुवातीच्या टप्प्यात Enterprise plans आणि API वापरणाऱ्या accounts साठी auto mode ऐच्छिक राहील.

तुम्ही Claude Code VPS (virtual private server) वर चालवत असल्यास, हा बदल लागू होण्यापूर्वी त्याची माहिती घेणे उपयुक्त ठरेल. Permission prompt हा keyboard समोर असलेल्या व्यक्तीच्या प्रतिसादाची गरज असलेला checkpoint असतो. Remote box वर तुम्ही अनेकदा उपस्थित नसता. त्यामुळे session ज्या mode मध्ये सुरू होते, तोच mode अनेक तास कायम राहतो.

Claude Code चे permission modes: सर्वाधिक देखरेखीपासून किमान देखरेखीपर्यंत

एकूण सहा modes आहेत. प्रत्येक ओळीच्या सुरुवातीला असलेले नाव settings मध्ये लिहायचे किंवा --permission-mode कडे pass करायचे value आहे.

• default: प्रत्येक नवीन tool वापरण्यापूर्वी Claude विचारतो. तुमच्या working directory मधील reads मात्र prompt शिवाय चालतात. CLI (command line interface) या mode ला Manual असे label करते आणि Claude Code v2.1.200 पासून manual हा alias स्वीकारते.
• plan: Claude files read करते आणि explore करण्यासाठी commands चालवते; तुमच्या source मध्ये edit करत नाही. तुम्ही plan approve करेपर्यंत edits blocked राहतात.
• acceptEdits: file edits prompt शिवाय चालतात. त्यासोबत mkdir, touch, rm, rmdir, mv, cp आणि sed हे filesystem commands देखील चालतात. हे फक्त तुमच्या working directory किंवा तुमच्या additionalDirectories मधील paths साठी लागू आहे. इतर प्रत्येक shell command साठी prompt दाखवला जातो.
• auto: सर्वकाही चालते; मात्र classifier प्रत्येक action आधी तपासतो. स्पष्ट ask rules असल्यास prompt दाखवणे अद्याप आवश्यक राहते.
• dontAsk: तुमच्याकडे prompt दाखवला असता अशा प्रत्येक कृतीला Claude Code आपोआप deny करते. फक्त तुमचे allow rules, built-in read-only Bash commands आणि PreToolUse hook ने approve केलेले calls चालतात. Session input साठी कधीही थांबत नाही.
• bypassPermissions: prompts आणि safety checks वगळले जातात. यात .git आणि .claude यांसारख्या protected paths वरील writes देखील समाविष्ट आहेत.

Session दरम्यान Shift+Tab दाबल्यास default, acceptEdits आणि plan यांमध्ये क्रमाने बदल करता येतो. Status bar मध्ये सध्या कोणता mode निवडला आहे ते दिसते, उदाहरणार्थ ⏵⏵ auto mode on किंवा gray ⏸ manual mode on. इतर modes default ने या cycle मध्ये नसतात. तुमचे account त्यासाठीच्या requirements पूर्ण केल्यानंतर auto या cycle मध्ये सामील होते. Session --permission-mode bypassPermissions किंवा --dangerously-skip-permissions ने सुरू केल्यावरच bypassPermissions या cycle मध्ये सामील होते. dontAsk या cycle मध्ये कधीही दिसत नाही; ते सेट करण्यासाठी claude --permission-mode dontAsk वापरा.

Auto mode साठी अलीकडील model देखील आवश्यक आहे. तो दिसतच नसण्याचे हेच सामान्य कारण आहे. August 2026 पर्यंत documentation मध्ये Anthropic API वर Claude Opus 4.6 किंवा त्यानंतरचे versions, Sonnet 4.6 किंवा त्यानंतरचे versions आणि Fable 5 सूचीबद्ध आहेत. Sonnet 4.5 सारखे जुने models कोणत्याही provider वर supported नाहीत, असेही documentation मध्ये नमूद आहे. Claude Code ने auto mode unavailable असल्याचे दाखवले, तर यापैकी एखादी requirement पूर्ण झालेली नाही. ही temporary outage नाही; त्यामुळे प्रतीक्षा केल्याने समस्या सुटणार नाही.

bypassPermissions सह प्रत्येक mode मध्ये दोन controls लागू राहतात: deny rules आणि स्पष्ट ask rules. Session कोणत्याही mode मध्ये सुरू झाले तरी हेच controls तुमच्या ताब्यात राहतात.

ऑटो मोड वर्गीकरणकर्ता कोणत्या कृती रोखतो

वर्गीकरणकर्ता हे दुसरे मॉडेल आहे. ते प्रलंबित कृती वाचते आणि ती तुम्ही दिलेल्या विनंतीच्या चौकटीत बसते का हे ठरवते. दस्तऐवजात त्याचे काम एका वाक्यात सांगितले आहे:

कृती सुरू होण्यापूर्वी स्वतंत्र वर्गीकरणकर्ता मॉडेल त्यांचे पुनरावलोकन करते. तुमच्या विनंतीच्या पलीकडे जाणाऱ्या, अपरिचित पायाभूत सुविधांना लक्ष्य करणाऱ्या किंवा Claude ने वाचलेल्या धोकादायक मजकुरामुळे प्रेरित झालेल्या कृती ते रोखते.

सर्व्हर ऑपरेटरला सर्वाधिक आढळणाऱ्या पुढील प्रकारच्या कृती डीफॉल्टनुसार रोखल्या जातात:

• कोड डाउनलोड करून चालवणे, जसे की curl | bash
• Production deploys आणि migrations
• Force push
• सामायिक पायाभूत सुविधांमध्ये बदल करणे
• स्थानिक सेवा सार्वजनिक इंटरनेटवरून पोहोचण्यायोग्य करणारा tunnel किंवा reverse shell उघडणे
• चालू credential किंवा token transcript किंवा फाइलमध्ये छापणे

पुढील कृती डीफॉल्टनुसार अनुमत आहेत:

• तुमच्या working directory मधील स्थानिक फाइल ऑपरेशन्स
• तुमच्या lock files किंवा manifests मध्ये घोषित केलेल्या dependencies इन्स्टॉल करणे
• Read-only HTTP requests
• तुम्ही ज्या repository मध्ये काम करत आहात तिच्या कोणत्याही branch वर push करणे

वरील सारांशावर अवलंबून राहू नका. संपूर्ण rule lists JSON म्हणून छापण्यासाठी claude auto-mode defaults चालवा आणि तुम्ही इन्स्टॉल केलेल्या version सोबत आलेला संच वाचा.

यावर अवलंबून राहण्यापूर्वी दोन दस्तऐवजीकृत मर्यादा लक्षात घ्या. पहिली, वर्गीकरणकर्ता तुमचे messages, tool calls आणि तुमची CLAUDE.md content पाहतो. Tool results काढून टाकले जातात. त्यामुळे Claude ने वाचलेल्या फाइलमधील किंवा web page मधील मजकूर वर्गीकरणकर्त्याला थेट संबोधित करू शकत नाही. दुसरी, वर्गीकरणकर्ता सलग 3 वेळा किंवा एका session मध्ये 20 वेळा एखादी कृती रोखल्यास auto mode थांबतो आणि Claude Code पुन्हा तुम्हाला prompt करते. हे thresholds configure करता येत नाहीत. -p flag असलेल्या non-interactive mode मध्ये prompt देण्यासाठी कोणीही नसते. त्यामुळे वारंवार झालेल्या blocks मुळे त्याऐवजी session abort होते.

दूरस्थ box वर दुसरे वर्तन विशेषतः अडचणीचे ठरते. Unattended run ने ही मर्यादा ओलांडल्यास तो थांबतो आणि terminal कडे पाहत नसलेल्या व्यक्तीची वाट पाहतो. Agent ने करावयाच्या कामाची व्याप्ती मर्यादित करणे हा उपायाचा दुसरा भाग आहे. कार्य करणारा सर्वात छोटा बदल करण्याकडे agent ला प्रवृत्त करणारे skill वापरल्यास session classifier थांबवतो अशा विस्तृत कृतींकडे भरकटत नाही.

settings.json मध्ये modes कुठे असतात

वरील सर्व मजकूर settings फाइलमधील एका object मध्ये असतो.

{
  "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 *)"
    ]
  }
}

Rules क्रमाने तपासले जातात: प्रथम deny, त्यानंतर ask आणि शेवटी allow. या क्रमातील पहिला match अंतिम परिणाम ठरवतो. आधी आलेला व्यापक rule नंतरच्या अधिक विशिष्ट rule पेक्षा प्राधान्याने लागू होतो. Bash(aws *) साठीचा deny rule aws s3 ls block करतो, जरी तुम्ही त्याच command ला स्वतंत्रपणे allow केलेले असले तरी. त्यामुळे deny rule मध्ये exceptions देता येत नाहीत.

Auto mode मध्ये ask हा rule type विशेष उपयोगी ठरतो. Auto mode मधील नेहमीचा prompt काढून टाकला जातो. तुम्हाला एखाद्या विशिष्ट command साठी मानवी पुष्टी हवी असल्यास ask rule तो prompt पुन्हा लागू करतो. तुमचा deploy command तिथे असावा. Code मशीनबाहेर पाठवण्यापूर्वी checkpoint हवा असल्यास Bash(git push *) देखील तिथे ठेवावा. Credential files deny मध्ये ठेवणे हा त्याच व्यवस्थेचा दुसरा भाग आहे. हे credentials agent च्या आवाक्याबाहेर ठेवण्याशी संबंधित आहे.

Settings फाइल्स, सर्वात कमी precedence पासून:

• ~/.claude/settings.json: तुमची user settings. ती प्रत्येक project मध्ये लागू होतात.
• .claude/settings.json: project settings. त्या repository मध्ये commit केल्या जातात.
• .claude/settings.local.json: एका repository साठीच्या तुमच्या स्वतःच्या settings. त्या git-ignored असतात.
• Managed settings, administrator कडून deploy केल्या जातात. Linux वर ती फाइल /etc/claude-code/managed-settings.json असते. Managed permission rule ला कोणतीही गोष्ट override करू शकत नाही, command line flag देखील नाही.

येथे एका अडचणीचे कारण documented आहे. Claude Code v2.1.142 पासून .claude/settings.json किंवा .claude/settings.local.json मधून आलेले defaultMode: "auto" ignore केले जाते. त्यामुळे repository स्वतःची settings file देऊन auto mode सुरू करू शकत नाही. तेथे ही line सेट केल्यास session कोणताही error न दाखवता default mode मध्ये सुरू होते. ही line ~/.claude/settings.json मध्ये हलवा. प्रत्येक active rule आणि तो कोणत्या फाइलमधून आला आहे हे शेजारी दाखवण्यासाठी /permissions चालवा.

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

प्रशासकांकडे दोन kill switch असतात आणि दोन्ही boolean ऐवजी "disable" ही string स्वीकारतात.

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

ती कुठे ठेवायची हे documentation मध्ये स्पष्टपणे सांगितले आहे:

bypassPermissions किंवा auto mode वापरला जाऊ नये असे असल्यास, कोणत्याही settings file मध्ये permissions.disableBypassPermissionsMode किंवा permissions.disableAutoMode चे मूल्य "disable" ठेवा. हे managed settings मध्ये सर्वाधिक उपयुक्त ठरतात, कारण त्यांना override करता येत नाही.

disableAutoMode auto ला Shift+Tab cycle मधून काढते आणि startup वेळी --permission-mode auto नाकारते. bypass mode साठी disableBypassPermissionsMode हेच काम करते आणि ते कोणत्याही scope मधून लागू होते. त्यामुळे live server वर पहाटे 2 वाजता वापरायचा टाळू इच्छित असलेला mode स्वतःपासून बंद करण्यासाठी ते आपल्या ~/.claude/settings.json मध्ये सेट करू शकता. इतर लोक वापरत असलेल्या box वर दोन्ही /etc/claude-code/managed-settings.json मध्ये ठेवा. user settings file ही त्या user ची असते, तर managed file user ची नसते.

VPS वरील auto mode साठी isolation boundary का आवश्यक आहे

Classifier एका वेळी एका action चे पुनरावलोकन करतो. मंजूर केलेल्या action मुळे पुढे काय घडते, हे त्यात समाविष्ट नसते. Documentation मध्ये ही मर्यादा स्पष्टपणे सांगितली आहे:

Classifier हे प्रत्येक action साठीचे नियंत्रण आहे, isolation boundary नाही. त्यामुळे unattended runs साठी isolation boundary अतिरिक्त defense in depth देते; --dangerously-skip-permissions साठी ती ज्या प्रकारे आवश्यक आहे, त्या प्रकारे येथे आवश्यक नाही.

म्हणून remote box साठी योग्य संयोजन म्हणजे auto mode आणि गमावण्यास हरकत नसलेले environment. bypassPermissions आणि केवळ आशा, हे योग्य संयोजन नाही. Bypass mode फक्त isolated environments साठी documented आहे: containers, virtual machines किंवा internet access नसलेले dev containers. अशा environment मध्ये Claude Code तुमच्या host system ला हानी पोहोचवू शकत नाही. तुमचा database आणि reverse proxy चालवणारा VPS यापैकी कोणताही प्रकार नाही.

Server वर तीन गोष्टी सर्वाधिक महत्त्वाच्या आहेत. Claude Code सामान्य user म्हणून चालवा; root म्हणून कधीही चालवू नका. त्या user ला working directory द्या आणि वाचण्यासारखे इतर कोणतेही महत्त्वाचे data देऊ नका. Box दुरुस्त करण्याऐवजी तो पुन्हा तयार करा. म्हणूनच प्रत्येक job नंतर टाकून देता येणारा disposable VM वापरण्याचा युक्तिवाद केला जातो. User creation पासून firewall rules पर्यंतची यामागची hardening माहिती VPS वर Claude Code चालवण्यासाठीच्या संपूर्ण safety pass मध्ये दिली आहे. त्यामुळे ती येथे पुन्हा दिलेली नाही.

Claude Code स्वतः root rule लागू करते. Linux आणि macOS वर sudo अंतर्गत किंवा root म्हणून चालवल्यास ते bypass mode मध्ये सुरू होण्यास नकार देते:

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

Recognized sandbox मध्ये ही तपासणी वगळली जाते. म्हणून autonomous container work साठी documented उत्तर म्हणजे Claude Code non-root user म्हणून चालवणारा dev container. SSH द्वारे phone किंवा laptop वरून agent नियंत्रित करत असल्यास हेच तर्क tmux मध्ये उघडे ठेवलेल्या दीर्घकाळ चालणाऱ्या Claude Code session लाही लागू होतात: session चालू असताना prompt वर लक्ष ठेवणारे कोणीही नसते.

Ubuntu VPS वर Bash sandbox सेट करा

अंगभूत sandbox Claude चालवत असलेल्या प्रत्येक Bash command चा filesystem आणि network access मर्यादित करतो. Operating system ही मर्यादा child processes वरही लागू करते. Linux वर यासाठी दोन packages आवश्यक आहेत.

sudo apt-get install bubblewrap socat

Claude Code सुरू करा आणि /sandbox चालवा. Mode tab आणि Overrides tab असलेले panel उघडते. त्यात Dependencies tab देखील असतो, ज्यामध्ये उपलब्ध नसलेल्या सर्व गोष्टींची यादी दिसते. Dependency check startup वेळी चालतो. त्यामुळे packages install केल्यानंतर Claude Code पुन्हा सुरू करा. अन्यथा panel मध्ये ते अजूनही उपलब्ध नसल्याचे दिसेल.

Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये default AppArmor policy मुळे bubblewrap आवश्यक असलेले user namespaces तयार करू शकत नाही. त्यामुळे sandbox सुरू होत नाही. ही अडचण तुमच्या server वर लागू आहे का ते तपासा:

sysctl kernel.apparmor_restrict_unprivileged_userns

0 किंवा key अस्तित्वात नसल्याचे सांगणारी error दिसल्यास काहीही करण्याची गरज नाही. 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 sandbox मध्ये चालवलेल्या commands साठी नसून स्वतः bwrap साठी लागू होतो. त्यानंतर settings मध्ये boundary अधिक मर्यादित करा:

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

हा block project's .claude/settings.json मध्ये असणे आवश्यक आहे, कारण project settings मधूनच . project root कडे resolve होतो. त्याच lines ~/.claude/settings.json मध्ये ठेवल्यास . त्याऐवजी ~/.claude कडे resolve होतो. त्यामुळे denyRead rule तुमच्या project files ला blocked ठेवतो आणि प्रत्येक command ला ज्या code मध्ये बदल करायचा आहे तो code वाचता येत नाही.

ही रचना कोणत्या गोष्टी नियंत्रित करत नाही हे समजून घ्या. Sandbox Bash आणि त्याच्या child processes वर मर्यादा घालतो. अंगभूत file tools Claude Code process मध्येच चालतात. MCP (model context protocol) servers आणि hooks हे host वर स्वतंत्र processes म्हणून, कोणत्याही मर्यादेशिवाय चालतात. या सर्वांना एकाच boundary मागे ठेवण्यासाठी संपूर्ण Claude Code process container, virtual machine किंवा @anthropic-ai/sandbox-runtime package मध्ये चालवा. हा package हा मजकूर लिहिताना beta research preview आहे.

प्रत्येक सेटअपसाठी कोणता mode योग्य आहे?

तुमच्या स्वतःच्या laptop वरील एकल repo

तुम्हाला दिसाव्यात अशा actions साठी ask नियमांसह auto वापरा. तुम्ही keyboard समोर आहात, classifier fallback तुमच्यापर्यंत प्रत्यक्ष पोहोचू शकतो आणि होणारे नुकसान तुम्ही नियंत्रित करत असलेल्या एका machine पुरते मर्यादित आहे. 14 August चे default याच परिस्थितीसाठी लिहिले गेले होते.

Shared VPS

प्रत्येक user साठी त्याच्या स्वतःच्या ~/.claude/settings.json मध्ये सेट केलेले auto वापरा. ज्या box वर Claude Code चालवणारे account root नाही आणि इतर users चे काम read करू शकत नाही, अशाच ठिकाणी हे करा. disableBypassPermissionsMode ला /etc/claude-code/managed-settings.json मध्ये "disable" म्हणून deploy करा आणि shared paths चे संरक्षण करणारे deny rules देखील जोडा. bypassPermissions चुकीचे ठरण्याचे सर्वात स्पष्ट उदाहरण shared box आहे, कारण त्या mode ने गृहीत धरलेली isolation boundary अस्तित्वात नसते: इतर tenants तिच्याच आत असतात.

CI आणि unattended sessions

Job ला आवश्यक असलेल्या commands ची स्पष्ट allow list देऊन dontAsk वापरा. कोणतीही व्यक्ती prompt पाहणार नसेल, तर auto-deny हा योग्य failure mode आहे. Auto mode non-interactively देखील चालतो; परंतु classifier blocks वारंवार झाल्यास -p session abort होते. त्यामुळे अशा blocks ना सामोरे जाणारे job अर्धवट कामासह मध्येच fail होते. bypassPermissions फक्त image मधून पुन्हा build करता येणाऱ्या container किंवा virtual machine साठी ठेवा आणि ज्या host वर तुम्हाला महत्त्वाची दुसरी कोणतीही गोष्ट चालते, तिथे ते वापरू नका.

FAQ

Claude Code मध्ये auto mode default कधी होते?

14 August 2026 पासून Pro, Max आणि Team plans वरील नवीन sessions साठी auto mode default होते. Documentation नुसार तुम्ही modes कधीही बदलू शकता. तुम्ही स्वतः सेट केलेला default, one-time switch prompt स्वीकारत नाही तोपर्यंत कायम राहतो. तुमची organization व्यवस्थापित करत असलेला default बदलत नाही. Rollout च्या सुरुवातीच्या टप्प्यात Enterprise plans आणि API वापरणाऱ्या accounts साठी auto mode optional राहील, असे announcement मध्ये नमूद आहे. Session प्रत्यक्षात कोणत्या mode मध्ये आहे ते status bar पाहून तपासा. auto mode मध्ये status bar मध्ये ⏵⏵ auto mode on दिसते.

VPS वर auto mode किंवा bypassPermissions वापरावे का?

Isolation boundary सोबत auto mode वापरा. प्रत्येक action चालण्यापूर्वी classifier त्याचे पुनरावलोकन करतो. मात्र documentation स्पष्ट सांगते की हे per-action control आहे; ते isolation boundary नाही. त्यामुळे unattended run साठी container, virtual machine किंवा पुन्हा तयार करण्यास तुम्ही तयार असलेला box आवश्यक आहे. bypassPermissions सर्व checks पूर्णपणे वगळते आणि ते फक्त isolated environments साठी documented आहे. Linux वर root म्हणून त्या mode मध्ये सुरू होण्यास Claude Code नकार देते आणि --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons दाखवते.

माझ्या server वर कोणालाही auto mode किंवा bypass mode वापरता येऊ नये यासाठी काय करावे?

permissions.disableAutoMode आणि permissions.disableBypassPermissionsMode यांना /etc/claude-code/managed-settings.json मध्ये "disable" ही string value द्या. Managed settings ला इतर सर्व scopes पेक्षा उच्च प्राधान्य असते. त्यामुळे कोणतीही user settings file किंवा command line flag त्यांना override करू शकत नाही. disableAutoMode हे auto ला Shift+Tab cycle मधून काढते आणि startup वेळी --permission-mode auto नाकारते. disableBypassPermissionsMode कोणत्याही scope मधूनही कार्य करते. त्यामुळे एखादा user ते स्वतःच्या ~/.claude/settings.json मध्ये सेट करू शकतो.

माझी defaultMode: "auto" setting का दुर्लक्षित केली जाते?

कारण ती चुकीच्या file मध्ये आहे. Claude Code v2.1.142 पासून, .claude/settings.json किंवा .claude/settings.local.json मधून आल्यास defaultMode: "auto" दुर्लक्षित केले जाते. त्यामुळे repository स्वतः settings file पाठवून auto mode सक्षम करू शकत नाही. Session default mode मध्ये सुरू होते आणि कोणतीही error दाखवत नाही. Setting ~/.claude/settings.json मध्ये हलवा. त्यानंतर प्रत्येक active rule कोणत्या file मधून आली आहे हे तपासण्यासाठी /permissions चालवा. Auto mode अजूनही उपलब्ध नसेल, तर model requirement तपासा. Sonnet 4.5 सारखी जुनी models कोणत्याही provider वर supported नाहीत.