Claude Code auto mode: 14 August 2026-এর নতুন default

14 August 2026-এ auto mode কী পরিবর্তন করবে

Claude Code-এর auto mode আপনার কাছে অনুমতি চাওয়ার জন্য থেমে না থেকে tool call চালায়। প্রতিটি action আগে আলাদা classifier model-এ review-এর জন্য পাঠানো হয়। 14 August 2026 থেকে Pro, Max এবং Team plan-এ নতুন session এই mode-এ শুরু হবে। আপনি যেকোনো সময় mode পরিবর্তন করতে পারেন। আপনার নিজের সেট করা default পরিবর্তন করা হবে না।

Documentation-এ পরিবর্তনটি এভাবে বলা হয়েছে:

14 August 2026 থেকে Pro, Max এবং Team plan-এ নতুন session-এর জন্য auto mode default permission mode হবে। আপনি যেকোনো সময় mode পরিবর্তন করতে পারেন। আপনি নিজে সেট করা default বহাল থাকবে, যদি না আপনি one-time switch prompt গ্রহণ করেন। আপনার organization যে default পরিচালনা করে, তাতে কোনো পরিবর্তন হবে না।

এখানে তারিখের চেয়ে দুটি clause বেশি গুরুত্বপূর্ণ। আপনার নিজের settings file-এ সেট করা defaultMode পরিবর্তনের পরেও বহাল থাকবে। আপনার organization managed settings-এর মাধ্যমে যে default deploy করে, সেটিও বহাল থাকবে। Announcement post-এ আরও বলা হয়েছে, rollout-এর প্রথম পর্যায়ে Enterprise plan এবং API ব্যবহারকারী account-এর জন্য auto mode ঐচ্ছিক থাকবে।

আপনি যদি VPS (virtual private server)-এ Claude Code চালান, পরিবর্তনটি কার্যকর হওয়ার আগে পড়ে নেওয়া ভালো। Permission prompt হলো এমন একটি checkpoint, যেখানে keyboard-এর সামনে থাকা কোনো ব্যক্তির প্রয়োজন হয়। Remote box-এ আপনি প্রায়ই উপস্থিত থাকেন না। তাই session যে mode-এ শুরু হয়, সেটিই কয়েক ঘণ্টা চালু থাকতে পারে।

Claude Code-এর permission mode: সর্বাধিক oversight থেকে সর্বনিম্ন oversight পর্যন্ত

মোট ছয়টি mode আছে। প্রতিটি লাইনের শুরুতে থাকা নামটি হলো settings-এ লেখা বা --permission-mode-এ pass করা value।

• default: Claude প্রতিটি নতুন tool ব্যবহারের আগে জিজ্ঞেস করে। আপনার working directory-এর ভেতরের read prompt ছাড়াই চলে। CLI (command line interface) এই mode-কে Manual নামে দেখায় এবং Claude Code v2.1.200 থেকে manual-কে alias হিসেবে গ্রহণ করে।
• plan: Claude file পড়ে এবং explore করার জন্য command চালায়, কিন্তু আপনার source edit করে না। আপনি plan অনুমোদন না করা পর্যন্ত edit বন্ধ থাকে।
• acceptEdits: file edit prompt ছাড়াই চলে। এর সঙ্গে mkdir, touch, rm, rmdir, mv, cp এবং sed filesystem command-ও চলে। এটি শুধু আপনার working directory বা additionalDirectories-এর ভেতরের path-এর ক্ষেত্রে প্রযোজ্য। অন্য সব shell command-এর জন্য এখনও prompt দেখায়।
• auto: সবকিছু চলে, তবে classifier প্রতিটি action আগে পরীক্ষা করে। স্পষ্ট ask rule থাকলে prompt দেখানো বাধ্যতামূলক।
• dontAsk: যে কাজের জন্য prompt দেখানোর কথা ছিল, Claude Code তা স্বয়ংক্রিয়ভাবে deny করে। শুধু আপনার allow rule, built-in read-only Bash command এবং কোনো PreToolUse hook অনুমোদিত call চলবে। Session কখনও input-এর জন্য অপেক্ষা করে না।
• bypassPermissions: prompt এবং safety check বাদ দেওয়া হয়। .git এবং .claude-এর মতো protected path-এ write করাও এর অন্তর্ভুক্ত।

