انتخابِ حالتِ دسترسی

Control whether Claude asks before editing files or running commands. Cycle modes with Shift+Tab in the CLI or use the mode selector in VS Code, Desktop, and claude.ai.

وقتی Claude می‌خواهد فایلی را ویرایش کند، فرمانی در شل اجرا کند یا درخواست شبکه‌ای بفرستد، مکث می‌کند و از تو می‌خواهد آن اقدام را تأیید کنی. حالت‌های دسترسی تعیین می‌کنند که این مکث چند بار رخ بدهد. حالتی که انتخاب می‌کنی، جریانِ یک نشست را شکل می‌دهد: در حالت پیش‌فرض هر اقدام را همان‌طور که پیش می‌آید بازبینی می‌کنی، در حالی که حالت‌های بازتر به Claude اجازه می‌دهند در بازه‌های طولانی‌تر و بدون وقفه کار کند و وقتی تمام شد گزارش بدهد. برای کارهای حساس نظارت بیشتر را انتخاب کن، یا وقتی به مسیر اعتماد داری وقفه‌های کمتر را.

حالت‌های در دسترس

هر حالت بده‌بستانی متفاوت بین راحتی و نظارت دارد. جدول زیر نشان می‌دهد در هر حالت Claude چه کاری را بدون پرسشِ مجوز می‌تواند انجام دهد.

حالت	چه چیزی بدون پرسیدن اجرا می‌شود	بهترین برای
`default`	فقط خواندن	شروع کار، کارهای حساس
`acceptEdits`	خواندن، ویرایش فایل‌ها و فرمان‌های رایجِ فایل‌سیستم (`mkdir`, `touch`, `mv`, `cp`، و غیره)	تکرار روی کدی که در حال بازبینی‌اش هستی
`plan`	فقط خواندن	کاوشِ یک کدبیس پیش از تغییرش
`auto`	همه چیز، همراه با بررسی‌های ایمنیِ پس‌زمینه	کارهای طولانی، کاهشِ خستگی از پرسش‌ها
`dontAsk`	فقط ابزارهای از پیش تأییدشده	CI و اسکریپت‌های قفل‌شده
`bypassPermissions`	همه چیز	فقط کانتینرها و VMهای ایزوله

در هر حالتی به‌جز bypassPermissions، نوشتن در مسیرهای محافظت‌شده هرگز به‌صورت خودکار تأیید نمی‌شود و این، وضعیتِ مخزن و پیکربندیِ خودِ Claude را در برابر خرابیِ تصادفی محافظت می‌کند.

حالت‌ها خط‌پایه را تعیین می‌کنند. برای پیش‌تأیید یا مسدودکردنِ ابزارهای مشخص، قواعدِ دسترسی را روی آن سوار کن. قواعدِ deny و قواعدِ ask صریح در هر حالتی اعمال می‌شوند، از جمله bypassPermissions. قواعدِ allow در آن حالت هیچ اثری ندارند، چون همه چیز از پیش تأیید شده است.

جابه‌جایی بین حالت‌های دسترسی

می‌توانی حالت را وسط نشست، در زمانِ راه‌اندازی، یا به‌عنوان پیش‌فرضِ ماندگار عوض کنی. حالت از طریق این کنترل‌ها تنظیم می‌شود، نه با درخواست از Claude در چت. رابطِ خود را در پایین انتخاب کن تا ببینی چطور آن را عوض کنی.

در حین نشست: Shift+Tab را بزن تا بین default → acceptEdits → plan بچرخی. حالتِ فعلی در نوارِ وضعیت نمایش داده می‌شود. هر حالتی در چرخه‌ی پیش‌فرض نیست:

auto: وقتی حسابِ تو الزاماتِ حالت auto را برآورده کند ظاهر می‌شود؛ چرخیدن به auto یک پرامپتِ پذیرش (opt-in) نشان می‌دهد تا وقتی آن را بپذیری، یا No, don’t ask again را انتخاب کنی تا auto از چرخه حذف شود
bypassPermissions: بعد از این‌که با --permission-mode bypassPermissions، --dangerously-skip-permissions، یا --allow-dangerously-skip-permissions شروع کنی ظاهر می‌شود؛ نسخه‌ی --allow- حالت را بدون فعال‌کردنش به چرخه اضافه می‌کند
dontAsk: هرگز در چرخه ظاهر نمی‌شود؛ آن را با --permission-mode dontAsk تنظیم کن

