---
read_when:
    - پیکربندی باینری‌های امن یا پروفایل‌های سفارشی باینری امن
    - ارسال تأییدها به Slack/Discord/Telegram یا دیگر کانال‌های گفت‌وگو
    - پیاده‌سازی یک کلاینت بومی تأیید برای یک کانال
summary: 'تأییدهای پیشرفتهٔ اجرا: باینری‌های امن، اتصال مفسر، ارسال تأیید و تحویل بومی'
title: تأییدهای اجرا — پیشرفته
x-i18n:
    generated_at: "2026-07-16T17:36:41Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 99f123c7663378cc30ff9b6498c5cbc18ce9f20e9ac769755bab23af69ef1c7d
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

موضوعات پیشرفتهٔ تأیید اجرای فرمان: مسیر سریع `safeBins`، مقیدسازی مفسر/محیط اجرا
و ارسال تأییدیه به کانال‌های گفتگو (از جمله تحویل بومی).
برای خط‌مشی اصلی و جریان تأیید، به [تأییدهای اجرا](/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 قطعی است (بدون بررسی وجود فایل در سامانهٔ فایل
میزبان) و این امر از رفتار افشاگر وجود فایل ناشی از تفاوت‌های مجاز/ممنوع
جلوگیری می‌کند. گزینه‌های فایل‌محور برای باینری‌های امن پیش‌فرض ممنوع‌اند؛ گزینه‌های
بلند به‌صورت بسته در برابر خطا اعتبارسنجی می‌شوند (پرچم‌های ناشناخته و اختصارهای مبهم
رد می‌شوند). پرچم‌های بولی فقط‌خواندنی شناخته‌شدهٔ باینری‌های پیش‌فرض (برای مثال
`wc -l`، `tr -d`، `uniq -c`) پذیرفته می‌شوند، درحالی‌که پرچم‌های کوتاه ناشناخته
همچنان به‌صورت بسته در برابر خطا عمل می‌کنند و به تأیید دستی واگذار می‌شوند.

پرچم‌های ممنوع بر اساس نمایهٔ باینری امن:

[//]: # "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`
- `tail`: `--follow`، `--retry`، `-F`، `-f`
- `wc`: `--files0-from`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

باینری‌های امن همچنین توکن‌های argv را وادار می‌کنند هنگام اجرا برای بخش‌های فقط stdin
به‌عنوان **متن تحت‌اللفظی** در نظر گرفته شوند (بدون بسط نویسه‌های عام و بدون بسط `$VARS`)؛ بنابراین
الگوهایی مانند `*` یا `$HOME/...` نمی‌توانند برای پنهان‌سازی خواندن فایل به کار روند. `awk`،
`sed` و `jq` همیشه به‌عنوان باینری امن ممنوع‌اند، زیرا معنای آن‌ها را نمی‌توان
به فقط stdin محدود و اعتبارسنجی کرد: `jq` می‌تواند داده‌های محیط را بخواند و کد jq را از
ماژول‌ها یا فایل‌های راه‌اندازی بارگذاری کند. برای این ابزارها به‌جای `safeBins` از یک ورودی صریح
فهرست مجاز یا اعلان تأیید استفاده کنید.

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

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

### زنجیره‌سازی پوسته، پوشاننده‌ها و چندراهه‌سازها

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

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

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

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

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

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

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

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

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

نمونهٔ نمایهٔ سفارشی:

```json5
{
  tools: {
    exec: {
      safeBins: ["myfilter"],
      safeBinProfiles: {
        myfilter: {
          minPositional: 0,
          maxPositional: 0,
          allowedValueFlags: ["-n", "--limit"],
          deniedFlags: ["-f", "--file", "-c", "--command"],
        },
      },
    },
  },
}
```

## فرمان‌های مفسر/محیط اجرا

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

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

وقتی تأیید لازم باشد، ابزار اجرا بلافاصله یک شناسهٔ تأیید برمی‌گرداند. از آن شناسه برای
هم‌بسته‌سازی رویدادهای سیستمی بعدی اجرای تأییدشده (`Exec finished` و در صورت پیکربندی، `Exec running`) استفاده کنید.
اگر پیش از پایان مهلت تصمیمی دریافت نشود، درخواست به‌عنوان پایان مهلت تأیید در نظر گرفته می‌شود و
به‌صورت رد نهایی فرمان میزبان نمایش داده می‌شود. برای تأییدهای ناهمگام عامل اصلی که نشست مبدأ دارند،
OpenClaw همچنین آن نشست را با یک پیگیری داخلی از سر می‌گیرد تا عامل متوجه شود که
فرمان اجرا نشده است، به‌جای آنکه بعداً نتیجهٔ مفقود را ترمیم کند. تأییدهای اجرای در انتظار
به‌طور پیش‌فرض پس از 30 دقیقه منقضی می‌شوند.

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

پس از پایان اجرای ناهمگام تأییدشده، OpenClaw یک نوبت پیگیری `agent` به همان نشست ارسال می‌کند.
تأییدهای ناهمگام ردشده از همان مسیر پیگیری نشست اصلی برای وضعیت رد استفاده می‌کنند، اما
واگذاری‌های محیط اجرای ارتقایافته را ثبت نمی‌کنند و فرمان را اجرا نمی‌کنند. ردهایی که نشست اصلی
قابل ازسرگیری ندارند، یا سرکوب می‌شوند یا در صورت وجود یک مسیر مستقیم امن از طریق آن گزارش می‌شوند.

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

## ارسال تأیید به کانال‌های گفتگو

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

پیکربندی:

```json5
{
  approvals: {
    exec: {
      enabled: true,
      mode: "session", // "session" | "targets" | "both"
      agentFilter: ["main"],
      sessionFilter: ["discord"], // substring or regex
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}
```

پاسخ در گفتگو:

```
/approve <id> allow-once
/approve <id> allow-always
/approve <id> deny
```

دستور `/approve` هم تأییدهای exec و هم تأییدهای Plugin را مدیریت می‌کند. اگر شناسه با یک تأیید exec در انتظار مطابقت نداشته باشد، به‌طور خودکار تأییدهای Plugin را بررسی می‌کند. این مسیر جایگزین فقط به خطاهای «تأیید یافت نشد» محدود است؛ رد شدن یا خطای واقعی تأیید exec، بی‌سروصدا به‌عنوان تأیید Plugin دوباره امتحان نمی‌شود.

### هدایت تأیید Plugin

هدایت تأیید Plugin از همان خط لولهٔ تحویل تأییدهای exec استفاده می‌کند، اما پیکربندی مستقل
خود را در `approvals.plugin` دارد. فعال یا غیرفعال کردن یکی بر دیگری تأثیری ندارد.
برای رفتار مربوط به ساخت Plugin، فیلدهای درخواست و معناشناسی تصمیم، به
[درخواست‌های مجوز Plugin](/plugins/plugin-permission-requests) مراجعه کنید.

```json5
{
  approvals: {
    plugin: {
      enabled: true,
      mode: "targets",
      agentFilter: ["main"],
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}
```

ساختار پیکربندی با `approvals.exec` یکسان است: `enabled`، `mode`، `agentFilter`،
`sessionFilter` و `targets` به همان شیوه کار می‌کنند.

کانال‌هایی که از پاسخ‌های تعاملی مشترک پشتیبانی می‌کنند، دکمه‌های تأیید یکسانی را هم برای تأییدهای exec و هم
برای تأییدهای Plugin نمایش می‌دهند. کانال‌های فاقد رابط کاربری تعاملی مشترک، به متن ساده همراه با دستورالعمل‌های
`/approve` برمی‌گردند. درخواست‌های تأیید Plugin ممکن است تصمیم‌های در دسترس را محدود کنند: سطوح تأیید از
مجموعه‌تصمیم اعلام‌شده در درخواست استفاده می‌کنند و Gateway تلاش برای ارسال تصمیمی را که
ارائه نشده است، رد می‌کند.

### تأیید در همان گفت‌وگو در هر کانال

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

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

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

برخی کانال‌ها می‌توانند به‌عنوان کارخواه بومی تأیید نیز عمل کنند: Discord، Slack، Telegram، Matrix و ربات QQ.
کارخواه‌های بومی، پیام‌های خصوصی به تأییدکنندگان، توزیع به گفت‌وگوی مبدأ و تجربهٔ کاربری تعاملی تأیید ویژهٔ کانال را
بر فراز جریان مشترک `/approve` در همان گفت‌وگو اضافه می‌کنند.

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

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

مدل عمومی:

- سیاست exec میزبان همچنان تعیین می‌کند که آیا تأیید exec لازم است
- `approvals.exec` هدایت اعلان‌های تأیید به مقصدهای گفت‌وگوی دیگر را کنترل می‌کند
- `channels.<channel>.execApprovals` کنترل می‌کند که آیا کارخواه‌های بومی ویژهٔ کانال برای Discord، Slack، Telegram، ربات QQ و موارد مشابه
  فعال باشند
- تأییدهای Plugin در Slack می‌توانند هنگامی که درخواست از Slack می‌آید
  و تأییدکنندگان Plugin در Slack تعیین می‌شوند، از کارخواه بومی تأیید Slack استفاده کنند؛ `approvals.plugin` همچنین می‌تواند تأییدهای Plugin را حتی زمانی که تأییدهای exec در Slack غیرفعال‌اند، به نشست‌ها یا مقصدهای Slack هدایت کند
- کارت‌های بومی تأیید Google Chat، تأییدهای exec و Plugin را که از فضاها یا رشته‌های Google
  Chat سرچشمه می‌گیرند، هنگامی مدیریت می‌کنند که تأییدکنندگان پایدار `users/<id>` از `dm.allowFrom` یا
  `defaultTo` تعیین شوند؛ آن‌ها برای تصمیم‌ها از رویدادهای واکنش استفاده نمی‌کنند
- تحویل تأیید واکنشی WhatsApp و Signal به `approvals.exec` و
  `approvals.plugin` وابسته است؛ آن‌ها بلوک‌های `channels.<channel>.execApprovals` ندارند

کارخواه‌های بومی هنگامی که همهٔ شرایط زیر برقرار باشند، تحویل با اولویت پیام خصوصی را به‌طور خودکار فعال می‌کنند:

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

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

پرسش‌های متداول: [چرا برای تأییدهای گفت‌وگویی دو پیکربندی تأیید exec وجود دارد؟](/help/faq-first-run)

- Discord: `channels.discord.execApprovals.*`
- Slack: `channels.slack.execApprovals.*`
- Telegram: `channels.telegram.execApprovals.*`
- ربات QQ: `channels.qqbot.execApprovals.*`
- Google Chat: تأییدکنندگان پایدار را با `channels.googlechat.dm.allowFrom` یا
  `channels.googlechat.defaultTo` پیکربندی کنید؛ هیچ بلوک `execApprovals` لازم نیست
- WhatsApp: برای هدایت اعلان‌های تأیید به WhatsApp از `approvals.exec` و `approvals.plugin` استفاده کنید
- Signal: برای هدایت اعلان‌های تأیید به Signal از `approvals.exec` و `approvals.plugin` استفاده کنید

مسیریابی ویژهٔ کارخواه بومی:

- Telegram به‌طور پیش‌فرض از پیام خصوصی تأییدکنندگان (`target: "dm"`) استفاده می‌کند. برای نمایش اعلان‌های تأیید در گفت‌وگو یا موضوع مبدأ
  Telegram نیز، به `channel` یا `both` تغییر دهید. برای موضوعات انجمن Telegram، OpenClaw
  موضوع را برای اعلان تأیید و پیگیری پس از تأیید حفظ می‌کند.
- تأییدکنندگان Discord و Telegram می‌توانند صریح (`execApprovals.approvers`) باشند یا از
  `commands.ownerAllowFrom` استنباط شوند؛ فقط تأییدکنندگان تعیین‌شده می‌توانند تأیید یا رد کنند.
- تأییدکنندگان Slack می‌توانند صریح (`execApprovals.approvers`) باشند یا از
  `commands.ownerAllowFrom` استنباط شوند. پیام‌های خصوصی تأیید Plugin در Slack از تأییدکنندگان Plugin در Slack از `allowFrom`
  و مسیریابی پیش‌فرض حساب استفاده می‌کنند، نه تأییدکنندگان exec در Slack. دکمه‌های بومی Slack نوع شناسهٔ تأیید را حفظ می‌کنند،
  بنابراین شناسه‌های `plugin:` می‌توانند تأییدهای Plugin را بدون لایهٔ جایگزین محلی دوم در Slack حل‌وفصل کنند.
- کارت‌های بومی Google Chat مسیر جایگزین دستی `/approve` را در متن پیام حفظ می‌کنند، اما فراخوان‌های
  دکمهٔ کارت فقط توکن‌های کنش مبهم را حمل می‌کنند؛ شناسهٔ تأیید و تصمیم از
  وضعیت در انتظار سمت سرور بازیابی می‌شوند.
- تأییدهای ایموجی WhatsApp هم اعلان‌های exec و هم Plugin را هنگامی مدیریت می‌کنند که خانوادهٔ هدایت سطح‌بالای متناظر
  به WhatsApp مسیریابی شود. اعلان‌های دارای مبدأ بومی مستقیماً متصل می‌شوند؛ تحویل مشترک در حالت مقصد
  همان فرادادهٔ نوع‌دار تأیید را به رسید پذیرفته‌شدهٔ پیام WhatsApp متصل می‌کند.
- تأییدهای واکنشی Signal فقط هنگامی هم اعلان‌های exec و هم Plugin را مدیریت می‌کنند که خانوادهٔ هدایت سطح‌بالای متناظر
  فعال باشد و به Signal مسیریابی شود. تأییدهای مستقیم exec در همان گفت‌وگوی Signal می‌توانند
  مسیر جایگزین محلی `/approve` را بدون تأییدکنندگان صریح سرکوب کنند؛ حل‌وفصل واکنش Signal
  همچنان به تأییدکنندگان صریح Signal از `channels.signal.allowFrom` یا `defaultTo` نیاز دارد.
- مسیریابی بومی پیام خصوصی/کانال Matrix و میان‌برهای واکنشی، هم تأییدهای exec و هم Plugin را مدیریت می‌کنند؛
  مجوزدهی Plugin همچنان از `channels.matrix.dm.allowFrom` می‌آید. اعلان‌های بومی Matrix
  محتوای رویداد سفارشی `com.openclaw.approval` را در نخستین رویداد اعلان شامل می‌شوند تا کارخواه‌های
  Matrix سازگار با OpenClaw بتوانند وضعیت ساخت‌یافتهٔ تأیید را بخوانند، درحالی‌که کارخواه‌های استاندارد مسیر جایگزین متنی سادهٔ
  `/approve` را حفظ می‌کنند.
- دکمه‌های بومی تأیید Discord و Telegram، نوع صریح مالک exec یا Plugin را در
  دادهٔ فراخوان خصوصی حمل‌ونقل حمل می‌کنند و فقط همان مالک را حل‌وفصل می‌کنند. کنترل‌های قدیمی‌تر `/approve` که
  فاقد نوع هستند، یک مسیر سازگاری محدود باقی می‌مانند: آن‌ها فقط انواع مالکی را امتحان می‌کنند که کنشگر مجاز به تأییدشان است،
  فقط پس از نتیجهٔ «تأیید یافت نشد» ادامه می‌دهند و هرگز مالکیت را از شناسهٔ تأیید استنباط نمی‌کنند.
- درخواست‌کننده لازم نیست تأییدکننده باشد.
- اگر هیچ رابط کاربری اپراتور یا کارخواه تأیید پیکربندی‌شده‌ای نتواند درخواست را بپذیرد، اعلان به
  `askFallback` برمی‌گردد.

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

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

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)
- [ربات QQ](/channels/qqbot)

### برنامه‌های رسمی اپراتور موبایل

برنامه‌های رسمی iOS و Android نیز می‌توانند تأییدهای exec در انتظار متعلق به Gateway را
هنگام استفاده از اتصال `operator.admin`، یا هنگامی که دستگاه جفت‌شدهٔ
`operator.approvals` آن‌ها به‌طور صریح هدف درخواست قرار گرفته است، بررسی کنند. آن‌ها
همان رکورد ماندگار و پاک‌سازی‌شدهٔ مورد استفادهٔ
رابط کاربری کنترل را می‌خوانند، تصمیمی آگاه از نوع ارسال می‌کنند و نتیجهٔ مرجع
نخستین پاسخ Gateway را نمایش می‌دهند. Apple Watch این اعلان‌های تأیید را از طریق
iPhone جفت‌شده بازتاب می‌دهد و کنش‌های یک‌بار اجازه دادن و رد کردن را ارائه می‌کند. حالت مستقیم Gateway در Watch
تأییدها را بررسی نمی‌کند.

از دست رفتن اعلام وصول حل‌وفصل، انتخاب ارسال‌شده را معتبر نمی‌کند:
برنامه کنترل‌ها را غیرفعال می‌کند و رکورد را دوباره می‌خواند. اگر سطح دیگری
برنده شده باشد، برنامه همان تصمیم ثبت‌شده را نمایش می‌دهد. اعلان‌های در انتظار به
Gateway صادرکنندهٔ خود متصل می‌مانند، بنابراین تغییر Gateway فعال نمی‌تواند یک
شناسهٔ تأیید قدیمی را هدایت مجدد کند.

### جریان IPC در macOS

```
Gateway -> سرویس Node (WS)
                 |  IPC (UDS + توکن + HMAC + TTL)
                 v
             برنامه Mac (رابط کاربری + تأییدها + system.run)
```

نکات امنیتی:

- حالت سوکت یونیکس `0600`، توکن ذخیره‌شده در `exec-approvals.json`.
- بررسی همتای دارای UID یکسان.
- چالش/پاسخ (nonce + توکن HMAC + هش درخواست) + TTL کوتاه.

## پرسش‌های متداول

### چه زمانی `accountId` و `threadId` در یک مقصد تأیید استفاده می‌شوند؟

هنگامی از `accountId` استفاده کنید که کانال چند هویت پیکربندی‌شده دارد و اعلان تأیید باید
از یک حساب مشخص ارسال شود. هنگامی از `threadId` استفاده کنید که مقصد از موضوع‌ها یا
رشته‌ها پشتیبانی می‌کند و اعلان باید به‌جای گفت‌وگوی سطح‌بالا در همان رشته باقی بماند.

یک نمونهٔ مشخص در Telegram، یک سوپرگروه عملیاتی با موضوعات انجمن و دو حساب ربات
Telegram است. مقدار `to` سوپرگروه را مشخص می‌کند، `accountId` حساب ربات را انتخاب می‌کند و `threadId`
موضوع انجمن را انتخاب می‌کند:

```json5
{
  approvals: {
    exec: {
      enabled: true,
      mode: "targets",
      targets: [
        {
          channel: "telegram",
          to: "-1001234567890",
          accountId: "ops-bot",
          threadId: "77",
        },
      ],
    },
  },
  channels: {
    telegram: {
      accounts: {
        default: {
          name: "Primary bot",
          botToken: "env:TELEGRAM_PRIMARY_BOT_TOKEN",
        },
        "ops-bot": {
          name: "Operations bot",
          botToken: "env:TELEGRAM_OPS_BOT_TOKEN",
        },
      },
    },
  },
}
```

با این تنظیمات، تأییدهای exec هدایت‌شده توسط حساب Telegram با شناسهٔ `ops-bot` در موضوع
`77` از گفت‌وگوی `-1001234567890` ارسال می‌شوند. مقصدی بدون `accountId` از حساب پیش‌فرض کانال استفاده می‌کند و
مقصدی بدون `threadId` در مقصد سطح‌بالا ارسال می‌شود.

### وقتی تأییدها به یک نشست ارسال می‌شوند، آیا هر کسی در آن نشست می‌تواند آن‌ها را تأیید کند؟

خیر. تحویل به نشست فقط محل نمایش درخواست را کنترل می‌کند. این کار به‌خودی‌خود به همه
شرکت‌کنندگان آن گفت‌وگو اجازه تأیید نمی‌دهد.

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

برخی کانال‌ها سخت‌گیرانه‌تر هستند. Discord، Telegram، Matrix، پیام‌های خصوصی بومی تأیید در Slack و
کلاینت‌های بومی مشابه برای تأیید، از فهرست‌های تأییدکنندگانِ تعیین‌شده خود برای مجوزدهی تأیید استفاده می‌کنند. برای مثال،
یک درخواست تأیید در موضوع انجمن Telegram ممکن است برای همه افراد حاضر در موضوع قابل‌مشاهده باشد، اما فقط شناسه‌های عددی
کاربران Telegram که از `channels.telegram.execApprovals.approvers` یا
`commands.ownerAllowFrom` تعیین شده‌اند می‌توانند آن را تأیید یا رد کنند.

## مرتبط

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