Claude Code auto mode: 14 August 2026 کی تبدیلی

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 تبدیل نہیں ہوگا۔

دستاویزات میں اس تبدیلی کو یوں بیان کیا گیا ہے:

14 August 2026 سے Pro، Max اور Team plans پر نئی sessions کے لیے auto mode، default permission mode بن جائے گا۔ آپ کسی بھی وقت mode تبدیل کر سکتے ہیں۔ آپ کا مقرر کردہ default برقرار رہے گا، جب تک آپ one-time switch prompt قبول نہ کریں، جبکہ آپ کی organization کے زیر انتظام default میں کوئی تبدیلی نہیں ہوگی۔

اس بیان میں تاریخ سے زیادہ دو شقیں اہم ہیں۔ آپ کی اپنی settings file میں مقرر کردہ defaultMode اس تبدیلی کے بعد بھی برقرار رہے گا۔ آپ کی organization کی managed settings کے ذریعے deploy کیا گیا default بھی برقرار رہے گا۔ اعلان کی پوسٹ میں مزید کہا گیا ہے کہ rollout کے ابتدائی مرحلے میں Enterprise plans اور API استعمال کرنے والے accounts کے لیے auto mode اختیاری رہے گا۔

اگر آپ Claude Code کو VPS (virtual private server) پر چلاتے ہیں تو یہ تبدیلی نافذ ہونے سے پہلے اسے پڑھ لینا مفید ہے۔ permission prompt ایک ایسا checkpoint ہے جس کے لیے keyboard پر موجود شخص کی ضرورت ہوتی ہے۔ remote box پر آپ اکثر موجود نہیں ہوتے، اس لیے session جس mode میں شروع ہوتی ہے، وہ کئی گھنٹوں تک اسی mode میں چلتی رہتی ہے۔

Claude Code کے اجازت کے طریقے: زیادہ نگرانی سے کم نگرانی تک

کل چھ طریقے ہیں۔ ہر سطر کے آغاز میں دیا گیا نام وہ قدر ہے جسے آپ settings میں لکھتے یا --permission-mode کو دیتے ہیں۔

• default: Claude ہر نئے tool کے استعمال سے پہلے اجازت مانگتا ہے۔ آپ کی working directory کے اندر ہونے والی reads بغیر prompt کے جاری رہتی ہیں۔ CLI (command line interface) اس طریقے کو Manual کا نام دیتا ہے اور Claude Code v2.1.200 سے manual کو alias کے طور پر قبول کرتا ہے۔
• plan: Claude فائلیں پڑھتا اور جائزہ لینے کے لیے commands چلاتا ہے، لیکن آپ کے source میں ترمیم نہیں کرتا۔ آپ کے plan کی منظوری تک edits مسدود رہتی ہیں۔
• acceptEdits: file edits بغیر prompt کے چلتے ہیں۔ اسی طرح filesystem commands mkdir، touch، rm، rmdir، mv، cp اور sed بھی بغیر prompt کے چلتے ہیں۔ یہ صرف آپ کی working directory یا آپ کے additionalDirectories کے اندر موجود paths پر لاگو ہوتا ہے۔ ہر دوسری shell command کے لیے اب بھی prompt ظاہر ہوتا ہے۔
• auto: ہر چیز چلتی ہے، لیکن classifier پہلے ہر action کی جانچ کرتا ہے۔ واضح ask rules اب بھی prompt لازم کرتی ہیں۔
• dontAsk: Claude Code ہر اس action کو خودکار طور پر مسترد کرتا ہے جس کے لیے آپ سے prompt کیا جاتا۔ صرف آپ کے allow rules، built-in read-only Bash commands، اور ایسے calls چلتے ہیں جنہیں PreToolUse hook approve کرے۔ session کبھی input کا انتظار نہیں کرتا۔
• bypassPermissions: prompts اور safety checks کو نظرانداز کیا جاتا ہے، جن میں .git اور .claude جیسے protected paths میں writes بھی شامل ہیں۔

session کے دوران Shift+Tab دبانے سے default سے acceptEdits اور پھر plan تک طریقہ تبدیل ہوتا ہے۔ status bar بتاتا ہے کہ آپ کس طریقے پر پہنچے ہیں، مثلاً ⏵⏵ auto mode on یا gray ⏸ manual mode on۔ دیگر طریقے default طور پر اس cycle میں شامل نہیں ہوتے۔ آپ کے account کے لیے مطلوبہ شرائط پوری ہونے کے بعد auto اس cycle میں شامل ہو جاتا ہے۔ bypassPermissions صرف اس وقت شامل ہوتا ہے جب session --permission-mode bypassPermissions یا --dangerously-skip-permissions کے ساتھ شروع کیا گیا ہو۔ dontAsk وہاں کبھی ظاہر نہیں ہوتا، اس لیے اسے claude --permission-mode dontAsk کے ساتھ set کریں۔