حالت‌های اختیاریِ فعال‌شده بعد از plan جای می‌گیرند، با bypassPermissions در ابتدا و auto در انتها. اگر هر دو را فعال داشته باشی، در مسیرِ رسیدن به auto از bypassPermissions عبور می‌کنی.

در زمانِ راه‌اندازی: حالت را به‌عنوان یک پرچم پاس بده.

claude --permission-mode plan

به‌عنوان پیش‌فرض: defaultMode را در تنظیمات تعیین کن.

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

همان پرچمِ --permission-mode با -p برای اجراهای غیرتعاملی هم کار می‌کند.

در حین نشست: روی نشانگرِ حالت در پایینِ کادرِ پرامپت کلیک کن.

به‌عنوان پیش‌فرض: claudeCode.initialPermissionMode را در تنظیماتِ VS Code تعیین کن، یا از پنلِ تنظیماتِ افزونه‌ی Claude Code استفاده کن.

نشانگرِ حالت این برچسب‌ها را نشان می‌دهد که هرکدام به حالتی که اعمال می‌کند نگاشت شده است:

برچسبِ UI	حالت
Ask before edits	`default`
Edit automatically	`acceptEdits`
Plan mode	`plan`
Auto mode	`auto`
Bypass permissions	`bypassPermissions`

حالتِ auto وقتی در نشانگرِ حالت ظاهر می‌شود که حسابِ تو همه‌ی الزاماتِ فهرست‌شده در بخشِ حالت auto را برآورده کند. تنظیمِ claudeCode.initialPermissionMode مقدارِ auto را نمی‌پذیرد. برای این‌که به‌صورت پیش‌فرض در حالت auto شروع کنی، به‌جایش defaultMode را در تنظیماتِ کاربر تعیین کن. Claude Code مقدارِ defaultMode: "auto" را در تنظیماتِ پروژه و محلی نادیده می‌گیرد.

Bypass permissions پیش از این‌که در نشانگرِ حالت ظاهر شود، نیازمندِ کلیدِ Allow dangerously skip permissions در تنظیماتِ افزونه است.

برای جزئیاتِ مخصوصِ افزونه، راهنمای VS Code را ببین.

افزونه‌ی JetBrains، Claude Code را در ترمینالِ IDE اجرا می‌کند، پس جابه‌جایی بین حالت‌ها مثلِ CLI کار می‌کند: Shift+Tab را بزن تا بچرخی، یا هنگامِ اجرا --permission-mode را پاس بده.

از منوی کشویی حالت کنارِ کادرِ پرامپت در claude.ai/code یا در اپِ موبایل استفاده کن. پرامپت‌های مجوز برای تأیید در claude.ai ظاهر می‌شوند. این‌که کدام حالت‌ها ظاهر می‌شوند به این بستگی دارد که نشست کجا اجرا می‌شود:

نشست‌های ابری روی Claude Code on the web: Accept edits، Plan mode، و Auto mode. Accept edits معادلِ حالت default است: محیطِ ابری ویرایشِ فایل‌ها را صرف‌نظر از حالت از پیش تأیید می‌کند، پس منوی کشویی به‌جای Ask permissions، Accept edits را نشان می‌دهد. مقدارِ defaultMode: "acceptEdits" از تنظیمات همچنان رعایت می‌شود. Auto mode فقط وقتی ظاهر می‌شود که سازمانت اجازه بدهد و مدلِ انتخاب‌شده از آن پشتیبانی کند. Bypass permissions در دسترس نیست.
نشست‌های Remote Control روی دستگاهِ محلیِ تو: Ask permissions، Auto accept edits، و Plan mode. Auto و Bypass permissions در دسترس نیستند.

برای Remote Control، می‌توانی هنگامِ اجرای میزبان، حالتِ شروع را هم تعیین کنی:

claude remote-control --permission-mode acceptEdits

تأیید خودکار ویرایش فایل‌ها با حالت acceptEdits

حالت acceptEdits به Claude اجازه می‌دهد بدون پرسیدن، در دایرکتوریِ کاریِ تو فایل بسازد و ویرایش کند. وقتی این حالت فعال است، نوارِ وضعیت ⏵⏵ accept edits on را نشان می‌دهد.

