تغییر حالت پیش‌فرض Claude Code به auto از 14 August 2026

تغییرات حالت auto در تاریخ 14 August 2026

حالت auto در Claude Code فراخوانی ابزارها را بدون توقف برای پرسش از شما انجام می‌دهد و هر اقدام را پیش از اجرا، برای بررسی به یک مدل طبقه‌بندی‌کننده مجزا می‌فرستد. از تاریخ 14 August 2026، این حالت به وضعیت پیش‌فرض برای نشست‌های جدید در طرح‌های Pro، Max و Team تبدیل می‌شود. شما می‌توانید در هر زمان حالت‌ها را تغییر دهید و تنظیمات پیش‌فرضی که قبلاً برای خود تعیین کرده‌اید، بازنویسی نخواهد شد.

در مستندات، این تغییر به شرح زیر بیان شده است:

از تاریخ 14 August 2026، حالت auto به حالت دسترسی پیش‌فرض برای نشست‌های جدید در طرح‌های Pro، Max و Team تبدیل می‌شود. شما می‌توانید در هر زمان حالت‌ها را تغییر دهید. پیش‌فرضی که خودتان تعیین کرده‌اید، مگر در صورت پذیرش اعلان تغییر یک‌باره، به قوت خود باقی می‌ماند و پیش‌فرضی که سازمان شما مدیریت می‌کند نیز بدون تغییر خواهد بود.

دو بند در متن بالا اهمیت بیشتری از تاریخ دارند. یک defaultMode که در فایل تنظیمات شخصی خود تعیین کرده‌اید، پس از این تغییر حفظ می‌شود. پیش‌فرضی که سازمان شما از طریق تنظیمات مدیریت‌شده اعمال می‌کند نیز دست‌نخورده باقی می‌ماند. در پست اطلاع‌رسانی اضافه شده است که حالت auto برای طرح‌های Enterprise و حساب‌هایی که در بخش اول عرضه از API استفاده می‌کنند، همچنان اختیاری باقی می‌ماند.

اگر Claude Code را روی یک VPS (سرور مجازی خصوصی) اجرا می‌کنید، پیش از اعمال این تغییر، مطالعه آن ضروری است. اعلان مجوز، یک نقطه بازرسی است که نیاز به حضور فرد پشت کیبورد دارد. در یک سیستم از راه دور، شما اغلب حضور ندارید؛ بنابراین حالتی که نشست در آن شروع می‌شود، همان حالتی است که برای ساعت‌ها باقی می‌ماند.

حالت‌های دسترسی Claude Code، از بیشترین نظارت تا کمترین

شش حالت وجود دارد. نامی که در ابتدای هر خط آمده، مقداری است که در تنظیمات می‌نویسید یا به --permission-mode ارسال می‌کنید.

• default: کلود پیش از هر بار استفاده از ابزار، اجازه می‌گیرد. خواندن فایل‌ها در دایرکتوری کاری همچنان بدون پرسش انجام می‌شود. رابط خط فرمان (CLI) این حالت را Manual نام‌گذاری کرده و از نسخه 2.1.200 به بعد، manual را نیز به عنوان نام مستعار می‌پذیرد.
• plan: کلود فایل‌ها را می‌خواند و دستورات را برای بررسی اجرا می‌کند، اما کد منبع شما را ویرایش نمی‌کند. ویرایش‌ها تا زمانی که طرح پیشنهادی را تأیید نکنید، مسدود می‌مانند.
• acceptEdits: ویرایش فایل‌ها بدون پرسش انجام می‌شود، به همراه دستورات فایل‌سیستم شامل mkdir، touch، rm، rmdir، mv، cp و sed. این مورد فقط برای مسیرهای داخل دایرکتوری کاری یا additionalDirectories شما اعمال می‌شود. سایر دستورات shell همچنان نیاز به تأیید دارند.
• auto: همه دستورات اجرا می‌شوند و یک طبقه‌بندی‌کننده (classifier) هر اقدام را پیش از اجرا بررسی می‌کند. قوانین صریح ask همچنان باعث ایجاد پرسش (prompt) می‌شوند.
• dontAsk: کلود کد به‌طور خودکار هر عملی که نیاز به تأیید داشته باشد را رد می‌کند. فقط قوانین allow شما، دستورات Bash داخلیِ فقط‌خواندنی و فراخوانی‌هایی که یک هوک PreToolUse تأیید کند، اجرا می‌شوند. نشست (session) هرگز منتظر ورودی نمی‌ماند.
• 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 mode) همچنین به یک مدل جدید نیاز دارد که معمول‌ترین دلیل عدم نمایش آن است. تا اوت 2026، مستندات مدل‌های Claude Opus 4.6 یا جدیدتر، Sonnet 4.6 یا جدیدتر، و Fable 5 را در Anthropic API فهرست کرده و ذکر می‌کند که مدل‌های قدیمی‌تر مانند Sonnet 4.5 در هیچ ارائه‌دهنده‌ای پشتیبانی نمی‌شوند. اگر Claude Code گزارش دهد که حالت خودکار در دسترس نیست، یکی از این الزامات برآورده نشده است. این یک قطعی موقت نیست، بنابراین انتظار کشیدن مشکل را حل نمی‌کند.

