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

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

Claude Code از دسترسی‌های ریزدانه پشتیبانی می‌کند تا بتوانی دقیقاً مشخص کنی ایجنت اجازه‌ی چه کارهایی را دارد و چه کارهایی را ندارد. تنظیماتِ دسترسی را می‌توان در version control ثبت کرد و میان همه‌ی developerهای سازمانت توزیع کرد، و هر developer هم می‌تواند آن را شخصی‌سازی کند.

سیستم دسترسی

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

نوع ابزار	نمونه	نیاز به تأیید	رفتارِ «بله، دیگر نپرس»
فقط-خواندنی	خواندن فایل، Grep	خیر	ندارد
دستورهای Bash	اجرای شل	بله	دائمی، به‌ازای هر دایرکتوریِ پروژه و هر دستور
تغییر فایل	ویرایش/نوشتن فایل	بله	تا پایان نشست

مدیریت دسترسی‌ها

می‌توانی دسترسی‌های ابزارهای Claude Code را با /permissions ببینی و مدیریت کنی. این رابط، همه‌ی قواعدِ دسترسی و فایل settings.json‌ای که از آن آمده‌اند را فهرست می‌کند.

• قواعدِ Allow به Claude Code اجازه می‌دهند ابزارِ مشخص‌شده را بدون تأییدِ دستی به کار ببرد.
• قواعدِ Ask هر بار که Claude Code می‌خواهد ابزارِ مشخص‌شده را به کار ببرد، تأیید می‌خواهند.
• قواعدِ Deny مانع از به‌کارگیریِ ابزارِ مشخص‌شده توسط Claude Code می‌شوند.

قواعد به این ترتیب ارزیابی می‌شوند: ابتدا deny، سپس ask، سپس allow. اولین تطابق در همین ترتیب، نتیجه را تعیین می‌کند و دقتِ قاعده ترتیب را تغییر نمی‌دهد. یک قاعده‌ی ask که تطابق دارد، حتی وقتی قاعده‌ی allow دقیق‌تری هم به همان فراخوانی تطابق داشته باشد، باز هم تأیید می‌خواهد.

قواعدِ deny بسته به اینکه یک ابزار را نام ببرند یا الگویی درونِ آن را محدود کنند، رفتارِ متفاوتی دارند. یک نامِ ابزارِ خالی مثل Bash ابزار را به‌کلی از کانتکستِ Claude حذف می‌کند، پس Claude هرگز آن را نمی‌بیند. یک قاعده‌ی محدودشده مثل Bash(rm *) ابزار را در دسترس نگه می‌دارد و وقتی Claude تلاش به فراخوانیِ منطبق کند، آن را مسدود می‌کند.

یادداشت

قواعدِ دسترسی توسط Claude Code اعمال می‌شوند، نه توسط مدل. دستورهای داخلِ پرامپت یا CLAUDE.md شکل می‌دهند که Claude چه چیزی را تلاش می‌کند انجام دهد، اما تغییری نمی‌دهند در اینکه Claude Code چه چیزی را اجازه می‌دهد. برای اعطا یا لغوِ دسترسی، از /permissions، قواعدِ توصیف‌شده در همین صفحه، یک حالتِ دسترسی، یا یک هوکِ PreToolUse استفاده کن.

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

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

حالت	توضیح
default	رفتارِ استاندارد: در اولین استفاده از هر ابزار، تأیید می‌خواهد
acceptEdits	ویرایش‌های فایل و دستورهای رایجِ فایل‌سیستمی (mkdir, touch, mv, cp و غیره) را برای مسیرهای داخلِ دایرکتوریِ کاری یا additionalDirectories به‌طور خودکار می‌پذیرد
plan	حالتِ Plan: Claude فایل‌ها را می‌خواند و دستورهای شلِ فقط-خواندنی را برای کاوش اجرا می‌کند اما فایل‌های منبعت را ویرایش نمی‌کند
auto	فراخوانی‌های ابزار را با بررسی‌های ایمنیِ پس‌زمینه که هم‌راستا بودنِ اقدامات با درخواستت را وارسی می‌کنند، به‌طور خودکار تأیید می‌کند. در حال حاضر یک research preview است
dontAsk	ابزارها را به‌طور خودکار رد می‌کند مگر اینکه از پیش از طریقِ /permissions یا قواعدِ permissions.allow تأیید شده باشند
bypassPermissions	تأییدهای دسترسی را رد می‌کند، به‌جز آن‌هایی که با قواعدِ صریحِ ask اجباری شده‌اند. حذف‌هایی از ریشه و دایرکتوریِ خانگی مثل rm -rf / نیز همچنان به‌عنوان یک قطع‌کننده‌ی مدار تأیید می‌خواهند

احتیاط

حالتِ bypassPermissions تأییدهای دسترسی را رد می‌کند، از جمله برای نوشتن در .git, .config/git, .claude, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn و .mvn. قواعدِ صریحِ ask همچنان تأیید را اجباری می‌کنند، و حذف‌هایی که ریشه‌ی فایل‌سیستم یا دایرکتوریِ خانگی را هدف می‌گیرند، مثل rm -rf / و rm -rf ~، همچنان به‌عنوان قطع‌کننده‌ی مدار در برابرِ خطای مدل تأیید می‌خواهند. این حالت را فقط در محیط‌های ایزوله مثل کانتینرها یا VMها به کار ببر، جایی که Claude Code نمی‌تواند آسیبی بزند. مدیرها می‌توانند با تنظیمِ permissions.disableBypassPermissionsMode روی "disable" در تنظیماتِ مدیریت‌شده، از این حالت جلوگیری کنند.

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

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

قواعدِ دسترسی از قالبِ Tool یا Tool(specifier) پیروی می‌کنند.

تطابق با همه‌ی کاربردهای یک ابزار

برای تطابق با همه‌ی کاربردهای یک ابزار، فقط نامِ ابزار را بدون پرانتز به کار ببر:

قاعده	اثر
Bash	با همه‌ی دستورهای Bash تطابق دارد
WebFetch	با همه‌ی درخواست‌های web fetch تطابق دارد
Read	با همه‌ی خواندن‌های فایل تطابق دارد

