پیکربندیِ حالتِ خودکار

این یک ترجمهٔ غیررسمی از مستندات Claude Code است که توسط مسیر تهیه شده. نسخهٔ مرجع و معتبر، مستندات رسمی انگلیسی است.

Auto mode به Claude Code اجازه می‌دهد بدونِ پرامپت‌های دسترسیِ روزمره اجرا شود، با مسیریابیِ فراخوانی‌های ابزار از طریقِ یک classifier که هر چیزِ برگشت‌ناپذیر، مخرب، یا متوجهِ بیرونِ محیطت را مسدود می‌کند. قواعدِ deny و askِ صریح پیش از classifier ارزیابی می‌شوند و همچنان مسدود می‌کنند یا پرامپت می‌دهند. از بلاکِ تنظیماتِ autoMode استفاده کن تا به آن classifier بگویی سازمانت به کدام مخزن‌ها، bucketها و دامنه‌ها اعتماد دارد، تا دیگر عملیاتِ داخلیِ روزمره را مسدود نکند.

یادداشت

Auto mode برای همه‌ی کاربران روی Anthropic API در دسترس است. روی Amazon Bedrock، Google Cloud Vertex AI و Microsoft Foundry، ابتدا باید CLAUDE_CODE_ENABLE_AUTO_MODE را تنظیم کنی. اگر Claude Code گزارش داد که auto mode برای حسابت در دسترس نیست، الزاماتِ کامل را بررسی کن، که مدل‌های پشتیبانی‌شده و فعال‌سازیِ ادمین روی پلن‌های Team و Enterprise را هم پوشش می‌دهد.

به‌صورتِ پیش‌فرض، classifier فقط به دایرکتوریِ کاری و remoteهای پیکربندی‌شده‌ی مخزنِ فعلی اعتماد می‌کند. اقدام‌هایی مثلِ push به سازمانِ source-controlِ شرکتت یا نوشتن در یک bucketِ ابریِ تیمی مسدود می‌شوند تا زمانی که آن‌ها را به autoMode.environment اضافه کنی.

برای نحوه‌ی فعال‌سازیِ auto mode و اینکه به‌صورتِ پیش‌فرض چه چیزی را مسدود می‌کند، Permission modes را ببین. این صفحه مرجعِ پیکربندی است.

این صفحه این موارد را پوشش می‌دهد:

• انتخابِ محلِ تنظیمِ قواعد میانِ CLAUDE.md، تنظیماتِ کاربر و تنظیماتِ مدیریت‌شده
• تعریفِ زیرساختِ مورد اعتماد با autoMode.environment
• override کردنِ قواعدِ block و allow وقتی پیش‌فرض‌ها با خط‌لوله‌ات جور درنمی‌آیند
• بازرسیِ پیکربندیِ مؤثرت با ساب‌فرمان‌های claude auto-mode
• بازبینیِ ردها تا بدانی بعداً چه چیزی را باید اضافه کنی

classifier پیکربندی را از کجا می‌خواند

classifier همان محتوای CLAUDE.md را می‌خواند که خودِ Claude بارگذاری می‌کند، پس دستوری مثلِ “never force push” در CLAUDE.mdِ پروژه‌ات هم‌زمان هم Claude و هم classifier را هدایت می‌کند. برای قراردادهای پروژه و قواعدِ رفتاری از همان‌جا شروع کن.

برای قواعدی که در سراسرِ پروژه‌ها اعمال می‌شوند، مثلِ زیرساختِ مورد اعتماد یا قواعدِ denyِ سراسریِ سازمان، از بلاکِ تنظیماتِ autoMode استفاده کن. classifier مقدارِ autoMode را از این scopeها می‌خواند:

Scope	فایل	برای
یک توسعه‌دهنده	~/.claude/settings.json	زیرساختِ مورد اعتمادِ شخصی
یک پروژه، یک توسعه‌دهنده	.claude/settings.local.json	bucketها یا سرویس‌های مورد اعتمادِ هر پروژه
سراسرِ سازمان	تنظیماتِ مدیریت‌شده	زیرساختِ مورد اعتمادِ توزیع‌شده به همه‌ی توسعه‌دهندگان
پرچمِ --settings یا Agent SDK	JSONِ inline	override های هر فراخوانی برای اتوماسیون