Session চলাকালে Shift+Tab চাপলে default থেকে acceptEdits, তারপর plan-এ mode পরিবর্তন হয়। Status bar-এ আপনি কোন mode-এ আছেন তা দেখা যায়, যেমন ⏵⏵ auto mode on বা gray ⏸ manual mode on। অন্য mode-গুলো defaultভাবে ওই cycle-এ থাকে না। আপনার account প্রয়োজনীয় শর্ত পূরণ করলে auto এতে যুক্ত হয়। Session --permission-mode bypassPermissions বা --dangerously-skip-permissions দিয়ে শুরু হলেই শুধু bypassPermissions এতে যুক্ত হয়। dontAsk সেখানে কখনও দেখা যায় না, তাই এটি claude --permission-mode dontAsk দিয়ে সেট করুন।

Auto mode-এর জন্য সাম্প্রতিক model-ও প্রয়োজন। এটি সাধারণত mode-টি একেবারেই না দেখানোর কারণ। August 2026 অনুযায়ী documentation-এ Anthropic API-এর জন্য Claude Opus 4.6 বা পরবর্তী version, Sonnet 4.6 বা পরবর্তী version এবং Fable 5 তালিকাভুক্ত আছে। সেখানে আরও বলা হয়েছে, Sonnet 4.5-এর মতো পুরোনো model কোনো provider-এই supported নয়। Claude Code যদি auto mode unavailable বলে, তাহলে এই শর্তগুলোর অন্তত একটি পূরণ হয়নি। এটি সাময়িক outage নয়, তাই অপেক্ষা করলেও সমস্যার সমাধান হবে না।

bypassPermissions-সহ প্রতিটি mode-এ দুটি control কার্যকর থাকে: deny rule এবং স্পষ্ট ask rule। Session যে mode-এ শুরু হোক, এই control দুটির ওপর আপনার নিয়ন্ত্রণ থাকে।

auto mode classifier যে কাজগুলো ব্লক করে

classifier হলো একটি দ্বিতীয় model, যা pending action পড়ে সিদ্ধান্ত নেয় সেটি আপনার অনুরোধের আওতায় পড়ে কি না। Documentation-এ এর কাজ এক বাক্যে বলা হয়েছে:

একটি পৃথক classifier model action চালানোর আগে তা পর্যালোচনা করে। আপনার অনুরোধের সীমা ছাড়িয়ে যায়, অচেনা infrastructure লক্ষ্য করে বা Claude যে hostile content পড়েছে তার প্রভাবে চালিত বলে মনে হয়—এমন যেকোনো action এটি ব্লক করে।

যেসব category server operator-রা সবচেয়ে বেশি দেখতে পান, সেগুলোতে ডিফল্টভাবে ব্লক করা হয়:

• Code download ও execute করা, যেমন curl | bash
• Production deploy ও migration
• Force push
• Shared infrastructure পরিবর্তন করা
• এমন tunnel বা reverse shell খোলা, যার মাধ্যমে কোনো local service public internet থেকে reachable হয়
• কোনো live credential বা token transcript-এ বা file-এ লেখা

ডিফল্টভাবে অনুমোদিত:

• আপনার working directory-তে local file operation
• আপনার lock file বা manifest-এ ঘোষিত dependency install করা
• Read-only HTTP request
• আপনি যে repository-তে কাজ করছেন, তার যেকোনো branch-এ push করা

উপরের মতো কোনো summary-এর ভিত্তিতে কাজ করবেন না। সম্পূর্ণ rule list JSON হিসেবে print করতে claude auto-mode defaults চালান এবং আপনার install করা version-এর সঙ্গে সরবরাহ করা rule set পড়ুন।