علاوه بر ویرایشِ فایل‌ها، حالت acceptEdits فرمان‌های رایجِ Bash مربوط به فایل‌سیستم را به‌صورت خودکار تأیید می‌کند: mkdir, touch, rm, rmdir, mv, cp، و sed. این فرمان‌ها وقتی با متغیرهای محیطیِ امن مثلِ LANG=C یا NO_COLOR=1، یا با پوشش‌دهنده‌های پردازش مثلِ timeout, nice، یا nohup پیشوند بخورند هم به‌صورت خودکار تأیید می‌شوند. مثلِ ویرایشِ فایل‌ها، تأییدِ خودکار فقط برای مسیرهای داخلِ دایرکتوریِ کاری یا additionalDirectories اعمال می‌شود. مسیرهای بیرون از آن دامنه، نوشتن در مسیرهای محافظت‌شده، و همه‌ی فرمان‌های دیگرِ Bash همچنان پرسیده می‌شوند.

وقتی ابزارِ PowerShell فعال باشد، حالت acceptEdits همچنین Set-Content, Add-Content, Clear-Content، و Remove-Item را روی مسیرهای درون‌دامنه، همراه با مستعارهای رایجشان، به‌صورت خودکار تأیید می‌کند. همان قواعدِ دامنه و مسیرِ محافظت‌شده اعمال می‌شوند.

از acceptEdits وقتی استفاده کن که می‌خواهی به‌جای تأییدِ تک‌تکِ ویرایش‌ها به‌صورت درجا، تغییرات را بعداً در ویرایشگرت یا از طریقِ git diff بازبینی کنی. یک بار از حالت پیش‌فرض Shift+Tab را بزن تا واردش شوی، یا مستقیماً با آن شروع کن:

claude --permission-mode acceptEdits

پیش از ویرایش، تحلیل کن با حالت plan

حالت plan به Claude می‌گوید بدون اعمالِ تغییرات، پژوهش کند و تغییراتی را پیشنهاد دهد. Claude فایل‌ها را می‌خواند، برای کاوش فرمان‌های شل اجرا می‌کند، و یک طرح می‌نویسد، اما سورس تو را ویرایش نمی‌کند. پرامپت‌های مجوز همچنان مثلِ حالت پیش‌فرض اعمال می‌شوند.

با زدنِ Shift+Tab یا با پیشونددادنِ یک پرامپتِ تکی با /plan واردِ حالت plan شو. می‌توانی از CLI هم در حالت plan شروع کنی:

claude --permission-mode plan

برای خروج از حالت plan بدونِ تأییدِ یک طرح، دوباره Shift+Tab را بزن.

بازبینی و تأیید یک طرح

وقتی طرح آماده شد، Claude آن را ارائه می‌دهد و می‌پرسد چطور ادامه دهد. از آن پرامپت می‌توانی:

تأیید کنی و در حالت auto شروع کنی
تأیید کنی و ویرایش‌ها را بپذیری
تأیید کنی و هر ویرایش را دستی بازبینی کنی
با بازخورد به برنامه‌ریزی ادامه دهی
با Ultraplan برای بازبینیِ مبتنی بر مرورگر اصلاحش کنی

تأییدِ یک طرح، از حالت plan خارج می‌شود و نشست را به حالتِ دسترسی‌ای که هر گزینه‌ی تأیید توصیف می‌کند سوئیچ می‌کند، پس Claude شروع به ویرایش می‌کند. برای برنامه‌ریزیِ دوباره، با Shift+Tab به حالت plan برگرد، یا پرامپتِ بعدی‌ات را با /plan پیشوند بده.

Ctrl+G را بزن تا طرحِ پیشنهادی در ویرایشگرِ متنیِ پیش‌فرضت باز شود و پیش از این‌که Claude ادامه دهد، مستقیماً ویرایشش کنی. وقتی showClearContextOnPlanAccept فعال باشد، هر گزینه‌ی تأیید این امکان را هم می‌دهد که اول کانتکستِ برنامه‌ریزی را پاک کنی.

پذیرفتنِ یک طرح همچنین نشست را به‌صورت خودکار از روی محتوای طرح نام‌گذاری می‌کند، مگر این‌که قبلاً با --name یا /rename نامی تعیین کرده باشی.