Auto mode کے لیے حالیہ model بھی درکار ہے، اور عموماً اسی وجہ سے یہ بالکل ظاہر نہیں ہوتا۔ August 2026 تک documentation میں Anthropic API پر Claude Opus 4.6 یا اس کے بعد کے versions، Sonnet 4.6 یا اس کے بعد کے versions، اور Fable 5 درج ہیں۔ Documentation یہ بھی کہتی ہے کہ Sonnet 4.5 جیسے پرانے models کسی بھی provider پر supported نہیں ہیں۔ اگر Claude Code auto mode کو unavailable بتائے تو ان میں سے کوئی شرط پوری نہیں ہو رہی۔ یہ عارضی outage نہیں ہے، اس لیے انتظار کرنے سے مسئلہ حل نہیں ہوگا۔

دو controls ہر طریقے میں برقرار رہتے ہیں، بشمول bypassPermissions: deny rules اور واضح ask rules۔ session جس طریقے سے بھی شروع ہو، یہ وہ controls ہیں جو آپ کے اختیار میں رہتے ہیں۔

آٹو موڈ کلاسیفائر کن کارروائیوں کو روکتا ہے

کلاسیفائر ایک دوسرا model ہے جو زیرِ التوا action پڑھتا ہے اور فیصلہ کرتا ہے کہ آیا یہ آپ کی درخواست کے مطابق ہے۔ دستاویزات میں اس کا کام ایک جملے میں یوں بیان کیا گیا ہے:

ایک الگ classifier model کارروائیاں چلنے سے پہلے ان کا جائزہ لیتا ہے۔ یہ ایسی کارروائیوں کو روکتا ہے جو آپ کی درخواست سے آگے بڑھیں، غیر شناخت شدہ infrastructure کو target کریں، یا بظاہر اس hostile content کی وجہ سے ہوں جسے Claude نے پڑھا ہو۔

وہ کارروائیاں جنہیں default طور پر روکا جاتا ہے اور جن کا server operator کو اکثر سامنا ہوتا ہے:

• Code download اور execute کرنا، جیسے curl | bash
• Production deploys اور migrations
• Force push
• Shared infrastructure میں ترمیم
• ایسا tunnel یا reverse shell کھولنا جس سے local service public internet سے reachable ہو جائے
• Live credential یا token کو transcript یا file میں print کرنا

وہ کارروائیاں جو default طور پر allowed ہیں:

• اپنی working directory میں local file operations
• اپنی lock files یا manifests میں declared dependencies install کرنا
• Read-only HTTP requests
• جس repository میں آپ کام کر رہے ہیں، اس کی کسی بھی branch پر push کرنا

اوپر دی گئی summary کی بنیاد پر کام نہ کریں۔ مکمل rule lists کو JSON کے طور پر print کرنے کے لیے claude auto-mode defaults چلائیں، اور اپنے installed version کے ساتھ فراہم کردہ rules پڑھیں۔

اس mechanism پر انحصار کرنے سے پہلے دو documented limits اہم ہیں۔ پہلی یہ کہ classifier آپ کے messages، tool calls اور آپ کے CLAUDE.md content کو دیکھتا ہے، جبکہ tool results اس سے ہٹا دیے جاتے ہیں۔ اس لیے کسی file یا web page کے اندر موجود وہ text جسے Claude نے پڑھا ہو، classifier کو براہِ راست address نہیں کر سکتا۔ دوسری یہ کہ جب classifier مسلسل 3 بار یا ایک session میں 20 بار کسی action کو block کرتا ہے تو auto mode pause ہو جاتا ہے اور Claude Code دوبارہ آپ سے اجازت طلب کرنے لگتا ہے۔ یہ thresholds configurable نہیں ہیں۔ -p flag کے ساتھ non-interactive mode میں prompt کا جواب دینے والا کوئی شخص موجود نہیں ہوتا، اس لیے repeated blocks کے نتیجے میں session abort ہو جاتا ہے۔

