تنظیماتِ Claude Code

Claude Code طیفی از تنظیمات را در اختیارت می‌گذارد تا رفتارش را مطابق نیازت تنظیم کنی. می‌توانی Claude Code را با اجرای فرمان /config در REPLِ تعاملی پیکربندی کنی؛ این فرمان یک رابطِ تنظیماتِ زبانه‌بندی‌شده باز می‌کند که در آن می‌توانی اطلاعاتِ وضعیت را ببینی و گزینه‌های پیکربندی را تغییر دهی.

دامنه‌های پیکربندی

Claude Code از یک سیستمِ دامنه (scope) استفاده می‌کند تا تعیین کند هر پیکربندی کجا اعمال می‌شود و با چه کسانی به اشتراک گذاشته می‌شود. درکِ دامنه‌ها کمکت می‌کند تصمیم بگیری Claude Code را برای استفاده‌ی شخصی، همکاری تیمی یا استقرارِ سازمانی چطور پیکربندی کنی.

دامنه‌های موجود

دامنه	محل	چه کسانی را تحت تأثیر می‌گذارد	اشتراک با تیم؟
Managed	تنظیماتِ مدیریت‌شده‌ی سروری، plist / رجیستری، یا `managed-settings.json`ِ سطحِ سیستم	همه‌ی کاربرانِ آن دستگاه	بله (مستقرشده توسط IT)
User	پوشه‌ی `~/.claude/`	تو، در همه‌ی پروژه‌ها	خیر
Project	`.claude/` در مخزن	همه‌ی همکارانِ این مخزن	بله (کامیت‌شده در git)
Local	`.claude/settings.local.json`	تو، فقط در این مخزن	خیر (وقتی Claude Code می‌سازدش gitignore می‌شود)

هر دامنه را کِی استفاده کنیم

دامنه‌ی Managed برای این‌هاست:

سیاست‌های امنیتی که باید در سطحِ کل سازمان اعمال شوند
الزاماتِ انطباقی که نباید قابلِ بازنویسی باشند
پیکربندی‌های استانداردشده که توسط IT/DevOps مستقر می‌شوند

دامنه‌ی User برای این‌ها بهترین است:

ترجیحاتِ شخصی که می‌خواهی همه‌جا باشند (تم‌ها، تنظیماتِ ویرایشگر)
ابزارها و پلاگین‌هایی که در همه‌ی پروژه‌ها استفاده می‌کنی
کلیدهای API و احراز هویت (که امن ذخیره می‌شوند)

دامنه‌ی Project برای این‌ها بهترین است:

تنظیماتِ اشتراکیِ تیم (دسترسی‌ها، hooks، سرورهای MCP)
پلاگین‌هایی که کل تیم باید داشته باشد
استانداردسازیِ ابزارها بین همکاران

دامنه‌ی Local برای این‌ها بهترین است:

بازنویسی‌های شخصی برای یک پروژه‌ی خاص
آزمایشِ پیکربندی‌ها پیش از اشتراک با تیم
تنظیماتِ مخصوصِ یک دستگاه که برای دیگران کار نمی‌کند

تعاملِ دامنه‌ها با یکدیگر

وقتی یک تنظیمِ یکسان در چند دامنه ظاهر شود، Claude Code آن‌ها را به ترتیبِ اولویت اعمال می‌کند:

Managed (بالاترین) - با هیچ چیز قابلِ بازنویسی نیست
آرگومان‌های خطِ فرمان - بازنویسی‌های موقتِ نشست
Local - تنظیماتِ project و user را بازنویسی می‌کند
Project - تنظیماتِ user را بازنویسی می‌کند
User (پایین‌ترین) - وقتی اعمال می‌شود که هیچ‌جای دیگری آن تنظیم را مشخص نکرده باشد

برای مثال، اگر تنظیماتِ user تو spinnerTipsEnabled را true بگذارد و تنظیماتِ project آن را false کند، مقدارِ project اعمال می‌شود. قواعدِ دسترسی متفاوت رفتار می‌کنند، چون به‌جای بازنویسی، بین دامنه‌ها با هم ادغام (merge) می‌شوند. ببین اولویتِ تنظیمات.

چه چیزهایی از دامنه استفاده می‌کنند

دامنه‌ها بر بسیاری از قابلیت‌های Claude Code اعمال می‌شوند:

قابلیت	محلِ User	محلِ Project	محلِ Local
Settings	`~/.claude/settings.json`	`.claude/settings.json`	`.claude/settings.local.json`
Subagents	`~/.claude/agents/`	`.claude/agents/`	None
MCP servers	`~/.claude.json`	`.mcp.json`	`~/.claude.json` (per-project)
Plugins	`~/.claude/settings.json`	`.claude/settings.json`	`.claude/settings.local.json`
CLAUDE.md	`~/.claude/CLAUDE.md`	`CLAUDE.md` or `.claude/CLAUDE.md`	`CLAUDE.local.md`

در ویندوز، مسیرهایی که به‌صورت ~/.claude نشان داده شده‌اند به %USERPROFILE%\.claude تبدیل می‌شوند.

فایل‌های تنظیمات

فایلِ settings.json سازوکارِ رسمیِ پیکربندیِ Claude Code از طریقِ تنظیماتِ سلسله‌مراتبی است:

تنظیماتِ User در ~/.claude/settings.json تعریف می‌شوند و بر همه‌ی پروژه‌ها اعمال می‌شوند.
تنظیماتِ Project در پوشه‌ی پروژه‌ات ذخیره می‌شوند:
- .claude/settings.json برای تنظیماتی که به source control سپرده می‌شوند و با تیمت به اشتراک گذاشته می‌شوند
- .claude/settings.local.json برای تنظیماتی که به source control سپرده نمی‌شوند؛ برای ترجیحاتِ شخصی و آزمایش مفید است. وقتی Claude Code فایلِ .claude/settings.local.json را می‌سازد، git را طوری تنظیم می‌کند که آن فایل را نادیده بگیرد. اگر خودت فایل را بسازی، آن را دستی به gitignoreت اضافه کن.
تنظیماتِ Managed: برای سازمان‌هایی که به کنترلِ متمرکز نیاز دارند، Claude Code از چند سازوکارِ تحویل برای تنظیماتِ مدیریت‌شده پشتیبانی می‌کند. همه از قالبِ JSONِ یکسانی استفاده می‌کنند و با تنظیماتِ user یا project قابلِ بازنویسی نیستند:
- تنظیماتِ مدیریت‌شده‌ی سروری: از سرورهای Anthropic از طریقِ کنسولِ ادمینِ Claude.ai تحویل می‌شوند. ببین server-managed settings.
- سیاست‌های MDM/سطحِ OS: از طریقِ مدیریتِ بومیِ دستگاه در macOS و ویندوز تحویل می‌شوند:
  - macOS: دامنه‌ی managed preferences با نامِ com.anthropic.claudecode. کلیدهای سطحِ بالای plist آینه‌ی managed-settings.json هستند، با تنظیماتِ تودرتو به‌صورتِ dictionary و آرایه‌ها به‌صورتِ آرایه‌های plist. از طریقِ profileهای پیکربندی در Jamf، Iru (Kandji) یا ابزارهای مشابهِ MDM مستقر کن.
  - ویندوز: کلیدِ رجیستریِ HKLM\SOFTWARE\Policies\ClaudeCode با مقدارِ Settings (از نوعِ REG_SZ یا REG_EXPAND_SZ) که حاویِ JSON است (مستقرشده از طریقِ Group Policy یا Intune)
  - ویندوز (سطحِ کاربر): HKCU\SOFTWARE\Policies\ClaudeCode (پایین‌ترین اولویتِ سیاست؛ فقط زمانی استفاده می‌شود که هیچ منبعِ سطحِ ادمینی وجود نداشته باشد)
- مبتنی بر فایل: managed-settings.json و managed-mcp.json که در پوشه‌های سیستمی مستقر می‌شوند:
  - macOS: /Library/Application Support/ClaudeCode/
  - Linux و WSL: /etc/claude-code/
  - ویندوز: C:\Program Files\ClaudeCode\
  مسیرِ قدیمیِ ویندوزِ C:\ProgramData\ClaudeCode\managed-settings.json از نسخه‌ی v2.1.75 دیگر پشتیبانی نمی‌شود. ادمین‌هایی که تنظیمات را در آن محل مستقر کرده بودند باید فایل‌ها را به C:\Program Files\ClaudeCode\managed-settings.json منتقل کنند.
  
  تنظیماتِ مدیریت‌شده‌ی مبتنی بر فایل همچنین از یک پوشه‌ی drop-in به نامِ managed-settings.d/ در همان پوشه‌ی سیستمی، کنارِ managed-settings.json، پشتیبانی می‌کنند. این اجازه می‌دهد تیم‌های جداگانه قطعه‌های مستقلِ سیاست را مستقر کنند بدون اینکه نیاز به هماهنگیِ ویرایش‌ها روی یک فایلِ واحد باشد.
  
  مطابق با قراردادِ systemd، ابتدا managed-settings.json به‌عنوانِ پایه ادغام می‌شود، سپس همه‌ی فایل‌های *.json در پوشه‌ی drop-in به ترتیبِ الفبایی مرتب و روی آن ادغام می‌شوند. فایل‌های بعدی برای مقادیرِ اسکالر روی فایل‌های قبلی اولویت دارند؛ آرایه‌ها به هم پیوست و حذفِ تکراری می‌شوند؛ شیءها به‌صورتِ عمیق ادغام می‌شوند. فایل‌های مخفی که با . شروع می‌شوند نادیده گرفته می‌شوند.
  
  برای کنترلِ ترتیبِ ادغام از پیشوندهای عددی استفاده کن، برای مثال 10-telemetry.json و 20-security.json.
برای جزئیات ببین managed settings و Managed MCP configuration.

این مخزن شامل قالب‌های آغازینِ استقرار برای Jamf، Iru (Kandji)، Intune و Group Policy است. این‌ها را به‌عنوانِ نقطه‌ی شروع استفاده کن و آن‌ها را مطابق نیازت تنظیم کن.

استقرارهای مدیریت‌شده می‌توانند افزودنِ مارکت‌پلیسِ پلاگین را نیز با strictKnownMarketplaces محدود کنند. برای اطلاعات بیشتر ببین Managed marketplace restrictions.
سایر پیکربندی‌ها در ~/.claude.json ذخیره می‌شوند. این فایل شاملِ نشستِ OAuth تو، پیکربندی‌های MCP server برای دامنه‌های user و local، وضعیتِ هر-پروژه (ابزارهای مجاز، تنظیماتِ trust) و کش‌های گوناگون است. سرورهای MCPِ دامنه‌ی project جداگانه در .mcp.json ذخیره می‌شوند.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp"
  },
  "companyAnnouncements": [
    "Welcome to Acme Corp! Review our code guidelines at docs.acme.com",
    "Reminder: Code reviews required for all PRs",
    "New security policy in effect"
  ]
}

خطِ $schema در مثالِ بالا به اسکیمای رسمیِ JSON برای تنظیماتِ Claude Code اشاره می‌کند. افزودنِ آن به settings.json، تکمیلِ خودکار و اعتبارسنجیِ درون‌خطی را در VS Code، Cursor و هر ویرایشگرِ دیگری که از اعتبارسنجیِ JSON schema پشتیبانی کند فعال می‌کند.

اسکیمای منتشرشده به‌صورتِ دوره‌ای به‌روزرسانی می‌شود و ممکن است تنظیماتی را که در آخرین نسخه‌های CLI اضافه شده‌اند دربر نگیرد؛ بنابراین یک هشدارِ اعتبارسنجی روی یک فیلدِ تازه‌مستندشده لزوماً به این معنا نیست که پیکربندی‌ات نامعتبر است.

ویرایش‌ها کِی اثر می‌گذارند

Claude Code فایل‌های تنظیماتت را زیرِ نظر می‌گیرد و وقتی تغییر کنند آن‌ها را دوباره بارگذاری می‌کند؛ بنابراین ویرایشِ بیشترِ کلیدها بدونِ راه‌اندازیِ مجدد روی نشستِ در حالِ اجرا اعمال می‌شود. این شاملِ permissions، hooks و کمک‌کننده‌های اعتبار مثلِ apiKeyHelper می‌شود. این بارگذاریِ مجدد، تنظیماتِ user، project، local و managed را پوشش می‌دهد و hookِ ConfigChange برای هر تغییرِ شناسایی‌شده فعال می‌شود.

چند کلید فقط یک‌بار در آغازِ نشست خوانده می‌شوند و در عوض در راه‌اندازیِ مجددِ بعدی اعمال می‌شوند:

model: برای جابه‌جایی در میانه‌ی نشست از /model استفاده کن
outputStyle: بخشی از پرامپتِ سیستم است که هنگامِ /clear یا راه‌اندازیِ مجدد بازسازی می‌شود

مدخل‌های نامعتبر در تنظیماتِ managed

تنظیماتِ managed با تساهل تجزیه می‌شوند. وقتی یک پیکربندیِ managed مدخلی داشته باشد که اعتبارسنجیِ اسکیما را رد کند، Claude Code آن مدخل را حذف می‌کند، یک هشدار ثبت می‌کند و هر سیاستِ معتبرِ باقی‌مانده را اعمال می‌کند. یک غلطِ تایپیِ واحد نمی‌تواند بقیه‌ی سیاستِ سازمانت را از کار بیندازد. این رفتار در هر سه سازوکارِ تحویل یکسان است: server-managed settings، سیاست‌های plist و رجیستریِ مستقرشده از طریقِ MDM، و فایل‌های managed-settings.json. نیازمندِ Claude Code v2.1.169 یا بالاتر.

فیلدهای اعمالِ امنیت به‌جای حذفِ یک‌جا، وقتی حاضر اما نامعتبر باشند، به‌صورتِ هر-فیلد رسیدگی می‌شوند:

فیلد	رفتار وقتی حاضر اما نامعتبر باشد
`allowedMcpServers`	به‌عنوانِ یک allowlistِ خالی اعمال می‌شود، پس تا زمانی که مقدار اصلاح نشود هیچ سرورِ MCPی پذیرفته نمی‌شود. یک مدخلِ نامعتبرِ منفرد حذف می‌شود و زیرمجموعه‌ی معتبر اعمال می‌گردد.
`allowManagedMcpServersOnly`	مانندِ `true` در نظر گرفته می‌شود.
`availableModels`	{/* min-version: 2.1.175 */}به‌عنوانِ یک allowlistِ خالی اعمال می‌شود، پس تا زمانی که مقدار اصلاح نشود فقط مدلِ Default در دسترس است. یک مدخلِ غیر-رشته‌ایِ منفرد حذف می‌شود و زیرمجموعه‌ی معتبر اعمال می‌گردد. در v2.1.175 و بالاتر اعمال می‌شود.
`enforceAvailableModels`	{/* min-version: 2.1.175 */}مانندِ `true` در نظر گرفته می‌شود. در v2.1.175 و بالاتر اعمال می‌شود.
`forceLoginOrgUUID`	تا زمانی که مقدار اصلاح نشود هیچ سازمانی اجازه‌ی ورود ندارد.
`deniedMcpServers`	یک مدخلِ نامعتبرِ منفرد حذف می‌شود و زیرمجموعه‌ی معتبر اعمال می‌گردد. یک مقدارِ کاملاً نامعتبر با یک هشدار کنار گذاشته می‌شود، چون رد کردنِ هر سرور، سرورهایی را که سیاست هرگز نام‌شان را نبرده مسدود می‌کند.