Bash(*) معادلِ Bash است و با همه‌ی دستورهای Bash تطابق دارد. به‌عنوان یک قاعده‌ی deny، هر دو شکل ابزار را از کانتکستِ Claude حذف می‌کنند.

استفاده از specifierها برای کنترلِ ریزدانه

یک specifier درونِ پرانتز اضافه کن تا با کاربردهای مشخصی از ابزار تطابق پیدا کنی:

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

الگوهای wildcard

قواعدِ Bash از الگوهای glob با * پشتیبانی می‌کنند. wildcardها می‌توانند در هر موقعیتی از دستور ظاهر شوند. این پیکربندی، دستورهای npm و git commit را اجازه می‌دهد ولی git push را مسدود می‌کند:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

فاصله‌ی پیش از * اهمیت دارد: Bash(ls *) با ls -la تطابق دارد اما با lsof نه، در حالی که Bash(ls*) با هر دو تطابق دارد. پسوندِ :* راهی معادل برای نوشتنِ wildcardِ پایانی است، پس Bash(ls:*) با همان دستورهایی تطابق دارد که Bash(ls *) تطابق دارد.

وقتی برای یک پیشوندِ دستور «بله، دیگر نپرس» را انتخاب کنی، دیالوگِ دسترسی شکلِ جداشده‌با‌فاصله را می‌نویسد. شکلِ :* فقط در انتهای یک الگو شناسایی می‌شود. در الگویی مثل Bash(git:* push)، علامتِ دونقطه یک کاراکترِ تحت‌اللفظی در نظر گرفته می‌شود و با دستورهای git تطابق پیدا نمی‌کند.

wildcardهای نامِ ابزار

قواعدِ deny و ask هم در موقعیتِ نامِ ابزار، الگوهای glob را می‌پذیرند. الگو باید با نامِ کاملِ ابزار تطابق داشته باشد: "*" با هر ابزاری تطابق دارد، و "mcp__*" با هر ابزارِ MCP در همه‌ی سرورها تطابق دارد. ابزاری که با یک قاعده‌ی deniِ glob با نامِ خالی تطابق پیدا کند، از کانتکستِ Claude حذف می‌شود، درست مثلِ یک نامِ ابزارِ خالی. این پیکربندی هر ابزارِ MCP را deny می‌کند:

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

قواعدِ allow فقط پس از یک پیشوندِ تحت‌اللفظیِ mcp__<server>__ این globهای نامِ ابزار را می‌پذیرند. بخشِ server باید بدون glob باشد تا قاعده، سرورِ مشخصی که پیکربندی کرده‌ای را نام ببرد. mcp__puppeteer__* با هر ابزاری از سرورِ puppeteer تطابق دارد، و mcp__github__get_* با ابزارهای get_ آن تطابق دارد. یک globِ allowِ بدون لنگر مثل "*", "B*" یا "mcp__*" با یک هشدار نادیده گرفته می‌شود و چیزی را به‌طور خودکار تأیید نمی‌کند.

یک قاعده‌ی deny یا ask که نامِ ابزارش با هیچ ابزارِ شناخته‌شده‌ای تطابق ندارد، یک هشدارِ راه‌اندازی تولید می‌کند تا غلط‌های تایپی گرفته شوند. نام‌های ابزاری که شاملِ _ یا * هستند از این بررسی مستثنا هستند.

قواعد دسترسیِ مخصوص هر ابزار

Bash

قواعدِ دسترسیِ Bash از تطابقِ wildcard با * پشتیبانی می‌کنند. wildcardها می‌توانند در هر موقعیتی از دستور ظاهر شوند، از جمله ابتدا، میانه یا انتها:

• Bash(npm run build) با دستورِ دقیقِ Bashِ npm run build تطابق دارد
• Bash(npm run test *) با دستورهای Bashی که با npm run test شروع می‌شوند تطابق دارد
• Bash(npm *) با هر دستوری که با npm شروع می‌شود تطابق دارد
• Bash(* install) با هر دستوری که به install ختم می‌شود تطابق دارد
• Bash(git * main) با دستورهایی مثل git checkout main و git log --oneline main تطابق دارد

یک * تنها با هر دنباله‌ای از کاراکترها از جمله فاصله‌ها تطابق دارد، پس یک wildcard می‌تواند چند آرگومان را در بر بگیرد. Bash(git *) با git log --oneline --all تطابق دارد، و Bash(git * main) هم با git push origin main و هم با git merge main تطابق دارد.

وقتی * در انتها با یک فاصله پیش از آن ظاهر شود (مثلِ Bash(ls *))، یک مرزِ کلمه‌ای را اعمال می‌کند و لازم می‌کند که پیشوند با یک فاصله یا انتهای رشته دنبال شود. برای مثال Bash(ls *) با ls -la تطابق دارد اما با lsof نه. در مقابل، Bash(ls*) بدون فاصله با هر دوی ls -la و lsof تطابق دارد چون قیدِ مرزِ کلمه‌ای ندارد.

دستورهای مرکب

نکته

Claude Code از عملگرهای شل آگاه است، پس قاعده‌ای مثل Bash(safe-cmd *) به آن اجازه‌ی اجرای دستورِ safe-cmd && other-cmd را نمی‌دهد. جداکننده‌های شناخته‌شده‌ی دستور عبارت‌اند از &&, ||, ;, |, |&, & و خطوطِ جدید. یک قاعده باید با هر زیردستور به‌طور مستقل تطابق داشته باشد.

وقتی یک دستورِ مرکب را با «بله، دیگر نپرس» تأیید کنی، Claude Code به‌جای یک قاعده‌ی واحد برای کلِ رشته‌ی مرکب، برای هر زیردستوری که نیاز به تأیید دارد یک قاعده‌ی جداگانه ذخیره می‌کند. برای مثال، تأییدِ git status && npm test یک قاعده برای npm test ذخیره می‌کند، پس فراخوانی‌های آینده‌ی npm test صرف‌نظر از آنچه پیش از && می‌آید شناسایی می‌شوند. زیردستورهایی مثلِ cd به یک زیردایرکتوری، قاعده‌ی Readِ خودشان را برای آن مسیر تولید می‌کنند. تا ۵ قاعده ممکن است برای یک دستورِ مرکبِ واحد ذخیره شود.