یہ دوسرا behavior remote box پر خاص طور پر مسئلہ پیدا کرتا ہے۔ Unattended run اگر یہ limit cross کر لے تو رک جاتا ہے اور ایسے شخص کا انتظار کرتا ہے جو terminal نہیں دیکھ رہا ہوتا۔ Agent کے کام کا scope محدود کرنا اس مسئلے کے حل کا دوسرا حصہ ہے، اور ایسی skill جو agent کو کام کرنے والی کم سے کم تبدیلی کی طرف متوجہ رکھتی ہے session کو ان وسیع کارروائیوں کی طرف بھٹکنے سے روکتی ہے جنہیں classifier block کر دیتا ہے۔

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۔ اسی ترتیب میں جو پہلی rule match ہو، نتیجہ وہی طے کرتی ہے۔ بعد میں آنے والی زیادہ مخصوص rule، پہلے آنے والی وسیع rule پر غالب نہیں آتی۔ Bash(aws *) کے لیے deny rule، aws s3 ls کو block کرتی ہے، چاہے آپ نے اسی exact command کو allow کیا ہو۔ اس لیے deny rule میں exceptions شامل نہیں کی جا سکتیں۔

ask وہ rule type ہے جو auto mode میں واقعی مفید ثابت ہوتا ہے۔ Auto mode معمول کا prompt ہٹا دیتا ہے، جبکہ ask rule صرف اس مخصوص command کے لیے prompt دوبارہ فعال کرتی ہے جس پر کسی شخص کی منظوری درکار ہو۔ آپ کی deploy command اسی میں ہونی چاہیے۔ اگر code کے box سے باہر جانے سے پہلے checkpoint درکار ہو تو Bash(git push *) بھی اسی میں شامل کریں۔ Credential files کو deny میں رکھنا اس انتظام کا دوسرا حصہ ہے، اور یہ credentials کو ابتدا ہی سے agent کی رسائی سے باہر رکھنے کے ساتھ مل کر کام کرتا ہے۔

Settings files خود، کم ترجیح سے زیادہ ترجیح کی ترتیب میں:

• ~/.claude/settings.json: آپ کی user settings، جو ہر project میں لاگو ہوتی ہیں۔
• .claude/settings.json: project settings، جو repository میں commit کی جاتی ہیں۔
• .claude/settings.local.json: ایک repository کے لیے آپ کی ذاتی settings، جنہیں git-ignore کیا جاتا ہے۔
• Managed settings، جو administrator deploy کرتا ہے۔ Linux پر یہ فائل /etc/claude-code/managed-settings.json ہے۔ کوئی بھی چیز managed permission rule کو override نہیں کر سکتی، حتیٰ کہ command line flag بھی نہیں۔

یہاں ایک مسئلے کی documented وجہ موجود ہے۔ Claude Code v2.1.142 سے شروع کرتے ہوئے، defaultMode: "auto" کو نظرانداز کیا جاتا ہے جب وہ .claude/settings.json یا .claude/settings.local.json سے آتی ہے، تاکہ repository settings فائل شامل کر کے خود کو auto mode نہ دے سکے۔ اگر اسے وہاں set کریں تو session خاموشی سے default mode میں شروع ہوتا ہے اور کہیں بھی error print نہیں ہوتی۔ اس line کو ~/.claude/settings.json میں منتقل کریں۔ ہر active rule کو اس فائل کے ساتھ دیکھنے کے لیے /permissions چلائیں جس سے وہ حاصل ہوئی ہے۔

موڈ کو بند کرنے والے دو سوئچ

منتظمین کے پاس دو kill switches ہوتے ہیں، اور دونوں boolean کے بجائے "disable" string لیتے ہیں۔

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

دستاویز میں یہ واضح طور پر بتایا گیا ہے کہ انہیں کہاں رکھنا ہے:

bypassPermissions یا auto mode کے استعمال کو روکنے کے لیے، کسی بھی settings file میں permissions.disableBypassPermissionsMode یا permissions.disableAutoMode کو "disable" پر set کریں۔ یہ managed settings میں سب سے زیادہ مفید ہوتے ہیں، جہاں انہیں override نہیں کیا جا سکتا۔

disableAutoMode، auto کو Shift+Tab cycle سے خارج کرتا ہے اور startup کے وقت --permission-mode auto کو مسترد کر دیتا ہے۔ disableBypassPermissionsMode bypass mode کے لیے یہی کام کرتا ہے، اور یہ کسی بھی scope سے کام کرتا ہے۔ اس لیے آپ اسے اپنی ~/.claude/settings.json میں set کر سکتے ہیں تاکہ ایسے mode سے خود کو دور رکھیں جسے آپ live server پر رات 2am بجے استعمال نہیں کرنا چاہتے۔ ایسے server پر جسے دوسرے لوگ بھی استعمال کرتے ہوں، اس کے بجائے دونوں کو /etc/claude-code/managed-settings.json میں رکھیں، کیونکہ user settings file صارف سے متعلق ہوتی ہے، جبکہ managed settings file ایسا نہیں ہوتی۔