এই ব্যবস্থার ওপর নির্ভর করার আগে দুটি documented সীমাবদ্ধতা জানা জরুরি। প্রথমত, classifier আপনার message, tool call এবং CLAUDE.md content দেখতে পায়; tool result বাদ দেওয়া হয়। তাই Claude যে file বা web page পড়েছে, তার ভেতরের text সরাসরি classifier-কে নির্দেশ দিতে পারে না। দ্বিতীয়ত, classifier পরপর 3 বার কোনো action ব্লক করলে, অথবা একই session-এ 20 বার ব্লক করলে, auto mode pause হয় এবং Claude Code আবার আপনাকে prompt করতে শুরু করে। এই threshold configurable নয়। -p flag-সহ non-interactive mode-এ prompt করার মতো কেউ থাকে না। তাই বারবার block হলে session abort হয়।

Remote box-এ দ্বিতীয় আচরণটিই সমস্যার কারণ হয়। Unattended run limit অতিক্রম করলে থেমে যায় এবং এমন একজনের জন্য অপেক্ষা করে, যিনি terminal দেখছেন না। Agent কী করতে পারবে তা সীমিত করাও সমাধানের একটি অংশ। যে skill agent-কে কাজের জন্য প্রয়োজনীয় সর্বনিম্ন পরিবর্তনের দিকে পরিচালিত করে session-কে classifier যে বিস্তৃত action-গুলো থামায়, সেদিকে চলে যাওয়া থেকে বিরত রাখে।

settings.json-এ mode-গুলো যেখানে থাকে

উপরের সবকিছু একটি settings file-এর একটি 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 *)"
    ]
  }
}

Rule-গুলো ক্রমানুসারে মূল্যায়ন করা হয়: deny, তারপর ask, তারপর allow। ওই ক্রমে প্রথম যে rule মেলে, সেটিই ফল নির্ধারণ করে। আগে থাকা একটি বিস্তৃত rule-কে পরে থাকা সংকীর্ণ rule অতিক্রম করতে পারে না। Bash(aws *)-এর জন্য একটি deny rule থাকলে aws s3 ls block হবে, এমনকি আপনি ওই নির্দিষ্ট command-টি allow করলেও। তাই deny rule-এ exception রাখা যায় না।

Auto mode-এ ask rule type-টির ব্যবহার সবচেয়ে গুরুত্বপূর্ণ। Auto mode নিয়মিত prompt সরিয়ে দেয়। আর একটি ask rule নির্দিষ্ট যে command-টির জন্য মানুষের অনুমোদন চান, সেটির আগে আবার prompt দেখায়। আপনার deploy command এখানে রাখা উচিত। Code box-এর বাইরে যাওয়ার আগে checkpoint চাইলে Bash(git push *)-ও এখানে রাখুন। Credential file-গুলো deny-এ রাখা এর অন্য অংশ। এটি প্রথমেই credential-গুলো agent-এর নাগালের বাইরে রাখার সঙ্গে একত্রে ব্যবহার করা যায়।

সবচেয়ে কম precedence থেকে settings file-গুলোর ক্রম:

• ~/.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-এ এই file হলো /etc/claude-code/managed-settings.json। Command line flag-সহ কোনো কিছুই managed permission rule-কে override করতে পারে না।

এখানে একটি বিভ্রান্তির documented কারণ আছে। Claude Code v2.1.142 থেকে defaultMode: "auto"-কে .claude/settings.json বা .claude/settings.local.json থেকে এলে উপেক্ষা করা হয়, যাতে কোনো repository settings file পাঠিয়ে নিজেই auto mode চালু করতে না পারে। সেখানে সেট করলে session কোনো error না দেখিয়েই default mode-এ শুরু হয়। Line-টি ~/.claude/settings.json-এ সরান। কোন rule কোন file থেকে এসেছে, তার পাশে সব active rule-এর তালিকা দেখতে /permissions চালান।