پوشش‌دهنده‌های فرایند

پیش از تطابق با قواعدِ Bash، Claude Code مجموعه‌ی ثابتی از پوشش‌دهنده‌های فرایند را حذف می‌کند تا قاعده‌ای مثل Bash(npm test *) با timeout 30 npm test هم تطابق پیدا کند. پوشش‌دهنده‌های شناخته‌شده عبارت‌اند از timeout, time, nice, nohup و stdbuf.

xargsِ خالی نیز حذف می‌شود، پس Bash(grep *) با xargs grep pattern تطابق دارد. این حذف فقط وقتی اعمال می‌شود که xargs هیچ پرچمی نداشته باشد: فراخوانی‌ای مثلِ xargs -n1 grep pattern به‌عنوان یک دستورِ xargs تطابق داده می‌شود، پس قواعدی که برای دستورِ درونی نوشته شده‌اند آن را پوشش نمی‌دهند.

این فهرستِ پوشش‌دهنده‌ها داخلی است و قابلِ پیکربندی نیست. اجراکننده‌های محیطِ توسعه مثل direnv exec, devbox run, mise exec, npx و docker exec در این فهرست نیستند. چون این ابزارها آرگومان‌هایشان را به‌عنوان یک دستور اجرا می‌کنند، قاعده‌ای مثل Bash(devbox run *) با هر چیزی که پس از run می‌آید تطابق دارد، از جمله devbox run rm -rf .. برای تأییدِ کار درونِ یک اجراکننده‌ی محیط، قاعده‌ی مشخصی بنویس که هم اجراکننده و هم دستورِ درونی را در بر بگیرد، مثلِ Bash(devbox run npm test). به‌ازای هر دستورِ درونی‌ای که می‌خواهی اجازه بدهی، یک قاعده اضافه کن.

پوشش‌دهنده‌های exec مثلِ watch, setsid, ionice و flock همیشه تأیید می‌خواهند و نمی‌توان آن‌ها را با یک قاعده‌ی پیشوندی مثلِ Bash(watch *) به‌طور خودکار تأیید کرد. همین مورد برای find با -exec یا -delete نیز صدق می‌کند: یک قاعده‌ی Bash(find *) این شکل‌ها را پوشش نمی‌دهد. برای تأییدِ یک فراخوانیِ مشخص، یک قاعده‌ی تطابقِ دقیق برای کلِ رشته‌ی دستور بنویس.

دستورهای فقط-خواندنی

Claude Code مجموعه‌ای درونی از دستورهای Bash را به‌عنوان فقط-خواندنی می‌شناسد و آن‌ها را در هر حالتی بدون تأییدِ دسترسی اجرا می‌کند. این‌ها شاملِ ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd و شکل‌های فقط-خواندنیِ git هستند. این مجموعه قابلِ پیکربندی نیست؛ برای اینکه یکی از این دستورها تأیید بخواهد، یک قاعده‌ی ask یا deny برایش اضافه کن.