تنظیمِ حالت plan به‌عنوان پیش‌فرض

برای این‌که حالت plan را پیش‌فرضِ یک پروژه کنی، defaultMode را در .claude/settings.json تنظیم کن:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

حذفِ پرامپت‌ها با حالت auto

حالت auto به Claude اجازه می‌دهد بدون پرامپت‌های مجوزِ معمول اجرا کند. یک مدلِ طبقه‌بندِ جداگانه اقدام‌ها را پیش از اجرا بازبینی می‌کند و هر چیزی را که فراتر از درخواست تو می‌رود، زیرساختِ ناشناخته را هدف می‌گیرد، یا به‌نظر برخاسته از محتوای خصمانه‌ای که Claude خوانده می‌رسد، مسدود می‌کند. قواعدِ ask صریح همچنان یک پرامپت را اجباری می‌کنند.

حالت auto همچنین Claude را ترغیب می‌کند که بدونِ توقف برای پرسش‌های روشن‌کننده به کار ادامه دهد، هرچند Claude هنوز وقتی پرامپت تو یا یک Skill صریحاً به آن متکی باشد می‌پرسد. برای رفتارِ خودمختارِ قوی‌تر همراه با حفظِ پرامپت‌های مجوز، به‌جایش سبکِ خروجیِ Proactive را تنظیم کن.

حالت auto فقط وقتی در دسترس است که حسابِ تو همه‌ی این الزامات را برآورده کند:

Plan: همه‌ی پلن‌ها.
Admin: روی Team و Enterprise، پیش از این‌که کاربران بتوانند آن را روشن کنند، یک ادمین باید آن را در تنظیماتِ ادمینِ Claude Code فعال کند. ادمین‌ها همچنین می‌توانند با تنظیمِ permissions.disableAutoMode روی "disable" در تنظیماتِ مدیریت‌شده آن را قفل و خاموش کنند.
Model: روی Anthropic API، Claude Opus 4.6 یا بالاتر، یا Sonnet 4.6. روی Amazon Bedrock، Google Cloud Vertex AI، و Microsoft Foundry، فقط Claude Opus 4.7 و Opus 4.8. مدل‌های قدیمی‌تر، از جمله Sonnet 4.5، Opus 4.5، Haiku، و مدل‌های claude-3، روی هیچ ارائه‌دهنده‌ای پشتیبانی نمی‌شوند.
Provider: به‌صورت پیش‌فرض روی Anthropic API در دسترس است. روی Amazon Bedrock، Google Cloud Vertex AI، و Microsoft Foundry، حالت auto خاموش است تا وقتی CLAUDE_CODE_ENABLE_AUTO_MODE را تنظیم کنی.

اگر Claude Code گزارش دهد حالت auto در دسترس نیست، یکی از این الزامات برآورده نشده است؛ این یک قطعیِ گذرا نیست. پیامی جداگانه که نامِ یک مدل را می‌برد و می‌گوید حالت auto «نمی‌تواند ایمنیِ» یک اقدام را تعیین کند، یک قطعیِ گذرای طبقه‌بند است؛ مرجعِ خطاها را ببین.

اگر defaultMode: "auto" را در تنظیمات تنظیم کنی و نشست بدونِ خطا در حالت default شروع شود، احتمالاً آن تنظیم در .claude/settings.json یا .claude/settings.local.json است. Claude Code نسخه‌ی v2.1.142 و بالاتر مقدارِ auto را از آن فایل‌ها نادیده می‌گیرند تا یک مخزن نتواند به خودش حالت auto بدهد. آن را به ~/.claude/settings.json منتقل کن.

فعال‌کردنِ حالت auto روی Bedrock، Vertex AI، یا Foundry

روی Amazon Bedrock، Google Cloud Vertex AI، و Microsoft Foundry، حالت auto تا وقتی CLAUDE_CODE_ENABLE_AUTO_MODE روی 1 تنظیم نشود در چرخه‌ی Shift+Tab ظاهر نمی‌شود. این متغیر در Claude Code نسخه‌ی v2.1.158 و بالاتر کار می‌کند. روی این ارائه‌دهنده‌ها فقط Claude Opus 4.7 و Opus 4.8 پشتیبانی می‌شوند.

برای فعال‌کردنش برای یک توسعه‌دهنده، متغیر را به بلاکِ env در ~/.claude/settings.json اضافه کن:

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

