---
read_when:
    - پیکربندی سطل‌های امن یا پروفایل‌های سفارشی سطل امن
    - بازارسال تأییدیه‌ها به Slack/Discord/Telegram یا سایر کانال‌های گفت‌وگو
    - پیاده‌سازی یک کلاینت تأیید بومی برای یک کانال
summary: 'تأییدیه‌های پیشرفتهٔ exec: باینری‌های امن، اتصال مفسر، بازفرست تأییدیه، تحویل بومی'
title: تأییدهای اجرا — پیشرفته
x-i18n:
    generated_at: "2026-04-29T23:42:06Z"
    model: gpt-5.5
    provider: openai
    source_hash: de8a72ca1d23e55dc198ae3c5ad55a57660c2111feebfb89f08d8fa9584e4337
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

موضوعات پیشرفتهٔ تأیید exec: مسیر سریع `safeBins`، اتصال مفسر/زمان اجرا، و ارسال تأیید به کانال‌های چت (از جمله تحویل بومی). برای خط‌مشی اصلی و جریان تأیید، [تأییدهای exec](/fa/tools/exec-approvals) را ببینید.

## باینری‌های امن (فقط stdin)

`tools.exec.safeBins` فهرست کوچکی از باینری‌های **فقط stdin** (برای مثال `cut`) را تعریف می‌کند که می‌توانند در حالت فهرست مجاز **بدون** ورودی‌های صریح فهرست مجاز اجرا شوند. باینری‌های امن آرگومان‌های مکانی فایل و توکن‌های شبیه مسیر را رد می‌کنند، بنابراین فقط می‌توانند روی جریان ورودی عمل کنند. این را یک مسیر سریع محدود برای فیلترهای جریان در نظر بگیرید، نه یک فهرست اعتماد عمومی.

<Warning>
باینری‌های مفسر یا زمان اجرا (برای مثال `python3`، `node`، `ruby`، `bash`، `sh`، `zsh`) را به `safeBins` اضافه **نکنید**. اگر یک دستور به‌صورت طراحی‌شده می‌تواند کد را ارزیابی کند، زیردستورها را اجرا کند، یا فایل‌ها را بخواند، ورودی‌های صریح فهرست مجاز را ترجیح دهید و اعلان‌های تأیید را فعال نگه دارید. باینری‌های امن سفارشی باید یک پروفایل صریح در `tools.exec.safeBinProfiles.<bin>` تعریف کنند.
</Warning>

باینری‌های امن پیش‌فرض:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

`grep` و `sort` در فهرست پیش‌فرض نیستند. اگر آن‌ها را فعال می‌کنید، برای گردش‌کارهای غیر stdin آن‌ها ورودی‌های صریح فهرست مجاز را نگه دارید. برای `grep` در حالت باینری امن، الگو را با `-e`/`--regexp` ارائه کنید؛ شکل الگوی مکانی رد می‌شود تا عملوندهای فایل نتوانند به‌صورت آرگومان‌های مکانی مبهم پنهان شوند.

### اعتبارسنجی argv و پرچم‌های ردشده

اعتبارسنجی فقط از شکل argv قطعی است (بدون بررسی وجود فایل در فایل‌سیستم میزبان)، که از رفتار اوراکل وجود فایل ناشی از تفاوت‌های مجاز/رد جلوگیری می‌کند. گزینه‌های فایل‌محور برای باینری‌های امن پیش‌فرض رد می‌شوند؛ گزینه‌های بلند به‌صورت fail-closed اعتبارسنجی می‌شوند (پرچم‌های ناشناخته و اختصارهای مبهم رد می‌شوند).

پرچم‌های ردشده بر اساس پروفایل باینری امن:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

- `grep`: `--dereference-recursive`, `--directories`, `--exclude-from`, `--file`, `--recursive`, `-R`, `-d`, `-f`, `-r`
- `jq`: `--argfile`, `--from-file`, `--library-path`, `--rawfile`, `--slurpfile`, `-L`, `-f`
- `sort`: `--compress-program`, `--files0-from`, `--output`, `--random-source`, `--temporary-directory`, `-T`, `-o`
- `wc`: `--files0-from`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