requiredMinimumVersion و requiredMaximumVersion از روی طراحی به‌صورتِ fail open رفتار می‌کنند: یک مقدارِ نامعتبر به‌جای اعمال‌شدن حذف می‌شود، پس یک push اشتباهِ سیاست نمی‌تواند از راه‌افتادنِ Claude Code جلوگیری کند.

خطاهای اعتبارسنجی در سه جا نمایان می‌شوند:

نشست‌های تعاملی در آغاز یک دیالوگ نشان می‌دهند که مدخل‌های نامعتبر را فهرست می‌کند.
اجراهای headless با -p یک خلاصه را در stderr چاپ می‌کنند.
claude doctor هر مدخلِ نامعتبر را همراه با منبع و فیلدش فهرست می‌کند.

تغییرات سیاست را با اجرای claude doctor روی یک دستگاهِ آزمایشی پیش از استقرارِ سراسری اعتبارسنجی کن.

این تساهل فقط برای تنظیماتِ managed صدق می‌کند. فایل‌های تنظیماتِ user، project و local سخت‌گیر می‌مانند: فایلی که اعتبارسنجی را رد کند به‌عنوانِ یک کل رد و گزارش می‌شود.

تنظیماتِ موجود

settings.json از تعدادی گزینه پشتیبانی می‌کند:

کلید	توضیح	مثال
`advisorModel`	{/* min-version: 2.1.98 /}مدل برای ابزارِ advisorِ سمتِ سرور. یک نامِ مستعارِ مدل مثلِ `"opus"`، `"sonnet"` یا `"fable"` ({/ min-version: 2.1.170 */}v2.1.170+)، یا یک model IDِ کامل را می‌پذیرد. وقتی `/advisor` را اجرا می‌کنی به‌صورتِ خودکار نوشته می‌شود. برای غیرفعال‌کردنِ advisor آن را تنظیم نکن. نیازمندِ Claude Code v2.1.98 یا بالاتر	`"opus"`
`agent`	نخِ اصلی را به‌عنوانِ یک ساب‌ایجنتِ نام‌دار اجرا کن، و ایجنتِ پیش‌فرض را برای نشست‌هایی که از `claude agents` فرستاده می‌شوند تنظیم کن. پرامپتِ سیستم، محدودیت‌های ابزار و مدلِ آن ساب‌ایجنت را اعمال می‌کند. ببین Invoke subagents explicitly	`"code-reviewer"`
`allowAllClaudeAiMcps`	(فقط تنظیماتِ managed) connectorهای claude.ai را کنارِ یک `managed-mcp.json`ِ مستقرشده بارگذاری کن، که در غیرِ این صورت کنترلِ انحصاری به دست می‌گیرد و آن‌ها را سرکوب می‌کند. ببین Managed MCP configuration	`true`
`allowedChannelPlugins`	(فقط تنظیماتِ managed) allowlistِ پلاگین‌های channel که می‌توانند پیام push کنند. وقتی تنظیم شود جایگزینِ allowlistِ پیش‌فرضِ Anthropic می‌شود. تعریف‌نشده = بازگشت به پیش‌فرض، آرایه‌ی خالی = مسدودکردنِ همه‌ی پلاگین‌های channel. نیازمندِ `channelsEnabled: true`. ببین Restrict which channel plugins can run	`[{ "marketplace": "claude-plugins-official", "plugin": "telegram" }]`
`allowedHttpHookUrls`	allowlistِ الگوهای URL که hookهای HTTP می‌توانند هدف بگیرند. از `*` به‌عنوانِ wildcard پشتیبانی می‌کند. وقتی تنظیم شود، hookهایی با URLهای نامطابق مسدود می‌شوند. تعریف‌نشده = بدونِ محدودیت، آرایه‌ی خالی = مسدودکردنِ همه‌ی hookهای HTTP. آرایه‌ها بین منابعِ تنظیمات ادغام می‌شوند. ببین Hook configuration	`["https://hooks.example.com/*"]`
`allowedMcpServers`	وقتی در managed-settings.json تنظیم شود، allowlistِ سرورهای MCP که کاربران می‌توانند پیکربندی کنند. تعریف‌نشده = بدونِ محدودیت، آرایه‌ی خالی = قفلِ کامل. به همه‌ی دامنه‌ها اعمال می‌شود. denylist اولویت دارد. ببین Managed MCP configuration	`[{ "serverName": "github" }]`
`allowManagedHooksOnly`	(فقط تنظیماتِ managed) فقط hookهای managed، hookهای SDK، و hookهای پلاگین‌هایی که در `enabledPlugins`ِ تنظیماتِ managed به‌اجبار فعال شده‌اند بارگذاری می‌شوند. hookهای user، project و همه‌ی hookهای پلاگینِ دیگر مسدود می‌شوند. ببین Hook configuration	`true`
`allowManagedMcpServersOnly`	(فقط تنظیماتِ managed) فقط `allowedMcpServers`ِ تنظیماتِ managed رعایت می‌شود. `deniedMcpServers` همچنان از همه‌ی منابع ادغام می‌شود. کاربران همچنان می‌توانند سرورِ MCP اضافه کنند، اما فقط allowlistِ تعریف‌شده‌ی ادمین اعمال می‌شود. ببین Managed MCP configuration	`true`
`allowManagedPermissionRulesOnly`	(فقط تنظیماتِ managed) از تعریفِ قواعدِ دسترسیِ `allow`، `ask` یا `deny` توسطِ تنظیماتِ user و project جلوگیری کن. فقط قواعدِ تنظیماتِ managed اعمال می‌شوند. ببین Managed-only settings	`true`
`alwaysThinkingEnabled`	تفکرِ گسترده (extended thinking) را به‌صورتِ پیش‌فرض برای همه‌ی نشست‌ها فعال کن. معمولاً به‌جای ویرایشِ مستقیم از طریقِ فرمانِ `/config` پیکربندی می‌شود. برای خاموش‌کردنِ اجباریِ تفکر صرفِ‌نظر از این تنظیم، `MAX_THINKING_TOKENS=0` را در `env` بگذار، که تفکر را روی Anthropic API غیرفعال می‌کند، مگر روی Fable 5 که نمی‌توان تفکرش را خاموش کرد. روی ارائه‌دهندگانِ شخصِ ثالث این کار به‌جای آن پارامترِ `thinking` را حذف می‌کند و مدل‌های adaptive-reasoning ممکن است همچنان فکر کنند	`true`
`apiKeyHelper`	اسکریپتِ سفارشی که در `/bin/sh` اجرا می‌شود تا یک مقدارِ احراز هویت تولید کند. این مقدار به‌عنوانِ هدرهای `X-Api-Key` و `Authorization: Bearer` برای درخواست‌های مدل فرستاده می‌شود. بازه‌ی نوسازی را با `CLAUDE_CODE_API_KEY_HELPER_TTL_MS` تنظیم کن	`/bin/generate_temp_api_key.sh`
`attribution`	انتسابِ (attribution) کامیت‌های git و pull requestها را سفارشی کن. ببین Attribution settings	`{"commit": "🤖 Generated with Claude Code", "pr": ""}`
`autoMemoryDirectory`	پوشه‌ی سفارشی برای ذخیره‌ی حافظه‌ی خودکار (auto memory). یک مسیرِ مطلق یا مسیرِ پیشوند‌دار با `~/` را می‌پذیرد. از تنظیماتِ project یا local، این فقط پس از پذیرشِ دیالوگِ trustِ workspace رعایت می‌شود، چون یک مخزنِ کلون‌شده می‌تواند این فایل را تأمین کند	`"~/my-memory-dir"`
`autoMemoryEnabled`	حافظه‌ی خودکار را فعال کن. وقتی `false` باشد، Claude از پوشه‌ی حافظه‌ی خودکار نمی‌خواند و در آن نمی‌نویسد. پیش‌فرض: `true`. این را می‌توانی در میانه‌ی نشست با `/memory` هم تغییر دهی. برای غیرفعال‌کردن از طریقِ متغیرِ محیطی، `CLAUDE_CODE_DISABLE_AUTO_MEMORY` را در `env` بگذار	`false`
`autoMode`	سفارشی کن که طبقه‌بندی‌کننده‌ی حالتِ خودکار (auto mode) چه چیزی را مسدود و چه چیزی را مجاز می‌کند. شاملِ آرایه‌های `environment`، `allow`، `soft_deny` و `hard_deny` از قواعدِ متنی است. رشته‌ی تحت‌اللفظیِ `"$defaults"` را در یک آرایه بگنجان تا قواعدِ توکارِ آن موقعیت را به ارث ببری. ببین Configure auto mode. از تنظیماتِ اشتراکیِ project خوانده نمی‌شود	`{"soft_deny": ["$defaults", "Never run terraform apply"]}`
`autoScrollEnabled`	در رندرِ تمام‌صفحه، خروجیِ جدید را تا انتهای گفت‌وگو دنبال کن. پیش‌فرض: `true`. در `/config` به‌عنوانِ Auto-scroll ظاهر می‌شود. وقتی این خاموش است، prompt‌های دسترسی همچنان به نمایش می‌آیند	`false`
`autoUpdatesChannel`	کانالِ انتشاری که برای به‌روزرسانی‌ها دنبال می‌شود. از `"stable"` برای نسخه‌ای که معمولاً حدودِ یک هفته قدمت دارد و نسخه‌هایی با regressionهای بزرگ را رد می‌کند استفاده کن، یا `"latest"` (پیش‌فرض) برای جدیدترین نسخه. برای غیرفعال‌کردنِ کاملِ به‌روزرسانیِ خودکار، `DISABLE_AUTOUPDATER` را در `env` بگذار	`"stable"`
`availableModels`	محدود کن که کاربران چه مدل‌هایی را می‌توانند برای نشستِ اصلی، ساب‌ایجنت‌ها و advisor انتخاب کنند. ببین Restrict model selection	`["sonnet", "haiku"]`
`awaySummaryEnabled`	وقتی پس از چند دقیقه دوری به ترمینال بازمی‌گردی یک خلاصه‌ی یک‌خطی از نشست نشان بده. برای غیرفعال‌کردن آن را `false` بگذار یا Session recap را در `/config` خاموش کن. مانندِ `CLAUDE_CODE_ENABLE_AWAY_SUMMARY`	`true`
`awsAuthRefresh`	اسکریپتِ سفارشی که پوشه‌ی `.aws` را تغییر می‌دهد (ببین advanced credential configuration)	`aws sso login --profile myprofile`
`awsCredentialExport`	اسکریپتِ سفارشی که JSON با اعتبارنامه‌های AWS خروجی می‌دهد (ببین advanced credential configuration)	`/bin/generate_aws_grant.sh`
`blockedMarketplaces`	(فقط تنظیماتِ managed) blocklistِ منابعِ مارکت‌پلیس. هنگامِ افزودنِ مارکت‌پلیس و هنگامِ نصب، به‌روزرسانی، refresh و به‌روزرسانیِ خودکارِ پلاگین اعمال می‌شود، پس مارکت‌پلیسی که پیش از تنظیمِ سیاست اضافه شده نمی‌تواند برای واکشیِ پلاگین استفاده شود. منابعِ مسدودشده پیش از دانلود بررسی می‌شوند، پس هرگز به سیستمِ فایل دست نمی‌زنند. ببین Managed marketplace restrictions	`[{ "source": "github", "repo": "untrusted/plugins" }]`
`channelsEnabled`	(فقط تنظیماتِ managed) به channels برای سازمان اجازه بده. در پلن‌های Team و Enterpriseِ claude.ai، وقتی این تنظیم‌نشده یا `false` باشد channelها مسدود می‌شوند. برای حساب‌های Anthropic Console که از احراز هویتِ کلیدِ API استفاده می‌کنند، channelها به‌صورتِ پیش‌فرض مجازند مگر اینکه سازمانت تنظیماتِ managed مستقر کند، که در آن صورت این کلید باید `true` تنظیم شود	`true`
`claudeMd`	(فقط تنظیماتِ managed) دستوراتِ سبکِ CLAUDE.md که به‌عنوانِ حافظه‌ی مدیریت‌شده‌ی سازمانی تزریق می‌شوند. فقط وقتی در تنظیماتِ managed یا policy تنظیم شود رعایت می‌گردد و در تنظیماتِ user، project و local نادیده گرفته می‌شود. ببین organization-wide CLAUDE.md	`"Always run make lint before committing."`
`claudeMdExcludes`	الگوهای glob یا مسیرهای مطلقِ فایل‌های `CLAUDE.md` که هنگامِ بارگذاریِ حافظه باید رد شوند. الگوها با مسیرهای مطلقِ فایل تطبیق داده می‌شوند. فقط بر حافظه‌ی user، project و local اعمال می‌شود؛ فایل‌های سیاستِ managed قابلِ استثنا نیستند	`["/vendor//CLAUDE.md"]`
`cleanupPeriodDays`	فایل‌های نشستِ قدیمی‌تر از این بازه هنگامِ راه‌اندازی حذف می‌شوند (پیش‌فرض: ۳۰ روز، حداقل ۱). تنظیم به `0` با خطای اعتبارسنجی رد می‌شود. همچنین حدِّ سنّی را برای حذفِ خودکارِ worktreeهای یتیمِ ساب‌ایجنت هنگامِ راه‌اندازی کنترل می‌کند. برای غیرفعال‌کردنِ کاملِ نوشتنِ transcript، متغیرِ محیطیِ `CLAUDE_CODE_SKIP_PROMPT_HISTORY` را بگذار، یا در حالتِ غیرتعاملی (`-p`) از پرچمِ `--no-session-persistence` یا گزینه‌ی SDKِ `persistSession: false` استفاده کن.	`20`
`companyAnnouncements`	اعلانی که هنگامِ راه‌اندازی به کاربران نشان داده می‌شود. اگر چند اعلان فراهم شود، به‌صورتِ تصادفی چرخانده می‌شوند.	`["Welcome to Acme Corp! Review our code guidelines at docs.acme.com"]`
`defaultShell`	shellِ پیش‌فرض برای فرمان‌های `!`ِ کادرِ ورودی. `"bash"` (پیش‌فرض) یا `"powershell"` را می‌پذیرد. تنظیمِ `"powershell"` فرمان‌های تعاملیِ `!` را روی ویندوز از طریقِ PowerShell مسیریابی می‌کند. نیازمندِ `CLAUDE_CODE_USE_POWERSHELL_TOOL=1`. ببین PowerShell tool	`"powershell"`
`deniedMcpServers`	وقتی در managed-settings.json تنظیم شود، denylistِ سرورهای MCP که صراحتاً مسدودند. به همه‌ی دامنه‌ها از جمله سرورهای managed اعمال می‌شود. denylist بر allowlist اولویت دارد. ببین Managed MCP configuration	`[{ "serverName": "filesystem" }]`
`disableAgentView`	برای خاموش‌کردنِ background agents و agent view آن را `true` بگذار: `claude agents`، `--bg`، `/background` و supervisorِ on-demand. معمولاً در تنظیماتِ managed تنظیم می‌شود. معادلِ تنظیمِ `CLAUDE_CODE_DISABLE_AGENT_VIEW` روی `1`	`true`
`disableAllHooks`	همه‌ی hooks و هر status lineِ سفارشی را غیرفعال کن	`true`
`disableAutoMode`	برای جلوگیری از فعال‌شدنِ حالتِ خودکار (auto mode) آن را `"disable"` بگذار. `auto` را از چرخه‌ی `Shift+Tab` حذف می‌کند و `--permission-mode auto` را هنگامِ راه‌اندازی رد می‌کند. بیشترین کاربرد در تنظیماتِ managed است، جایی که کاربران نمی‌توانند آن را بازنویسی کنند	`"disable"`
`disableBundledSkills`	برای غیرفعال‌کردنِ skills و ورک‌فلوهایی که همراهِ Claude Code می‌آیند آن را `true` بگذار: skillها و ورک‌فلوهای bundled کاملاً حذف می‌شوند، در حالی که slash commandهای توکار مثلِ `/init` همچنان قابلِ تایپ می‌مانند اما از دیدِ مدل پنهان می‌شوند. skillهای پلاگین‌ها، `.claude/skills/` و `.claude/commands/` تحتِ تأثیر قرار نمی‌گیرند. معادلِ تنظیمِ `CLAUDE_CODE_DISABLE_BUNDLED_SKILLS` روی `1`	`true`
`disableDeepLinkRegistration`	برای جلوگیری از ثبتِ هندلرِ پروتکلِ `claude-cli://` توسطِ Claude Code با سیستم‌عامل هنگامِ راه‌اندازی آن را `"disable"` بگذار. Deep links به ابزارهای بیرونی اجازه می‌دهند یک نشستِ Claude Code را با پرامپتِ ازپیش‌پرشده باز کنند. در محیط‌هایی مفید است که ثبتِ هندلرِ پروتکل محدود یا جداگانه مدیریت می‌شود	`"disable"`
`disabledMcpjsonServers`	فهرستِ سرورهای MCPِ خاص از فایل‌های `.mcp.json` که باید رد شوند	`["filesystem"]`
`disableRemoteControl`	{/* min-version: 2.1.128 */}Remote Control را غیرفعال کن: `claude remote-control`، پرچمِ `--remote-control`، شروعِ خودکار و کلیدِ تغییرِ درون‌نشست را مسدود می‌کند. معمولاً برای اعمالِ MDMِ هر-دستگاه در تنظیماتِ managed قرار می‌گیرد، اما از هر دامنه‌ای کار می‌کند. نیازمندِ Claude Code v2.1.128 یا بالاتر	`true`
`disableSkillShellExecution`	اجرای درون‌خطیِ shell را برای !`...` و بلوک‌های ```! در skills و فرمان‌های سفارشی از منابعِ user، project، پلاگین یا additional-directory غیرفعال کن. فرمان‌ها به‌جای اجرا با `[shell command execution disabled by policy]` جایگزین می‌شوند. skillهای bundled و managed تحتِ تأثیر قرار نمی‌گیرند. بیشترین کاربرد در تنظیماتِ managed است، جایی که کاربران نمی‌توانند آن را بازنویسی کنند	`true`
`disableWorkflows`	ورک‌فلوهای پویا (dynamic workflows) و فرمان‌های ورک‌فلوِ bundled را غیرفعال کن. پیش‌فرض: `false`. معادلِ تنظیمِ `CLAUDE_CODE_DISABLE_WORKFLOWS` روی `1`	`true`
`editorMode`	حالتِ کلیدبندی برای پرامپتِ ورودی: `"normal"` یا `"vim"`. پیش‌فرض: `"normal"`. در `/config` به‌عنوانِ Editor mode ظاهر می‌شود	`"vim"`
`effortLevel`	سطحِ تلاش (effort level) را بین نشست‌ها پایدار نگه دار. `"low"`، `"medium"`، `"high"` یا `"xhigh"` را می‌پذیرد. وقتی `/effort` را با یکی از این مقادیر اجرا کنی به‌صورتِ خودکار نوشته می‌شود. `--effort` و `CLAUDE_CODE_EFFORT_LEVEL` این را برای یک نشست بازنویسی می‌کنند. برای مدل‌های پشتیبانی‌شده ببین Adjust effort level	`"xhigh"`
`enableAllProjectMcpServers`	همه‌ی سرورهای MCPِ تعریف‌شده در فایل‌های `.mcp.json`ِ project را به‌صورتِ خودکار تأیید کن	`true`
`enabledMcpjsonServers`	فهرستِ سرورهای MCPِ خاص از فایل‌های `.mcp.json` که باید تأیید شوند	`["memory", "github"]`
`enforceAvailableModels`	وقتی `true` باشد و `availableModels` فهرستی ناخالی در تنظیماتِ managed یا policy باشد، مدلِ Default هم به allowlist محدود می‌شود. برای جزئیات و رفتارِ ادغام وقتی `availableModels` در چند سطح تنظیم شده، ببین Restrict model selection. نیازمندِ Claude Code v2.1.175 یا بالاتر	`true`
`env`	متغیرهای محیطی که به هر نشست و به زیرفرایندهایی که Claude Code از آن ایجاد می‌کند اعمال می‌شوند. از v2.1.143، `NO_COLOR` و `FORCE_COLOR`ی که اینجا تنظیم شوند به زیرفرایندها منتقل می‌شوند اما رنگ‌های رابطِ خودِ Claude Code را تغییر نمی‌دهند. برای تغییرِ رنگ‌های رابط، آن‌ها را پیش از اجرای `claude` در shellت تنظیم کن	`\{"FOO": "bar"\}`
`fallbackModel`	مدل(های) جایگزین که به ترتیب امتحان می‌شوند وقتی مدلِ اصلی overload یا در دسترس نباشد. Claude Code برای باقی‌مانده‌ی نوبت به مدلِ موجودِ بعدی در زنجیره سوییچ می‌کند و یک اعلان نشان می‌دهد. `"default"` به مدلِ پیش‌فرض گسترش می‌یابد. زنجیره‌ها به سه مدل محدود می‌شوند؛ مدخل‌های اضافی نادیده گرفته می‌شوند. برخلافِ بیشترِ تنظیماتِ آرایه‌ای، این کلید بین فایل‌های تنظیمات ادغام نمی‌شود: فایلِ با بالاترین اولویت که آن را تعریف می‌کند کلِ زنجیره را تأمین می‌کند. پرچمِ `--fallback-model` این را برای یک نشست بازنویسی می‌کند. ببین Fallback model chains	`["claude-sonnet-4-6", "claude-haiku-4-5"]`
`fastModePerSessionOptIn`	وقتی `true` باشد، حالتِ fast بین نشست‌ها پایدار نمی‌ماند. هر نشست با حالتِ fast خاموش شروع می‌شود و کاربران باید آن را با `/fast` فعال کنند. ترجیحِ حالتِ fastِ کاربر همچنان ذخیره می‌شود. ببین Require per-session opt-in	`true`
`feedbackSurveyRate`	احتمالِ (۰ تا ۱) ظاهرشدنِ نظرسنجیِ کیفیتِ نشست هنگامِ واجدِ شرایط بودن. برای سرکوبِ کامل آن را `0` بگذار، یا `CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY` را در `env` بگذار. هنگامِ استفاده از Bedrock، Vertex یا Foundry که نرخِ نمونه‌گیریِ پیش‌فرض اعمال نمی‌شود مفید است	`0.05`
`fileSuggestion`	یک اسکریپتِ سفارشی برای تکمیلِ خودکارِ فایلِ `@` پیکربندی کن. ببین File suggestion settings	`\{"type": "command", "command": "~/.claude/file-suggestion.sh"\}`
`forceLoginMethod`	از `claudeai` برای محدودکردنِ ورود به حساب‌های Claude.ai، یا `console` برای محدودکردنِ ورود به حساب‌های Claude Console استفاده کن. وقتی در تنظیماتِ managed تنظیم شود، نشست‌هایی که با `ANTHROPIC_API_KEY`، `ANTHROPIC_AUTH_TOKEN` یا `apiKeyHelper` احراز هویت شده‌اند هنگامِ راه‌اندازی مسدود می‌شوند، چون هیچ‌یک از این دو مقدار بدونِ OAuthِ first-party برآورده نمی‌شود. نشست‌های ارائه‌دهنده‌ی شخصِ ثالث مثلِ Bedrock، Vertex و Foundry مسدود نمی‌شوند: آن‌ها در برابرِ ارائه‌دهنده‌ی ابریِ تو احراز هویت می‌شوند نه Anthropic	`claudeai`
`forceLoginOrgUUID`	ورود باید به یک سازمانِ مشخصِ Anthropic تعلق داشته باشد. یک رشته‌ی UUIDِ واحد را می‌پذیرد، که آن سازمان را هنگامِ ورود هم ازپیش انتخاب می‌کند، یا یک آرایه از UUIDها که در آن هر سازمانِ فهرست‌شده بدونِ پیش‌انتخاب پذیرفته می‌شود. وقتی در تنظیماتِ managed تنظیم شود، اگر حسابِ احراز هویت‌شده به یکی از سازمان‌های فهرست‌شده تعلق نداشته باشد ورود ناموفق می‌شود، و نشست‌هایی که با `ANTHROPIC_API_KEY`، `ANTHROPIC_AUTH_TOKEN` یا `apiKeyHelper` احراز هویت شده‌اند هنگامِ راه‌اندازی مسدود می‌شوند چون عضویتِ سازمانی برای آن‌ها قابلِ تأیید نیست. نشست‌های ارائه‌دهنده‌ی شخصِ ثالث مثلِ Bedrock، Vertex و Foundry مسدود نمی‌شوند: از IAMِ ابریِ خودت برای محدودکردنِ حساب‌های ابریِ قابلِ استفاده بهره ببر. یک آرایه‌ی خالی fail closed می‌کند و ورود را با پیامِ پیکربندیِ نادرست مسدود می‌کند	`"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"` or `["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"]`
`forceRemoteSettingsRefresh`	(فقط تنظیماتِ managed) راه‌اندازیِ CLI را مسدود کن تا زمانی که تنظیماتِ managedِ راه‌دور به‌تازگی از سرور واکشی شوند. اگر واکشی ناموفق شود، CLI به‌جای ادامه با تنظیماتِ کش‌شده یا بدونِ تنظیمات، خارج می‌شود. وقتی تنظیم‌نشده باشد، راه‌اندازی بدونِ انتظار برای تنظیماتِ راه‌دور ادامه می‌یابد. ببین fail-closed enforcement	`true`
`gcpAuthRefresh`	اسکریپتِ سفارشی که Application Default Credentialsِ GCP را وقتی منقضی می‌شوند یا قابلِ بارگذاری نیستند نوسازی می‌کند. ببین advanced credential configuration	`gcloud auth application-default login`
`hooks`	فرمان‌های سفارشی برای اجرا در رویدادهای چرخه‌ی حیات را پیکربندی کن. برای قالب ببین hooks documentation	See hooks
`httpHookAllowedEnvVars`	allowlistِ نام‌های متغیرِ محیطی که hookهای HTTP می‌توانند در هدرها درون‌میان‌یابی (interpolate) کنند. وقتی تنظیم شود، `allowedEnvVars`ِ مؤثرِ هر hook اشتراکِ آن با این فهرست است. تعریف‌نشده = بدونِ محدودیت. آرایه‌ها بین منابعِ تنظیمات ادغام می‌شوند. ببین Hook configuration	`["MY_TOKEN", "HOOK_SECRET"]`
`includeCoAuthoredBy`	منسوخ‌شده: به‌جایش از `attribution` استفاده کن. اینکه آیا امضای `co-authored-by Claude` در کامیت‌های git و pull requestها گنجانده شود (پیش‌فرض: `true`)	`false`
`includeGitInstructions`	دستوراتِ توکارِ ورک‌فلوِ commit و PR و عکسِ فوریِ git status را در پرامپتِ سیستمِ Claude بگنجان (پیش‌فرض: `true`). برای حذفِ هر دو آن را `false` بگذار، برای مثال وقتی از skillهای ورک‌فلوِ git خودت استفاده می‌کنی. متغیرِ محیطیِ `CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS` وقتی تنظیم شود بر این تنظیم اولویت دارد	`false`
`language`	زبانِ پاسخِ ترجیحیِ Claude را پیکربندی کن (مثلاً `"japanese"`، `"spanish"`، `"french"`). Claude به‌صورتِ پیش‌فرض به این زبان پاسخ می‌دهد. زبانِ دیکته‌ی صوتی (voice dictation) را هم تنظیم می‌کند	`"japanese"`
`maxSkillDescriptionChars`	سقفِ کاراکترِ هر-skill روی متنِ ترکیبیِ `description` و `when_to_use` در فهرستِ skill که Claude هر نوبت می‌بیند (پیش‌فرض: `1536`). متنِ بلندتر از این کوتاه می‌شود. بالاتر ببر تا توضیحاتِ بلند سالم بمانند، به قیمتِ کانتکستِ بیشتر در هر نوبت؛ پایین‌تر بیاور تا skillهای بیشتری زیرِ `skillListingBudgetFraction` جا شوند. نیازمندِ Claude Code v2.1.105 یا بالاتر	`2048`
`minimumVersion`	کفی که از نصبِ نسخه‌ای پایین‌تر از این توسطِ به‌روزرسانیِ خودکارِ پس‌زمینه و `claude update` جلوگیری می‌کند. تغییر از کانالِ `"latest"` به `"stable"` از طریقِ `/config` از تو می‌خواهد روی نسخه‌ی فعلی بمانی یا اجازه‌ی downgrade بدهی. انتخابِ ماندن این مقدار را تنظیم می‌کند. در تنظیماتِ managed هم برای پین‌کردنِ یک حداقلِ سراسری مفید است. برای کفِ سختی که راه‌اندازی را کاملاً مسدود می‌کند، ببین `requiredMinimumVersion`	`"2.1.100"`
`model`	مدلِ پیش‌فرضِ مورد استفاده‌ی Claude Code را بازنویسی کن. `--model` و `ANTHROPIC_MODEL` این را برای یک نشست بازنویسی می‌کنند	`"claude-sonnet-4-6"`
`modelOverrides`	model IDهای Anthropic را به model IDهای مخصوصِ ارائه‌دهنده مثلِ ARNهای inference profileِ Bedrock نگاشت کن. هر مدخلِ انتخاب‌گرِ مدل هنگامِ فراخوانیِ API ارائه‌دهنده از مقدارِ نگاشت‌شده‌اش استفاده می‌کند. ببین Override model IDs per version	`\{"claude-opus-4-6": "arn:aws:bedrock:..."\}`
`otelHeadersHelper`	اسکریپت برای تولیدِ هدرهای پویای OpenTelemetry. هنگامِ راه‌اندازی و به‌صورتِ دوره‌ای اجرا می‌شود. بازه‌ی نوسازی را با `CLAUDE_CODE_OTEL_HEADERS_HELPER_DEBOUNCE_MS` تنظیم کن. ببین Dynamic headers	`/bin/generate_otel_headers.sh`
`outputStyle`	یک output style برای تنظیمِ پرامپتِ سیستم پیکربندی کن. ببین output styles documentation	`"Explanatory"`
`parentSettingsBehavior`	(فقط تنظیماتِ managed) کنترل می‌کند که آیا تنظیماتِ managed که به‌صورتِ برنامه‌نویسانه توسطِ یک فرایندِ میزبانِ تعبیه‌کننده مثلِ Agent SDK یا یک افزونه‌ی IDE تأمین می‌شوند، وقتی یک لایه‌ی managedِ مستقرشده توسطِ ادمین هم حاضر است اعمال می‌شوند یا نه. `"first-wins"`: تنظیماتِ تأمین‌شده توسطِ والد کنار گذاشته می‌شوند و فقط لایه‌ی ادمین اعمال می‌شود. `"merge"`: تنظیماتِ تأمین‌شده توسطِ والد زیرِ لایه‌ی ادمین اعمال می‌شوند، با فیلتری که اجازه می‌دهد سیاست را سفت‌تر کنند اما شل‌تر نه. وقتی هیچ لایه‌ی ادمینی مستقر نباشد بی‌اثر است. پیش‌فرض: `"first-wins"`. نیازمندِ Claude Code v2.1.133 یا بالاتر	`"merge"`
`permissions`	برای ساختارِ دسترسی‌ها جدولِ زیر را ببین.
`plansDirectory`	جایی که فایل‌های plan ذخیره می‌شوند را سفارشی کن. مسیر نسبت به ریشه‌ی پروژه است. پیش‌فرض: `~/.claude/plans`	`"./plans"`
`pluginSuggestionMarketplaces`	(فقط تنظیماتِ managed) نام‌های مارکت‌پلیس که پلاگین‌هایشان می‌توانند به‌عنوانِ پیشنهادهای نصبِ متنی ظاهر شوند. بدونِ این allowlist هیچ پیشنهادِ اعلام‌شده‌ی مارکت‌پلیسی نمایان نمی‌شود؛ نکته‌ی توکارِ first-partyِ frontend-design بی‌تأثیر است. پیشنهادها از اعلانِ `relevance`ِ هر پلاگین در مدخلِ مارکت‌پلیسش می‌آیند. یک نام فقط زمانی اثر می‌کند که مارکت‌پلیس روی دستگاه ثبت شده باشد و منبعِ ثبت‌شده‌اش هم در تنظیماتِ managed اعلام شده باشد، چه به‌عنوانِ مدخلِ `extraKnownMarketplaces` برای آن نام و چه به‌عنوانِ مدخلی از `strictKnownMarketplaces`. مارکت‌پلیسی که از منبعی متفاوت زیرِ نامی allowlist‌شده ثبت شود نادیده گرفته می‌شود. مارکت‌پلیسِ رسمی از الزامِ منبع معاف است: allowlist‌کردنِ نامش به‌تنهایی کافی است، چون آن نام فقط می‌تواند از منبعِ رسمیِ Anthropic ثبت شود.	`["acme-corp-plugins"]`
`pluginTrustMessage`	(فقط تنظیماتِ managed) پیامِ سفارشی که به هشدارِ trustِ پلاگین که پیش از نصب نشان داده می‌شود افزوده می‌شود. از این برای افزودنِ کانتکستِ مخصوصِ سازمان استفاده کن، برای مثال برای تأییدِ اینکه پلاگین‌های مارکت‌پلیسِ داخلی‌ات بررسی شده‌اند.	`"All plugins from our marketplace are approved by IT"`
`policyHelper`	اجراپذیرِ مستقرشده توسطِ ادمین که تنظیماتِ managed را به‌صورتِ پویا هنگامِ راه‌اندازی محاسبه می‌کند. فقط از MDM یا یک فایلِ `managed-settings.json`ِ سیستمی رعایت می‌شود. ببین Compute managed settings with a policy helper. نیازمندِ Claude Code v2.1.136 یا بالاتر	`\{"path": "/usr/local/bin/claude-policy"\}`
`preferredNotifChannel`	روشِ اعلان‌های task-complete و permission-prompt: `"auto"`، `"terminal_bell"`، `"iterm2"`، `"iterm2_with_bell"`، `"kitty"`، `"ghostty"` یا `"notifications_disabled"`. پیش‌فرض: `"auto"`، که در iTerm2، Ghostty و Kitty اعلانِ دسکتاپ می‌فرستد و در ترمینال‌های دیگر کاری نمی‌کند. `"terminal_bell"` را بگذار تا در هر ترمینالی کاراکترِ زنگ را به صدا درآورد. در `/config` به‌عنوانِ Notifications ظاهر می‌شود. ببین Get a terminal bell or notification	`"terminal_bell"`
`prefersReducedMotion`	برای دسترس‌پذیری، انیمیشن‌های رابط (spinnerها، shimmer، افکت‌های flash) را کاهش بده یا غیرفعال کن	`true`
`prUrlTemplate`	قالبِ URL برای نشانِ PR که در پاورقی و در خلاصه‌های نتیجه‌ی ابزار نشان داده می‌شود. `\{host\}`، `\{owner\}`، `\{repo\}`، `\{number\}` و `\{url\}` را از URLِ PRِ گزارش‌شده توسطِ `gh` جایگزین می‌کند. برای اشاره‌دادنِ لینک‌های PR به یک ابزارِ code-reviewِ داخلی به‌جای `github.com` استفاده کن. روی autolinkهای `#123` در متنِ Claude اثری ندارد	`"https://reviews.example.com/\{owner\}/\{repo\}/pull/\{number\}"`
`requiredMaximumVersion`	فقط تنظیماتِ managed. حداکثر نسخه‌ی Claude Code که اجازه‌ی راه‌اندازی دارد. اگر نسخه‌ی در حالِ اجرا جدیدتر باشد، Claude Code هنگامِ راه‌اندازی خارج می‌شود و به کاربر دستور می‌دهد یک نسخه‌ی تأییدشده را از روشِ تأییدشده‌ی سازمان نصب کند؛ `claude install <version>` هم ممکن است کار کند. به‌روزرسانی‌های خودکارِ پس‌زمینه و `claude update` نسخه‌های بالای سقف را رد می‌کنند، پس یک نصبِ درون‌محدوده درون‌محدوده می‌ماند. `claude update`، `claude install` و `claude doctor` بالای سقف کار می‌کنند تا کاربران بتوانند بازیابی کنند. نسخه‌هایی که پیش از این تنظیم بودند آن را نادیده می‌گیرند	`"2.1.150"`
`requiredMinimumVersion`	فقط تنظیماتِ managed. حداقل نسخه‌ی Claude Code که برای راه‌اندازی لازم است. اگر نسخه‌ی در حالِ اجرا قدیمی‌تر باشد، Claude Code هنگامِ راه‌اندازی خارج می‌شود و به کاربر دستور می‌دهد از روشِ تأییدشده‌ی سازمان به‌روزرسانی کند. `claude update`، `claude install` و `claude doctor` زیرِ کف کار می‌کنند تا کاربران بتوانند بازیابی کنند. با `minimumVersion` فرق دارد که از downgrade جلوگیری می‌کند اما هرگز راه‌اندازی را مسدود نمی‌کند. نسخه‌هایی که پیش از این تنظیم بودند آن را نادیده می‌گیرند	`"2.1.150"`
`respectGitignore`	کنترل کن که آیا انتخاب‌گرِ فایلِ `@` الگوهای `.gitignore` را رعایت کند. وقتی `true` (پیش‌فرض) باشد، فایل‌هایی که با الگوهای `.gitignore` تطبیق دارند از پیشنهادها حذف می‌شوند	`false`
`showClearContextOnPlanAccept`	گزینه‌ی «clear context» را در صفحه‌ی پذیرشِ plan نشان بده. پیش‌فرض `false`. برای بازگرداندنِ گزینه آن را `true` بگذار	`true`
`showThinkingSummaries`	خلاصه‌های تفکرِ گسترده را در نشست‌های تعاملی نشان بده. وقتی تنظیم‌نشده یا `false` (پیش‌فرض در حالتِ تعاملی) باشد، بلوک‌های تفکر توسطِ API ویرایش (redact) و به‌صورتِ یک stubِ جمع‌شده نشان داده می‌شوند. ویرایش فقط چیزی را که می‌بینی تغییر می‌دهد، نه چیزی را که مدل تولید می‌کند: برای کاهشِ هزینه‌ی تفکر، به‌جایش بودجه را پایین بیاور یا تفکر را غیرفعال کن. این تنظیم در حالتِ غیرتعاملی (`-p`)، Agent SDK یا افزونه‌های IDE مثلِ VS Code اثری ندارد	`true`
`showTurnDuration`	پیام‌های مدتِ نوبت را پس از پاسخ‌ها نشان بده، مثلاً «Cooked for 1m 6s». پیش‌فرض: `true`. در `/config` به‌عنوانِ Show turn duration ظاهر می‌شود	`false`
`skillListingBudgetFraction`	کسری از پنجره‌ی کانتکستِ مدل که برای فهرستِ skillی که Claude هر نوبت می‌بیند رزرو می‌شود (پیش‌فرض: `0.01` = ۱٪). وقتی فهرست از بودجه فراتر رود، توضیحاتِ کم‌استفاده‌ترین skillها به نام‌های خالی جمع می‌شوند تا Claude همچنان بتواند فراخوانی‌شان کند اما دلیلش را نبیند. بالاتر ببر تا توضیحاتِ بیشتری نمایان بمانند، به قیمتِ کانتکستِ بیشتر در هر نوبت. `/doctor` شمارشِ کوتاه‌سازیِ فعلی و اینکه کدام skillها متأثرند را نشان می‌دهد. نیازمندِ Claude Code v2.1.105 یا بالاتر	`0.02`
`skillOverrides`	بازنویسی‌های نمایانیِ هر-skill که با نامِ skill کلیددهی می‌شوند. مقدار `"on"`، `"name-only"`، `"user-invocable-only"` یا `"off"` است. اجازه می‌دهد یک skill را بدونِ ویرایشِ SKILL.mdش پنهان یا جمع کنی. به skillهای پلاگین اعمال نمی‌شود، که از طریقِ `/plugin` مدیریت می‌شوند. منوی `/skills` این‌ها را در `.claude/settings.local.json` می‌نویسد. ببین Override skill visibility from settings. نیازمندِ Claude Code v2.1.129 یا بالاتر	`\{"legacy-context": "name-only", "deploy": "off"\}`
`skipWebFetchPreflight`	بررسیِ ایمنیِ دامنه‌ی WebFetch را که هر hostnameِ درخواست‌شده را پیش از واکشی به `api.anthropic.com` می‌فرستد رد کن. در محیط‌هایی که ترافیک به Anthropic را مسدود می‌کنند، مثلِ استقرارهای Bedrock، Vertex AI یا Foundry با egressِ محدودکننده، آن را `true` بگذار. وقتی رد شود، WebFetch هر URLی را بدونِ مشورت با blocklist امتحان می‌کند	`true`
`spinnerTipsEnabled`	نکته‌ها را در spinner در حالی که Claude کار می‌کند نشان بده. برای غیرفعال‌کردنِ نکته‌ها آن را `false` بگذار (پیش‌فرض: `true`)	`false`
`spinnerTipsOverride`	نکته‌های spinner را با رشته‌های سفارشی بازنویسی کن. `tips`: آرایه‌ای از رشته‌های نکته. `excludeDefault`: اگر `true` باشد فقط نکته‌های سفارشی نشان داده می‌شوند؛ اگر `false` یا غایب باشد، نکته‌های سفارشی با نکته‌های توکار ادغام می‌شوند	`\{ "excludeDefault": true, "tips": ["Use our internal tool X"] \}`
`spinnerVerbs`	فعل‌های کنشی که در حینِ پیشرفتِ یک نوبت نشان داده می‌شوند را سفارشی کن. `mode` را `"replace"` بگذار تا فقط فعل‌های خودت استفاده شوند، یا `"append"` تا به پیش‌فرض‌ها افزوده شوند	`\{"mode": "append", "verbs": ["Pondering", "Crafting"]\}`
`sshConfigs`	اتصال‌های SSH که در منوی کشوییِ محیطِ Desktop نشان داده می‌شوند. هر مدخل به `id`، `name` و `sshHost` نیاز دارد؛ `sshPort`، `sshIdentityFile` و `startDirectory` اختیاری‌اند. وقتی در تنظیماتِ managed تنظیم شوند، اتصال‌ها برای کاربران فقط‌خواندنی‌اند. فقط از تنظیماتِ managed و user خوانده می‌شود	`[\{"id": "dev-vm", "name": "Dev VM", "sshHost": "user@dev.example.com"\}]`
`statusLine`	یک status lineِ سفارشی برای نمایشِ کانتکست پیکربندی کن. ببین `statusLine` documentation	`\{"type": "command", "command": "~/.claude/statusline.sh"\}`
`strictKnownMarketplaces`	(فقط تنظیماتِ managed) allowlistِ منابعِ مارکت‌پلیسِ پلاگین. تعریف‌نشده = بدونِ محدودیت، آرایه‌ی خالی = قفلِ کامل. هنگامِ افزودنِ مارکت‌پلیس و هنگامِ نصب، به‌روزرسانی، refresh و به‌روزرسانیِ خودکارِ پلاگین اعمال می‌شود، پس مارکت‌پلیسی که پیش از تنظیمِ سیاست اضافه شده نمی‌تواند برای واکشیِ پلاگین استفاده شود. ببین Managed marketplace restrictions	`[\{ "source": "github", "repo": "acme-corp/plugins" \}]`
`strictPluginOnlyCustomization`	(فقط تنظیماتِ managed) skillها، agentها، hookها و سرورهای MCP را از منابعِ user و project مسدود کن، تا فقط بتوانند از پلاگین‌ها یا تنظیماتِ managed بیایند. `true` هر چهار سطح را قفل می‌کند؛ یک آرایه فقط موارد نام‌برده را قفل می‌کند. ببین `strictPluginOnlyCustomization`	`["skills", "hooks"]`
`syntaxHighlightingDisabled`	برجسته‌سازیِ نحوی (syntax highlighting) را در diffها، بلوک‌های کد و پیش‌نمایش‌های فایل غیرفعال کن	`true`
`teammateMode`	نحوه‌ی نمایشِ هم‌تیمی‌های agent team: `auto` (پنل‌های split هنگامِ اجرا درونِ tmux یا iTerm2، در غیرِ این صورت in-process)، `in-process` یا `tmux` (پنل‌های split با tmux یا iTerm2، که از ترمینالت تشخیص داده می‌شود). `--teammate-mode` این را برای یک نشست بازنویسی می‌کند. ببین choose a display mode	`"in-process"`
`terminalProgressBarEnabled`	نوارِ پیشرفتِ ترمینال را در ترمینال‌های پشتیبانی‌شده نشان بده: ConEmu، Ghostty 1.2.0+ و iTerm2 3.6.6+. پیش‌فرض: `true`. در `/config` به‌عنوانِ Terminal progress bar ظاهر می‌شود	`false`
`tui`	رندرکننده‌ی رابطِ ترمینال. از `"fullscreen"` برای رندرکننده‌ی alt-screen بدونِ flicker با scrollbackِ مجازی‌شده استفاده کن. از `"default"` برای رندرکننده‌ی کلاسیکِ main-screen استفاده کن. از طریقِ `/tui` تنظیم می‌شود. متغیرِ محیطیِ `CLAUDE_CODE_NO_FLICKER` را هم می‌توانی بگذاری. نشست‌های پس‌زمینه که از agent view باز می‌شوند صرفِ‌نظر از این تنظیم همیشه از رندرکننده‌ی fullscreen استفاده می‌کنند	`"fullscreen"`
`ultracode`	ultracode را برای نشست روشن کن. فقط-نشستی است و از `settings.json` خوانده نمی‌شود. از طریقِ `/effort ultracode`، `--settings` یا یک درخواستِ کنترلِ Agent SDK تنظیم می‌شود	`true`
`useAutoModeDuringPlan`	اینکه آیا حالتِ plan وقتی حالتِ خودکار در دسترس است از معناشناسیِ حالتِ خودکار استفاده کند. پیش‌فرض: `true`. از تنظیماتِ اشتراکیِ project خوانده نمی‌شود. در `/config` به‌عنوانِ «Use auto mode during plan» ظاهر می‌شود	`false`
`viewMode`	حالتِ نمایشِ پیش‌فرضِ transcript هنگامِ راه‌اندازی: `"default"`، `"verbose"` یا `"focus"`. وقتی تنظیم شود انتخابِ چسبانِ `/focus` را بازنویسی می‌کند. پرچمِ `--verbose` این را برای یک نشست بازنویسی می‌کند	`"verbose"`
`voice`	تنظیماتِ دیکته‌ی صوتی (voice dictation): `enabled` دیکته را روشن می‌کند، `mode` بین `"hold"` یا `"tap"` انتخاب می‌کند، و `autoSubmit` در حالتِ hold پرامپت را هنگامِ رهاکردنِ کلید می‌فرستد. وقتی `/voice` را اجرا کنی به‌صورتِ خودکار نوشته می‌شود. نیازمندِ یک حسابِ Claude.ai	`\{ "enabled": true, "mode": "tap" \}`
`voiceEnabled`	نامِ مستعارِ قدیمی برای `voice.enabled`. شیءِ `voice` را ترجیح بده	`true`
`wheelScrollAccelerationEnabled`	در رندرِ تمام‌صفحه، سرعتِ اسکرولِ چرخِ ماوس را در اسکرول‌های سریع شتاب بده. پیش‌فرض: `true`. برای نرخِ اسکرولِ ثابت به‌ازای هر notchِ چرخ آن را `false` بگذار. نیازمندِ Claude Code v2.1.174 یا بالاتر	`false`
`workflowKeywordTriggerEnabled`	اینکه آیا کلیدواژه‌ی `ultracode` در یک پرامپت یک ورک‌فلوِ پویا را فعال کند. برای تایپِ این کلمه بدونِ فعال‌کردنِ ورک‌فلو آن را `false` بگذار. تنظیمِ effortِ `ultracode`، `/workflows` و فرمان‌های ورک‌فلوِ ذخیره‌شده تحتِ تأثیر قرار نمی‌گیرند. پیش‌فرض: `true`. در `/config` به‌عنوانِ Ultracode keyword trigger ظاهر می‌شود. در v2.1.157 افزوده شد؛ پیش از v2.1.160 کلیدواژه‌ی trigger `workflow` بود	`false`
`wslInheritsWindowsSettings`	(فقط تنظیماتِ managedِ ویندوز) وقتی `true` باشد، Claude Code روی WSL علاوه بر `/etc/claude-code`، تنظیماتِ managed را از زنجیره‌ی سیاستِ ویندوز هم می‌خواند، با اولویت‌داشتنِ منابعِ ویندوز. فقط وقتی در کلیدِ رجیستریِ HKLM یا `C:\Program Files\ClaudeCode\managed-settings.json` تنظیم شود رعایت می‌شود، که هر دو برای نوشتن نیازمندِ ادمینِ ویندوزند. برای اینکه سیاستِ HKCU هم روی WSL اعمال شود، پرچم باید علاوه بر آن در خودِ HKCU هم تنظیم شود. روی ویندوزِ بومی اثری ندارد	`true`