برای فعال‌کردنش برای سازمانت، همان بلاکِ env را به تنظیماتِ مدیریت‌شده اضافه کن.

وقتی متغیر تنظیم شد، حالت auto برای هر نشست در چرخه‌ی Shift+Tab ظاهر می‌شود. برای این‌که حالتِ شروعِ پیش‌فرض شود، "permissions": {"defaultMode": "auto"} را هم در تنظیماتِ کاربر یا مدیریت‌شده تنظیم کن. روی این ارائه‌دهنده‌ها، Claude Code مقدارِ defaultMode: "auto" را نادیده می‌گیرد مگر این‌که CLAUDE_CODE_ENABLE_AUTO_MODE هم تنظیم شده باشد.

برای جلوگیری از این‌که توسعه‌دهندگان حالت auto را فعال کنند، disableAutoMode را روی "disable" در تنظیماتِ مدیریت‌شده تنظیم کن. این، متغیرِ فعال‌سازی را override می‌کند.

اگر از طریقِ یک LLM gateway که با ANTHROPIC_BASE_URL پیکربندی شده وصل می‌شوی، ممکن است حالت auto بدونِ متغیرِ فعال‌سازی هم در دسترس باشد، چون gateway درخواست‌ها را از طریقِ Anthropic API مسیریابی می‌کند. تنظیمِ disableAutoMode در آن پیکربندی هم به همان شکل اعمال می‌شود.

آن‌چه طبقه‌بند به‌صورت پیش‌فرض مسدود می‌کند

طبقه‌بند به دایرکتوریِ کاریِ تو و ریموت‌های پیکربندی‌شده‌ی مخزنت اعتماد می‌کند. هر چیزِ دیگر تا وقتی زیرساختِ مورد اعتماد را پیکربندی کنی خارجی تلقی می‌شود.

به‌صورت پیش‌فرض مسدود:

دانلود و اجرای کد، مثلِ curl | bash
فرستادنِ داده‌ی حساس به نقاطِ پایانیِ خارجی
استقرارها و مهاجرت‌های production
حذفِ انبوه روی فضای ذخیره‌سازیِ ابری
اعطای دسترسی‌های IAM یا مخزن
تغییرِ زیرساختِ مشترک
نابودیِ برگشت‌ناپذیرِ فایل‌هایی که پیش از نشست وجود داشتند
force push، یا push مستقیم روی main

به‌صورت پیش‌فرض مجاز:

عملیاتِ فایلِ محلی در دایرکتوریِ کاریِ تو
نصبِ وابستگی‌هایی که در فایل‌های lock یا manifestهای تو اعلام شده‌اند
خواندنِ .env و فرستادنِ اعتبارنامه‌ها به APIِ متناظرشان
درخواست‌های HTTPِ فقط‌خواندنی
push به شاخه‌ای که رویش شروع کردی یا شاخه‌ای که Claude ساخت

درخواست‌های دسترسیِ شبکه‌ی سندباکس به‌جای این‌که به‌صورت پیش‌فرض مجاز باشند، از طریقِ طبقه‌بند مسیریابی می‌شوند. claude auto-mode defaults را اجرا کن تا فهرستِ کاملِ قواعد را ببینی. اگر اقدام‌های معمول مسدود می‌شوند، یک مدیر می‌تواند مخزن‌ها، باکت‌ها و سرویس‌های مورد اعتماد را از طریقِ تنظیمِ autoMode.environment اضافه کند: پیکربندیِ حالت auto را ببین.

مرزهایی که در گفت‌وگو بیان می‌کنی

طبقه‌بند مرزهایی را که در گفت‌وگو بیان می‌کنی به‌عنوان سیگنالِ مسدودسازی در نظر می‌گیرد. اگر به Claude بگویی «push نکن» یا «تا وقتی بازبینی نکردم برای استقرار صبر کن»، طبقه‌بند اقدام‌های منطبق را مسدود می‌کند، حتی وقتی قواعدِ پیش‌فرض اجازه‌اش را بدهند. یک مرز تا وقتی در پیامی بعدی برش نداری در اعتبار می‌ماند. قضاوتِ خودِ Claude مبنی بر این‌که شرطی برآورده شده آن را برنمی‌دارد.