دو کنترل در همه حالت‌ها، از جمله bypassPermissions، برقرار هستند: قوانین deny و قوانین صریح ask. این‌ها اهرم‌هایی هستند که فارغ از حالتی که نشست با آن شروع می‌شود، در اختیار شما باقی می‌مانند.

آنچه مدل طبقه‌بندی خودکار مسدود می‌کند

این طبقه‌بندی‌کننده (classifier) مدل دومی است که اقدام در انتظار اجرا را بررسی می‌کند و تصمیم می‌گیرد که آیا با درخواست شما مطابقت دارد یا خیر. مستندات، وظیفه آن را در یک جمله این‌گونه توصیف می‌کنند:

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

موارد مسدودشده به‌صورت پیش‌فرض، در دسته‌هایی که مدیر سرور بیش از همه با آن‌ها مواجه می‌شود:

• دانلود و اجرای کد، مانند curl | bash
• استقرار (deploy) و مهاجرت‌های محیط عملیاتی (production)
• دستور force push
• تغییر در زیرساخت‌های اشتراکی
• باز کردن تونل یا reverse shell که یک سرویس محلی را از طریق اینترنت عمومی در دسترس قرار می‌دهد
• چاپ اعتبارنامه (credential) یا توکن فعال در متن گفتگو یا یک فایل

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

• عملیات فایل محلی در دایرکتوری کاری شما
• نصب وابستگی‌های تعریف‌شده در فایل‌های lock یا manifest
• درخواست‌های HTTP فقط‌خواندنی (read-only)
• push کردن به هر شاخه‌ای از مخزنی که در آن کار می‌کنید

بر اساس خلاصه‌ای مانند آنچه در بالا آمد، کار نکنید. دستور claude auto-mode defaults را اجرا کنید تا لیست کامل قوانین را به‌صورت JSON چاپ کنید و مجموعه‌ای را که همراه با نسخه‌ای که نصب کرده‌اید ارائه شده است، مطالعه کنید.

پیش از تکیه بر این قابلیت، دو محدودیت مستندشده اهمیت دارند. نخست، طبقه‌بندی‌کننده پیام‌های شما، فراخوانی‌های ابزار و محتوای CLAUDE.md شما را می‌بیند، اما نتایج ابزار حذف می‌شوند؛ بنابراین متن داخل یک فایل یا صفحه وبی که Claude خوانده است، نمی‌تواند مستقیماً طبقه‌بندی‌کننده را خطاب قرار دهد. دوم، زمانی که طبقه‌بندی‌کننده یک اقدام را 3 بار متوالی یا 20 بار در یک نشست (session) مسدود کند، حالت خودکار متوقف شده و Claude Code به مرحله پرسش از شما بازمی‌گردد. این آستانه‌ها قابل پیکربندی نیستند. در حالت غیرتعاملی با پرچم -p، کسی برای پاسخگویی وجود ندارد، بنابراین مسدود شدن‌های مکرر باعث لغو نشست می‌شود.

