---
read_when:
    - پیکربندی تأییدیه‌های اجرا یا فهرست‌های مجاز
    - پیاده‌سازی تجربهٔ کاربری تأیید exec در برنامهٔ macOS
    - بررسی پرامپت‌های فرار از سندباکس و پیامدهای آن‌ها
sidebarTitle: Exec approvals
summary: 'تأییدیه‌های اجرای میزبان: گزینه‌های تنظیم سیاست، فهرست‌های مجاز، و گردش‌کار YOLO/سخت‌گیرانه'
title: تأییدهای اجرا
x-i18n:
    generated_at: "2026-04-29T23:42:23Z"
    model: gpt-5.5
    provider: openai
    source_hash: 71c16d0e547c4dd42a351d37e37e97b681a062cd496d5e0cba923b54c8f5b0e9
    source_path: tools/exec-approvals.md
    workflow: 16
---

تأییدهای اجرا، **محافظ اپ همراه / میزبان Node** برای اجازه دادن به
یک عامل سندباکس‌شده جهت اجرای فرمان‌ها روی یک میزبان واقعی (`gateway` یا `node`) هستند. یک
قفل ایمنی: فرمان‌ها فقط زمانی مجازند که سیاست + allowlist +
تأیید کاربر (اختیاری) همگی موافق باشند. تأییدهای اجرا **روی**
سیاست ابزار و دروازه‌گذاری elevated قرار می‌گیرند (مگر اینکه elevated روی `full` تنظیم شده باشد، که
تأییدها را رد می‌کند).

<Note>
سیاست مؤثر، **سخت‌گیرانه‌تر** از `tools.exec.*` و پیش‌فرض‌های تأییدها است؛ اگر فیلدی از تأییدها حذف شود، مقدار `tools.exec`
استفاده می‌شود. اجرای میزبان همچنین از وضعیت تأییدهای محلی روی همان ماشین استفاده می‌کند — یک
`ask: "always"` محلیِ میزبان در `~/.openclaw/exec-approvals.json` همچنان
درخواست تأیید می‌دهد، حتی اگر پیش‌فرض‌های نشست یا پیکربندی `ask: "on-miss"` را درخواست کنند.
</Note>

## بررسی سیاست مؤثر

| فرمان                                                          | چه چیزی نشان می‌دهد                                                                          |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| `openclaw approvals get` / `--gateway` / `--node <id\|name\|ip>` | سیاست درخواست‌شده، منابع سیاست میزبان، و نتیجه مؤثر.                       |
| `openclaw exec-policy show`                                      | نمای ادغام‌شده ماشین محلی.                                                             |
| `openclaw exec-policy set` / `preset`                            | همگام‌سازی سیاست درخواست‌شده محلی با فایل تأییدهای میزبان محلی در یک مرحله. |

وقتی یک دامنه محلی `host=node` را درخواست می‌کند، `exec-policy show` آن
دامنه را در زمان اجرا به‌صورت مدیریت‌شده توسط Node گزارش می‌کند، به‌جای اینکه وانمود کند فایل
تأییدهای محلی منبع حقیقت است.

اگر رابط کاربری اپ همراه **در دسترس نباشد**، هر درخواستی که
معمولاً اعلان تأیید می‌داد، با **fallback درخواست** حل می‌شود (پیش‌فرض: `deny`).

<Tip>
کلاینت‌های تأیید چت بومی می‌توانند امکانات ویژه هر کانال را روی
پیام تأیید در انتظار قرار دهند. برای مثال، Matrix میان‌برهای واکنشی را قرار می‌دهد
(`✅` اجازه یک‌بار، `❌` رد، `♾️` اجازه همیشگی) و همچنان
فرمان‌های `/approve ...` را به‌عنوان fallback در پیام باقی می‌گذارد.
</Tip>

## محل اعمال

تأییدهای اجرا به‌صورت محلی روی میزبان اجرا اعمال می‌شوند:

- **میزبان Gateway** → فرایند `openclaw` روی ماشین Gateway.
- **میزبان Node** → اجراکننده Node (اپ همراه macOS یا میزبان Node بدون رابط).

### مدل اعتماد