مرزها به‌عنوان قاعده ذخیره نمی‌شوند. طبقه‌بند آن‌ها را در هر بررسی از روی رونوشتِ نشست دوباره می‌خواند، پس اگر فشرده‌سازیِ کانتکست پیامی را که آن مرز را بیان کرده حذف کند، آن مرز ممکن است از دست برود. برای تضمینِ قطعی، به‌جایش یک قاعده‌ی deny اضافه کن.

وقتی حالت auto به حالتِ پشتیبان برمی‌گردد

هر اقدامِ ردشده یک اعلان نشان می‌دهد و در /permissions زیرِ زبانه‌ی Recently denied ظاهر می‌شود، جایی که می‌توانی r را بزنی تا با یک تأییدِ دستی دوباره امتحانش کنی.

اگر طبقه‌بند یک اقدام را ۳ بار پشتِ‌سرِ‌هم یا ۲۰ بار در مجموع مسدود کند، حالت auto مکث می‌کند و Claude Code دوباره به پرسیدن برمی‌گردد. تأییدِ اقدامِ پرسیده‌شده، حالت auto را از سر می‌گیرد. این آستانه‌ها قابل‌تنظیم نیستند. هر اقدامِ مجاز، شمارنده‌ی متوالی را صفر می‌کند، در حالی که شمارنده‌ی کل برای نشست باقی می‌ماند و فقط وقتی صفر می‌شود که سقفِ خودش یک بازگشت به پشتیبان را راه بیندازد.

در حالت غیرتعاملی با پرچمِ -p، مسدودسازی‌های مکرر نشست را لغو می‌کنند چون کاربری برای پرسیدن وجود ندارد.

مسدودسازی‌های مکرر معمولاً یعنی طبقه‌بند کانتکستی درباره‌ی زیرساختِ تو کم دارد. از /feedback برای گزارشِ مثبت‌های کاذب استفاده کن، یا از یک مدیر بخواه زیرساختِ مورد اعتماد را پیکربندی کند.

طبقه‌بند چطور اقدام‌ها را ارزیابی می‌کند

هر اقدام از یک ترتیبِ تصمیمِ ثابت می‌گذرد. اولین گامِ منطبق برنده است:

اقدام‌هایی که با قواعدِ allow یا deny تو منطبق‌اند بلافاصله حل می‌شوند، به‌جز نوشتن در مسیرهای محافظت‌شده که حتی وقتی یک قاعده‌ی allow منطبق باشد به طبقه‌بند مسیریابی می‌شوند
اقدام‌های فقط‌خواندنی و ویرایش‌های فایل در دایرکتوریِ کاریِ تو به‌صورت خودکار تأیید می‌شوند، به‌جز نوشتن در مسیرهای محافظت‌شده
هر چیزِ دیگر به طبقه‌بند می‌رود
اگر طبقه‌بند مسدود کند، Claude دلیل را دریافت می‌کند و راهِ جایگزینی را امتحان می‌کند

هنگامِ ورود به حالت auto، قواعدِ allowِ گسترده‌ای که اجرای دلخواهِ کد را اعطا می‌کنند کنار گذاشته می‌شوند:

Bash(*) یا PowerShell(*)ِ سراسری
مفسرهای wildcard مثلِ Bash(python*)
فرمان‌های اجرای مدیرِ بسته
قواعدِ allowِ Agent

قواعدِ باریک مثلِ Bash(npm test) منتقل می‌شوند. قواعدِ کنارگذاشته‌شده وقتی از حالت auto خارج شوی بازگردانده می‌شوند.

طبقه‌بند پیام‌های کاربر، فراخوانی‌های ابزار، و محتوای CLAUDE.md تو را می‌بیند. نتایجِ ابزار حذف می‌شوند، پس محتوای خصمانه در یک فایل یا صفحه‌ی وب نمی‌تواند مستقیماً آن را دستکاری کند. یک کاوشگرِ جداگانه‌ی سمتِ سرور نتایجِ ورودیِ ابزار را اسکن می‌کند و پیش از این‌که Claude بخواندشان، محتوای مشکوک را علامت می‌زند. برای اطلاعاتِ بیشتر درباره‌ی این‌که این لایه‌ها چطور با هم کار می‌کنند، اعلانِ حالت auto و غوصِ مهندسیِ عمیق را ببین.