VPS پر auto mode کے لیے isolation boundary کیوں ضروری ہے

classifier ایک وقت میں ایک action کا جائزہ لیتا ہے۔ یہ اس بات کو محدود نہیں کرتا کہ منظور شدہ action کے بعد کیا ہوتا ہے۔ documentation یہ فرق واضح طور پر بیان کرتی ہے:

classifier ہر action کے لیے control ہے، isolation boundary نہیں۔ اس لیے unattended runs کے لیے isolation boundary defense in depth فراہم کرتی ہے، جبکہ --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 کو نقصان نہیں پہنچا سکتا۔ آپ کا database اور reverse proxy چلانے والا VPS ان میں سے کوئی نہیں ہے۔

سرور پر تین چیزیں سب سے زیادہ اہم ہیں۔ Claude Code کو normal user کے طور پر چلائیں، کبھی root کے طور پر نہیں۔ اس user کو ایک working directory دیں اور اس کے علاوہ پڑھنے کے قابل کوئی اہم چیز نہ دیں۔ box کو repair کرنے کے بجائے اسے rebuild کریں۔ اسی لیے ہر job کے بعد ضائع کر دینے والی disposable VM بہتر انتخاب ہے۔ ان اقدامات کے پیچھے موجود hardening detail، user creation سے firewall rules تک، 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

recognized sandbox کے اندر یہ check نہیں کیا جاتا۔ اسی لیے autonomous container work کے لیے documentation میں non-root user کے طور پر Claude Code چلانے والا dev container تجویز کیا گیا ہے۔ اگر آپ SSH کے ذریعے phone یا laptop سے agent چلاتے ہیں تو یہی اصول tmux میں کھلے رکھے گئے long-running Claude Code session پر بھی لاگو ہوتا ہے: session چلنے کے دوران کوئی prompt کی نگرانی نہیں کر رہا ہوتا۔

Ubuntu VPS پر Bash sandbox ترتیب دیں

مربوط sandbox ان تمام Bash commands کی filesystem اور network access محدود کرتا ہے جنہیں Claude چلاتا ہے، اور operating system اس پابندی کو child processes پر بھی نافذ کرتا ہے۔ Linux پر اس کے لیے دو packages درکار ہیں۔

sudo apt-get install bubblewrap socat

Claude Code شروع کریں اور /sandbox چلائیں۔ panel میں Mode tab اور Overrides tab کے علاوہ Dependencies tab بھی کھلتا ہے، جس میں تمام missing dependencies درج ہوتی ہیں۔ dependency check startup کے وقت چلتا ہے، اس لیے packages install کرنے کے بعد Claude Code restart کریں، ورنہ panel انہیں اب بھی absent دکھائے گا۔

Ubuntu 24.04 اور اس کے بعد کے versions میں default AppArmor policy bubblewrap کو درکار user namespaces بنانے سے روکتی ہے، اس لیے sandbox start نہیں ہوتا۔ پہلے دیکھیں کہ یہ مسئلہ آپ کے server پر موجود ہے یا نہیں:

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 کو پڑھنے میں ناکام رہتی ہے جس میں اسے ترمیم کرنی ہے۔

یہ بھی سمجھیں کہ اس طریقے میں کیا شامل نہیں ہے۔ sandbox Bash اور اس کے child processes کو محدود کرتا ہے۔ built-in 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 ہے۔

ہر سیٹ اپ کے لیے کون سا mode مناسب ہے؟

اپنے laptop پر ایک ذاتی repo

auto استعمال کریں، اور ان actions کے لیے ask rules مقرر کریں جنہیں آپ کی منظوری کے بغیر آگے نہیں بڑھنا چاہیے۔ آپ keyboard کے سامنے موجود ہیں، classifier fallback حقیقتاً آپ تک پہنچ سکتا ہے، اور نقصان ایک ایسی machine تک محدود ہے جسے آپ control کرتے ہیں۔ 14 August کا default اسی صورتِ حال کے لیے بنایا گیا تھا۔

مشترکہ VPS