- فراخوان‌های احراز هویت‌شده توسط Gateway، عملگرهای مورد اعتماد برای آن Gateway هستند.
- Nodeهای جفت‌شده آن قابلیت عملگر مورد اعتماد را به میزبان Node گسترش می‌دهند.
- تأییدهای اجرا ریسک اجرای تصادفی را کاهش می‌دهند، اما **مرز احراز هویت به‌ازای هر کاربر** نیستند.
- اجراهای تأییدشده میزبان Node زمینه اجرای canonical را متصل می‌کنند: cwd canonical، argv دقیق، اتصال env در صورت وجود، و مسیر اجرایی pinشده در صورت کاربرد.
- برای اسکریپت‌های shell و فراخوانی‌های مستقیم فایل مفسر/زمان اجرا، OpenClaw همچنین تلاش می‌کند یک عملوند فایل محلی مشخص را متصل کند. اگر آن فایل متصل‌شده پس از تأیید اما پیش از اجرا تغییر کند، اجرا به‌جای اجرای محتوای تغییرکرده رد می‌شود.
- اتصال فایل عمداً best-effort است، **نه** یک مدل معنایی کامل از همه مسیرهای بارگذار مفسر/زمان اجرا. اگر حالت تأیید نتواند دقیقاً یک فایل محلی مشخص را برای اتصال شناسایی کند، به‌جای وانمود کردن پوشش کامل، از ایجاد اجرای مبتنی بر تأیید خودداری می‌کند.

### تفکیک macOS

- **سرویس میزبان Node** `system.run` را از طریق IPC محلی به **اپ macOS** ارسال می‌کند.
- **اپ macOS** تأییدها را اعمال می‌کند و فرمان را در زمینه رابط کاربری اجرا می‌کند.

## تنظیمات و ذخیره‌سازی

تأییدها در یک فایل JSON محلی روی میزبان اجرا نگهداری می‌شوند:

```text
~/.openclaw/exec-approvals.json
```

نمونه schema:

```json
{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "source": "allow-always",
          "commandText": "rg -n TODO",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}
```

## گزینه‌های سیاست

### `exec.security`

<ParamField path="security" type='"deny" | "allowlist" | "full"'>
  - `deny` — مسدود کردن همه درخواست‌های اجرای میزبان.
  - `allowlist` — اجازه دادن فقط به فرمان‌های موجود در allowlist.
  - `full` — اجازه دادن به همه‌چیز (معادل elevated).

</ParamField>

### `exec.ask`

<ParamField path="ask" type='"off" | "on-miss" | "always"'>
  - `off` — هرگز اعلان نده.
  - `on-miss` — فقط وقتی allowlist مطابقت ندارد اعلان بده.
  - `always` — برای هر فرمان اعلان بده. اعتماد پایدار `allow-always` وقتی حالت مؤثر درخواست `always` باشد، اعلان‌ها را **سرکوب نمی‌کند**.

</ParamField>

### `askFallback`

<ParamField path="askFallback" type='"deny" | "allowlist" | "full"'>
  راه‌حل زمانی که اعلان لازم است اما هیچ رابط کاربری در دسترس نیست.

- `deny` — مسدود کن.
- `allowlist` — فقط در صورت تطابق allowlist اجازه بده.
- `full` — اجازه بده.

</ParamField>

### `tools.exec.strictInlineEval`

<ParamField path="strictInlineEval" type="boolean">
  وقتی `true` باشد، OpenClaw فرم‌های eval کد درون‌خطی را فقط با تأیید مجاز می‌داند،
  حتی اگر خود باینری مفسر در allowlist باشد. دفاع چندلایه
  برای بارگذارهای مفسر که به‌صورت تمیز به یک عملوند فایل پایدار
  نگاشت نمی‌شوند.
</ParamField>

نمونه‌هایی که حالت سخت‌گیرانه می‌گیرد:

- `python -c`
- `node -e`, `node --eval`, `node -p`
- `ruby -e`
- `perl -e`, `perl -E`
- `php -r`
- `lua -e`
- `osascript -e`

در حالت سخت‌گیرانه، این فرمان‌ها همچنان به تأیید صریح نیاز دارند، و
`allow-always` ورودی‌های جدید allowlist را برای آن‌ها به‌طور خودکار
پایدار نمی‌کند.

## حالت YOLO (بدون تأیید)

اگر می‌خواهید اجرای میزبان بدون اعلان‌های تأیید اجرا شود، باید
**هر دو** لایه سیاست را باز کنید — سیاست اجرای درخواست‌شده در پیکربندی OpenClaw
(`tools.exec.*`) **و** سیاست تأییدهای محلیِ میزبان در
`~/.openclaw/exec-approvals.json`.

YOLO رفتار پیش‌فرض میزبان است، مگر اینکه صریحاً آن را سخت‌گیرانه‌تر کنید:

| لایه                 | تنظیم YOLO               |
| --------------------- | -------------------------- |
| `tools.exec.security` | `full` روی `gateway`/`node` |
| `tools.exec.ask`      | `off`                      |
| Host `askFallback`    | `full`                     |