تنظیماتِ پیکربندیِ سراسری

این تنظیمات به‌جای settings.json در ~/.claude.json ذخیره می‌شوند. افزودنِ آن‌ها به settings.json خطای اعتبارسنجیِ اسکیما ایجاد می‌کند.

کلید	توضیح	مثال
`autoConnectIde`	وقتی Claude Code از یک ترمینالِ بیرونی شروع می‌شود، به‌صورتِ خودکار به یک IDEِ در حالِ اجرا متصل شو. پیش‌فرض: `false`. هنگامِ اجرا خارج از ترمینالِ VS Code یا JetBrains، در `/config` به‌عنوانِ Auto-connect to IDE (external terminal) ظاهر می‌شود. متغیرِ محیطیِ `CLAUDE_CODE_AUTO_CONNECT_IDE` وقتی تنظیم شود این را بازنویسی می‌کند	`true`
`autoInstallIdeExtension`	وقتی از یک ترمینالِ VS Code اجرا می‌شوی، افزونه‌ی IDEِ Claude Code را به‌صورتِ خودکار نصب کن. پیش‌فرض: `true`. هنگامِ اجرا درونِ ترمینالِ VS Code یا JetBrains، در `/config` به‌عنوانِ Auto-install IDE extension ظاهر می‌شود. متغیرِ محیطیِ `CLAUDE_CODE_IDE_SKIP_AUTO_INSTALL` را هم می‌توانی بگذاری	`false`
`externalEditorContext`	وقتی ویرایشگرِ بیرونی را با `Ctrl+G` باز می‌کنی، پاسخِ قبلیِ Claude را به‌عنوانِ کانتکستِ کامنت‌شده با `#` پیش‌درج کن. پیش‌فرض: `false`. در `/config` به‌عنوانِ Show last response in external editor ظاهر می‌شود	`true`
`teammateDefaultModel`	مدلِ پیش‌فرض برای هم‌تیمی‌های agent team وقتی پرامپتِ spawn مدلی مشخص نکند. یک نامِ مستعارِ مدل مثلِ `"sonnet"` بگذار، یا `null` تا انتخابِ `/model`ِ فعلیِ رهبر را به ارث ببرد. در `/config` به‌عنوانِ Default teammate model ظاهر می‌شود	`"sonnet"`