حالت auto چطور ساب‌ایجنت‌ها را مدیریت می‌کند

طبقه‌بند کارِ ساب‌ایجنت را در سه نقطه بررسی می‌کند:

پیش از این‌که یک ساب‌ایجنت شروع کند، شرحِ وظیفه‌ی واگذارشده ارزیابی می‌شود، پس یک وظیفه‌ی خطرناک‌به‌نظر در زمانِ ایجاد مسدود می‌شود.
در حین اجرای ساب‌ایجنت، هر اقدامِ آن با همان قواعدِ نشستِ والد از طریقِ طبقه‌بند می‌گذرد، و هر permissionModeای در frontmatterِ ساب‌ایجنت نادیده گرفته می‌شود.
وقتی ساب‌ایجنت تمام می‌کند، طبقه‌بند کلِ تاریخچه‌ی اقدام‌هایش را بازبینی می‌کند؛ اگر آن بررسیِ بازگشتی نگرانی‌ای را علامت بزند، یک هشدارِ امنیتی به ابتدای نتایجِ ساب‌ایجنت افزوده می‌شود.

هزینه و تأخیر

طبقه‌بند روی مدلی که سمتِ سرور پیکربندی شده اجرا می‌شود و مستقل از انتخابِ /model توست، پس عوض‌کردنِ مدل، در دسترس‌بودنِ طبقه‌بند را تغییر نمی‌دهد. فراخوانی‌های طبقه‌بند به‌حساب مصرفِ توکنِ تو منظور می‌شوند. هر بررسی، بخشی از رونوشتِ نشست به‌علاوه‌ی اقدامِ معلق را می‌فرستد و یک رفت‌وبرگشت پیش از اجرا اضافه می‌کند. خواندن‌ها و ویرایش‌های دایرکتوریِ کاری بیرون از مسیرهای محافظت‌شده از طبقه‌بند رد می‌شوند، پس سربار عمدتاً از فرمان‌های شل و عملیاتِ شبکه می‌آید.

اجازه‌ی فقط ابزارهای از پیش تأییدشده با حالت dontAsk

حالت dontAsk هر فراخوانیِ ابزاری را که در غیرِ این‌صورت پرسیده می‌شد به‌صورت خودکار رد می‌کند. فقط اقدام‌هایی که با قواعدِ permissions.allow تو منطبق‌اند و فرمان‌های فقط‌خواندنیِ Bash می‌توانند اجرا شوند؛ قواعدِ ask صریح به‌جای پرسیدن، رد می‌شوند. این کار حالت را برای خطوطِ لوله‌ی CI یا محیط‌های محدودشده، که در آن‌ها دقیقاً از پیش تعریف می‌کنی Claude چه کاری مجاز است انجام دهد، کاملاً غیرتعاملی می‌کند. نشست‌های ابری روی Claude Code on the web مقدارِ defaultMode: "dontAsk" را نادیده می‌گیرند؛ برای جزئیات bypassPermissions را ببین.

آن را در زمانِ راه‌اندازی با این پرچم تنظیم کن:

claude --permission-mode dontAsk

ردکردنِ همه‌ی بررسی‌ها با حالت bypassPermissions

حالت bypassPermissions پرامپت‌های مجوز و بررسی‌های ایمنی را غیرفعال می‌کند تا فراخوانی‌های ابزار بلافاصله اجرا شوند. از نسخه‌ی v2.1.126، این شاملِ نوشتن در مسیرهای محافظت‌شده هم می‌شود، که نسخه‌های قبلی هنوز برایش می‌پرسیدند. قواعدِ ask صریح در این حالت هم هنوز یک پرامپت را اجباری می‌کنند، و حذف‌هایی که ریشه‌ی فایل‌سیستم یا دایرکتوریِ خانگی را هدف می‌گیرند، مثلِ rm -rf / و rm -rf ~، همچنان به‌عنوان مدارشکن (circuit breaker) در برابرِ خطای مدل پرسیده می‌شوند. این حالت را فقط در محیط‌های ایزوله مثلِ کانتینرها، VMها، یا dev containerهای بدونِ دسترسی به اینترنت استفاده کن، جایی که Claude Code نمی‌تواند به سیستمِ میزبانت آسیب بزند.