الگوهای globِ بدون‌کوتیشن برای دستورهایی که همه‌ی پرچم‌هایشان فقط-خواندنی است مجاز هستند، پس ls *.ts و wc -l src/*.py بدون تأیید اجرا می‌شوند. دستورهایی با پرچم‌های توانمند به نوشتن یا اجرا، مثلِ find, sort, sed و git، وقتی یک globِ بدون‌کوتیشن حاضر باشد همچنان تأیید می‌خواهند، چون glob می‌تواند به پرچمی مثلِ -delete گسترش پیدا کند.

یک cd به مسیری درونِ دایرکتوریِ کاری‌ات یا یک دایرکتوریِ افزوده نیز فقط-خواندنی است. یک دستورِ مرکب مثلِ cd packages/api && ls وقتی هر بخش به‌تنهایی واجدِ شرایط باشد، بدون تأیید اجرا می‌شود. ترکیبِ cd با git در یک دستورِ مرکبِ واحد همیشه تأیید می‌خواهد، صرف‌نظر از دایرکتوریِ مقصد.

احتیاط

الگوهای دسترسیِ Bash که می‌کوشند آرگومان‌های دستور را محدود کنند، شکننده‌اند. برای مثال، Bash(curl http://github.com/ *) قصد دارد curl را به URLهای GitHub محدود کند، اما با گونه‌هایی مثلِ این‌ها تطابق پیدا نمی‌کند:

• گزینه‌ها پیش از URL: curl -X GET http://github.com/...
• پروتکلِ متفاوت: curl https://github.com/...
• تغییرِ مسیر: curl -L http://bit.ly/xyz (به github ریدایرکت می‌شود)
• متغیرها: URL=http://github.com && curl $URL
• فاصله‌های اضافه: curl http://github.com

برای فیلترِ URLِ قابل‌اتکاتر، این‌ها را در نظر بگیر:

• محدود کردنِ ابزارهای شبکه‌ی Bash: از قواعدِ deny برای مسدود کردنِ curl, wget و دستورهای مشابه استفاده کن، سپس برای دامنه‌های مجاز از ابزارِ WebFetch با دسترسیِ WebFetch(domain:github.com) استفاده کن
• استفاده از هوک‌های PreToolUse: هوکی پیاده‌سازی کن که URLها را در دستورهای Bash اعتبارسنجی کند و دامنه‌های مجازنشده را مسدود کند
• افزودنِ راهنماییِ CLAUDE.md: الگوهای curlِ مجازت را در CLAUDE.md توصیف کن. این شکل می‌دهد که Claude چه چیزی را تلاش می‌کند اما یک مرز را اعمال نمی‌کند، پس آن را با یکی از گزینه‌های بالا همراه کن

توجه کن که استفاده از WebFetch به‌تنهایی مانعِ دسترسیِ شبکه نمی‌شود. اگر Bash مجاز باشد، Claude همچنان می‌تواند از curl, wget یا ابزارهای دیگر برای رسیدن به هر URLی استفاده کند.

PowerShell

قواعدِ دسترسیِ PowerShell از همان شکلِ قواعدِ Bash استفاده می‌کنند. wildcardها با * در هر موقعیتی تطابق دارند، پسوندِ :* معادلِ یک *ِ پایانی است، و یک PowerShell یا PowerShell(*)ِ خالی با هر دستوری تطابق دارد. این پیکربندی دستورهای Get-ChildItem و git commit را اجازه می‌دهد ولی Remove-Item را مسدود می‌کند:

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

نام‌های مستعارِ رایج پیش از تطابق، به شکلِ متعارف درمی‌آیند. قاعده‌ای که برای نامِ cmdlet نوشته شده با نام‌های مستعارش هم تطابق دارد، پس PowerShell(Get-ChildItem *) با gci, ls و dir نیز تطابق دارد. تطابق نسبت به بزرگی و کوچکی حروف بی‌تفاوت است.

Claude Code، ASTِ PowerShell را پارس می‌کند و هر دستور در یک دستورِ مرکب را به‌طور مستقل بررسی می‌کند. عملگرهای پایپ‌لاین |، جداکننده‌های دستور ; و در PowerShell نسخه‌ی ۷ به بالا عملگرهای زنجیره‌ای && و || یک دستورِ مرکب را به زیردستورها تقسیم می‌کنند. یک قاعده باید با هر زیردستور تطابق داشته باشد تا دستورِ مرکب مجاز شود.

Read و Edit

قواعدِ Edit بر همه‌ی ابزارهای درونی‌ای که فایل‌ها را ویرایش می‌کنند اعمال می‌شوند. Claude بهترین تلاشش را می‌کند تا قواعدِ Read را بر همه‌ی ابزارهای درونی‌ای که فایل‌ها را می‌خوانند مثلِ Grep و Glob، بر اشاره‌های @file در پرامپت‌هایت، و بر کانتکستِ انتخاب و فایلِ بازِ مشترکی که یک IDEِ متصل با Claude به اشتراک می‌گذارد، اعمال کند.

احتیاط

قواعدِ deniِ Read و Edit بر ابزارهای درونیِ فایلِ Claude و بر دستورهای فایلی‌ای که Claude Code در Bash می‌شناسد، مثلِ cat, head, tail و sed، اعمال می‌شوند. آن‌ها بر زیرفرایندهای دلخواهی که فایل‌ها را به‌طور غیرمستقیم می‌خوانند یا می‌نویسند، مثلِ یک اسکریپتِ Python یا Node که خودش فایل‌ها را باز می‌کند، اعمال نمی‌شوند. برای اعمالِ در سطحِ OS که دسترسیِ همه‌ی فرایندها به یک مسیر را مسدود می‌کند، سندباکس را فعال کن.

قواعدِ Read و Edit هر دو از مشخصاتِ gitignore با چهار نوع الگوی متمایز پیروی می‌کنند:

الگو	معنی	نمونه	تطابق‌ها
//path	مسیرِ مطلق از ریشه‌ی فایل‌سیستم	Read(//Users/alice/secrets/**)	/Users/alice/secrets/**
~/path	مسیر از دایرکتوریِ خانگی	Read(~/Documents/*.pdf)	/Users/alice/Documents/*.pdf
/path	مسیرِ نسبی به ریشه‌ی پروژه	Edit(/src/**/*.ts)	<project root>/src/**/*.ts
path یا ./path	مسیرِ نسبی به دایرکتوریِ جاری	Read(*.env)	<cwd>/*.env

احتیاط

الگویی مثلِ /Users/alice/file یک مسیرِ مطلق نیست. نسبی به ریشه‌ی پروژه است. برای مسیرهای مطلق از //Users/alice/file استفاده کن.

روی Windows، مسیرها پیش از تطابق به شکلِ POSIX نرمال‌سازی می‌شوند. C:\Users\alice به /c/Users/alice تبدیل می‌شود، پس از //c/**/.env استفاده کن تا با فایل‌های .env در هر جای آن درایو تطابق پیدا کنی. برای تطابق در همه‌ی درایوها، از //**/.env استفاده کن.

نمونه‌ها:

• Edit(/docs/**): ویرایش‌ها در <project>/docs/ (نه /docs/ و نه <project>/.claude/docs/)
• Read(~/.zshrc): .zshrcِ دایرکتوریِ خانگی‌ات را می‌خواند
• Edit(//tmp/scratch.txt): مسیرِ مطلقِ /tmp/scratch.txt را ویرایش می‌کند
• Read(src/**): از <current-directory>/src/ می‌خواند

یک قاعده فقط با فایل‌های زیرِ لنگرش تطابق دارد، پس لنگر تعیین می‌کند که یک قاعده‌ی deny تا کجا می‌رسد. نام‌فایل‌های خالی از معناشناسیِ gitignore پیروی می‌کنند و در هر عمقی تطابق پیدا می‌کنند، پس Read(.env) و Read(**/.env) معادل‌اند:

قاعده‌ی deny	مسدود می‌کند	مسدود نمی‌کند
Read(.env) یا Read(**/.env)	هر .envی در یا زیرِ دایرکتوریِ جاری	.env در یک دایرکتوریِ والد یا پروژه‌ی دیگر
Read(//**/.env)	هر .envی در هر جای فایل‌سیستم	هیچ‌چیز؛ قاعده در ریشه‌ی فایل‌سیستم لنگر شده است

یادداشت

در الگوهای gitignore، * درونِ یک بخشِ مسیر تطابق دارد و می‌تواند در هر موقعیتی از الگو ظاهر شود، در حالی که ** در طولِ دایرکتوری‌ها تطابق دارد. برای اجازه‌ی دسترسیِ کامل به فایل، فقط نامِ ابزار را بدون پرانتز به کار ببر: Read, Edit یا Write.

وقتی Claude به یک symlink دسترسی پیدا می‌کند، قواعدِ دسترسی دو مسیر را بررسی می‌کنند: خودِ symlink و فایلی که به آن resolve می‌شود. قواعدِ allow و deny این جفت را متفاوت برخورد می‌کنند: قواعدِ allow به تأییدِ تو برمی‌گردند، در حالی که قواعدِ deny به‌کلی مسدود می‌کنند.

• قواعدِ allow: فقط وقتی اعمال می‌شوند که هم مسیرِ symlink و هم مقصدش تطابق داشته باشند. یک symlink درونِ یک دایرکتوریِ مجاز که به بیرونِ آن اشاره می‌کند همچنان از تو تأیید می‌خواهد.
• قواعدِ deny: وقتی اعمال می‌شوند که یا مسیرِ symlink یا مقصدش تطابق داشته باشد. یک symlink که به یک فایلِ deny‌شده اشاره می‌کند، خودش deny می‌شود.

برای مثال، با مجاز بودنِ Read(./project/**) و deny بودنِ Read(~/.ssh/**)، یک symlink در ./project/key که به ~/.ssh/id_rsa اشاره می‌کند مسدود می‌شود: مقصد در قاعده‌ی allow رد می‌شود و با قاعده‌ی deny تطابق پیدا می‌کند.

WebFetch

قواعدِ WebFetch از یک پیشوندِ domain: استفاده می‌کنند و با hostnameِ URLِ درخواست‌شده تطابق پیدا می‌کنند. تطابق نسبت به بزرگی و کوچکیِ حروف بی‌تفاوت است، از wildcardهای * پشتیبانی می‌کند، و یک .ِ پایانی را هم از قاعده و هم از hostname حذف می‌کند تا example.com. و example.com یکسان برخورد شوند.

• WebFetch(domain:example.com) با درخواست‌ها به example.com تطابق دارد
• WebFetch(domain:*.example.com) با هر زیردامنه‌ای در هر عمقی تطابق دارد، مثلِ api.example.com یا a.b.example.com، اما با خودِ example.com نه
• WebFetch(domain:*) با هر دامنه‌ای تطابق دارد و معادلِ یک قاعده‌ی WebFetchِ خالی است

یک * تنها به‌صورتِ یک *.ِ پیشرو یا به‌عنوانِ کلِ الگو، از روی یک . عبور می‌کند. در جاهای دیگر درونِ یک برچسب می‌ماند، پس WebFetch(domain:github.*) با github.io تطابق دارد اما با github.evil.com نه، دامنه‌ای که یک مهاجم می‌تواند ثبت کند. وقتی یک قاعده‌ی دقیق و یک قاعده‌ی wildcard در همان فهرستِ allow، ask یا deny هر دو با یک hostname تطابق داشته باشند، قاعده‌ی دقیق همان است که تطابق پیدا می‌کند. ترتیبِ ارزیابی بدون تغییر است: قواعدِ deny همچنان پیش از قواعدِ ask و allow اجرا می‌شوند، صرف‌نظر از دقت.

MCP

• mcp__puppeteer با هر ابزاری که سرورِ puppeteer فراهم می‌کند تطابق دارد (نام در Claude Code پیکربندی شده)
• mcp__puppeteer__* نحوِ wildcard که هم با همه‌ی ابزارهای سرورِ puppeteer تطابق دارد
• mcp__puppeteer__puppeteer_navigate با ابزارِ puppeteer_navigate که سرورِ puppeteer فراهم می‌کند تطابق دارد

Agent (ساب‌ایجنت‌ها)

از قواعدِ Agent(AgentName) استفاده کن تا کنترل کنی Claude کدام ساب‌ایجنت‌ها را می‌تواند به کار ببرد:

• Agent(Explore) با ساب‌ایجنتِ Explore تطابق دارد
• Agent(Plan) با ساب‌ایجنتِ Plan تطابق دارد
• Agent(my-custom-agent) با یک ساب‌ایجنتِ سفارشی به نامِ my-custom-agent تطابق دارد

این قواعد را به آرایه‌ی deny در تنظیماتت اضافه کن یا از پرچمِ CLIِ --disallowedTools استفاده کن تا ایجنت‌های مشخصی را غیرفعال کنی. برای غیرفعال کردنِ ایجنتِ Explore:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Cd

قواعدِ Cd کنترل می‌کنند که دستورِ /cd می‌تواند نشست را به کدام دایرکتوری‌ها منتقل کند. Cd یک ابزارِ قابلِ‌فراخوانی‌توسطِ‌مدل نیست: Claude نمی‌تواند آن را فراخوانی کند، و قواعد فقط وقتی اعمال می‌شوند که خودت /cd را اجرا کنی.

یک قاعده‌ی deniِ Cdِ خالی، /cd را به‌کلی غیرفعال می‌کند. یک قاعده‌ی deniِ Cd(<path-pattern>) مقصدهای منطبق را مسدود می‌کند. قواعدِ deny هر املای مقصد را بررسی می‌کنند، از جمله هر گامِ symlinkی که از آن resolve می‌شود، پس قاعده‌ای که برای یک مسیر نوشته شده، مقصدهایی را هم که به آن resolve می‌شوند مسدود می‌کند.

افزودنِ هر قاعده‌ی allowِ Cd، حالتِ /cd را به حالتِ allowlist تغییر می‌دهد: دایرکتوریِ مقصدِ resolve‌شده باید با یکی از قواعدِ allowت تطابق داشته باشد، وگرنه /cd امتناع می‌کند. بدونِ هیچ قاعده‌ی Cdِ پیکربندی‌شده، /cd رفتارِ پیش‌فرضش را حفظ می‌کند و از تو می‌خواهد که یک دایرکتوریِ ناآشنا را اعتماد کنی.

الگوهای مسیر، لنگرهای //, ~/ و / را از قواعدِ Read و Edit به اشتراک می‌گذارند، اما تطابق به‌جای سبکِ gitignore، به کلِ مسیرِ دایرکتوری لنگر شده است. * دقیقاً با یک بخشِ مسیر تطابق دارد و ** در طولِ بخش‌ها تطابق دارد. یک /**ِ پایانی، ریشه‌ی نام‌گذاری‌شده‌اش را هم تطابق می‌دهد.

قاعده	تطابق‌ها	تطابق نمی‌دهد
Cd(~/code/*)	~/code/app	~/code/app/src, ~/code
Cd(~/code/**)	~/code و هر دایرکتوریِ زیرِ آن	دایرکتوری‌های بیرونِ ~/code
Cd(**/node_modules)	هر دایرکتوریِ node_modules در هر عمقی	node_modules/pkg

گسترش دسترسی‌ها با هوک‌ها

هوک‌های Claude Code راهی فراهم می‌کنند تا دستورهای شلِ سفارشی را ثبت کنی که ارزیابیِ دسترسی را در زمانِ اجرا انجام می‌دهند. وقتی Claude Code یک فراخوانیِ ابزار انجام می‌دهد، هوک‌های PreToolUse پیش از تأییدِ دسترسی اجرا می‌شوند. خروجیِ هوک می‌تواند فراخوانیِ ابزار را deny کند، تأیید را اجباری کند، یا تأیید را رد کند تا فراخوانی ادامه پیدا کند.

تصمیم‌های هوک از قواعدِ دسترسی عبور نمی‌کنند. قواعدِ deny و ask صرف‌نظر از آنچه یک هوکِ PreToolUse برمی‌گرداند ارزیابی می‌شوند، پس یک قاعده‌ی deniِ منطبق فراخوانی را مسدود می‌کند و یک قاعده‌ی askِ منطبق حتی وقتی هوک "allow" یا "ask" برگردانده باشد همچنان تأیید می‌خواهد. این، تقدمِ deny-firstِ توصیف‌شده در مدیریت دسترسی‌ها را حفظ می‌کند، از جمله قواعدِ deniِ تنظیم‌شده در تنظیماتِ مدیریت‌شده.

یک هوکِ مسدودکننده نیز بر قواعدِ allow تقدم دارد. هوکی که با کدِ خروجِ ۲ خارج می‌شود، فراخوانیِ ابزار را پیش از ارزیابیِ قواعدِ دسترسی متوقف می‌کند، پس این مسدودسازی حتی وقتی یک قاعده‌ی allow در غیرِ این صورت اجازه‌ی ادامه‌ی فراخوانی را می‌داد، اعمال می‌شود. برای اجرای همه‌ی دستورهای Bash بدون تأیید به‌جز چند تایی که می‌خواهی مسدود شوند، "Bash" را به فهرستِ allowت اضافه کن و یک هوکِ PreToolUse ثبت کن که همان دستورهای مشخص را رد کند. برای یک اسکریپتِ هوک که می‌توانی تطبیق دهی، مسدود کردن ویرایش‌ها روی فایل‌های محافظت‌شده را ببین.

دایرکتوری‌های کاری

به‌طور پیش‌فرض، Claude به فایل‌های دایرکتوری‌ای که از آن راه‌اندازی شده دسترسی دارد. می‌توانی این دسترسی را گسترش بدهی:

• در حین راه‌اندازی: از آرگومانِ CLIِ --add-dir <path> استفاده کن
• در حین نشست: از دستورِ /add-dir استفاده کن
• پیکربندیِ دائمی: به additionalDirectories در فایل‌های تنظیمات اضافه کن

فایل‌های دایرکتوری‌های افزوده از همان قواعدِ دسترسیِ دایرکتوریِ کاریِ اصلی پیروی می‌کنند: بدون تأیید قابلِ‌خواندن می‌شوند، و دسترسی‌های ویرایشِ فایل از حالتِ دسترسیِ جاری پیروی می‌کنند.

برای تغییرِ دایرکتوریِ کاریِ اصلیِ نشست به‌جای افزودنِ یکی دیگر، از /cd استفاده کن. دستورِ /cd به Claude Code نسخه‌ی v2.1.169 یا بالاتر نیاز دارد. برخلافِ /add-dir، این دستور نشست را جابه‌جا می‌کند: CLAUDE.mdِ دایرکتوریِ جدید بارگذاری می‌شود و --resume نشست را از آنجا پیدا می‌کند.

دایرکتوری‌های افزوده دسترسیِ فایل می‌دهند، نه پیکربندی

افزودنِ یک دایرکتوری، جایی که Claude می‌تواند فایل‌ها را بخواند و ویرایش کند را گسترش می‌دهد. این، آن دایرکتوری را به یک ریشه‌ی پیکربندیِ کامل تبدیل نمی‌کند: بیشترِ پیکربندیِ .claude/ از دایرکتوری‌های افزوده کشف نمی‌شود، هرچند چند نوع به‌عنوان استثنا بارگذاری می‌شوند.

این استثناها فقط بر دایرکتوری‌هایی اعمال می‌شوند که با پرچمِ --add-dir یا دستورِ /add-dir افزوده شده‌اند. دایرکتوری‌های فهرست‌شده در permissions.additionalDirectories در یک فایلِ تنظیمات، فقط دسترسیِ فایل می‌دهند و هیچ‌یک از پیکربندی‌های زیر را بارگذاری نمی‌کنند.

انواعِ پیکربندیِ زیر از دایرکتوری‌های --add-dir بارگذاری می‌شوند:

پیکربندی	بارگذاری‌شده از --add-dir
مهارت‌ها در .claude/skills/	بله، با بارگذاریِ زنده
تنظیماتِ پلاگین در .claude/settings.json	فقط enabledPlugins و extraKnownMarketplaces
فایل‌های CLAUDE.md، .claude/rules/ و CLAUDE.local.md	فقط وقتی CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 تنظیم شده باشد. CLAUDE.local.md علاوه بر این به منبعِ تنظیماتِ local نیاز دارد که به‌طور پیش‌فرض فعال است

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

• پیکربندیِ در سطحِ کاربر: فایل‌ها را در ~/.claude/agents/, ~/.claude/output-styles/ یا ~/.claude/settings.json بگذار تا در هر پروژه‌ای در دسترس باشند
• پلاگین‌ها: پیکربندی را به‌صورتِ یک پلاگین بسته‌بندی و توزیع کن که تیم‌ها بتوانند نصبش کنند
• راه‌اندازی از دایرکتوریِ پیکربندی: Claude Code را از دایرکتوری‌ای که شاملِ پیکربندیِ .claude/ِ موردِ نظرت است اجرا کن

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

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

• دسترسی‌ها کنترل می‌کنند که Claude Code کدام ابزارها را می‌تواند به کار ببرد و به کدام فایل‌ها یا دامنه‌ها می‌تواند دسترسی پیدا کند. آن‌ها بر همه‌ی ابزارها (Bash, Read, Edit, WebFetch, MCP و دیگران) اعمال می‌شوند.
• سندباکس اعمالِ در سطحِ OS را فراهم می‌کند که دسترسیِ فایل‌سیستم و شبکه‌ی ابزارِ Bash را محدود می‌کند. فقط بر دستورهای Bash و فرایندهای فرزندشان اعمال می‌شود.

برای دفاعِ لایه‌به‌لایه از هر دو استفاده کن:

• قواعدِ deniِ دسترسی، Claude را از حتی تلاش برای دسترسی به منابعِ محدودشده مسدود می‌کنند
• محدودیت‌های سندباکس مانع از رسیدنِ دستورهای Bash به منابعِ بیرونِ مرزهای تعریف‌شده می‌شوند، حتی اگر یک prompt injection تصمیم‌گیریِ Claude را دور بزند
• محدودیت‌های فایل‌سیستم در سندباکس، تنظیماتِ sandbox.filesystem را با قواعدِ deniِ Read و Edit ترکیب می‌کنند؛ هر دو در مرزِ نهاییِ سندباکس ادغام می‌شوند
• محدودیت‌های شبکه، قواعدِ دسترسیِ WebFetch را با فهرست‌های allowedDomains و deniedDomainsِ سندباکس ترکیب می‌کنند

وقتی سندباکس با autoAllowBashIfSandboxed: true فعال باشد، که پیش‌فرض است، دستورهای Bashِ سندباکس‌شده بدون تأیید اجرا می‌شوند حتی اگر دسترسی‌هایت شاملِ یک قاعده‌ی askِ Bashِ خالی، یا شکلِ معادلِ Bash(*) باشند: مرزِ سندباکس جایگزینِ آن تأییدِ کلِ-ابزار می‌شود. قواعدِ askِ محدودشده‌به‌محتوا مثلِ Bash(git push *) همچنان تأیید را اجباری می‌کنند، قواعدِ deniِ صریح همچنان اعمال می‌شوند، و دستورهای rm یا rmdir که /، دایرکتوریِ خانگی‌ات یا دیگر مسیرهای حیاتیِ سیستم را هدف می‌گیرند همچنان تأیید را راه‌اندازی می‌کنند. دستورهایی که سندباکس‌شده اجرا نمی‌شوند، مثلِ دستورهای مستثنا، طبقِ معمول به قاعده‌ی askِ Bashِ خالی احترام می‌گذارند. برای تغییرِ این رفتار، حالت‌های سندباکس را ببین.

تنظیمات مدیریت‌شده

برای سازمان‌هایی که به کنترلِ متمرکز روی پیکربندیِ Claude Code نیاز دارند، مدیرها می‌توانند تنظیماتِ مدیریت‌شده‌ای را مستقر کنند که با تنظیماتِ کاربر یا پروژه قابلِ بازنویسی نیستند. این تنظیماتِ سیاستی از همان قالبِ فایل‌های تنظیماتِ معمولی پیروی می‌کنند و می‌توانند از طریقِ سیاست‌های MDM/در‌سطحِ‌OS، فایل‌های تنظیماتِ مدیریت‌شده، یا تنظیماتِ مدیریت‌شده‌ی سروری تحویل داده شوند. برای مکانیزم‌های تحویل و مکانِ فایل‌ها، فایل‌های تنظیمات را ببین.

تنظیماتی که فقط مدیریت‌شده‌اند

تنظیماتِ زیر فقط از تنظیماتِ مدیریت‌شده خوانده می‌شوند. گذاشتنِ آن‌ها در فایل‌های تنظیماتِ کاربر یا پروژه هیچ اثری ندارد.

تنظیم	توضیح
allowAllClaudeAiMcps	وقتی true باشد، connectorهای claude.ai در کنارِ یک managed-mcp.jsonِ مستقرشده بارگذاری می‌شوند به‌جای اینکه با کنترلِ انحصاریِ آن سرکوب شوند. پیکربندیِ MCPِ مدیریت‌شده را ببین
allowedChannelPlugins	فهرستِ مجازِ پلاگین‌های کانال که می‌توانند پیام push کنند. وقتی تنظیم شود، جایگزینِ فهرستِ مجازِ پیش‌فرضِ Anthropic می‌شود. به channelsEnabled: true نیاز دارد. محدود کردن اینکه کدام پلاگین‌های کانال می‌توانند اجرا شوند را ببین
allowManagedHooksOnly	وقتی true باشد، فقط هوک‌های مدیریت‌شده، هوک‌های SDK، و هوک‌های پلاگین‌هایی که در enabledPluginsِ تنظیماتِ مدیریت‌شده به‌اجبار فعال شده‌اند بارگذاری می‌شوند. هوک‌های کاربر، پروژه و همه‌ی پلاگین‌های دیگر مسدود می‌شوند
allowManagedMcpServersOnly	وقتی true باشد، فقط allowedMcpServers از تنظیماتِ مدیریت‌شده رعایت می‌شوند. deniedMcpServers همچنان از همه‌ی منابع ادغام می‌شود. پیکربندیِ MCPِ مدیریت‌شده را ببین
allowManagedPermissionRulesOnly	وقتی true باشد، مانع از تعریفِ قواعدِ دسترسیِ allow, ask یا deny توسطِ تنظیماتِ کاربر و پروژه می‌شود. فقط قواعدِ تنظیماتِ مدیریت‌شده اعمال می‌شوند. بر فهرستِ مجازِ سرورِ MCP اثری ندارد؛ برای آن، allowManagedMcpServersOnly را تنظیم کن
blockedMarketplaces	فهرستِ مسدودِ منابعِ marketplace. منابعِ مسدودشده پیش از دانلود بررسی می‌شوند، پس هرگز به فایل‌سیستم نمی‌رسند. محدودیت‌های marketplaceِ مدیریت‌شده را ببین
channelsEnabled	کانال‌ها را برای سازمان اجازه می‌دهد. برای پیش‌فرضِ هر پلن، کنترل‌های enterprise را ببین
forceRemoteSettingsRefresh	وقتی true باشد، راه‌اندازیِ CLI را مسدود می‌کند تا زمانی که تنظیماتِ مدیریت‌شده‌ی راه‌دور به‌تازگی واکشی شوند و اگر واکشی شکست بخورد خارج می‌شود. اعمالِ fail-closed را ببین
pluginTrustMessage	پیامِ سفارشی که به هشدارِ اعتمادِ پلاگین که پیش از نصب نمایش داده می‌شود ضمیمه می‌شود
sandbox.filesystem.allowManagedReadPathsOnly	وقتی true باشد، فقط مسیرهای filesystem.allowRead از تنظیماتِ مدیریت‌شده رعایت می‌شوند. denyRead همچنان از همه‌ی منابع ادغام می‌شود
sandbox.network.allowManagedDomainsOnly	وقتی true باشد، فقط allowedDomains و قواعدِ allowِ WebFetch(domain:...) از تنظیماتِ مدیریت‌شده رعایت می‌شوند. دامنه‌های مجازنشده به‌طور خودکار بدون تأیید از کاربر مسدود می‌شوند. دامنه‌های deny‌شده همچنان از همه‌ی منابع ادغام می‌شوند
strictKnownMarketplaces	کنترل می‌کند که کاربران از کدام منابعِ marketplaceِ پلاگین می‌توانند پلاگین اضافه و نصب کنند. محدودیت‌های marketplaceِ مدیریت‌شده را ببین
strictPluginOnlyCustomization	مهارت‌ها، ایجنت‌ها، هوک‌ها و سرورهای MCP را از منابعِ کاربر و پروژه مسدود می‌کند، پس آن‌ها فقط می‌توانند از پلاگین‌ها یا تنظیماتِ مدیریت‌شده بیایند. true هر چهار سطح را قفل می‌کند؛ آرایه‌ای مثلِ ["skills", "hooks"] فقط آن‌هایی که نام برده شده‌اند را قفل می‌کند. strictPluginOnlyCustomization را ببین
wslInheritsWindowsSettings	وقتی true باشد در کلیدِ رجیستریِ HKLMِ Windows یا C:\Program Files\ClaudeCode\managed-settings.json، WSL تنظیماتِ مدیریت‌شده را علاوه بر /etc/claude-code از زنجیره‌ی سیاستِ Windows می‌خواند. فایل‌های تنظیمات را ببین

disableBypassPermissionsMode معمولاً در تنظیماتِ مدیریت‌شده گذاشته می‌شود تا سیاستِ سازمانی را اعمال کند، اما از هر دامنه‌ای کار می‌کند. یک کاربر می‌تواند آن را در تنظیماتِ خودش بگذارد تا خودش را از حالتِ bypass قفل کند.

یادداشت

در پلن‌های Team و Enterprise، یک مدیر Remote Control و نشست‌های وب را در سطحِ سازمان در تنظیماتِ مدیریتِ Claude Code فعال یا غیرفعال می‌کند. Remote Control علاوه بر این می‌تواند به‌ازای هر دستگاه با تنظیمِ مدیریت‌شده‌ی disableRemoteControl غیرفعال شود. نشست‌های وب کلیدِ تنظیماتِ مدیریت‌شده‌ی به‌ازای دستگاه ندارند.

تقدم تنظیمات

قواعدِ دسترسی از همان تقدمِ تنظیماتِ همه‌ی تنظیماتِ دیگرِ Claude Code پیروی می‌کنند:

1. تنظیماتِ مدیریت‌شده: با هیچ سطحِ دیگری، از جمله آرگومان‌های خطِ فرمان، قابلِ بازنویسی نیستند
2. آرگومان‌های خطِ فرمان: بازنویسی‌های موقتِ نشست
3. تنظیماتِ محلیِ پروژه (.claude/settings.local.json)
4. تنظیماتِ مشترکِ پروژه (.claude/settings.json)
5. تنظیماتِ کاربر (~/.claude/settings.json)

اگر یک ابزار در هر سطحی deny شود، هیچ سطحِ دیگری نمی‌تواند آن را allow کند. برای مثال، یک deniِ تنظیماتِ مدیریت‌شده را نمی‌توان با --allowedTools بازنویسی کرد، و --disallowedTools می‌تواند محدودیت‌هایی فراتر از آنچه تنظیماتِ مدیریت‌شده تعریف می‌کند اضافه کند.

میزبان‌های embedding می‌توانند سیاستِ مدیریت‌شده‌ی اضافی را از طریقِ گزینه‌ی managedSettingsِ SDK فراهم کنند، وقتی parentSettingsBehavior روی "merge" تنظیم شده باشد؛ مقادیرِ embedder می‌توانند سیاست را سخت‌تر کنند اما نه شل‌تر.

برای مثال، اگر تنظیماتِ کاربر یک دسترسی را allow کند و تنظیماتِ پروژه آن را deny کند، قاعده‌ی deny آن را مسدود می‌کند. عکسش هم درست است: یک deniِ در سطحِ کاربر یک allowِ در سطحِ پروژه را مسدود می‌کند، چون قواعدِ deny از هر دامنه‌ای پیش از قواعدِ allow ارزیابی می‌شوند.

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

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

همچنین ببین

• تنظیمات: مرجعِ کاملِ پیکربندی از جمله جدولِ تنظیماتِ دسترسی
• پیکربندیِ حالتِ auto: به دسته‌بندِ حالتِ auto بگو که سازمانت به کدام زیرساخت اعتماد می‌کند
• سندباکس: ایزوله‌سازیِ در سطحِ OSِ فایل‌سیستم و شبکه برای دستورهای Bash
• احراز هویت: راه‌اندازیِ دسترسیِ کاربر به Claude Code
• امنیت: تدابیرِ امنیتی و بهترین شیوه‌ها
• هوک‌ها: خودکارسازیِ ورک‌فلوها و گسترشِ ارزیابیِ دسترسی