classifier مقدارِ autoMode را از تنظیماتِ مشترکِ پروژه در .claude/settings.json نمی‌خواند، پس یک مخزنِ checked-in نمی‌تواند قواعدِ allowِ خودش را تزریق کند.

ورودی‌های هر scope با هم ترکیب می‌شوند. یک توسعه‌دهنده می‌تواند environment، allow، soft_deny و hard_deny را با ورودی‌های شخصی گسترش دهد اما نمی‌تواند ورودی‌هایی را که تنظیماتِ مدیریت‌شده فراهم می‌کند حذف کند. چون قواعدِ allow به‌عنوانِ استثنا برای قواعدِ soft block داخلِ classifier عمل می‌کنند، یک ورودیِ allowِ اضافه‌شده توسطِ توسعه‌دهنده می‌تواند یک ورودیِ soft_denyِ سازمانی را override کند: ترکیب جمع‌شونده است، نه یک مرزِ سیاستِ سخت.

یادداشت

classifier دروازه‌ی دومی است که پس از سیستمِ دسترسی‌ها اجرا می‌شود. برای اقدام‌هایی که هرگز نباید فارغ از نیتِ کاربر یا پیکربندیِ classifier اجرا شوند، از permissions.deny در تنظیماتِ مدیریت‌شده استفاده کن، که اقدام را پیش از مشورت با classifier مسدود می‌کند و نمی‌توان آن را override کرد.

تعریفِ زیرساختِ مورد اعتماد

برای بیشترِ سازمان‌ها، autoMode.environment تنها فیلدی است که باید تنظیم کنی. به classifier می‌گوید کدام مخزن‌ها، bucketها و دامنه‌ها مورد اعتمادند: classifier از آن استفاده می‌کند تا تصمیم بگیرد “external” یعنی چه، پس هر مقصدی که فهرست نشده باشد یک هدفِ بالقوه‌ی exfiltration است.

فهرستِ پیش‌فرضِ environment به مخزنِ کاری و remoteهای پیکربندی‌شده‌اش اعتماد می‌کند. برای افزودنِ ورودی‌های خودت در کنارِ آن پیش‌فرض، رشته‌ی literalِ "$defaults" را در آرایه قرار بده. ورودی‌های پیش‌فرض در همان موقعیت جاسازی می‌شوند، پس ورودی‌های سفارشی‌ات می‌توانند پیش یا پس از آن‌ها بیایند.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

ورودی‌ها متنِ روان‌اند، نه regex یا الگوی ابزار. classifier آن‌ها را به‌عنوانِ قواعدِ زبانِ طبیعی می‌خواند. آن‌ها را همان‌طور بنویس که زیرساختت را برای یک مهندسِ تازه‌وارد توصیف می‌کنی. یک بخشِ environmentِ کامل این‌ها را پوشش می‌دهد:

• سازمان: نامِ شرکتت و اینکه Claude Code عمدتاً برای چه استفاده می‌شود، مثلِ توسعه‌ی نرم‌افزار، اتوماسیونِ زیرساخت، یا data engineering
• Source control: هر سازمانِ GitHub، GitLab یا Bitbucket که توسعه‌دهندگانت به آن push می‌کنند
• ارائه‌دهنده‌های ابری و bucketهای مورد اعتماد: نام‌ها یا پیشوندهای bucketی که Claude باید بتواند از آن‌ها بخواند و در آن‌ها بنویسد
• دامنه‌های داخلیِ مورد اعتماد: hostnameهای APIها، داشبوردها و سرویس‌های داخلِ شبکه‌ات، مثلِ *.internal.example.com
• سرویس‌های داخلیِ کلیدی: CI، artifact registryها، indexهای داخلیِ بسته، ابزارهای incident
• کانتکستِ اضافی: محدودیت‌های صنایعِ تنظیم‌شده، زیرساختِ multi-tenant، یا الزاماتِ انطباق که بر آنچه classifier باید پرخطر تلقی کند اثر می‌گذارند