একটি mode বন্ধ করার দুটি switch

Administrators-এর জন্য দুটি 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, Shift+Tab cycle থেকে auto সরিয়ে দেয় এবং startup-এর সময় --permission-mode auto প্রত্যাখ্যান করে। Bypass mode-এর জন্য disableBypassPermissionsMode একই কাজ করে এবং যেকোনো scope থেকে কার্যকর হয়। তাই live server-এ রাত 2am-এ যে mode ব্যবহার করতে চাইবেন না, নিজের ~/.claude/settings.json-এ সেট করে সেটিতে প্রবেশের পথ বন্ধ করতে পারেন। অন্যরা ব্যবহার করে এমন server-এ পরিবর্তে দুটিই /etc/claude-code/managed-settings.json-এ রাখুন। কারণ user settings file সংশ্লিষ্ট user-এর অধীন, কিন্তু managed settings file তা নয়।

VPS-এ auto mode-এর জন্য কেন একটি isolation boundary প্রয়োজন

Classifier একবারে একটি action পর্যালোচনা করে। অনুমোদিত action এরপর কী করে, তা classifier-এর আওতায় থাকে না। Documentation-এ বিষয়টি স্পষ্টভাবে বলা হয়েছে:

Classifier প্রতি-action control, isolation boundary নয়। তাই unattended run-এর জন্য isolation boundary অতিরিক্ত defense in depth দেয়। তবে --dangerously-skip-permissions-এর ক্ষেত্রে যেমন এটি আবশ্যক, এখানে তেমন নয়।

তাই remote box-এর জন্য উপযুক্ত সমন্বয় হলো auto mode এবং এমন একটি environment, যা নষ্ট হয়ে গেলে আপনি পুনর্নির্মাণ করতে রাজি; bypassPermissions এবং আশার ওপর নির্ভর করা নয়। Bypass mode কেবল isolated environment-এর জন্য documented: internet access-বিহীন container, virtual machine বা dev container, যেখানে Claude Code আপনার host system-এর ক্ষতি করতে পারে না। Database এবং reverse proxy চালানো একটি VPS এই শ্রেণির কোনোটিই নয়।

একটি server-এ তিনটি বিষয় সবচেয়ে বেশি সুরক্ষা দেয়। Claude Code normal user হিসেবে চালান, কখনো root হিসেবে নয়। ওই user-কে একটি working directory দিন এবং পড়ার মতো মূল্যবান অন্য কোনো resource দেবেন না। Box মেরামত না করে পুনর্নির্মাণ করুন। এই কারণেই প্রতিটি job-এর পরে ফেলে দেওয়া যায় এমন disposable VM ব্যবহার করা হয়। User তৈরি করা থেকে firewall rule পর্যন্ত এই বিষয়গুলোর hardening detail VPS-এ Claude Code চালানোর পূর্ণ safety pass-এ দেওয়া আছে, তাই এখানে পুনরাবৃত্তি করা হলো না।

Claude Code নিজেই root rule প্রয়োগ করে। Linux এবং macOS-এ sudo-এর অধীনে অথবা root হিসেবে চালালে এটি bypass mode-এ start হতে অস্বীকার করে:

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

স্বীকৃত sandbox-এর ভেতরে এই check বাদ দেওয়া হয়। তাই autonomous container কাজের জন্য documented সমাধান হলো এমন একটি dev container, যেখানে Claude Code non-root user হিসেবে চলে। আপনি যদি SSH-এর মাধ্যমে phone বা laptop থেকে agent নিয়ন্ত্রণ করেন, একই যুক্তি tmux-এ দীর্ঘ সময় চালু রাখা Claude Code session-এর ক্ষেত্রেও প্রযোজ্য: session চলার সময় prompt কেউ পর্যবেক্ষণ করছে না।

Ubuntu VPS-এ Bash sandbox সেট আপ করুন