<Warning>
**تفاوت‌های مهم:**

- `tools.exec.host=auto` انتخاب می‌کند اجرا **کجا** انجام شود: وقتی sandbox در دسترس باشد در sandbox، وگرنه Gateway.
- YOLO انتخاب می‌کند اجرای میزبان **چگونه** تأیید شود: `security=full` به‌همراه `ask=off`.
- در حالت YOLO، OpenClaw یک دروازه تأیید heuristic جداگانه برای مبهم‌سازی فرمان یا لایه رد preflight اسکریپت را روی سیاست اجرای میزبان پیکربندی‌شده اضافه **نمی‌کند**.
- `auto` باعث نمی‌شود مسیریابی Gateway یک override آزاد از نشست سندباکس‌شده باشد. درخواست به‌ازای هر فراخوانی `host=node` از `auto` مجاز است؛ `host=gateway` فقط زمانی از `auto` مجاز است که هیچ runtime سندباکسی فعال نباشد. برای یک پیش‌فرض پایدار غیر auto، `tools.exec.host` را تنظیم کنید یا صریحاً از `/exec host=...` استفاده کنید.

</Warning>

Providerهای مبتنی بر CLI که حالت permission غیرتعاملی خود را ارائه می‌کنند
می‌توانند از این سیاست پیروی کنند. Claude CLI وقتی سیاست اجرای درخواست‌شده OpenClaw
برابر YOLO باشد، `--permission-mode bypassPermissions` را اضافه می‌کند.
آن رفتار backend را با آرگومان‌های صریح Claude
زیر `agents.defaults.cliBackends.claude-cli.args` / `resumeArgs` override کنید —
برای مثال `--permission-mode default`، `acceptEdits`، یا
`bypassPermissions`.

اگر تنظیم محافظه‌کارانه‌تری می‌خواهید، یکی از لایه‌ها را دوباره به
`allowlist` / `on-miss` یا `deny` سخت‌گیرانه‌تر کنید.

### تنظیم پایدار «هرگز اعلان نده» برای میزبان Gateway

<Steps>
  <Step title="تنظیم سیاست پیکربندی درخواست‌شده">
    ```bash
    openclaw config set tools.exec.host gateway
    openclaw config set tools.exec.security full
    openclaw config set tools.exec.ask off
    openclaw gateway restart
    ```
  </Step>
  <Step title="هماهنگ کردن فایل تأییدهای میزبان">
    ```bash
    openclaw approvals set --stdin <<'EOF'
    {
      version: 1,
      defaults: {
        security: "full",
        ask: "off",
        askFallback: "full"
      }
    }
    EOF
    ```
  </Step>
</Steps>

### میان‌بر محلی

```bash
openclaw exec-policy preset yolo
```

آن میان‌بر محلی هر دو مورد را به‌روزرسانی می‌کند:

- `tools.exec.host/security/ask` محلی.
- پیش‌فرض‌های محلی `~/.openclaw/exec-approvals.json`.

این عمداً فقط محلی است. برای تغییر تأییدهای میزبان Gateway یا میزبان Node
از راه دور، از `openclaw approvals set --gateway` یا
`openclaw approvals set --node <id|name|ip>` استفاده کنید.

### میزبان Node

برای یک میزبان Node، همان فایل تأییدها را روی همان Node اعمال کنید:

```bash
openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
```

<Note>
**محدودیت‌های فقط محلی:**

- `openclaw exec-policy` تأییدهای Node را همگام‌سازی نمی‌کند.
- `openclaw exec-policy set --host node` رد می‌شود.
- تأییدهای اجرای Node در زمان اجرا از Node واکشی می‌شوند، بنابراین به‌روزرسانی‌های هدف‌گیری‌شده برای Node باید از `openclaw approvals --node ...` استفاده کنند.

</Note>

### میان‌بر فقط نشست

- `/exec security=full ask=off` فقط نشست فعلی را تغییر می‌دهد.
- `/elevated full` یک میان‌بر اضطراری است که تأییدهای اجرا را نیز برای آن نشست رد می‌کند.

اگر فایل تأییدهای میزبان سخت‌گیرانه‌تر از پیکربندی باقی بماند، سیاست سخت‌گیرانه‌تر میزبان
همچنان برنده است.

## Allowlist (به‌ازای هر عامل)

Allowlistها **به‌ازای هر عامل** هستند. اگر چند عامل وجود دارد، در اپ macOS عاملی را که
ویرایش می‌کنید تغییر دهید. الگوها تطابق glob هستند.