یک قالبِ شروعِ مفید: فیلدهای داخلِ براکت را پر کن و هر خطی را که اعمال نمی‌شود حذف کن.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

هرچه کانتکستِ مشخص‌تری بدهی، classifier بهتر می‌تواند عملیاتِ داخلیِ روزمره را از تلاش‌های exfiltration تشخیص دهد.

لازم نیست همه‌چیز را یک‌جا پر کنی. یک roll-outِ معقول: با پیش‌فرض‌ها شروع کن و سازمانِ source-control و سرویس‌های داخلیِ کلیدی‌ات را اضافه کن، که رایج‌ترین false positiveها مثلِ push به مخزن‌های خودت را برطرف می‌کند. سپس دامنه‌های مورد اعتماد و bucketهای ابری را اضافه کن. بقیه را هرجا که blockها پیش آمدند پر کن.

override کردنِ قواعدِ block و allow

سه فیلدِ اضافی به تو اجازه می‌دهند فهرست‌های داخلیِ قواعدِ classifier را جایگزین کنی: autoMode.hard_deny برای مرزهای امنیتیِ بی‌قید‌و‌شرط، autoMode.soft_deny برای اقدام‌های مخربی که نیتِ کاربر می‌تواند آن‌ها را رفع کند، و autoMode.allow برای استثناها. هر کدام آرایه‌ای از توصیف‌های روان است که به‌عنوانِ قواعدِ زبانِ طبیعی خوانده می‌شوند. برای hard blockهای مبتنی بر الگوی ابزار که پیش از classifier اجرا می‌شوند، از permissions.deny استفاده کن.

داخلِ classifier، اولویت در چهار لایه کار می‌کند:

• قواعدِ hard_deny بی‌قید‌و‌شرط مسدود می‌کنند. نیتِ کاربر و استثناهای allow اعمال نمی‌شوند.
• قواعدِ soft_deny بعد مسدود می‌کنند. نیتِ کاربر و استثناهای allow می‌توانند این‌ها را override کنند.
• سپس قواعدِ allow به‌عنوانِ استثنا قواعدِ منطبقِ soft_deny را override می‌کنند.
• نیتِ صریحِ کاربر بقیه‌ی soft blockها را override می‌کند: اگر پیامِ کاربر مستقیماً و مشخصاً دقیقاً همان اقدامی را توصیف کند که Claude در شرفِ انجامش است، classifier آن را اجازه می‌دهد حتی وقتی یک قاعده‌ی soft_deny منطبق باشد.

درخواست‌های کلی به‌عنوانِ نیتِ صریح حساب نمی‌شوند. خواستن از Claude برای “clean up the repo” به force-push مجوز نمی‌دهد، اما خواستن از Claude برای “force-push this branch” مجوز می‌دهد.

برای شل‌کردن، وقتی classifier مرتب یک الگوی روزمره را که استثناهای پیش‌فرض پوشش نمی‌دهند نشان می‌زند، به allow اضافه کن. برای سفت‌کردن، برای خطرهای مخربِ خاصِ محیطت که پیش‌فرض‌ها از قلم می‌اندازند به soft_deny اضافه کن، یا برای مرزهای امنیتی که هرگز نباید زیرِ پا گذاشته شوند به hard_deny اضافه کن.

برای حفظِ قواعدِ داخلی هنگامِ افزودنِ قواعدِ خودت، رشته‌ی literalِ "$defaults" را در آرایه قرار بده. قواعدِ پیش‌فرض در همان موقعیت جاسازی می‌شوند، پس قواعدِ سفارشی‌ات می‌توانند پیش یا پس از آن‌ها بیایند، و همچنان با تغییرِ فهرستِ داخلی در نسخه‌های مختلف، به‌روزرسانی‌ها را به ارث می‌بری.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

خطر