ہر user کے لیے auto استعمال کریں اور اسے ہر user کے اپنے ~/.claude/settings.json میں set کریں۔ اس box پر Claude Code چلانے والا account root نہ ہو اور دوسرے users کے کام کو read نہ کر سکے۔ disableBypassPermissionsMode کو "disable" کے طور پر /etc/claude-code/managed-settings.json میں deploy کریں، اور shared paths کو محفوظ رکھنے والے deny rules بھی شامل کریں۔ مشترکہ box وہ واضح صورت ہے جہاں bypassPermissions غلط ہے، کیونکہ اس mode کی فرض کردہ isolation boundary موجود نہیں: دوسرے tenants اسی boundary کے اندر ہیں۔

CI اور unattended sessions

dontAsk استعمال کریں اور job کو درکار commands کی واضح allow list فراہم کریں۔ جب کوئی شخص prompt نہیں دیکھے گا تو auto-deny درست failure mode ہے۔ Auto mode بھی non-interactively چلتا ہے، لیکن classifier کے بار بار blocks کسی -p session کو abort کر دیتے ہیں۔ اس لیے ایسے blocks آنے پر job درمیان میں fail ہو جاتی ہے اور کام ادھورا رہ جاتا ہے۔ bypassPermissions کو صرف ایسی container یا virtual machine کے لیے رکھیں جسے آپ image سے دوبارہ build کرتے ہیں، اور ایسے host پر استعمال نہ کریں جہاں کوئی اہم چیز بھی چل رہی ہو۔

FAQ

Claude Code میں auto mode کب default بن جاتا ہے؟

14 August 2026 سے Pro، Max اور Team plans پر نئی sessions کے لیے۔ دستاویز میں یہ بھی بتایا گیا ہے کہ آپ modes کسی بھی وقت تبدیل کر سکتے ہیں، آپ کی اپنی مقرر کردہ default اس وقت تک برقرار رہتی ہے جب تک آپ one-time switch prompt قبول نہ کریں، اور آپ کی organization کے زیرِ انتظام default تبدیل نہیں ہوتی۔ اعلان کے مطابق rollout کے ابتدائی مرحلے میں Enterprise plans اور API استعمال کرنے والے accounts کے لیے auto mode اختیاری رہے گا۔ یہ جاننے کے لیے کہ session اس وقت کس mode میں ہے، status bar دیکھیں؛ auto mode میں یہ ⏵⏵ auto mode on دکھاتا ہے۔

VPS پر auto mode یا bypassPermissions میں سے کون سا استعمال کرنا چاہیے؟

Isolation boundary کے ساتھ auto mode استعمال کریں۔ classifier ہر action کے چلنے سے پہلے اس کا جائزہ لیتا ہے، لیکن دستاویز واضح کرتی ہے کہ یہ per-action control ہے، isolation boundary نہیں۔ اس لیے unattended run کے لیے اب بھی container، virtual machine یا ایسا box درکار ہے جسے آپ دوبارہ بنا سکیں۔ bypassPermissions تمام checks مکمل طور پر چھوڑ دیتا ہے اور صرف isolated environments کے لیے documented ہے۔ Claude Code Linux پر root کے طور پر اس mode میں start ہونے سے انکار کرتا ہے اور --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 میں string "disable" پر set کریں۔ Managed settings ہر دوسرے scope سے بالاتر ہوتی ہیں، اس لیے کوئی user settings file یا command line flag انہیں override نہیں کر سکتا۔ disableAutoMode، auto کو Shift+Tab cycle سے خارج کرتا ہے اور startup پر --permission-mode auto کو مسترد کرتا ہے۔ disableBypassPermissionsMode بھی کسی بھی scope سے کام کرتا ہے، اس لیے ایک user اسے اپنی ~/.claude/settings.json میں set کر سکتا ہے۔

میری defaultMode: "auto" setting نظرانداز کیوں کی جا رہی ہے؟

کیونکہ یہ غلط file میں موجود ہے۔ Claude Code v2.1.142 سے defaultMode: "auto" کو اس وقت نظرانداز کیا جاتا ہے جب یہ .claude/settings.json یا .claude/settings.local.json سے آتا ہو، تاکہ کوئی repository settings file فراہم کر کے خود کو auto mode نہ دے سکے۔ Session default mode میں start ہوتی ہے اور کوئی error نہیں دکھاتی۔ Setting کو ~/.claude/settings.json میں منتقل کریں، پھر /permissions چلائیں تاکہ تصدیق ہو سکے کہ ہر active rule کس file سے حاصل ہوا ہے۔ اگر auto mode اب بھی دستیاب نہ ہو تو model requirement check کریں: Sonnet 4.5 جیسے پرانے models کسی بھی provider پر supported نہیں ہیں۔