Built-in sandbox Claude যে প্রতিটি Bash command চালায়, তার filesystem ও network access সীমিত করে। Operating system child process-গুলোর ক্ষেত্রেও একই সীমাবদ্ধতা প্রয়োগ করে। Linux-এ এর জন্য দুটি package প্রয়োজন।

sudo apt-get install bubblewrap socat

Claude Code চালু করুন এবং /sandbox চালান। একটি panel খুলবে। এতে Mode tab, Overrides tab এবং Dependencies tab থাকবে। Dependencies tab-এ যে package বা dependency অনুপস্থিত, সেগুলোর তালিকা দেখা যাবে। Dependency check startup-এর সময় চলে। তাই package install করার পরে Claude Code restart করুন। তা না হলে panel এখনও সেগুলোকে অনুপস্থিত দেখাবে।

Ubuntu 24.04 এবং পরবর্তী সংস্করণে default AppArmor policy bubblewrap-কে প্রয়োজনীয় user namespace তৈরি করতে বাধা দেয়। ফলে sandbox start করতে ব্যর্থ হয়। আপনার system-এ এটি প্রযোজ্য কি না পরীক্ষা করুন:

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 শুধু bwrap-এর ক্ষেত্রে প্রযোজ্য। sandbox-এর ভিতরে এটি যে command-গুলো চালায়, সেগুলোর ক্ষেত্রে নয়। এরপর settings-এ boundary আরও সীমিত করুন:

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

এই block-টি project-এর .claude/settings.json-এ রাখতে হবে। কারণ project settings থেকে শুধু সেখানেই . project root হিসেবে resolve হয়। একই line-গুলো ~/.claude/settings.json-এ রাখলে . পরিবর্তে ~/.claude হিসেবে resolve হবে। ফলে denyRead rule project file-গুলো block করে রাখবে এবং প্রতিটি command যে code edit করার কথা, সেটি পড়তে ব্যর্থ হবে।

এটি কী কী cover করে না, তা বুঝে নিন। Sandbox Bash এবং তার child process-গুলোর access সীমিত করে। Built-in file tool-গুলো Claude Code process-এর ভিতরে চলে। MCP (model context protocol) server এবং hook-গুলো আলাদা process হিসেবে host-এ কোনো সীমাবদ্ধতা ছাড়াই চলে। সবকিছুকে একটি boundary-এর মধ্যে রাখতে হলে পুরো Claude Code process-কে container, virtual machine অথবা @anthropic-ai/sandbox-runtime package-এর ভিতরে চালান। এই লেখা তৈরির সময় package-টি beta research preview হিসেবে উপলভ্য।

প্রতিটি সেটআপে কোন mode ব্যবহার করা উচিত?

নিজের laptop-এ একটি একক repo

auto ব্যবহার করুন। যেসব action-এর জন্য অনুমতি প্রয়োজন, সেগুলোর ক্ষেত্রে ask rules নির্ধারণ করুন। আপনি keyboard-এর সামনে আছেন, classifier fallback প্রয়োজনে আপনার কাছে prompt দেখাতে পারে, এবং ক্ষতির পরিসর আপনার নিয়ন্ত্রণাধীন একটি machine-এর মধ্যে সীমাবদ্ধ। 14 August-এর default এই পরিস্থিতির জন্যই তৈরি করা হয়েছিল।

একটি shared VPS

প্রতিটি user-এর জন্য auto ব্যবহার করুন। প্রতিটি user-এর নিজস্ব ~/.claude/settings.json-এ এটি নির্ধারণ করুন। যে box-এ Claude Code চালানো account-টি root নয় এবং অন্য user-দের কাজ পড়তে পারে না, সেই box-এ এই ব্যবস্থা ব্যবহার করুন। disableBypassPermissionsMode-কে "disable" হিসেবে /etc/claude-code/managed-settings.json-এ deploy করুন, এবং shared path সুরক্ষিত রাখার deny rules-ও যোগ করুন। shared box হলো সেই পরিস্থিতি যেখানে bypassPermissions ভুল, কারণ ওই mode যে isolation boundary ধরে নেয়, এখানে তা নেই: অন্য tenant-রা সেই boundary-এর ভেতরেই রয়েছে।