تنظیمِ هر کدام از environment، allow، soft_deny یا hard_deny بدونِ "$defaults" کلِ فهرستِ پیش‌فرضِ آن بخش را جایگزین می‌کند. یک آرایه‌ی soft_deny بدونِ "$defaults" همه‌ی قواعدِ داخلیِ soft block را دور می‌اندازد، از جمله force push، curl | bash و deployهای production. یک آرایه‌ی hard_deny بدونِ "$defaults" قواعدِ داخلیِ data exfiltration و auto-mode bypass را دور می‌اندازد.

هر بخش مستقل ارزیابی می‌شود، پس تنظیمِ environment به‌تنهایی فهرست‌های پیش‌فرضِ allow، soft_deny و hard_deny را دست‌نخورده می‌گذارد. فقط وقتی "$defaults" را حذف کن که قصد داری مالکیتِ کاملِ فهرست را بر عهده بگیری. برای انجامِ امنِ آن، claude auto-mode defaults را اجرا کن تا قواعدِ داخلی چاپ شوند، آن‌ها را در فایلِ تنظیماتت کپی کن، سپس هر قاعده را در برابرِ خط‌لوله و آستانه‌ی ریسکِ خودت بازبینی کن.

بازرسیِ پیش‌فرض‌ها و پیکربندیِ مؤثرت

سه ساب‌فرمانِ CLI به تو کمک می‌کنند پیکربندی‌ات را بازرسی و اعتبارسنجی کنی.

قواعدِ داخلیِ environment، allow، soft_deny و hard_deny را به‌صورتِ JSON چاپ کن:

claude auto-mode defaults

آنچه را که classifier واقعاً استفاده می‌کند به‌صورتِ JSON چاپ کن، با تنظیماتت در جاهایی که تنظیم شده و پیش‌فرض‌ها در بقیه:

claude auto-mode config

روی قواعدِ سفارشیِ allow، soft_deny و hard_denyات از هوش مصنوعی بازخورد بگیر:

claude auto-mode critique

پس از ذخیره‌ی تنظیماتت claude auto-mode config را اجرا کن تا مطمئن شوی قواعدِ مؤثر همان چیزی هستند که انتظار داری، با "$defaults"ِ گسترش‌یافته در جای خودش. اگر قواعدِ سفارشی نوشته‌ای، claude auto-mode critique آن‌ها را بازبینی می‌کند و ورودی‌هایی را که مبهم، تکراری یا محتملِ ایجادِ false positive‌اند نشان می‌زند. اگر لازم است یک قاعده‌ی داخلی را به‌جای افزودن در کنارش حذف یا بازنویسی کنی، خروجیِ claude auto-mode defaults را در یک فایل ذخیره کن، فهرست‌ها را ویرایش کن، و نتیجه را در فایلِ تنظیماتت به‌جای "$defaults" بچسبان.

بازبینیِ ردها

وقتی auto mode یک فراخوانیِ ابزار را رد می‌کند، رد در /permissions زیرِ تبِ Recently denied ثبت می‌شود. روی یک اقدامِ ردشده r را بزن تا برای retry علامت‌گذاری شود: وقتی از دیالوگ خارج می‌شوی، Claude Code پیامی می‌فرستد که به مدل می‌گوید می‌تواند آن فراخوانیِ ابزار را دوباره تلاش کند و گفتگو را ادامه می‌دهد.

ردهای مکرر برای یک مقصدِ یکسان معمولاً یعنی classifier کانتکست ندارد. آن مقصد را به autoMode.environment اضافه کن، سپس claude auto-mode config را اجرا کن تا مطمئن شوی اعمال شده.

برای واکنش به ردها به‌صورتِ برنامه‌ای، از hookِ PermissionDenied استفاده کن.

همچنین ببین

• Permission modes: auto mode چیست، به‌صورتِ پیش‌فرض چه چیزی را مسدود می‌کند، و چطور فعالش کنی
• تنظیماتِ مدیریت‌شده: استقرارِ پیکربندیِ autoMode در سراسرِ سازمانت
• Permissions: قواعدِ allow، ask و deny که پیش از اجرای classifier اعمال می‌شوند
• Settings: مرجعِ کاملِ تنظیمات، از جمله کلیدِ autoMode