تنظیماتِ worktree

پیکربندی کن که --worktree چطور worktreeهای git را می‌سازد و مدیریت می‌کند.

کلید	توضیح	مثال
`worktree.baseRef`	اینکه worktreeهای جدید از کدام ref شاخه می‌گیرند. `"fresh"` (پیش‌فرض) از `origin/<default-branch>` شاخه می‌گیرد تا یک درختِ تمیز مطابقِ remote داشته باشی. `"head"` از `HEAD`ِ محلیِ فعلی‌ات شاخه می‌گیرد، پس کامیت‌های push‌نشده و وضعیتِ شاخه‌ی قابلیت در worktree حاضرند. به `--worktree`، ابزارِ `EnterWorktree` و جداسازیِ ساب‌ایجنت اعمال می‌شود	`"head"`
`worktree.symlinkDirectories`	پوشه‌هایی که باید از مخزنِ اصلی به هر worktree با symlink آورده شوند تا از تکثیرِ پوشه‌های بزرگ روی دیسک جلوگیری شود. به‌صورتِ پیش‌فرض هیچ پوشه‌ای symlink نمی‌شود	`["node_modules", ".cache"]`
`worktree.sparsePaths`	پوشه‌هایی که در هر worktree از طریقِ git sparse-checkout بیرون کشیده می‌شوند. فقط پوشه‌های فهرست‌شده به‌علاوه‌ی فایل‌های سطحِ ریشه روی دیسک نوشته می‌شوند، که در monorepoهای بزرگ سریع‌تر است	`["packages/my-app", "shared/utils"]`
`worktree.bgIsolation`	حالتِ جداسازی برای نشست‌های پس‌زمینه. `"worktree"` (پیش‌فرض) `Edit`/`Write` را در checkoutِ اصلی مسدود می‌کند تا زمانی که `EnterWorktree` فراخوانی شود. `"none"` به کارهای پس‌زمینه اجازه می‌دهد مستقیم نسخه‌ی کاری را ویرایش کنند. نیازمندِ Claude Code v2.1.143 یا بالاتر	`"none"`

برای کپیِ فایل‌های gitignore‌شده مثلِ .env به worktreeهای جدید، به‌جای یک تنظیم از یک فایلِ .worktreeinclude در ریشه‌ی پروژه‌ات استفاده کن.

تنظیماتِ دسترسی

کلیدها	توضیح	مثال
`allow`	آرایه‌ای از قواعدِ دسترسی برای مجازکردنِ استفاده از ابزار. globهای نامِ ابزار فقط در موقعیتِ ابزار پس از یک پیشوندِ تحت‌اللفظیِ `mcp__<server>__` پشتیبانی می‌شوند، مثلِ `mcp__github__get_*`؛ بخشِ سرور باید بدونِ glob باشد. برای جزئیاتِ تطبیقِ الگو، Permission rule syntax را در پایین ببین	`[ "Bash(git diff *)" ]`
`ask`	آرایه‌ای از قواعدِ دسترسی برای درخواستِ تأیید هنگامِ استفاده از ابزار. Permission rule syntax را در پایین ببین	`[ "Bash(git push *)" ]`
`deny`	آرایه‌ای از قواعدِ دسترسی برای ردِ استفاده از ابزار. از این برای کنار گذاشتنِ فایل‌های حساس از دسترسیِ Claude Code استفاده کن. نام‌های ابزار الگوهای glob را می‌پذیرند: `""` هر ابزاری را رد می‌کند و `"mcp__"` همه‌ی ابزارهای MCP را رد می‌کند. ببین Permission rule syntax و Bash permission limitations	`[ "WebFetch", "Bash(curl )", "Read(./.env)", "Read(./secrets/*)" ]`
`additionalDirectories`	پوشه‌های کاریِ اضافی برای دسترسی به فایل. بیشترِ پیکربندیِ `.claude/` از این پوشه‌ها کشف نمی‌شود	`[ "../docs/" ]`
`defaultMode`	حالتِ دسترسیِ پیش‌فرض هنگامِ بازکردنِ Claude Code. مقادیرِ معتبر: `default`، `acceptEdits`، `plan`، `auto`، `dontAsk`، `bypassPermissions`. از Claude Code v2.1.142، `auto` وقتی در تنظیماتِ project یا local (`.claude/settings.json`، `.claude/settings.local.json`) تنظیم شود نادیده گرفته می‌شود تا یک مخزن نتواند به خودش حالتِ خودکار بدهد. به‌جایش آن را در `~/.claude/settings.json` بگذار. پرچمِ CLIِ `--permission-mode` این تنظیم را برای یک نشست بازنویسی می‌کند	`"acceptEdits"`
`disableBypassPermissionsMode`	برای جلوگیری از فعال‌شدنِ حالتِ `bypassPermissions` آن را `"disable"` بگذار. این پرچمِ خطِ فرمانِ `--dangerously-skip-permissions` را غیرفعال می‌کند. معمولاً در تنظیماتِ managed برای اعمالِ سیاستِ سازمانی قرار می‌گیرد، اما از هر دامنه‌ای کار می‌کند	`"disable"`
`skipDangerousModePermissionPrompt`	پرامپتِ تأییدی را که پیش از ورود به حالتِ bypass permissions از طریقِ `--dangerously-skip-permissions` یا `defaultMode: "bypassPermissions"` نشان داده می‌شود رد کن. وقتی در تنظیماتِ project (`.claude/settings.json`) تنظیم شود نادیده گرفته می‌شود تا از auto-bypassِ پرامپت توسطِ مخازنِ نامطمئن جلوگیری شود	`true`

نحوِ قواعدِ دسترسی

قواعدِ دسترسی از قالبِ Tool یا Tool(specifier) پیروی می‌کنند. قواعد به ترتیب ارزیابی می‌شوند: ابتدا قواعدِ deny، سپس ask، سپس allow. اولین تطابق نتیجه را تعیین می‌کند، صرفِ‌نظر از خاص‌بودنِ قاعده. برای جزئیات ترتیبِ ارزیابیِ قواعدِ دسترسی را ببین.

مثال‌های سریع:

قاعده	اثر
`Bash`	با همه‌ی فرمان‌های Bash تطبیق دارد
`Bash(npm run *)`	با فرمان‌هایی که با `npm run` شروع می‌شوند تطبیق دارد
`Read(./.env)`	با خواندنِ فایلِ `.env` تطبیق دارد
`WebFetch(domain:example.com)`	با درخواست‌های واکشی به example.com تطبیق دارد

برای مرجعِ کاملِ نحوِ قواعد، شاملِ رفتارِ wildcard، الگوهای مخصوصِ ابزار برای Read، Edit، WebFetch، MCP و قواعدِ Agent، و محدودیت‌های امنیتیِ الگوهای Bash، ببین Permission rule syntax.

تنظیماتِ sandbox

رفتارِ پیشرفته‌ی sandbox را پیکربندی کن. sandboxing فرمان‌های bash را از سیستمِ فایل و شبکه‌ات جدا می‌کند. برای جزئیات ببین Sandboxing.