نمی‌توانی از نشستی که بدونِ یکی از پرچم‌های فعال‌ساز شروع شده واردِ bypassPermissions شوی؛ برای فعال‌کردنش با یکی از آن‌ها دوباره راه‌اندازی کن:

claude --permission-mode bypassPermissions

پرچمِ --dangerously-skip-permissions معادلِ آن است.

روی Linux و macOS، وقتی Claude Code به‌عنوان root یا زیرِ sudo اجرا شود، از شروع در این حالت سر باز می‌زند:

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

این بررسی به‌صورت خودکار داخلِ یک سندباکسِ شناخته‌شده رد می‌شود. برای اجرای خودمختار در یک کانتینر، از پیکربندیِ dev container استفاده کن که Claude Code را به‌عنوان کاربرِ غیرِ root اجرا می‌کند.

Claude Code on the web مقدارِ defaultMode: "bypassPermissions" یا "dontAsk" را از فایل‌های تنظیماتت رعایت نمی‌کند، پس تنظیماتِ کامیت‌شده‌ی یک مخزن نمی‌تواند یک نشستِ ابری را در حالت bypass-permissions شروع کند. آن تنظیم بی‌صدا نادیده گرفته می‌شود و نشست به‌جایش در حالتِ نشان‌داده‌شده در منوی کشویی حالت شروع می‌شود. برای این‌که ببینی نشست‌های ابری چه حالت‌هایی ارائه می‌دهند، جابه‌جایی بین حالت‌های دسترسی را ببین.

مسیرهای محافظت‌شده

نوشتن در مجموعه‌ی کوچکی از مسیرها هرگز به‌صورت خودکار تأیید نمی‌شود، در هر حالتی به‌جز bypassPermissions. این از خرابیِ تصادفیِ وضعیتِ مخزن و پیکربندیِ خودِ Claude جلوگیری می‌کند.

حالت	نوشتن در مسیرِ محافظت‌شده
`default`, `acceptEdits`, `plan`	پرسیده می‌شود
`auto`	به طبقه‌بند مسیریابی می‌شود
`dontAsk`	رد می‌شود
`bypassPermissions`	مجاز است

قواعدِ permissions.allow در فایل‌های تنظیمات، نوشتن در مسیرهای محافظت‌شده را از پیش تأیید نمی‌کنند. بررسیِ ایمنی پیش از این‌که Claude Code قواعدِ allow را از تنظیمات ارزیابی کند اجرا می‌شود، پس ورودی‌ای مثلِ Edit(.claude/**) در ~/.claude/settings.json یا .claude/settings.json نتیجه‌ی هر-حالتی را در جدولِ بالا تغییر نمی‌دهد. در حالت‌هایی که می‌پرسند، پرامپتِ نوشتن در .claude/ گزینه‌ی Yes, and allow Claude to edit its own settings for this session را ارائه می‌دهد، که نوشتن‌های بعدیِ .claude/ را در آن نشست بدونِ پرسیدنِ دوباره تأیید می‌کند.

دایرکتوری‌های محافظت‌شده:

.git
.config/git
.vscode
.idea
.husky
.cargo
.devcontainer
.yarn
.mvn
.claude، به‌جز .claude/worktrees که Claude git worktreeهای خودش را آن‌جا ذخیره می‌کند

فایل‌های محافظت‌شده:

.gitconfig, .gitmodules
.bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
.npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
.bazelrc, .bazelversion, .bazeliskrc
.pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
gradle-wrapper.properties, maven-wrapper.properties
.devcontainer.json
.ripgreprc, pyrightconfig.json
.mcp.json, .claude.json

همچنین ببین

دسترسی‌ها: قواعدِ allow، ask، و deny؛ سیاست‌های مدیریت‌شده
پیکربندیِ حالت auto: به طبقه‌بند بگو سازمانت به کدام زیرساخت اعتماد دارد
Hooks: منطقِ سفارشیِ مجوز از طریقِ هوک‌های PreToolUse و PermissionRequest
Ultraplan: اجرای حالت plan در یک نشستِ Claude Code on the web با بازبینیِ مبتنی بر مرورگر
امنیت: محافظت‌ها و بهترین شیوه‌ها
Sandboxing: ایزوله‌سازیِ فایل‌سیستم و شبکه برای فرمان‌های Bash
حالت غیرتعاملی: اجرای Claude Code با پرچمِ -p