آن رفتار دوم همان چیزی است که در یک سیستم از راه دور مشکل‌ساز می‌شود. اجرای بدون نظارت که به این محدودیت برخورد کند، متوقف شده و منتظر شخصی می‌ماند که به ترمینال نگاه نمی‌کند. محدود کردن آنچه عامل (agent) قصد انجام آن را دارد، نیمه دیگر راه‌حل است و مهارتی که عامل را به سمت کوچک‌ترین تغییرِ کارآمد سوق می‌دهد، از انحراف نشست به سمت اقدامات گسترده‌ای که طبقه‌بندی‌کننده آن‌ها را متوقف می‌کند، جلوگیری می‌کند.

محل قرارگیری حالت‌ها در settings.json

تمام موارد بالا در یک شیء واحد در فایل تنظیمات قرار دارند.

{
  "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. اولین تطبیق در این ترتیب، نتیجه را تعیین می‌کند و یک قانون محدودتر، بر قانون گسترده‌تری که پیش از آن آمده است، اولویت ندارد. یک قانون deny برای Bash(aws *)، دسترسی aws s3 ls را مسدود می‌کند، حتی اگر دقیقاً همان دستور را مجاز کرده باشید؛ بنابراین یک قانون deny نمی‌تواند استثنا داشته باشد.

ask نوع قانونی است که در حالت auto کارایی خود را نشان می‌دهد. حالت auto درخواست‌های معمول را حذف می‌کند و یک قانون ask، برای دستوری خاص که می‌خواهید کاربر روی آن تأییدیه دهد، دوباره درخواست را فعال می‌کند. دستور deploy شما در این دسته قرار می‌گیرد. همچنین اگر می‌خواهید پیش از خروج کد از محیط، یک نقطه بازرسی (checkpoint) داشته باشید، Bash(git push *) نیز در همین دسته جای می‌گیرد. نگهداری فایل‌های حاوی اعتبارنامه‌ها در deny نیمه دیگر این موضوع است و با دور نگه داشتن اعتبارنامه‌ها از دسترس عامل (agent) جفت می‌شود.

فایل‌های تنظیمات به ترتیب اولویت (از کم به زیاد):

• ~/.claude/settings.json: تنظیمات کاربری شما که در همه پروژه‌ها اعمال می‌شود.
• .claude/settings.json: تنظیمات پروژه که در مخزن (repository) کامیت می‌شود.
• .claude/settings.local.json: تنظیمات شخصی شما برای یک مخزن خاص که در gitignore قرار دارد.
• تنظیمات مدیریت‌شده که توسط مدیر سیستم اعمال می‌شود. در لینوکس، این فایل /etc/claude-code/managed-settings.json است. هیچ‌چیز، حتی پرچم‌های خط فرمان، نمی‌تواند بر یک قانون دسترسی مدیریت‌شده غلبه کند.

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

دو سوییچی که یک حالت را غیرفعال می‌کنند

مدیران سیستم دو سوییچ برای غیرفعال‌سازی (kill switch) در اختیار دارند و هر دو به جای مقدار بولی، رشته "disable" را می‌پذیرند.

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

مستندات در مورد محل قرارگیری آن‌ها دقیق است:

برای جلوگیری از استفاده از حالت bypassPermissions یا auto، مقدار permissions.disableBypassPermissionsMode یا permissions.disableAutoMode را در هر فایل تنظیماتی برابر با "disable" قرار دهید. این تنظیمات در محیط‌های مدیریت‌شده که امکان تغییر آن‌ها توسط کاربر وجود ندارد، بسیار مفید هستند.

disableAutoMode حالت auto را از چرخه Shift+Tab حذف کرده و --permission-mode auto را در زمان راه‌اندازی رد می‌کند. disableBypassPermissionsMode همین کار را برای حالت bypass انجام می‌دهد و از هر scopeای عمل می‌کند؛ بنابراین می‌توانید آن را در ~/.claude/settings.json شخصی خود قرار دهید تا دسترسی خود را به حالتی که ترجیح می‌دهید ساعت 2 بامداد در یک سرور عملیاتی به آن دسترسی نداشته باشید، مسدود کنید. در سیستمی که افراد دیگری از آن استفاده می‌کنند، هر دو را در /etc/claude-code/managed-settings.json قرار دهید، زیرا فایل تنظیمات کاربر متعلق به خود اوست و فایل مدیریت‌شده چنین نیست.

چرا حالت خودکار روی یک VPS به مرز ایزولاسیون نیاز دارد

طبقه‌بندی‌کننده (classifier) هر اقدام را به‌صورت جداگانه بررسی می‌کند. این ابزار شامل بررسی پیامدهای یک اقدام تأییدشده نیست. مستندات این مرز را به‌وضوح مشخص کرده‌اند:

طبقه‌بندی‌کننده یک کنترل برای هر اقدام است، نه یک مرز ایزولاسیون؛ بنابراین مرز ایزولاسیون همچنان برای اجراهای بدون نظارت، لایه‌ای از دفاع در عمق ایجاد می‌کند و برخلاف --dangerously-skip-permissions، یک الزام مطلق نیست.

بنابراین، ترکیب مناسب برای یک سرور از راه دور، استفاده از حالت خودکار به همراه محیطی است که از دست دادن آن برای شما اهمیتی نداشته باشد، نه استفاده از bypassPermissions و تکیه بر شانس. حالت Bypass فقط برای محیط‌های ایزوله مستند شده است: کانتینرها، ماشین‌های مجازی یا dev containerهایی که به اینترنت دسترسی ندارند و در آن‌ها Claude Code نمی‌تواند به سیستم میزبان شما آسیب برساند. یک VPS که دیتابیس و reverse proxy شما روی آن اجرا می‌شود، هیچ‌کدام از این موارد نیست.

سه مورد بیشترین اهمیت را در امنیت سرور دارند. Claude Code را به‌عنوان یک کاربر معمولی اجرا کنید، هرگز از root استفاده نکنید. به آن کاربر فقط یک دایرکتوری کاری اختصاص دهید و هیچ فایل دیگری که ارزش خواندن داشته باشد در دسترسش قرار ندهید. به‌جای تعمیر سرور، آن را دوباره بسازید؛ این همان استدلالی است که برای یک ماشین مجازی یک‌بارمصرف که پس از هر کار حذف می‌شود مطرح می‌شود. جزئیات مقاوم‌سازی (hardening) این موارد، از ایجاد کاربر تا قوانین فایروال، در راهنمای کامل ایمنی برای اجرای Claude Code روی VPS پوشش داده شده است و در اینجا تکرار نمی‌شود.

Claude Code قانون استفاده نکردن از root را خودش اعمال می‌کند. در Linux و macOS، این ابزار از شروع به کار در حالت bypass با کاربر sudo یا root خودداری می‌کند:

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

این بررسی در داخل یک sandbox شناسایی‌شده نادیده گرفته می‌شود؛ به همین دلیل پاسخ مستند برای کار خودکار در کانتینر، استفاده از یک dev container است که Claude Code را با کاربری غیر از root اجرا می‌کند. اگر عامل (agent) را از طریق گوشی یا لپ‌تاپ و با SSH کنترل می‌کنید، همین استدلال برای یک نشست طولانی‌مدت Claude Code که در tmux باز نگه داشته شده صدق می‌کند: در زمانی که نشست در حال اجراست، کسی بر خروجی‌ها نظارت نمی‌کند.

راه‌اندازی Bash sandbox روی Ubuntu VPS

sandbox داخلی، دسترسی به فایل‌سیستم و شبکه برای هر دستور Bash که Claude اجرا می‌کند را محدود کرده و سیستم‌عامل این محدودیت را بر فرآیندهای فرزند نیز اعمال می‌کند. در لینوکس، این قابلیت به دو بسته نیاز دارد.

sudo apt-get install bubblewrap socat

برنامه Claude Code را اجرا کرده و /sandbox را وارد کنید. پنل با تب‌های Mode و Overrides باز می‌شود؛ همچنین تب Dependencies هر وابستگیِ مفقود را فهرست می‌کند. بررسی وابستگی‌ها در زمان شروع برنامه انجام می‌شود، بنابراین پس از نصب بسته‌ها، Claude Code را مجدداً راه‌اندازی کنید، در غیر این صورت پنل همچنان آن‌ها را غایب گزارش می‌کند.

در Ubuntu 24.04 و نسخه‌های بعد از آن، سیاست پیش‌فرض AppArmor مانع از ایجاد namespaceهای کاربری توسط bubblewrap می‌شود و در نتیجه sandbox اجرا نمی‌شود. بررسی کنید که آیا این مورد برای سرور شما صدق می‌کند یا خیر:

sysctl kernel.apparmor_restrict_unprivileged_userns

خروجی 0، یا خطایی مبنی بر عدم وجود کلید، به این معنی است که نیازی به انجام کاری نیست. خروجی 1 به این معنی است که bwrap به پروفایل اختصاصی خود نیاز دارد:

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

این پروفایل روی خودِ bwrap اعمال می‌شود، نه روی دستوراتی که درون sandbox اجرا می‌کند. سپس محدوده را در تنظیمات محدودتر کنید:

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

این بلوک باید در فایل .claude/settings.json پروژه قرار بگیرد، زیرا . فقط در تنظیمات پروژه به ریشه پروژه اشاره می‌کند. اگر همین خطوط را در ~/.claude/settings.json قرار دهید، . به ~/.claude اشاره خواهد کرد و در نتیجه، قانون denyRead فایل‌های پروژه شما را مسدود نگه می‌دارد و هر دستوری در خواندن کدی که قرار است ویرایش کند، شکست می‌خورد.

بدانید که این روش چه مواردی را پوشش نمی‌دهد. sandbox فقط Bash و فرآیندهای فرزند آن را محدود می‌کند. ابزارهای فایل داخلی درون فرآیند Claude Code اجرا می‌شوند و سرورهای MCP (پروتکل زمینه مدل) و هوک‌ها، فرآیندهای مجزایی هستند که بدون محدودیت روی میزبان اجرا می‌شوند. برای قرار دادن همه آن‌ها پشت یک مرز امنیتی، کل فرآیند Claude Code را درون یک کانتینر، یک ماشین مجازی یا بسته @anthropic-ai/sandbox-runtime اجرا کنید که در زمان نگارش این متن، یک پیش‌نمایش تحقیقاتی در مرحله بتا است.

هر پیکربندی شایسته چه حالتی است؟

یک مخزن تکی روی لپ‌تاپ شخصی شما

از auto به همراه قوانین ask برای عملیاتی که می‌خواهید نظارت شوند، استفاده کنید. شما پشت سیستم هستید، بازگشت به طبقه‌بندی‌کننده (classifier fallback) می‌تواند به شما دسترسی داشته باشد و خسارت احتمالی محدود به ماشینی است که خودتان کنترل می‌کنید. این همان سناریویی است که پیش‌فرض 14 August برای آن نوشته شده است.

یک VPS اشتراکی

از auto برای هر کاربر استفاده کنید که در فایل ~/.claude/settings.json اختصاصی همان کاربر تنظیم شده باشد؛ روی سیستمی که حساب کاربری اجرای Claude Code در آن root نیست و نمی‌تواند کارهای سایر کاربران را بخواند. disableBypassPermissionsMode را به عنوان "disable" در /etc/claude-code/managed-settings.json مستقر کنید، همراه با قوانین deny که از مسیرهای اشتراکی محافظت می‌کنند. یک سیستم اشتراکی واضح‌ترین موردی است که در آن bypassPermissions اشتباه است، زیرا مرز ایزوله‌سازی که این حالت فرض می‌کند وجود ندارد: سایر مستأجران (tenants) درون آن قرار دارند.

CI و نشست‌های بدون نظارت (unattended)

از dontAsk با یک لیست صریح allow از دستوراتی که آن job نیاز دارد، استفاده کنید. وقتی هیچ فردی برای مشاهده اعلان (prompt) حضور ندارد، Auto-deny حالت شکست صحیح است. حالت Auto نیز به صورت غیرتعاملی اجرا می‌شود، اما مسدودسازی‌های مکرر توسط طبقه‌بندی‌کننده باعث توقف نشست -p می‌شود، بنابراین jobای که به آن‌ها برخورد کند، در میانه راه با کاری نیمه‌تمام شکست می‌خورد. bypassPermissions را فقط برای کانتینر یا ماشین مجازی که از روی یک image بازسازی می‌کنید نگه دارید و آن را روی هیچ میزبانی که سرویس‌های مهم شما روی آن اجرا می‌شوند، فعال نکنید.

FAQ

حالت خودکار (auto mode) از چه زمانی در Claude Code به حالت پیش‌فرض تبدیل می‌شود؟

از تاریخ 14 اوت 2026، برای نشست‌های جدید در طرح‌های Pro، Max و Team. مستندات اضافه می‌کنند که شما می‌توانید در هر زمان حالت‌ها را تغییر دهید؛ همچنین اگر خودتان یک حالت پیش‌فرض تعیین کرده باشید، تا زمانی که اعلان تغییر یک‌باره (one-time switch prompt) را نپذیرید، همان حالت باقی می‌ماند و تنظیمات پیش‌فرضی که توسط سازمان شما مدیریت می‌شود نیز بدون تغییر می‌ماند. در این اطلاعیه ذکر شده است که حالت خودکار برای طرح‌های Enterprise و حساب‌هایی که در بخش اول عرضه از API استفاده می‌کنند، همچنان اختیاری باقی می‌ماند. برای بررسی وضعیت فعلی نشست، به نوار وضعیت نگاه کنید که در حالت خودکار عبارت ⏵⏵ auto mode on را نمایش می‌دهد.

آیا باید در VPS از حالت خودکار استفاده کنم یا از bypassPermissions؟

از حالت خودکار، همراه با یک مرز ایزوله‌سازی (isolation boundary) استفاده کنید. طبقه‌بندی‌کننده (classifier) هر اقدام را پیش از اجرا بررسی می‌کند، اما مستندات به‌صراحت بیان می‌کنند که این یک کنترل برای هر اقدام است و نه یک مرز ایزوله‌سازی؛ بنابراین برای اجرای بدون نظارت، همچنان به یک container، ماشین مجازی یا محیطی که آمادگی بازسازی آن را دارید، نیاز است. گزینه bypassPermissions بررسی‌ها را به‌طور کامل نادیده می‌گیرد و مستندات آن را فقط برای محیط‌های ایزوله توصیه کرده‌اند. Claude Code در لینوکس از اجرای این حالت با دسترسی root خودداری کرده و عبارت --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons را چاپ می‌کند.

چگونه می‌توانم استفاده از حالت خودکار یا حالت bypass را برای کاربران سرورم مسدود کنم؟

مقادیر permissions.disableAutoMode و permissions.disableBypassPermissionsMode را در فایل /etc/claude-code/managed-settings.json برابر با رشته "disable" قرار دهید. تنظیمات مدیریت‌شده (Managed settings) بر تمام محدوده‌های دیگر اولویت دارند، بنابراین هیچ فایل تنظیمات کاربری و هیچ پرچم (flag) خط فرمانی نمی‌تواند آن‌ها را نادیده بگیرد. گزینه disableAutoMode، حالت auto را از چرخه Shift+Tab حذف کرده و در هنگام راه‌اندازی، --permission-mode auto را رد می‌کند. گزینه disableBypassPermissionsMode نیز از هر محدوده‌ای کار می‌کند، بنابراین یک کاربر می‌تواند آن را در فایل ~/.claude/settings.json شخصی خود تنظیم کند.

چرا تنظیمات defaultMode: "auto" من نادیده گرفته می‌شود؟

زیرا در فایل اشتباهی قرار دارد. از نسخه 2.1.142 به بعد در Claude Code، تنظیم defaultMode: "auto" هنگامی که از .claude/settings.json یا .claude/settings.local.json فراخوانی شود نادیده گرفته می‌شود تا یک مخزن (repository) نتواند با ارسال یک فایل تنظیمات، به خود مجوز حالت خودکار بدهد. نشست در حالت default شروع می‌شود و هیچ خطایی چاپ نمی‌کند. تنظیمات را به ~/.claude/settings.json منتقل کنید و سپس دستور /permissions را اجرا کنید تا تأیید کنید هر قانون فعال از کدام فایل آمده است. اگر حالت خودکار همچنان در دسترس نیست، پیش‌نیاز مدل را بررسی کنید: مدل‌های قدیمی‌تر مانند Sonnet 4.5 در هیچ ارائه‌دهنده‌ای پشتیبانی نمی‌شوند.