CI এবং unattended session

dontAsk ব্যবহার করুন এবং job-এর প্রয়োজনীয় command-গুলোর একটি স্পষ্ট allow তালিকা নির্ধারণ করুন। কোনো ব্যক্তি prompt দেখবেন না হলে auto-deny-ই সঠিক failure mode। Auto mode non-interactively-ও চলে, কিন্তু classifier বারবার block করলে একটি -p session abort হয়। ফলে job মাঝপথে ব্যর্থ হয় এবং কাজের একটি অংশ অসম্পূর্ণ থাকে। bypassPermissions কেবল এমন container বা virtual machine-এর জন্য রাখুন, যেটি image থেকে পুনর্নির্মাণ করেন। একই সঙ্গে, এমন কোনো host-এ এটি ব্যবহার করবেন না যেখানে আপনার গুরুত্বপূর্ণ অন্য কিছু চলছে।

FAQ

Claude Code-এ auto mode কখন ডিফল্ট হয়ে যায়?

14 August 2026 থেকে Pro, Max এবং Team plan-এর নতুন session-গুলোর জন্য। Documentation-এ বলা হয়েছে, আপনি যেকোনো সময় mode পরিবর্তন করতে পারেন। আপনি নিজে নির্ধারণ করা default তখনই বদলাবে, যখন one-time switch prompt গ্রহণ করবেন। আপনার organization যে default পরিচালনা করে, সেটি অপরিবর্তিত থাকবে। Announcement-এ আরও বলা হয়েছে, rollout-এর প্রথম পর্যায়ে Enterprise plan এবং API ব্যবহারকারী account-গুলোর জন্য auto mode ঐচ্ছিক থাকবে। কোনো session বর্তমানে কোন mode-এ আছে তা status bar দেখে যাচাই করুন; auto mode-এ এটি ⏵⏵ auto mode on দেখায়।

VPS-এ auto mode নাকি bypassPermissions ব্যবহার করা উচিত?

Isolation boundary-এর সঙ্গে auto mode ব্যবহার করুন। প্রতিটি action চালানোর আগে classifier সেটি পর্যালোচনা করে। তবে documentation স্পষ্টভাবে জানায়, এটি প্রতি-action control, isolation boundary নয়। তাই unattended run-এর জন্য এখনও container, virtual machine, অথবা এমন একটি system প্রয়োজন যেটি প্রয়োজনে পুনর্নির্মাণ করতে পারবেন। bypassPermissions সব check সম্পূর্ণভাবে এড়িয়ে যায় এবং শুধু isolated environment-এর জন্য নথিভুক্ত। Linux-এ root হিসেবে ওই mode-এ Claude Code start হতে অস্বীকার করে এবং --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons দেখায়।

আমার server-এ কেউ যাতে auto mode বা bypass mode ব্যবহার করতে না পারে, তা কীভাবে বন্ধ করব?

/etc/claude-code/managed-settings.json-এ permissions.disableAutoMode এবং permissions.disableBypassPermissionsMode-এর মান "disable" string হিসেবে সেট করুন। Managed settings অন্য সব scope-এর ওপর প্রাধান্য পায়। তাই কোনো user settings file বা command line flag এগুলো override করতে পারে না। disableAutoMode, Shift+Tab cycle থেকে auto সরিয়ে দেয় এবং 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-এ সরান। এরপর /permissions চালিয়ে প্রতিটি active rule কোন file থেকে এসেছে তা নিশ্চিত করুন। Auto mode এখনও unavailable থাকলে model requirement পরীক্ষা করুন। Sonnet 4.5-এর মতো পুরোনো model কোনো provider-এই supported নয়।