الگوها می‌توانند globهای مسیر باینری resolveشده یا globهای نام فرمان ساده باشند.
نام‌های ساده فقط با فرمان‌هایی مطابقت دارند که از طریق `PATH` فراخوانی شده‌اند، بنابراین `rg` می‌تواند با
`/opt/homebrew/bin/rg` وقتی فرمان `rg` است مطابقت داشته باشد، اما **نه** با `./rg` یا
`/tmp/rg`. وقتی می‌خواهید به یک مکان باینری مشخص اعتماد کنید، از glob مسیر استفاده کنید.

ورودی‌های legacy `agents.default` هنگام load به `agents.main` migrate می‌شوند.
زنجیره‌های shell مانند `echo ok && pwd` همچنان نیاز دارند هر بخش سطح‌بالا
قواعد allowlist را برآورده کند.

نمونه‌ها:

- `rg`
- `~/Projects/**/bin/peekaboo`
- `~/.local/bin/*`
- `/opt/homebrew/bin/rg`

هر ورودی allowlist این موارد را دنبال می‌کند:

| فیلد              | معنا                          |
| ------------------ | -------------------------------- |
| `id`               | UUID پایدار استفاده‌شده برای هویت رابط کاربری |
| `lastUsedAt`       | زمان آخرین استفاده              |
| `lastUsedCommand`  | آخرین فرمانی که مطابقت داشت        |
| `lastResolvedPath` | آخرین مسیر باینری resolveشده        |

## مجازسازی خودکار CLIهای Skills

وقتی **مجازسازی خودکار CLIهای Skills** فعال باشد، فایل‌های اجرایی ارجاع‌شده توسط
Skills شناخته‌شده روی Nodeها (Node macOS یا میزبان Node بدون رابط)
مانند موارد allowlist رفتار می‌کنند. این کار از `skills.bins` از طریق RPC Gateway برای واکشی
فهرست binهای Skills استفاده می‌کند. اگر allowlistهای دستی سخت‌گیرانه می‌خواهید، این را غیرفعال کنید.

<Warning>
- این یک **allowlist ضمنی برای راحتی** است، جدا از ورودی‌های allowlist مسیر دستی.
- برای محیط‌های عملگر مورد اعتماد در نظر گرفته شده است که Gateway و Node در یک مرز اعتماد یکسان هستند.
- اگر به اعتماد صریح سخت‌گیرانه نیاز دارید، `autoAllowSkills: false` را نگه دارید و فقط از ورودی‌های allowlist مسیر دستی استفاده کنید.

</Warning>

## binهای ایمن و ارسال تأیید

برای binهای ایمن (مسیر سریع فقط stdin)، جزئیات اتصال مفسر، و
نحوه ارسال اعلان‌های تأیید به Slack/Discord/Telegram (یا اجرای آن‌ها به‌عنوان
کلاینت‌های تأیید بومی)، ببینید
[تأییدهای اجرا — پیشرفته](/fa/tools/exec-approvals-advanced).

## ویرایش در رابط کاربری کنترل

از کارت **Control UI → Nodes → Exec approvals** برای ویرایش پیش‌فرض‌ها،
overrideهای به‌ازای هر عامل، و allowlistها استفاده کنید. یک دامنه انتخاب کنید (پیش‌فرض‌ها یا یک عامل)،
سیاست را تنظیم کنید، الگوهای allowlist را اضافه/حذف کنید، سپس **ذخیره** کنید. رابط کاربری
فراداده آخرین استفاده را برای هر الگو نشان می‌دهد تا بتوانید فهرست را مرتب نگه دارید.

گزینشگر مقصد، **Gateway** (تأییدهای محلی) یا یک **Node** را انتخاب می‌کند.
Nodeها باید `system.execApprovals.get/set` را اعلان کنند (برنامهٔ macOS یا
میزبان Node بدون رابط). اگر یک Node هنوز تأییدهای exec را اعلان نمی‌کند،
فایل محلی `~/.openclaw/exec-approvals.json` آن را مستقیماً ویرایش کنید.

CLI: `openclaw approvals` از ویرایش Gateway یا Node پشتیبانی می‌کند — ببینید
[CLI تأییدها](/fa/cli/approvals).

## جریان تأیید

وقتی یک درخواست تأیید لازم باشد، gateway رویداد
`exec.approval.requested` را برای کلاینت‌های اپراتور پخش می‌کند. رابط کنترل و برنامهٔ macOS
آن را از طریق `exec.approval.resolve` حل می‌کنند، سپس gateway درخواست
تأییدشده را به میزبان Node ارسال می‌کند.

برای `host=node`، درخواست‌های تأیید شامل بار دادهٔ متعارف `systemRunPlan`
هستند. gateway هنگام ارسال درخواست‌های تأییدشدهٔ `system.run`، از آن طرح به‌عنوان زمینهٔ
معتبر command/cwd/session استفاده می‌کند.