باینری‌های امن همچنین در زمان اجرا توکن‌های argv را برای بخش‌های فقط stdin مجبور می‌کنند به‌عنوان **متن لفظی** رفتار شوند (بدون globbing و بدون گسترش `$VARS`)، بنابراین الگوهایی مانند `*` یا `$HOME/...` نمی‌توانند برای پنهان‌کردن خواندن فایل استفاده شوند.

### دایرکتوری‌های باینری مورد اعتماد

باینری‌های امن باید از دایرکتوری‌های باینری مورد اعتماد resolve شوند (پیش‌فرض‌های سیستم به‌علاوهٔ `tools.exec.safeBinTrustedDirs` اختیاری). ورودی‌های `PATH` هرگز به‌صورت خودکار مورد اعتماد قرار نمی‌گیرند. دایرکتوری‌های مورد اعتماد پیش‌فرض عمداً حداقلی هستند: `/bin`، `/usr/bin`. اگر فایل اجرایی باینری امن شما در مسیرهای مدیر بسته/کاربر قرار دارد (برای مثال `/opt/homebrew/bin`، `/usr/local/bin`، `/opt/local/bin`، `/snap/bin`)، آن‌ها را صریحاً به `tools.exec.safeBinTrustedDirs` اضافه کنید.

### زنجیره‌سازی shell، wrapperها و multiplexerها

زنجیره‌سازی shell (`&&`، `||`، `;`) زمانی مجاز است که هر بخش سطح بالا فهرست مجاز را برآورده کند (از جمله باینری‌های امن یا اجازهٔ خودکار skill). Redirectionها در حالت فهرست مجاز همچنان پشتیبانی نمی‌شوند. جایگزینی دستور (`$()` / backticks) هنگام parsing فهرست مجاز رد می‌شود، از جمله داخل کوتیشن‌های دوتایی؛ اگر به متن لفظی `$()` نیاز دارید از کوتیشن‌های تکی استفاده کنید.