کلیدها	توضیح	مثال
`enabled`	sandboxingِ bash را فعال کن (macOS، Linux و WSL2). پیش‌فرض: false	`true`
`failIfUnavailable`	اگر `sandbox.enabled` صحیح باشد اما sandbox نتواند راه بیفتد (وابستگی‌های گم‌شده یا پلتفرمِ پشتیبانی‌نشده)، هنگامِ راه‌اندازی با خطا خارج شو. وقتی false (پیش‌فرض) باشد، یک هشدار نشان داده می‌شود و فرمان‌ها بدونِ sandbox اجرا می‌شوند. برای استقرارهای تنظیماتِ managed در نظر گرفته شده که sandboxing را به‌عنوانِ یک گیتِ سخت لازم دارند	`true`
`autoAllowBashIfSandboxed`	فرمان‌های bash را هنگامِ sandbox‌شدن به‌صورتِ خودکار تأیید کن. پیش‌فرض: true	`true`
`excludedCommands`	فرمان‌هایی که باید خارج از sandbox اجرا شوند	`["docker *"]`
`allowUnsandboxedCommands`	به فرمان‌ها اجازه بده از طریقِ پارامترِ `dangerouslyDisableSandbox` خارج از sandbox اجرا شوند. وقتی روی `false` تنظیم شود، روزنه‌ی فرارِ `dangerouslyDisableSandbox` کاملاً غیرفعال می‌شود و همه‌ی فرمان‌ها باید sandbox‌شده اجرا شوند (یا در `excludedCommands` باشند). برای سیاست‌های سازمانی که sandboxingِ سخت‌گیرانه می‌خواهند مفید است. پیش‌فرض: true	`false`
`filesystem.allowWrite`	مسیرهای اضافی که فرمان‌های sandbox‌شده می‌توانند در آن‌ها بنویسند. آرایه‌ها در همه‌ی دامنه‌های تنظیمات ادغام می‌شوند: مسیرهای user، project و managed با هم ترکیب می‌شوند نه جایگزین. همچنین با مسیرهای قواعدِ دسترسیِ `Edit(...)` allow ادغام می‌شوند. ببین path prefixes در پایین.	`["/tmp/build", "~/.kube"]`
`filesystem.denyWrite`	مسیرهایی که فرمان‌های sandbox‌شده نمی‌توانند در آن‌ها بنویسند. آرایه‌ها در همه‌ی دامنه‌های تنظیمات ادغام می‌شوند. همچنین با مسیرهای قواعدِ دسترسیِ `Edit(...)` deny ادغام می‌شوند.	`["/etc", "/usr/local/bin"]`
`filesystem.denyRead`	مسیرهایی که فرمان‌های sandbox‌شده نمی‌توانند از آن‌ها بخوانند. آرایه‌ها در همه‌ی دامنه‌های تنظیمات ادغام می‌شوند. همچنین با مسیرهای قواعدِ دسترسیِ `Read(...)` deny ادغام می‌شوند.	`["~/.aws/credentials"]`
`filesystem.allowRead`	مسیرهایی برای دوباره-مجازکردنِ خواندن درونِ نواحیِ `denyRead`. بر `denyRead` اولویت دارد. آرایه‌ها در همه‌ی دامنه‌های تنظیمات ادغام می‌شوند. از این برای ساختِ الگوهای دسترسیِ خواندنیِ فقط-workspace استفاده کن.	`["."]`
`filesystem.allowManagedReadPathsOnly`	(فقط تنظیماتِ managed) فقط مسیرهای `filesystem.allowRead`ِ تنظیماتِ managed رعایت می‌شوند. `denyRead` همچنان از همه‌ی منابع ادغام می‌شود. پیش‌فرض: false	`true`
`network.allowUnixSockets`	(فقط macOS) مسیرهای Unix socket که در sandbox قابلِ دسترسی‌اند. روی Linux و WSL2 نادیده گرفته می‌شود، جایی که فیلترِ seccomp نمی‌تواند مسیرهای socket را بازرسی کند؛ به‌جایش از `allowAllUnixSockets` استفاده کن.	`["~/.ssh/agent-socket"]`
`network.allowAllUnixSockets`	همه‌ی اتصال‌های Unix socket را در sandbox مجاز کن. روی Linux و WSL2 این تنها راهِ مجازکردنِ Unix socketهاست، چون فیلترِ seccomp را که در غیرِ این صورت فراخوانی‌های `socket(AF_UNIX, ...)` را مسدود می‌کند رد می‌کند. پیش‌فرض: false	`true`
`network.allowLocalBinding`	اجازه‌ی bind به پورت‌های localhost را بده (فقط macOS). پیش‌فرض: false	`true`
`network.allowMachLookup`	نام‌های سرویسِ XPC/Mach اضافی که sandbox می‌تواند جست‌وجو کند (فقط macOS). از یک `*`ِ انتهاییِ منفرد برای تطبیقِ پیشوند پشتیبانی می‌کند. برای ابزارهایی که از طریقِ XPC ارتباط می‌گیرند مثلِ iOS Simulator یا Playwright لازم است.	`["com.apple.coresimulator.*"]`
`network.allowedDomains`	آرایه‌ای از دامنه‌ها که برای ترافیکِ شبکه‌ی خروجی مجازند. از wildcard پشتیبانی می‌کند (مثلاً `*.example.com`).	`["github.com", "*.npmjs.org"]`
`network.deniedDomains`	آرایه‌ای از دامنه‌ها که برای ترافیکِ شبکه‌ی خروجی مسدودند. از همان نحوِ wildcardِ `allowedDomains` پشتیبانی می‌کند. وقتی هر دو تطبیق دهند بر `allowedDomains` اولویت دارد. صرفِ‌نظر از `allowManagedDomainsOnly` از همه‌ی منابعِ تنظیمات ادغام می‌شود.	`["sensitive.cloud.example.com"]`
`network.allowManagedDomainsOnly`	(فقط تنظیماتِ managed) فقط `allowedDomains` و قواعدِ allowِ `WebFetch(domain:...)`ِ تنظیماتِ managed رعایت می‌شوند. دامنه‌های تنظیماتِ user، project و local نادیده گرفته می‌شوند. دامنه‌های غیرمجاز به‌صورتِ خودکار بدونِ پرامپت‌کردنِ کاربر مسدود می‌شوند. دامنه‌های ردشده همچنان از همه‌ی منابع رعایت می‌شوند. پیش‌فرض: false	`true`
`network.httpProxyPort`	پورتِ پراکسیِ HTTP که در صورتِ تمایل به آوردنِ پراکسیِ خودت استفاده می‌شود. اگر مشخص نشود، Claude پراکسیِ خودش را اجرا می‌کند.	`8080`
`network.socksProxyPort`	پورتِ پراکسیِ SOCKS5 که در صورتِ تمایل به آوردنِ پراکسیِ خودت استفاده می‌شود. اگر مشخص نشود، Claude پراکسیِ خودش را اجرا می‌کند.	`8081`
`enableWeakerNestedSandbox`	sandboxِ ضعیف‌تر را برای محیط‌های Dockerِ بدونِ امتیاز فعال کن (فقط Linux و WSL2). امنیت را کاهش می‌دهد. پیش‌فرض: false	`true`
`enableWeakerNetworkIsolation`	(فقط macOS) به سرویسِ trustِ TLSِ سیستم (`com.apple.trustd.agent`) در sandbox اجازه‌ی دسترسی بده. برای ابزارهای مبتنی بر Go مثلِ `gh`، `gcloud` و `terraform` لازم است تا هنگامِ استفاده از `httpProxyPort` با یک پراکسیِ MITM و CAِ سفارشی گواهی‌های TLS را تأیید کنند. امنیت را کاهش می‌دهد چون یک مسیرِ بالقوه‌ی exfiltrationِ داده باز می‌کند. پیش‌فرض: false	`true`
`bwrapPath`	(فقط تنظیماتِ managed، Linux/WSL2) مسیرِ مطلق به باینریِ bubblewrap (`bwrap`). تشخیصِ خودکار از طریقِ `PATH` را بازنویسی می‌کند. فقط از تنظیماتِ managed رعایت می‌شود، نه از تنظیماتِ user یا project. وقتی `bwrap` در محلی غیراستاندارد در محیط‌های managed نصب شده باشد مفید است.	`/opt/admin/bwrap`
`socatPath`	(فقط تنظیماتِ managed، Linux/WSL2) مسیرِ مطلق به باینریِ `socat` که برای پراکسیِ شبکه‌ی sandbox استفاده می‌شود. تشخیصِ خودکار از طریقِ `PATH` را بازنویسی می‌کند. فقط از تنظیماتِ managed رعایت می‌شود.	`/opt/admin/socat`

پیشوندهای مسیرِ sandbox

مسیرها در filesystem.allowWrite، filesystem.denyWrite، filesystem.denyRead و filesystem.allowRead از این پیشوندها پشتیبانی می‌کنند:

پیشوند	معنا	مثال
`/`	مسیرِ مطلق از ریشه‌ی سیستمِ فایل	`/tmp/build` همان `/tmp/build` می‌ماند
`~/`	نسبت به پوشه‌ی home	`~/.kube` به `$HOME/.kube` تبدیل می‌شود
`./` یا بدونِ پیشوند	برای تنظیماتِ project نسبت به ریشه‌ی پروژه، یا برای تنظیماتِ user نسبت به `~/.claude`	`./output` در `.claude/settings.json` به `<project-root>/output` تبدیل می‌شود

پیشوندِ قدیمی‌ترِ //path برای مسیرهای مطلق هنوز کار می‌کند. اگر قبلاً از تک‌اسلشِ /path با انتظارِ تفکیکِ نسبی-به-پروژه استفاده می‌کردی، به ./path سوییچ کن. این نحو با قواعدِ دسترسیِ Read و Edit فرق دارد، که از //path برای مطلق و /path برای نسبی-به-پروژه استفاده می‌کنند. مسیرهای سیستمِ فایلِ sandbox از قراردادهای استاندارد استفاده می‌کنند: /tmp/build یک مسیرِ مطلق است.

مثالِ پیکربندی:

\{
  "sandbox": \{
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker *"],
    "filesystem": \{
      "allowWrite": ["/tmp/build", "~/.kube"],
      "denyRead": ["~/.aws/credentials"]
    \},
    "network": \{
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"],
      "deniedDomains": ["uploads.github.com"],
      "allowUnixSockets": [
        "/var/run/docker.sock"
      ],
      "allowLocalBinding": true
    \}
  \}
\}

محدودیت‌های سیستمِ فایل و شبکه را می‌توان به دو روش که با هم ادغام می‌شوند پیکربندی کرد:

تنظیماتِ sandbox.filesystem (که در بالا نشان داده شد): مسیرها را در مرزِ sandboxِ سطحِ OS کنترل می‌کند. این محدودیت‌ها به همه‌ی فرمان‌های زیرفرایند (مثلاً kubectl، terraform، npm) اعمال می‌شوند، نه فقط ابزارهای فایلِ Claude.
قواعدِ دسترسی: از قواعدِ Edit allow/deny برای کنترلِ دسترسیِ ابزارِ فایلِ Claude، قواعدِ Read deny برای مسدودکردنِ خواندن‌ها، و قواعدِ WebFetch allow/deny برای کنترلِ دامنه‌های شبکه استفاده کن. مسیرهای این قواعد هم در پیکربندیِ sandbox ادغام می‌شوند.

تنظیماتِ attribution

Claude Code به کامیت‌های git و pull requestها انتساب (attribution) اضافه می‌کند. این‌ها جداگانه پیکربندی می‌شوند:

کامیت‌ها به‌صورتِ پیش‌فرض از git trailers (مثلِ Co-Authored-By) استفاده می‌کنند، که می‌توان آن‌ها را سفارشی یا غیرفعال کرد
توضیحاتِ pull request متنِ ساده‌اند

کلیدها	توضیح
`commit`	انتساب برای کامیت‌های git، شاملِ هر trailer. رشته‌ی خالی انتسابِ کامیت را پنهان می‌کند
`pr`	انتساب برای توضیحاتِ pull request. رشته‌ی خالی انتسابِ pull request را پنهان می‌کند

انتسابِ پیش‌فرضِ کامیت:

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

نامِ مدل در trailer مدلِ فعالِ نشست را بازتاب می‌دهد.

انتسابِ پیش‌فرضِ pull request:

🤖 Generated with [Claude Code](https://claude.com/claude-code)

مثال:

\{
  "attribution": \{
    "commit": "Generated with AI\n\nCo-Authored-By: AI <ai@example.com>",
    "pr": ""
  \}
\}

تنظیماتِ file suggestion

یک فرمانِ سفارشی برای تکمیلِ خودکارِ مسیرِ فایلِ @ پیکربندی کن. پیشنهادِ فایلِ توکار از پیمایشِ سریعِ سیستمِ فایل استفاده می‌کند، اما monorepoهای بزرگ ممکن است از ایندکس‌گذاریِ مخصوصِ پروژه مثلِ یک ایندکسِ فایلِ ازپیش‌ساخته یا ابزارِ سفارشی بهره ببرند.

\{
  "fileSuggestion": \{
    "type": "command",
    "command": "~/.claude/file-suggestion.sh"
  \}
\}

فرمان با همان متغیرهای محیطیِ hooks، از جمله CLAUDE_PROJECT_DIR، اجرا می‌شود. JSON را از طریقِ stdin با یک فیلدِ query دریافت می‌کند:

\{"query": "src/comp"\}

مسیرهای فایلِ جداشده با خطِ جدید را به stdout خروجی بده (در حالِ حاضر محدود به ۱۵):

src/components/Button.tsx
src/components/Modal.tsx
src/components/Form.tsx

مثال:

#!/bin/bash
query=$(cat | jq -r '.query')
# Replace your-repo-file-index with your own file search command
your-repo-file-index --query "$query" | head -20

پیکربندیِ hook

این تنظیمات کنترل می‌کنند که کدام hookها اجازه‌ی اجرا دارند و hookهای HTTP به چه چیزی می‌توانند دسترسی داشته باشند. تنظیمِ allowManagedHooksOnly فقط در تنظیماتِ managed قابلِ پیکربندی است. allowlistهای URL و متغیرِ محیطی را می‌توان در هر سطحی از تنظیمات گذاشت و بین منابع ادغام می‌شوند.

رفتار وقتی allowManagedHooksOnly برابرِ true باشد:

hookهای managed و hookهای SDK بارگذاری می‌شوند
hookهای پلاگین‌هایی که در enabledPluginsِ تنظیماتِ managed به‌اجبار فعال شده‌اند بارگذاری می‌شوند. این به ادمین‌ها اجازه می‌دهد hookهای بررسی‌شده را از طریقِ یک مارکت‌پلیسِ سازمانی توزیع کنند در حالی که بقیه را مسدود می‌کنند. اعتماد با IDِ کاملِ plugin@marketplace اعطا می‌شود، پس یک پلاگین با همان نام از مارکت‌پلیسی دیگر مسدود می‌ماند
hookهای user، hookهای project و همه‌ی hookهای پلاگینِ دیگر مسدود می‌شوند

محدودکردنِ URLهای hookِ HTTP:

محدود کن که hookهای HTTP می‌توانند کدام URLها را هدف بگیرند. از * به‌عنوانِ wildcard برای تطبیق پشتیبانی می‌کند. وقتی آرایه تعریف شود، hookهای HTTP که URLهای نامطابق را هدف می‌گیرند بی‌سروصدا مسدود می‌شوند. تطبیقِ hostname به حروفِ کوچک و بزرگ حساس نیست و یک نقطه‌ی انتهاییِ FQDN را نادیده می‌گیرد، مطابق با معناشناسیِ DNS.

\{
  "allowedHttpHookUrls": ["https://hooks.example.com/*", "http://localhost:*"]
\}

محدودکردنِ متغیرهای محیطیِ hookِ HTTP:

محدود کن که hookهای HTTP می‌توانند کدام نام‌های متغیرِ محیطی را در مقادیرِ هدر درون‌میان‌یابی کنند. allowedEnvVarsِ مؤثرِ هر hook اشتراکِ فهرستِ خودش و این تنظیم است.

\{
  "httpHookAllowedEnvVars": ["MY_TOKEN", "HOOK_SECRET"]
\}

محاسبه‌ی تنظیماتِ managed با یک policy helper

تنظیمِ policyHelper به یک اجراپذیر اشاره می‌کند که تنظیماتِ managed را هنگامِ راه‌اندازی محاسبه می‌کند، پس ادمین‌ها می‌توانند سیاست را به‌جای یک فایلِ ایستا از وضعیتِ دستگاه، هویت یا یک سرویسِ راه‌دور استخراج کنند. آن را از MDM یا یک فایلِ managed-settings.jsonِ سیستمی پیکربندی کن. Claude Code وقتی policyHelper در هر دامنه‌ی دیگری ظاهر شود آن را نادیده می‌گیرد، از جمله تنظیماتِ user، تنظیماتِ project، شاخه‌ی رجیستریِ HKCU و server-managed settings.

این تنظیم این کلیدها را می‌پذیرد:

کلید	نوع	توضیح
`path`	string	مسیرِ مطلق به اجراپذیرِ helper
`timeoutMs`	number	چقدر منتظرِ helper بماند پیش از آنکه اجرا را ناموفق تلقی کند
`refreshIntervalMs`	number	helper هر چند وقت یک‌بار در پس‌زمینه دوباره اجرا شود. برای غیرفعال‌کردنِ refresh آن را `0` بگذار، یا دستِ‌کم `60000`

helper یک پوششِ JSON را به stdout می‌نویسد. تنظیمات را زیرِ یک کلیدِ managedSettings بگذار، نه در سطحِ بالا، چون یک شیءِ تنظیماتِ خالی با managedSettingsِ تعریف‌نشده تجزیه می‌شود و چیزی اعمال نمی‌کند:

\{
  "managedSettings": \{
    "permissions": \{ "deny": ["Read(//etc/secrets/**)"] \}
  \},
  "claudeMd": "# Organization context\n...",
  "appendSystemPrompt": "Always cite the internal style guide."
\}

وقتی helper managedSettings را ساطع کند، آن شیء برای آن اجرا جایگزینِ تنظیماتِ managedِ مبتنی بر فایل می‌شود. وقتی helper هنگامِ راه‌اندازی با کدِ ناصفر خارج شود، Claude Code خطا را چاپ می‌کند و از راه‌اندازی امتناع می‌کند، پس helperی که به تابِ‌آوریِ قطعی نیاز دارد باید از کشِ خودش سرو کند و با 0 خارج شود.

اولویتِ تنظیمات

تنظیمات به ترتیبِ اولویت اعمال می‌شوند. از بالاترین به پایین‌ترین:

تنظیماتِ managed (server-managed، سیاست‌های MDM/سطحِ OS، یا managed settings)
- سیاست‌هایی که IT از طریقِ تحویلِ سروری، profileهای پیکربندیِ MDM، سیاست‌های رجیستری یا فایل‌های تنظیماتِ managed مستقر می‌کند
- با هیچ سطحِ دیگری، از جمله آرگومان‌های خطِ فرمان، قابلِ بازنویسی نیست
- درونِ لایه‌ی managed، اولویت این است: server-managed > سیاست‌های MDM/سطحِ OS > مبتنی بر فایل (managed-settings.d/*.json + managed-settings.json) > رجیستریِ HKCU (فقط ویندوز). فقط یک منبعِ managed استفاده می‌شود؛ منابع بین لایه‌ها ادغام نمی‌شوند. درونِ لایه‌ی مبتنی بر فایل، فایل‌های drop-in و فایلِ پایه با هم ادغام می‌شوند.
- میزبان‌های تعبیه‌کننده مثلِ Claude Desktop می‌توانند سیاست را از طریقِ گزینه‌ی managedSettingsِ SDK تأمین کنند. به‌صورتِ پیش‌فرض وقتی هر لایه‌ی managed-settingsی حاضر باشد این نادیده گرفته می‌شود. ادمین‌ها می‌توانند با تنظیمِ parentSettingsBehavior روی "merge" آن را فعال کنند. مقادیرِ تعبیه‌کننده فیلتر می‌شوند تا بتوانند سیاستِ managed را سفت‌تر کنند اما شل‌تر نه.
آرگومان‌های خطِ فرمان
- بازنویسی‌های موقت برای یک نشستِ مشخص. JSONی که از طریقِ --settings <file-or-json> پاس داده می‌شود با تنظیماتِ مبتنی بر فایل با همان قواعدِ سایرِ لایه‌ها ادغام می‌شود: کلیدی که اینجا تنظیم شود همان کلید را در تنظیماتِ local، project یا user بازنویسی می‌کند، و حذفِ یک کلید مقدارِ لایه‌ی پایین‌تر را سرِ جایش نگه می‌دارد
تنظیماتِ localِ project (.claude/settings.local.json)
- تنظیماتِ شخصیِ مخصوصِ project
تنظیماتِ اشتراکیِ project (.claude/settings.json)
- تنظیماتِ اشتراکیِ تیمیِ project در source control
تنظیماتِ user (~/.claude/settings.json)
- تنظیماتِ سراسریِ شخصی

این سلسله‌مراتب تضمین می‌کند که سیاست‌های سازمانی همیشه اعمال شوند در حالی که همچنان به تیم‌ها و افراد اجازه می‌دهد تجربه‌شان را سفارشی کنند. همین اولویت چه Claude Code را از CLI اجرا کنی، چه از افزونه‌ی VS Code یا یک JetBrains IDE، صدق می‌کند.

برای مثال، اگر تنظیماتِ user تو permissions.defaultMode را روی acceptEdits بگذارد و تنظیماتِ اشتراکیِ یک project آن را روی default بگذارد، مقدارِ project اعمال می‌شود. مثالِ زیر پوشش می‌دهد که چطور تنظیماتِ آرایه‌ای مثلِ قواعدِ دسترسی به‌جایش ترکیب می‌شوند.

تنظیماتِ آرایه‌ای بین دامنه‌ها ادغام می‌شوند. وقتی یک تنظیمِ آرایه‌ایِ یکسان (مثلِ sandbox.filesystem.allowWrite یا permissions.allow) در چند دامنه ظاهر شود، آرایه‌ها به هم پیوست و حذفِ تکراری می‌شوند، نه جایگزین. این یعنی دامنه‌های با اولویتِ پایین‌تر می‌توانند مدخل اضافه کنند بدونِ بازنویسیِ آن‌هایی که دامنه‌های با اولویتِ بالاتر تنظیم کرده‌اند، و برعکس. برای مثال، اگر تنظیماتِ managed allowWrite را روی ["/opt/company-tools"] بگذارد و یک کاربر ["~/.kube"] اضافه کند، هر دو مسیر در پیکربندیِ نهایی گنجانده می‌شوند. دو استثنا: fallbackModel، یک زنجیره‌ی مرتب که موقعیت در آن معنا دارد پس فایلِ با بالاترین اولویت که آن را تعریف می‌کند کلِ مقدار را تأمین می‌کند، و از v2.1.175، availableModels، که در آن یک مقدارِ managed یا policy مدخل‌های با اولویتِ پایین‌تر را کاملاً جایگزین می‌کند. ببین Merge behavior.

بررسیِ تنظیماتِ فعال

/status را اجرا کن و خطِ Setting sources را در زبانه‌ی Status ببین. هر لایه‌ی تنظیماتی را که Claude Code برای این نشست بارگذاری کرده فهرست می‌کند:

اگر لایه‌ای مثلِ User settings یا Project local settings ظاهر شود، آن فایل خوانده می‌شود.
اگر لایه‌ای غایب باشد، آن فایل پیدا نشده یا هیچ کلیدی ندارد.

وقتی تنظیماتِ managed اعمال شده باشند، مدخل کانالِ تحویل را در پرانتز نشان می‌دهد، برای مثال Enterprise managed settings (remote)، (plist)، (HKLM)، (HKCU) یا (file).

اگر یک فایلِ تنظیمات JSONِ نامعتبر یا مقداری داشته باشد که اعتبارسنجی را رد کند، Claude Code هنگامِ راه‌اندازی یک اعلانِ مشکلاتِ راه‌اندازی نشان می‌دهد و زبانه‌ی Status فایل‌های متأثر را فهرست می‌کند. برای جزئیاتِ هر خطا /doctor را اجرا کن.

این خط تأیید می‌کند کدام فایل‌ها خوانده می‌شوند، نه اینکه کدام لایه هر کلیدِ منفرد را تأمین کرده. زبانه‌ی Config در همان دیالوگ کلیدهای توکار مثلِ تم و خروجیِ verbose را ویرایش می‌کند، نه محتوای settings.jsonت را.

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

فایل‌های حافظه (CLAUDE.md): شاملِ دستورات و کانتکستی که Claude هنگامِ راه‌اندازی بارگذاری می‌کند
فایل‌های تنظیمات (JSON): دسترسی‌ها، متغیرهای محیطی و رفتارِ ابزار را پیکربندی می‌کنند
Skills: پرامپت‌های سفارشی که می‌توان با /skill-name فراخوانی کرد یا Claude به‌صورتِ خودکار بارگذاری می‌کند
سرورهای MCP: Claude Code را با ابزارها و یکپارچه‌سازی‌های اضافی گسترش می‌دهند
اولویت: پیکربندی‌های سطحِ بالاتر (Managed) سطحِ پایین‌تر (User/Project) را بازنویسی می‌کنند
وراثت: تنظیمات بین دامنه‌ها ادغام می‌شوند؛ مقادیرِ اسکالر از دامنه‌های با اولویتِ بالاتر بازنویسی می‌کنند و آرایه‌ها به هم پیوست می‌شوند. استثناها: fallbackModel، که در آن دامنه‌ی با بالاترین اولویت کلِ زنجیره را تأمین می‌کند، و availableModels، که در آن یک مقدارِ managed یا policy مدخل‌های با اولویتِ پایین‌تر را جایگزین می‌کند

پرامپتِ سیستم

پرامپتِ سیستمِ داخلیِ Claude Code منتشر نشده است. برای افزودنِ دستوراتِ سفارشی، از فایل‌های CLAUDE.md یا پرچمِ --append-system-prompt استفاده کن.

کنار گذاشتنِ فایل‌های حساس

برای جلوگیری از دسترسیِ Claude Code به فایل‌های حاویِ اطلاعاتِ حساس مثلِ کلیدهای API، secretها و فایل‌های محیطی، از تنظیمِ permissions.deny در فایلِ .claude/settings.jsonت استفاده کن:

\{
  "permissions": \{
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./build)"
    ]
  \}
\}

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

پیکربندیِ ساب‌ایجنت

Claude Code از ساب‌ایجنت‌های هوش مصنوعیِ سفارشی پشتیبانی می‌کند که می‌توان آن‌ها را هم در سطحِ user و هم در سطحِ project پیکربندی کرد. این ساب‌ایجنت‌ها به‌صورتِ فایل‌های Markdown با frontmatterِ YAML ذخیره می‌شوند:

ساب‌ایجنت‌های User: ~/.claude/agents/ - در همه‌ی پروژه‌هایت در دسترس
ساب‌ایجنت‌های Project: .claude/agents/ - مخصوصِ پروژه‌ات و قابلِ اشتراک با تیمت

فایل‌های ساب‌ایجنت دستیارهای هوش مصنوعیِ تخصصی را با پرامپت‌های سفارشی و دسترسی‌های ابزار تعریف می‌کنند. درباره‌ی ساخت و استفاده از ساب‌ایجنت‌ها در subagents documentation بیشتر بدان.

پیکربندیِ پلاگین

Claude Code از یک سیستمِ پلاگین پشتیبانی می‌کند که به تو اجازه می‌دهد کارکرد را با skillها، agentها، hookها و سرورهای MCP گسترش دهی. پلاگین‌ها از طریقِ مارکت‌پلیس‌ها توزیع می‌شوند و می‌توان آن‌ها را هم در سطحِ user و هم در سطحِ مخزن پیکربندی کرد.

تنظیماتِ پلاگین

تنظیماتِ مرتبط با پلاگین در settings.json:

\{
  "enabledPlugins": \{
    "formatter@acme-tools": true,
    "deployer@acme-tools": true,
    "analyzer@security-plugins": false
  \},
  "extraKnownMarketplaces": \{
    "acme-tools": \{
      "source": \{
        "source": "github",
        "repo": "acme-corp/claude-plugins"
      \}
    \}
  \}
\}

`enabledPlugins`

کنترل می‌کند کدام پلاگین‌ها فعال‌اند. قالب: "plugin-name@marketplace-name": true/false. پلاگینی که در هیچ دامنه‌ای مدخل ندارد به مقدارِ defaultEnabledش بازمی‌گردد.

دامنه‌ها:

تنظیماتِ User (~/.claude/settings.json): ترجیحاتِ شخصیِ پلاگین
تنظیماتِ Project (.claude/settings.json): پلاگین‌های مخصوصِ project که با تیم به اشتراک گذاشته می‌شوند
تنظیماتِ Local (.claude/settings.local.json): بازنویسی‌های هر-دستگاه، که وقتی Claude Code می‌سازدش gitignore می‌شوند
تنظیماتِ Managed (managed-settings.json): بازنویسی‌های سیاستِ سراسریِ سازمان که نصب را در همه‌ی دامنه‌ها مسدود و پلاگین را از مارکت‌پلیس پنهان می‌کنند

مثال:

\{
  "enabledPlugins": \{
    "code-formatter@team-tools": true,
    "deployment-tools@team-tools": true,
    "experimental-features@personal": false
  \}
\}

`extraKnownMarketplaces`

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

وقتی یک مخزن شاملِ extraKnownMarketplaces باشد:

به اعضای تیم پیشنهاد می‌شود وقتی به پوشه اعتماد می‌کنند مارکت‌پلیس را نصب کنند
سپس به اعضای تیم پیشنهاد می‌شود پلاگین‌ها را از آن مارکت‌پلیس نصب کنند
کاربران می‌توانند از مارکت‌پلیس‌ها یا پلاگین‌های ناخواسته رد شوند (در تنظیماتِ user ذخیره می‌شود)
نصب مرزهای trust را رعایت می‌کند و به رضایتِ صریح نیاز دارد

مثال:

\{
  "extraKnownMarketplaces": \{
    "acme-tools": \{
      "source": \{
        "source": "github",
        "repo": "acme-corp/claude-plugins"
      \}
    \},
    "security-plugins": \{
      "source": \{
        "source": "git",
        "url": "https://git.example.com/security/plugins.git"
      \}
    \}
  \}
\}

انواعِ منبعِ مارکت‌پلیس:

github: مخزنِ GitHub (از repo استفاده می‌کند)
git: هر URLِ git (از url استفاده می‌کند)
directory: مسیرِ سیستمِ فایلِ محلی (از path استفاده می‌کند، فقط برای توسعه)
hostPattern: الگوی regex برای تطبیقِ هاست‌های مارکت‌پلیس (از hostPattern استفاده می‌کند)
settings: مارکت‌پلیسِ درون‌خطی که مستقیماً در settings.json بدونِ یک مخزنِ میزبان‌شده‌ی جداگانه اعلام می‌شود (از name و plugins استفاده می‌کند)

نوعِ منبعِ git با هر سرویسِ میزبانیِ git کار می‌کند، از جمله GitLab و Bitbucketِ self-hosted. Claude Code مخزن را با همان احراز هویتی که git clone روی آن دستگاه استفاده می‌کند کلون می‌کند: credential helperهای پیکربندی‌شده، کلیدهای SSH یا یک متغیرِ محیطیِ توکنِ مخصوصِ هاست. برای جزئیاتِ راه‌اندازی ببین Private repositories.

برای منابعِ github و git، داخلِ شیءِ source (کنارِ repo یا url) "skipLfs": true بگذار تا هنگامی که Claude Code مخزنِ مارکت‌پلیس را کلون یا به‌روزرسانی می‌کند دانلودهای Git LFS رد شوند. فایل‌های اشاره‌گرِ LFS به‌جای دانلودِ محتوایشان به‌صورتِ اشاره‌گر باقی می‌مانند. از این وقتی استفاده کن که مخزن شاملِ اشیاءِ بزرگِ LFSِ بی‌ربط به محتوای پلاگین باشد. نیازمندِ Claude Code v2.1.153 یا بالاتر.

هر مدخلِ مارکت‌پلیس همچنین یک بولینِ اختیاریِ autoUpdate می‌پذیرد. "autoUpdate": true را کنارِ source بگذار تا Claude Code آن مارکت‌پلیس را refresh کند و پلاگین‌های نصب‌شده‌اش را هنگامِ راه‌اندازی به‌روزرسانی کند. وقتی حذف شود، مارکت‌پلیس‌های رسمیِ Anthropic به‌صورتِ پیش‌فرض true و همه‌ی مارکت‌پلیس‌های دیگر به‌صورتِ پیش‌فرض false هستند. ببین Configure auto-updates.

از source: 'settings' برای اعلامِ مجموعه‌ای کوچک از پلاگین‌ها به‌صورتِ درون‌خطی بدونِ راه‌اندازیِ یک مخزنِ مارکت‌پلیسِ میزبان‌شده استفاده کن. پلاگین‌هایی که اینجا فهرست می‌شوند باید به منابعِ بیرونی مثلِ GitHub یا npm ارجاع دهند. هنوز باید هر پلاگین را جداگانه در enabledPlugins فعال کنی.

\{
  "extraKnownMarketplaces": \{
    "team-tools": \{
      "source": \{
        "source": "settings",
        "name": "team-tools",
        "plugins": [
          \{
            "name": "code-formatter",
            "source": \{
              "source": "github",
              "repo": "acme-corp/code-formatter"
            \}
          \}
        ]
      \}
    \}
  \}
\}

`strictKnownMarketplaces`

فقط تنظیماتِ managed: کنترل می‌کند کاربران اجازه دارند از کدام مارکت‌پلیس‌های پلاگین، مارکت‌پلیس اضافه و پلاگین نصب کنند. این تنظیم فقط در تنظیماتِ managed قابلِ پیکربندی است و کنترلِ سخت‌گیرانه‌ی منابعِ مارکت‌پلیس را در اختیارِ ادمین‌ها می‌گذارد.

محل‌های فایلِ تنظیماتِ managed:

macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux و WSL: /etc/claude-code/managed-settings.json
ویندوز: C:\Program Files\ClaudeCode\managed-settings.json

ویژگی‌های کلیدی:

فقط در تنظیماتِ managed (managed-settings.json) موجود است
با تنظیماتِ user یا project قابلِ بازنویسی نیست (بالاترین اولویت)
پیش از عملیاتِ شبکه/سیستمِ فایل اعمال می‌شود (منابعِ مسدودشده هرگز اجرا نمی‌شوند)
از تطبیقِ دقیق برای مشخصاتِ منبع استفاده می‌کند (از جمله ref، path برای منابعِ git)، به‌جز hostPattern و pathPattern که از تطبیقِ regex استفاده می‌کنند

رفتارِ allowlist:

undefined (پیش‌فرض): بدونِ محدودیت - کاربران می‌توانند هر مارکت‌پلیسی اضافه کنند
آرایه‌ی خالی []: قفلِ کامل - کاربران نمی‌توانند هیچ مارکت‌پلیسِ جدیدی اضافه کنند
فهرستِ منابع: کاربران فقط می‌توانند مارکت‌پلیس‌هایی اضافه کنند که دقیقاً تطبیق دارند

همه‌ی انواعِ منبعِ پشتیبانی‌شده:

allowlist از چند نوعِ منبعِ مارکت‌پلیس پشتیبانی می‌کند. بیشترِ منابع از تطبیقِ دقیق استفاده می‌کنند، در حالی که hostPattern و pathPattern به‌ترتیب از تطبیقِ regex با هاست و مسیرِ سیستمِ فایلِ مارکت‌پلیس استفاده می‌کنند.

مخازنِ GitHub:

\{ "source": "github", "repo": "acme-corp/approved-plugins" \}
\{ "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" \}
\{ "source": "github", "repo": "acme-corp/plugins", "ref": "main", "path": "marketplace" \}

فیلدها: repo (الزامی)، ref (اختیاری: شاخه/تگ/SHA)، path (اختیاری: زیرپوشه)

مخازنِ Git:

\{ "source": "git", "url": "https://gitlab.example.com/tools/plugins.git" \}
\{ "source": "git", "url": "https://bitbucket.org/acme-corp/plugins.git", "ref": "production" \}
\{ "source": "git", "url": "ssh://git@git.example.com/plugins.git", "ref": "v3.1", "path": "approved" \}

فیلدها: url (الزامی)، ref (اختیاری: شاخه/تگ/SHA)، path (اختیاری: زیرپوشه)

مارکت‌پلیس‌های مبتنی بر URL:

\{ "source": "url", "url": "https://plugins.example.com/marketplace.json" \}
\{ "source": "url", "url": "https://cdn.example.com/marketplace.json", "headers": \{ "Authorization": "Bearer $\{TOKEN\}" \} \}

فیلدها: url (الزامی)، headers (اختیاری: هدرهای HTTP برای دسترسیِ احراز هویت‌شده)

بسته‌های NPM:

\{ "source": "npm", "package": "@acme-corp/claude-plugins" \}
\{ "source": "npm", "package": "@acme-corp/approved-marketplace" \}

فیلدها: package (الزامی، از بسته‌های scoped پشتیبانی می‌کند)

مسیرهای فایل:

\{ "source": "file", "path": "/usr/local/share/claude/acme-marketplace.json" \}
\{ "source": "file", "path": "/opt/acme-corp/plugins/marketplace.json" \}

فیلدها: path (الزامی: مسیرِ مطلق به فایلِ marketplace.json)

مسیرهای پوشه:

\{ "source": "directory", "path": "/usr/local/share/claude/acme-plugins" \}
\{ "source": "directory", "path": "/opt/acme-corp/approved-marketplaces" \}

فیلدها: path (الزامی: مسیرِ مطلق به پوشه‌ی حاویِ .claude-plugin/marketplace.json)

تطبیقِ الگوی هاست:

\{ "source": "hostPattern", "hostPattern": "^github\\.example\\.com$" \}
\{ "source": "hostPattern", "hostPattern": "^gitlab\\.internal\\.example\\.com$" \}

فیلدها: hostPattern (الزامی: الگوی regex برای تطبیق با هاستِ مارکت‌پلیس)

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

استخراجِ هاست بر اساسِ نوعِ منبع:

github: همیشه با github.com تطبیق داده می‌شود
git: hostname را از URL استخراج می‌کند (از هر دو قالبِ HTTPS و SSH پشتیبانی می‌کند)
url: hostname را از URL استخراج می‌کند
npm، file، directory: برای تطبیقِ الگوی هاست پشتیبانی نمی‌شوند

تطبیقِ الگوی مسیر:

\{ "source": "pathPattern", "pathPattern": "^/opt/approved/" \}
\{ "source": "pathPattern", "pathPattern": ".*" \}

فیلدها: pathPattern (الزامی: الگوی regex که با فیلدِ pathِ منابعِ file و directory تطبیق داده می‌شود)

از تطبیقِ الگوی مسیر برای مجازکردنِ مارکت‌پلیس‌های مبتنی بر سیستمِ فایل کنارِ محدودیت‌های hostPattern برای منابعِ شبکه استفاده کن. ".*" را بگذار تا همه‌ی مسیرهای محلی مجاز شوند، یا یک الگوی محدودتر برای محدودکردن به پوشه‌های مشخص.

مثال‌های پیکربندی:

مثال: فقط مارکت‌پلیس‌های مشخص را مجاز کن:

\{
  "strictKnownMarketplaces": [
    \{
      "source": "github",
      "repo": "acme-corp/approved-plugins"
    \},
    \{
      "source": "github",
      "repo": "acme-corp/security-tools",
      "ref": "v2.0"
    \},
    \{
      "source": "url",
      "url": "https://plugins.example.com/marketplace.json"
    \},
    \{
      "source": "npm",
      "package": "@acme-corp/compliance-plugins"
    \}
  ]
\}

مثال - همه‌ی افزودنی‌های مارکت‌پلیس را غیرفعال کن:

\{
  "strictKnownMarketplaces": []
\}

مثال: همه‌ی مارکت‌پلیس‌ها از یک سرورِ گیتِ داخلی را مجاز کن:

\{
  "strictKnownMarketplaces": [
    \{
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    \}
  ]
\}

الزاماتِ تطبیقِ دقیق:

منابعِ مارکت‌پلیس باید دقیقاً تطبیق دهند تا افزودنِ یک کاربر مجاز شود. برای منابعِ مبتنی بر git (github و git)، این شاملِ همه‌ی فیلدهای اختیاری است:

repo یا url باید دقیقاً تطبیق دهد
فیلدِ ref باید دقیقاً تطبیق دهد (یا هر دو تعریف‌نشده باشند)
فیلدِ path باید دقیقاً تطبیق دهد (یا هر دو تعریف‌نشده باشند)

مثال‌هایی از منابعی که تطبیق نمی‌دهند:

// These are DIFFERENT sources:
\{ "source": "github", "repo": "acme-corp/plugins" \}
\{ "source": "github", "repo": "acme-corp/plugins", "ref": "main" \}

// These are also DIFFERENT:
\{ "source": "github", "repo": "acme-corp/plugins", "path": "marketplace" \}
\{ "source": "github", "repo": "acme-corp/plugins" \}

مقایسه با extraKnownMarketplaces:

جنبه	`strictKnownMarketplaces`	`extraKnownMarketplaces`
هدف	اعمالِ سیاستِ سازمانی	راحتیِ تیم
فایلِ تنظیمات	فقط `managed-settings.json`	هر فایلِ تنظیمات
رفتار	افزودنی‌های غیرِ allowlist را مسدود می‌کند	مارکت‌پلیس‌های گم‌شده را خودکار نصب می‌کند
زمانِ اعمال	پیش از عملیاتِ شبکه/سیستمِ فایل	پس از پرامپتِ trustِ کاربر
قابلِ بازنویسی	خیر (بالاترین اولویت)	بله (با تنظیماتِ با اولویتِ بالاتر)
قالبِ منبع	شیءِ منبعِ مستقیم	مارکت‌پلیسِ نام‌دار با منبعِ تودرتو
موردِ استفاده	انطباق، محدودیت‌های امنیتی	onboarding، استانداردسازی

تفاوتِ قالب:

strictKnownMarketplaces از شیءهای منبعِ مستقیم استفاده می‌کند:

\{
  "strictKnownMarketplaces": [
    \{ "source": "github", "repo": "acme-corp/plugins" \}
  ]
\}

extraKnownMarketplaces به مارکت‌پلیس‌های نام‌دار نیاز دارد:

\{
  "extraKnownMarketplaces": \{
    "acme-tools": \{
      "source": \{ "source": "github", "repo": "acme-corp/plugins" \}
    \}
  \}
\}

استفاده‌ی هر دو با هم:

strictKnownMarketplaces یک گیتِ سیاست است: کنترل می‌کند کاربران چه چیزی می‌توانند اضافه کنند اما هیچ مارکت‌پلیسی ثبت نمی‌کند. برای اینکه هم محدود کنی و هم یک مارکت‌پلیس را برای همه‌ی کاربران ازپیش ثبت کنی، هر دو را در managed-settings.json بگذار:

\{
  "strictKnownMarketplaces": [
    \{ "source": "github", "repo": "acme-corp/plugins" \}
  ],
  "extraKnownMarketplaces": \{
    "acme-tools": \{
      "source": \{ "source": "github", "repo": "acme-corp/plugins" \}
    \}
  \}
\}

وقتی فقط strictKnownMarketplaces تنظیم شده باشد، کاربران همچنان می‌توانند مارکت‌پلیسِ مجاز را دستی از طریقِ /plugin marketplace add اضافه کنند، اما به‌صورتِ خودکار در دسترس نیست.

نکاتِ مهم:

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

برای مستنداتِ کاربرپسند ببین Managed marketplace restrictions.

`strictPluginOnlyCustomization`

فقط تنظیماتِ managed: skillها، agentها، hookها و سرورهای MCP را از منابعِ user و project مسدود می‌کند، تا فقط بتوانند از پلاگین‌ها یا تنظیماتِ managed بیایند. آن را با strictKnownMarketplaces ترکیب کن تا کلِ زنجیره‌ی تأمینِ سفارشی‌سازی را کنترل کنی: allowlistِ مارکت‌پلیس کنترل می‌کند کاربران چه پلاگین‌هایی می‌توانند نصب کنند، و این تنظیم هر چیزی را که از یک پلاگین یا از تنظیماتِ managed نمی‌آید مسدود می‌کند.

مقدار یا true است تا هر چهار سطح قفل شوند، یا یک آرایه که سطوحِ موردِ قفل را نام می‌برد:

\{
  "strictPluginOnlyCustomization": ["skills", "hooks"]
\}

برای هر سطحِ قفل‌شده، Claude Code منابعِ سطحِ user و سطحِ project را رد می‌کند و فقط منابعِ تأمین‌شده توسطِ پلاگین و managed را بارگذاری می‌کند:

سطح	وقتی قفل شود مسدود می‌شود	همچنان بارگذاری می‌شود
`skills`	`~/.claude/skills/`، `.claude/skills/`	skillهای پلاگین، skillهای bundled، skillهای پوشه‌ی سیاستِ managed
`agents`	`~/.claude/agents/`، `.claude/agents/`	agentهای پلاگین، agentهای توکار، agentهای پوشه‌ی سیاستِ managed
`hooks`	hookها در `settings.json`ِ user، project و local	hookهای پلاگین، hookهای تنظیماتِ managed
`mcp`	سرورها در `~/.claude.json` و `.mcp.json`	سرورهای MCPِ پلاگین، سرورهای `managed-mcp.json`

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

مدیریتِ پلاگین‌ها

از فرمانِ /plugin برای مدیریتِ تعاملیِ پلاگین‌ها استفاده کن:

پلاگین‌های موجود را از مارکت‌پلیس‌ها مرور کن
پلاگین‌ها را نصب/حذف کن
پلاگین‌ها را فعال/غیرفعال کن
جزئیاتِ پلاگین را ببین (skillها، agentها، hookهای فراهم‌شده)
مارکت‌پلیس‌ها را اضافه/حذف کن

درباره‌ی سیستمِ پلاگین در plugins documentation بیشتر بدان.

متغیرهای محیطی

متغیرهای محیطی به تو اجازه می‌دهند رفتارِ Claude Code را بدونِ ویرایشِ فایل‌های تنظیمات کنترل کنی. هر متغیر را می‌توان در settings.json زیرِ کلیدِ env هم پیکربندی کرد تا به هر نشست اعمال شود یا برای تیمت منتشر گردد.

برای فهرستِ کامل ببین environment variables reference.

ابزارهای در دسترسِ Claude

Claude Code به مجموعه‌ای از ابزارها برای خواندن، ویرایش، جست‌وجو، اجرای فرمان‌ها و هماهنگیِ ساب‌ایجنت‌ها دسترسی دارد. نام‌های ابزار همان رشته‌های دقیقی هستند که در قواعدِ دسترسی و matcherهای hook استفاده می‌کنی.

برای فهرستِ کامل و جزئیاتِ رفتارِ ابزارِ Bash ببین tools reference.

همچنین ببینید

Permissions: سیستمِ دسترسی، نحوِ قواعد، الگوهای مخصوصِ ابزار و سیاست‌های managed
Authentication: راه‌اندازیِ دسترسیِ کاربر به Claude Code
Debug your configuration: تشخیصِ اینکه چرا یک تنظیم، hook یا سرورِ MCP اثر نمی‌گذارد
Troubleshoot installation and login: مسائلِ نصب، احراز هویت و پلتفرم