این موضوع برای تأخیر تأیید ناهمگام مهم است:

- مسیر exec در Node یک طرح متعارف را از ابتدا آماده می‌کند.
- رکورد تأیید آن طرح و فرادادهٔ اتصال آن را ذخیره می‌کند.
- پس از تأیید، فراخوانی نهایی و ارسال‌شدهٔ `system.run` به‌جای اعتماد به ویرایش‌های بعدی فراخواننده، از طرح ذخیره‌شده دوباره استفاده می‌کند.
- اگر فراخواننده پس از ایجاد درخواست تأیید، `command`، `rawCommand`، `cwd`، `agentId` یا `sessionKey` را تغییر دهد، gateway اجرای ارسال‌شده را به‌دلیل ناهماهنگی تأیید رد می‌کند.

## رویدادهای سیستم

چرخهٔ عمر exec به‌صورت پیام‌های سیستم نمایش داده می‌شود:

- `Exec running` (فقط اگر اجرای دستور از آستانهٔ اعلان در حال اجرا بیشتر شود).
- `Exec finished`.
- `Exec denied`.

این‌ها پس از گزارش رویداد توسط Node در نشست عامل ثبت می‌شوند.
تأییدهای exec میزبان‌شده در Gateway هنگام پایان دستور، همان رویدادهای چرخهٔ عمر را منتشر می‌کنند (و در صورت طولانی‌تر شدن اجرا از آستانه، به‌صورت اختیاری هنگام اجرا نیز).
execهای وابسته به تأیید، برای هم‌بستگی آسان، از شناسهٔ تأیید به‌عنوان `runId` در این
پیام‌ها دوباره استفاده می‌کنند.

## رفتار تأیید ردشده

وقتی یک تأیید exec ناهمگام رد شود، OpenClaw مانع می‌شود که عامل
از خروجی هر اجرای قبلی همان دستور در همان نشست دوباره استفاده کند.
دلیل رد همراه با راهنمایی صریح ارسال می‌شود که هیچ خروجی دستوری
در دسترس نیست؛ این کار جلوی عامل را می‌گیرد تا ادعا نکند خروجی تازه‌ای وجود دارد یا
دستور ردشده را با نتایج کهنهٔ یک اجرای موفق قبلی تکرار نکند.

## پیامدها

- **`full`** قدرتمند است؛ هر جا ممکن است فهرست‌های مجاز را ترجیح دهید.
- **`ask`** شما را در جریان نگه می‌دارد و همچنان تأییدهای سریع را ممکن می‌کند.
- فهرست‌های مجاز هر عامل مانع نشت تأییدهای یک عامل به دیگران می‌شوند.
- تأییدها فقط برای درخواست‌های exec میزبان از طرف **فرستندگان مجاز** اعمال می‌شوند. فرستندگان غیرمجاز نمی‌توانند `/exec` صادر کنند.
- `/exec security=full` یک امکان در سطح نشست برای اپراتورهای مجاز است و طبق طراحی از تأییدها عبور می‌کند. برای مسدودسازی سخت exec میزبان، امنیت تأییدها را روی `deny` تنظیم کنید یا ابزار `exec` را از طریق سیاست ابزار رد کنید.

## مرتبط

<CardGroup cols={2}>
  <Card title="Exec approvals — advanced" href="/fa/tools/exec-approvals-advanced" icon="gear">
    مخزن‌های امن، اتصال مفسر، و ارسال تأیید به چت.
  </Card>
  <Card title="Exec tool" href="/fa/tools/exec" icon="terminal">
    ابزار اجرای دستور شل.
  </Card>
  <Card title="Elevated mode" href="/fa/tools/elevated" icon="shield-exclamation">
    مسیر اضطراری که از تأییدها نیز عبور می‌کند.
  </Card>
  <Card title="Sandboxing" href="/fa/gateway/sandboxing" icon="box">
    حالت‌های sandbox و دسترسی به فضای کار.
  </Card>
  <Card title="Security" href="/fa/gateway/security" icon="lock">
    مدل امنیتی و سخت‌سازی.
  </Card>
  <Card title="Sandbox vs tool policy vs elevated" href="/fa/gateway/sandbox-vs-tool-policy-vs-elevated" icon="sliders">
    چه زمانی از هر کنترل استفاده کنید.
  </Card>
  <Card title="Skills" href="/fa/tools/skills" icon="sparkles">
    رفتار اجازه‌دهی خودکار مبتنی بر Skills.
  </Card>
</CardGroup>