در تأییدهای اپ همراه macOS، متن خام shell که شامل نحو کنترل یا گسترش shell باشد (`&&`، `||`، `;`، `|`، `` ` ``، `$`، `<`، `>`، `(`، `)`) به‌عنوان عدم تطابق با فهرست مجاز تلقی می‌شود، مگر اینکه خود باینری shell در فهرست مجاز باشد.

برای wrapperهای shell (`bash|sh|zsh ... -c/-lc`)، overrideهای env در محدودهٔ درخواست به یک فهرست مجاز صریح کوچک کاهش می‌یابند (`TERM`، `LANG`، `LC_*`، `COLORTERM`، `NO_COLOR`، `FORCE_COLOR`).

برای تصمیم‌های `allow-always` در حالت فهرست مجاز، wrapperهای dispatch شناخته‌شده (`env`، `nice`، `nohup`، `stdbuf`، `timeout`) به‌جای مسیر wrapper، مسیر فایل اجرایی داخلی را پایدار می‌کنند. Multiplexerهای shell (`busybox`، `toybox`) برای appletهای shell (`sh`، `ash`، و غیره) به همین روش باز می‌شوند. اگر یک wrapper یا multiplexer را نتوان ایمن باز کرد، هیچ ورودی فهرست مجازی به‌صورت خودکار پایدار نمی‌شود.

اگر مفسرهایی مانند `python3` یا `node` را در فهرست مجاز قرار می‌دهید، `tools.exec.strictInlineEval=true` را ترجیح دهید تا eval درون‌خطی همچنان به تأیید صریح نیاز داشته باشد. در حالت strict، `allow-always` همچنان می‌تواند فراخوانی‌های بی‌خطر مفسر/اسکریپت را پایدار کند، اما حامل‌های inline-eval به‌صورت خودکار پایدار نمی‌شوند.

### باینری‌های امن در برابر فهرست مجاز

| موضوع | `tools.exec.safeBins` | فهرست مجاز (`exec-approvals.json`) |
| ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| هدف | اجازهٔ خودکار به فیلترهای محدود stdin | اعتماد صریح به فایل‌های اجرایی مشخص |
| نوع تطابق | نام فایل اجرایی + خط‌مشی argv باینری امن | glob مسیر فایل اجرایی resolveشده، یا glob نام دستور خام برای دستورهای فراخوانی‌شده از PATH |
| دامنهٔ آرگومان | محدودشده با پروفایل باینری امن و قواعد توکن لفظی | فقط تطابق مسیر؛ آرگومان‌ها در غیر این صورت مسئولیت شما هستند |
| مثال‌های معمول | `head`، `tail`، `tr`، `wc` | `jq`، `python3`، `node`، `ffmpeg`، CLIهای سفارشی |
| بهترین کاربرد | تبدیل‌های متنی کم‌ریسک در pipelineها | هر ابزاری با رفتار گسترده‌تر یا اثرات جانبی |

محل پیکربندی:

- `safeBins` از config می‌آید (`tools.exec.safeBins` یا `agents.list[].tools.exec.safeBins` برای هر عامل).
- `safeBinTrustedDirs` از config می‌آید (`tools.exec.safeBinTrustedDirs` یا `agents.list[].tools.exec.safeBinTrustedDirs` برای هر عامل).
- `safeBinProfiles` از config می‌آید (`tools.exec.safeBinProfiles` یا `agents.list[].tools.exec.safeBinProfiles` برای هر عامل). کلیدهای پروفایل هر عامل کلیدهای سراسری را override می‌کنند.
- ورودی‌های فهرست مجاز در `~/.openclaw/exec-approvals.json` محلی میزبان، زیر `agents.<id>.allowlist` قرار دارند (یا از طریق Control UI / `openclaw approvals allowlist ...`).
- `openclaw security audit` وقتی باینری‌های مفسر/زمان اجرا بدون پروفایل صریح در `safeBins` ظاهر شوند، با `tools.exec.safe_bins_interpreter_unprofiled` هشدار می‌دهد.
- `openclaw doctor --fix` می‌تواند ورودی‌های سفارشیِ از دست‌رفتهٔ `safeBinProfiles.<bin>` را به‌صورت `{}` scaffold کند (بعداً بازبینی و سخت‌گیرانه‌تر کنید). باینری‌های مفسر/زمان اجرا به‌صورت خودکار scaffold نمی‌شوند.

مثال پروفایل سفارشی:
__OC_I18N_900000__
اگر `jq` را صریحاً در `safeBins` فعال کنید، OpenClaw همچنان builtin به نام `env` را در حالت باینری امن رد می‌کند، تا `jq -n env` نتواند محیط فرایند میزبان را بدون مسیر فهرست مجاز صریح یا اعلان تأیید dump کند.

## دستورهای مفسر/زمان اجرا

اجراهای مفسر/زمان اجرا که با تأیید پشتیبانی می‌شوند عمداً محافظه‌کارانه هستند:

- زمینهٔ دقیق argv/cwd/env همیشه متصل می‌شود.
- شکل‌های مستقیم اسکریپت shell و فایل مستقیم زمان اجرا، به‌صورت best-effort به یک snapshot مشخص از یک فایل محلی متصل می‌شوند.
- شکل‌های رایج wrapper مدیر بسته که همچنان به یک فایل محلی مستقیم resolve می‌شوند (برای مثال `pnpm exec`، `pnpm node`، `npm exec`، `npx`) پیش از اتصال باز می‌شوند.
- اگر OpenClaw نتواند دقیقاً یک فایل محلی مشخص را برای یک دستور مفسر/زمان اجرا شناسایی کند (برای مثال اسکریپت‌های بسته، شکل‌های eval، زنجیره‌های loader ویژهٔ زمان اجرا، یا شکل‌های مبهم چندفایلی)، اجرای مبتنی بر تأیید به‌جای ادعای پوشش معنایی‌ای که ندارد، رد می‌شود.
- برای این گردش‌کارها، sandboxing، یک مرز میزبان جداگانه، یا یک فهرست مجاز/گردش‌کار کامل و صریح مورد اعتماد را ترجیح دهید که در آن اپراتور معناشناسی گسترده‌تر زمان اجرا را می‌پذیرد.

وقتی تأیید لازم باشد، ابزار exec بلافاصله با یک شناسهٔ تأیید برمی‌گردد. از آن شناسه برای هم‌بستگی رویدادهای بعدی سیستم (`Exec finished` / `Exec denied`) استفاده کنید. اگر پیش از timeout تصمیمی نرسد، درخواست به‌عنوان timeout تأیید تلقی می‌شود و به‌صورت دلیل رد نمایش داده می‌شود.

### رفتار تحویل پیگیری

پس از پایان یک exec ناهمگام تأییدشده، OpenClaw یک نوبت پیگیری `agent` به همان session می‌فرستد.

- اگر یک هدف تحویل خارجی معتبر وجود داشته باشد (کانال قابل‌تحویل به‌علاوهٔ هدف `to`)، تحویل پیگیری از همان کانال استفاده می‌کند.
- در جریان‌های فقط webchat یا session داخلی بدون هدف خارجی، تحویل پیگیری فقط در session باقی می‌ماند (`deliver: false`).
- اگر فراخوان صریحاً تحویل خارجی strict را بدون کانال خارجی قابل resolve درخواست کند، درخواست با `INVALID_REQUEST` شکست می‌خورد.
- اگر `bestEffortDeliver` فعال باشد و هیچ کانال خارجی قابل resolve نباشد، تحویل به‌جای شکست، به حالت فقط session کاهش می‌یابد.

## ارسال تأیید به کانال‌های چت

می‌توانید اعلان‌های تأیید exec را به هر کانال چت (از جمله کانال‌های Plugin) ارسال کنید و آن‌ها را با `/approve` تأیید کنید. این از pipeline معمول تحویل خروجی استفاده می‌کند.

Config:
__OC_I18N_900001__
پاسخ در چت:
__OC_I18N_900002__
دستور `/approve` هم تأییدهای exec و هم تأییدهای Plugin را مدیریت می‌کند. اگر ID با هیچ تأیید exec در انتظار مطابقت نداشته باشد، به‌صورت خودکار به‌جای آن تأییدهای Plugin را بررسی می‌کند.

### ارسال تأیید Plugin

ارسال تأیید Plugin از همان pipeline تحویلِ تأییدهای exec استفاده می‌کند، اما config مستقل خودش را زیر `approvals.plugin` دارد. فعال یا غیرفعال کردن یکی روی دیگری اثر نمی‌گذارد.
__OC_I18N_900003__
شکل config با `approvals.exec` یکسان است: `enabled`، `mode`، `agentFilter`، `sessionFilter`، و `targets` به همان روش کار می‌کنند.

کانال‌هایی که از پاسخ‌های تعاملی مشترک پشتیبانی می‌کنند، همان دکمه‌های تأیید را برای هر دو نوع تأیید exec و Plugin نمایش می‌دهند. کانال‌های بدون UI تعاملی مشترک، به متن ساده با دستورالعمل‌های `/approve` fallback می‌کنند.

### تأییدهای همان چت در هر کانال

وقتی یک درخواست تأیید exec یا Plugin از یک سطح چت قابل‌تحویل منشأ بگیرد، همان چت اکنون می‌تواند به‌صورت پیش‌فرض آن را با `/approve` تأیید کند. این علاوه بر جریان‌های موجود Web UI و terminal UI، برای کانال‌هایی مانند Slack، Matrix، و Microsoft Teams نیز اعمال می‌شود.

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

Discord و Telegram نیز از `/approve` در همان چت پشتیبانی می‌کنند، اما این کانال‌ها حتی وقتی تحویل تأیید بومی غیرفعال باشد، همچنان از فهرست تأییدکنندگان resolveشدهٔ خود برای مجوزدهی استفاده می‌کنند.

برای Telegram و دیگر کلاینت‌های تأیید بومی که مستقیماً Gateway را فراخوانی می‌کنند، این fallback عمداً به شکست‌های «تأیید پیدا نشد» محدود است. یک رد/خطای واقعی تأیید exec بی‌صدا به‌عنوان تأیید Plugin دوباره امتحان نمی‌شود.

### تحویل تأیید بومی

برخی کانال‌ها همچنین می‌توانند به‌عنوان کلاینت‌های تأیید بومی عمل کنند. کلاینت‌های بومی، DMهای تأییدکننده، fanout چت مبدأ، و تجربهٔ کاربری تأیید تعاملی ویژهٔ کانال را روی جریان مشترک `/approve` در همان چت اضافه می‌کنند.

وقتی کارت‌ها/دکمه‌های تأیید بومی در دسترس باشند، آن رابط کاربری بومی مسیر اصلی
روبه‌روی agent است. agent نباید هم‌زمان یک فرمان ساده و تکراری `/approve`
را در چت بازتاب دهد، مگر اینکه نتیجهٔ ابزار بگوید تأییدهای چتی در دسترس نیستند یا
تأیید دستی تنها مسیر باقی‌مانده است.

اگر یک کلاینت تأیید بومی پیکربندی شده باشد اما هیچ runtime بومی برای
کانال مبدأ فعال نباشد، OpenClaw اعلان تعیین‌پذیر محلی `/approve`
را قابل‌مشاهده نگه می‌دارد. اگر runtime بومی فعال باشد و تحویل را امتحان کند اما هیچ
مقصدی کارت را دریافت نکند، OpenClaw یک اعلان fallback در همان چت با
فرمان دقیق `/approve <id> <decision>` می‌فرستد تا درخواست همچنان قابل حل باشد.

مدل عمومی:

- سیاست exec میزبان همچنان تصمیم می‌گیرد که آیا تأیید exec لازم است یا نه
- `approvals.exec` ارسال اعلان‌های تأیید به مقصدهای چت دیگر را کنترل می‌کند
- `channels.<channel>.execApprovals` کنترل می‌کند که آیا آن کانال به‌عنوان کلاینت تأیید بومی عمل کند یا نه

کلاینت‌های تأیید بومی وقتی همهٔ این موارد درست باشند، تحویل DM-first را به‌صورت خودکار فعال می‌کنند:

- کانال از تحویل تأیید بومی پشتیبانی می‌کند
- تأییدکنندگان می‌توانند از `execApprovals.approvers` صریح یا هویت مالک
  مانند `commands.ownerAllowFrom` تعیین شوند
- `channels.<channel>.execApprovals.enabled` تنظیم نشده یا `"auto"` است

برای غیرفعال‌کردن صریح یک کلاینت تأیید بومی، `enabled: false` را تنظیم کنید. برای اجبار
به فعال‌بودن آن وقتی تأییدکنندگان تعیین می‌شوند، `enabled: true` را تنظیم کنید. تحویل عمومی در چت مبدأ از طریق
`channels.<channel>.execApprovals.target` صریح باقی می‌ماند.

پرسش‌های متداول: [چرا برای تأییدهای چتی دو پیکربندی تأیید exec وجود دارد؟](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)

- Discord: `channels.discord.execApprovals.*`
- Slack: `channels.slack.execApprovals.*`
- Telegram: `channels.telegram.execApprovals.*`

این کلاینت‌های تأیید بومی، مسیریابی DM و fanout اختیاری کانال را روی جریان مشترک
`/approve` در همان چت و دکمه‌های تأیید مشترک اضافه می‌کنند.

رفتار مشترک:

- Slack، Matrix، Microsoft Teams، و چت‌های قابل‌تحویل مشابه از مدل auth عادی کانال
  برای `/approve` در همان چت استفاده می‌کنند
- وقتی یک کلاینت تأیید بومی به‌صورت خودکار فعال می‌شود، مقصد پیش‌فرض تحویل بومی DMهای تأییدکنندگان است
- برای Discord و Telegram، فقط تأییدکنندگان تعیین‌شده می‌توانند تأیید یا رد کنند
- تأییدکنندگان Discord می‌توانند صریح باشند (`execApprovals.approvers`) یا از `commands.ownerAllowFrom` استنباط شوند
- تأییدکنندگان Telegram می‌توانند صریح باشند (`execApprovals.approvers`) یا از `commands.ownerAllowFrom` استنباط شوند
- تأییدکنندگان Slack می‌توانند صریح باشند (`execApprovals.approvers`) یا از `commands.ownerAllowFrom` استنباط شوند
- دکمه‌های بومی Slack نوع شناسهٔ تأیید را حفظ می‌کنند، بنابراین شناسه‌های `plugin:` می‌توانند تأییدهای Plugin را
  بدون یک لایهٔ fallback محلیِ دوم در Slack حل کنند
- مسیریابی DM/کانال بومی Matrix و میانبرهای واکنشی، هم تأییدهای exec و هم تأییدهای Plugin را مدیریت می‌کنند؛
  مجوزدهی Plugin همچنان از `channels.matrix.dm.allowFrom` می‌آید
- اعلان‌های بومی Matrix محتوای رویداد سفارشی `com.openclaw.approval` را در نخستین رویداد اعلان شامل می‌شوند
  تا کلاینت‌های Matrix آگاه از OpenClaw بتوانند وضعیت ساختاریافتهٔ تأیید را بخوانند، در حالی که کلاینت‌های معمولی
  fallback متنی سادهٔ `/approve` را نگه می‌دارند
- درخواست‌کننده لازم نیست تأییدکننده باشد
- چت مبدأ وقتی از قبل از فرمان‌ها و پاسخ‌ها پشتیبانی می‌کند، می‌تواند مستقیماً با `/approve` تأیید کند
- دکمه‌های تأیید بومی Discord بر اساس نوع شناسهٔ تأیید مسیریابی می‌کنند: شناسه‌های `plugin:`
  مستقیم به تأییدهای Plugin می‌روند، و هر چیز دیگر به تأییدهای exec می‌رود
- دکمه‌های تأیید بومی Telegram همان fallback محدودشدهٔ exec به Plugin را مانند `/approve` دنبال می‌کنند
- وقتی `target` بومی تحویل در چت مبدأ را فعال می‌کند، اعلان‌های تأیید متن فرمان را شامل می‌شوند
- تأییدهای exec در انتظار، به‌طور پیش‌فرض پس از ۳۰ دقیقه منقضی می‌شوند
- اگر هیچ رابط کاربری اپراتور یا کلاینت تأیید پیکربندی‌شده‌ای نتواند درخواست را بپذیرد، اعلان به `askFallback` برمی‌گردد

فرمان‌های حساس گروهی فقط برای مالک مانند `/diagnostics` و `/export-trajectory` از مسیریابی خصوصی
مالک برای اعلان‌های تأیید و نتایج نهایی استفاده می‌کنند. OpenClaw ابتدا یک مسیر خصوصی را روی همان
سطحی که مالک فرمان را اجرا کرده امتحان می‌کند. اگر آن سطح مسیر خصوصی مالک نداشته باشد، به
نخستین مسیر مالکِ در دسترس از `commands.ownerAllowFrom` برمی‌گردد، بنابراین یک فرمان گروهی Discord
همچنان می‌تواند وقتی Telegram رابط خصوصی اصلی پیکربندی‌شده است، تأیید و نتیجه را به DM مالک در Telegram بفرستد.
چت گروهی فقط یک تأیید کوتاه دریافت می‌کند.

Telegram به‌طور پیش‌فرض از DMهای تأییدکنندگان استفاده می‌کند (`target: "dm"`). وقتی می‌خواهید
اعلان‌های تأیید در چت/موضوع Telegram مبدأ هم ظاهر شوند، می‌توانید آن را به `channel` یا `both` تغییر دهید.
برای موضوعات انجمنی Telegram، OpenClaw موضوع را برای اعلان تأیید و پیگیری پس از تأیید حفظ می‌کند.

ببینید:

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)

### جریان IPC در macOS
__OC_I18N_900004__
نکات امنیتی:

- حالت Unix socket برابر `0600` است، token در `exec-approvals.json` ذخیره می‌شود.
- بررسی peer با همان UID.
- Challenge/response (nonce + HMAC token + request hash) + TTL کوتاه.

## مرتبط

- [تأییدهای Exec](/fa/tools/exec-approvals) — سیاست اصلی و جریان تأیید
- [ابزار Exec](/fa/tools/exec)
- [حالت Elevated](/fa/tools/elevated)
- [Skills](/fa/tools/skills) — رفتار اجازه‌دهی خودکار مبتنی بر skill
