---
read_when:
    - إعداد موافقات التنفيذ أو قوائم السماح
    - تنفيذ تجربة مستخدم لموافقات التنفيذ في تطبيق macOS
    - مراجعة مطالبات الخروج من العزل sandbox وآثارها
summary: موافقات التنفيذ، قوائم السماح، ومطالبات الخروج من العزل sandbox
title: موافقات التنفيذ
x-i18n:
    generated_at: "2026-04-10T07:18:06Z"
    model: gpt-5.4
    provider: openai
    source_hash: 5f4a2e2f1f3c13a1d1926c9de0720513ea8a74d1ca571dbe74b188d8c560c14c
    source_path: tools/exec-approvals.md
    workflow: 15
---

# موافقات التنفيذ

موافقات التنفيذ هي **وسيلة الحماية للتطبيق المصاحب / مضيف العقدة** للسماح لوكيل معزول بتشغيل
أوامر على مضيف حقيقي (`gateway` أو `node`). يمكنك اعتبارها قفل أمان:
لا يُسمح بالأوامر إلا عندما تتفق السياسة + قائمة السماح + (اختياريًا) موافقة المستخدم جميعًا.
تُعد موافقات التنفيذ **إضافة إلى** سياسة الأداة وبوابات الرفع، (إلا إذا كانت قيمة الرفع `full`، إذ يتجاوز ذلك الموافقات).
السياسة الفعلية هي **الأكثر تقييدًا** بين `tools.exec.*` وافتراضيات الموافقات؛ وإذا حُذف أحد حقول الموافقات، تُستخدم قيمة `tools.exec`.
يستخدم تنفيذ المضيف أيضًا حالة الموافقات المحلية على ذلك الجهاز. إن كانت القيمة المحلية على المضيف
`ask: "always"` في `~/.openclaw/exec-approvals.json` فسيستمر ظهور المطالبات حتى لو
طلبت الجلسة أو افتراضيات الإعداد `ask: "on-miss"`.
استخدم `openclaw approvals get` أو `openclaw approvals get --gateway` أو
`openclaw approvals get --node <id|name|ip>` لفحص السياسة المطلوبة،
ومصادر سياسة المضيف، والنتيجة الفعلية.
وبالنسبة للجهاز المحلي، يعرض `openclaw exec-policy show` العرض المدمج نفسه،
ويمكن لـ `openclaw exec-policy set|preset` مزامنة السياسة المحلية المطلوبة مع
ملف موافقات المضيف المحلي بخطوة واحدة. وعندما يطلب نطاق محلي `host=node`,
فإن `openclaw exec-policy show` يبلّغ عن هذا النطاق على أنه مُدار من العقدة وقت التشغيل بدلًا من
الادعاء بأن ملف الموافقات المحلي هو المصدر الفعلي للحقيقة.

إذا كانت واجهة التطبيق المصاحب **غير متاحة**، فإن أي طلب يتطلب مطالبة
يتم حسمه بواسطة **بديل السؤال** (الافتراضي: الرفض).

يمكن لعملاء الموافقة الأصليين في الدردشة أيضًا إظهار وسائل تفاعل خاصة بالقناة على
رسالة الموافقة المعلّقة. على سبيل المثال، يمكن لـ Matrix تجهيز اختصارات التفاعل على
مطالبة الموافقة (`✅` للسماح مرة واحدة، و`❌` للرفض، و`♾️` للسماح دائمًا عند توفره)
مع الإبقاء على أوامر `/approve ...` في الرسالة كحل احتياطي.

## أين يُطبّق

تُفرض موافقات التنفيذ محليًا على مضيف التنفيذ:

- **مضيف gateway** → عملية `openclaw` على جهاز gateway
- **مضيف node** → مشغّل العقدة (تطبيق macOS المصاحب أو مضيف عقدة بدون واجهة)

ملاحظة حول نموذج الثقة:

- الجهات التي تمت مصادقتها على Gateway هي مشغّلون موثوقون لذلك Gateway.
- تمدّ العقد المقترنة هذه القدرة الخاصة بالمشغّل الموثوق إلى مضيف العقدة.
- تقلل موافقات التنفيذ من مخاطر التنفيذ العرضي، لكنها ليست حدًا لمصادقة كل مستخدم على حدة.
- تربط عمليات التشغيل المعتمدة على مضيف العقدة سياق التنفيذ المعياري: cwd معياري، وargv مطابق، وربط env
  عند وجوده، ومسار تنفيذي مثبت عند انطباق ذلك.
- بالنسبة لسكربتات الصدفة وعمليات الاستدعاء المباشر لملفات المفسّر/بيئة التشغيل، يحاول OpenClaw أيضًا ربط
  معامل ملف محلي ملموس واحد. إذا تغيّر ذلك الملف المرتبط بعد الموافقة ولكن قبل التنفيذ،
  فسيتم رفض التشغيل بدلًا من تنفيذ محتوى متغير.
- هذا الربط للملف مقصود به أن يكون بأفضل جهد، وليس نموذجًا دلاليًا كاملًا لكل
  مسار تحميل في المفسرات/بيئات التشغيل. إذا لم يتمكن وضع الموافقة من تحديد ملف محلي ملموس واحد بالضبط
  لربطه، فإنه يرفض إنشاء تشغيل مدعوم بالموافقة بدلًا من الادعاء بوجود تغطية كاملة.

تقسيم macOS:

- تقوم **خدمة مضيف node** بتمرير `system.run` إلى **تطبيق macOS** عبر IPC محلي.
- يقوم **تطبيق macOS** بفرض الموافقات + تنفيذ الأمر في سياق واجهة المستخدم.

## الإعدادات والتخزين

توجد الموافقات في ملف JSON محلي على مضيف التنفيذ:

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

مثال على البنية:

```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",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}
```

## وضع "YOLO" بدون موافقة

إذا كنت تريد أن يعمل تنفيذ المضيف من دون مطالبات موافقة، فيجب فتح **كلتا** طبقتي السياسة:

- سياسة التنفيذ المطلوبة في إعداد OpenClaw (`tools.exec.*`)
- سياسة الموافقات المحلية على المضيف في `~/.openclaw/exec-approvals.json`

وهذا هو الآن سلوك المضيف الافتراضي ما لم تقم بتشديده صراحةً:

- `tools.exec.security`: ‏`full` على `gateway`/`node`
- `tools.exec.ask`: ‏`off`
- `askFallback` على المضيف: ‏`full`

تمييز مهم:

- يختار `tools.exec.host=auto` مكان تنفيذ الأمر: داخل sandbox عندما يكون متاحًا، وإلا على gateway.
- يحدد وضع YOLO كيفية الموافقة على تنفيذ المضيف: `security=full` مع `ask=off`.
- في وضع YOLO، لا يضيف OpenClaw بوابة موافقة استدلالية منفصلة لإخفاء الأوامر فوق سياسة تنفيذ المضيف المضبوطة.
- لا يجعل `auto` التوجيه إلى gateway تجاوزًا مجانيًا من جلسة داخل sandbox. يُسمح بطلب `host=node` لكل استدعاء من `auto`، ولا يُسمح بـ `host=gateway` من `auto` إلا عندما لا يكون وقت تشغيل sandbox نشطًا. إذا كنت تريد افتراضيًا ثابتًا غير `auto`، فاضبط `tools.exec.host` أو استخدم `/exec host=...` صراحةً.

إذا كنت تريد إعدادًا أكثر تحفظًا، فأعد تشديد أي من الطبقتين إلى `allowlist` / `on-miss`
أو `deny`.

إعداد دائم لمضيف gateway مع "عدم المطالبة أبدًا":

```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
```

ثم اضبط ملف موافقات المضيف ليطابق ذلك:

```bash
openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
```

اختصار محلي للسياسة نفسها الخاصة بمضيف gateway على الجهاز الحالي:

```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، طبّق ملف الموافقات نفسه على تلك العقدة بدلًا من ذلك:

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

قيد مهم محلي فقط:

- لا يقوم `openclaw exec-policy` بمزامنة موافقات العقدة
- يتم رفض `openclaw exec-policy set --host node`
- تُجلب موافقات تنفيذ العقدة من العقدة وقت التشغيل، لذا يجب أن تستخدم التحديثات الموجّهة للعقدة `openclaw approvals --node ...`

اختصار على مستوى الجلسة فقط:

- يغيّر `/exec security=full ask=off` الجلسة الحالية فقط.
- يُعد `/elevated full` اختصارًا للطوارئ يتجاوز أيضًا موافقات التنفيذ لتلك الجلسة.

إذا بقي ملف موافقات المضيف أكثر تقييدًا من الإعداد، فستظل سياسة المضيف الأشد هي السارية.

## عناصر التحكم في السياسة

### الأمان (`exec.security`)

- **deny**: حظر جميع طلبات تنفيذ المضيف.
- **allowlist**: السماح فقط بالأوامر الموجودة في قائمة السماح.
- **full**: السماح بكل شيء (يعادل elevated).

### السؤال (`exec.ask`)

- **off**: لا تطلب أبدًا.
- **on-miss**: اطلب فقط عندما لا توجد مطابقة في قائمة السماح.
- **always**: اطلب لكل أمر.
- لا يؤدي `allow-always` الخاص بالثقة الدائمة إلى كتم المطالبات عندما يكون وضع السؤال الفعلي `always`

### بديل السؤال (`askFallback`)

إذا كانت هناك حاجة إلى مطالبة ولكن لا يمكن الوصول إلى أي واجهة مستخدم، فإن البديل يقرر:

- **deny**: الحظر.
- **allowlist**: السماح فقط إذا وُجدت مطابقة في قائمة السماح.
- **full**: السماح.

### تقوية التقييم المضمّن داخل المفسر (`tools.exec.strictInlineEval`)

عندما تكون القيمة `tools.exec.strictInlineEval=true`، يتعامل OpenClaw مع صيغ تقييم الشيفرة المضمّنة على أنها تتطلب موافقة فقط حتى لو كان ملف المفسر الثنائي نفسه موجودًا في قائمة السماح.

أمثلة:

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

هذا إجراء دفاعي إضافي للمحملات الخاصة بالمفسرات التي لا ترتبط بشكل نظيف
بمعامل ملف ثابت واحد. في الوضع الصارم:

- لا تزال هذه الأوامر تحتاج إلى موافقة صريحة؛
- لا يقوم `allow-always` بحفظ إدخالات جديدة في قائمة السماح لها تلقائيًا.

## قائمة السماح (لكل وكيل)

قوائم السماح هي **لكل وكيل**. إذا كان هناك عدة وكلاء، فبدّل الوكيل الذي
تقوم بتحريره في تطبيق macOS. الأنماط هي **مطابقات glob غير حساسة لحالة الأحرف**.
ينبغي أن تُحل الأنماط إلى **مسارات ملفات ثنائية** (يتم تجاهل الإدخالات التي تحتوي على الاسم الأساسي فقط).
تتم ترحيل إدخالات `agents.default` القديمة إلى `agents.main` عند التحميل.
ولا تزال سلاسل الصدفة مثل `echo ok && pwd` تتطلب أن يستوفي كل مقطع من المستوى الأعلى قواعد قائمة السماح.

أمثلة:

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

يتعقب كل إدخال في قائمة السماح ما يلي:

- **id** UUID ثابت يُستخدم لهوية واجهة المستخدم (اختياري)
- **آخر استخدام** الطابع الزمني
- **آخر أمر مستخدم**
- **آخر مسار تم حله**

## السماح التلقائي لـ CLI الخاصة بـ Skills

عند تفعيل **السماح التلقائي لـ CLI الخاصة بـ Skills**، يتم التعامل مع الملفات التنفيذية المشار إليها بواسطة Skills المعروفة
على أنها موجودة في قائمة السماح على العقد (عقدة macOS أو مضيف عقدة بدون واجهة). ويستخدم ذلك
`skills.bins` عبر Gateway RPC لجلب قائمة ملفات skill bin. عطّل هذا إذا كنت تريد قوائم سماح يدوية صارمة.

ملاحظات مهمة حول الثقة:

- هذه **قائمة سماح ضمنية للتيسير**، منفصلة عن إدخالات قائمة السماح اليدوية للمسارات.
- وهي مخصّصة لبيئات المشغلين الموثوقين حيث يكون Gateway والعقدة ضمن حدود الثقة نفسها.
- إذا كنت تحتاج إلى ثقة صريحة صارمة، فأبقِ `autoAllowSkills: false` واستخدم فقط إدخالات قائمة السماح اليدوية للمسارات.

## الملفات الثنائية الآمنة (stdin-only)

يحدد `tools.exec.safeBins` قائمة صغيرة من الملفات الثنائية **stdin-only** (مثل `cut`)
يمكنها العمل في وضع قائمة السماح **من دون** إدخالات صريحة في قائمة السماح. ترفض الملفات الثنائية الآمنة
وسائط الملفات الموضعية والرموز المشابهة للمسارات، لذلك لا يمكنها العمل إلا على التدفق الوارد.
تعامل مع هذا على أنه مسار سريع ضيق لمرشحات التدفق، وليس قائمة ثقة عامة.
**لا** تضف ملفات المفسر أو بيئة التشغيل الثنائية (مثل `python3` و`node` و`ruby` و`bash` و`sh` و`zsh`) إلى `safeBins`.
إذا كان بإمكان أمر ما تقييم الشيفرة أو تنفيذ أوامر فرعية أو قراءة ملفات بطبيعته، ففضّل إدخالات قائمة السماح الصريحة وأبقِ مطالبات الموافقة مفعلة.
يجب أن تحدد الملفات الثنائية الآمنة المخصصة ملف تعريف صريحًا في `tools.exec.safeBinProfiles.<bin>`.
يكون التحقق حتميًا من شكل argv فقط (من دون عمليات تحقق من وجود ملفات في نظام ملفات المضيف)، وهذا
يمنع سلوك oracle الخاص بوجود الملف من خلال فروق السماح/الرفض.
يتم رفض الخيارات الموجّهة للملفات للملفات الثنائية الآمنة الافتراضية (مثل `sort -o` و`sort --output`,
و`sort --files0-from`, و`sort --compress-program`, و`sort --random-source`,
و`sort --temporary-directory`/`-T`, و`wc --files0-from`, و`jq -f/--from-file`,
و`grep -f/--file`).
كما تفرض الملفات الثنائية الآمنة سياسة أعلام صريحة لكل ملف ثنائي للخيارات التي تخرق
سلوك stdin-only (مثل أعلام `sort -o/--output/--compress-program` وأعلام grep التكرارية).
يتم التحقق من الخيارات الطويلة بشكل مغلق-افتراضي في وضع الملفات الثنائية الآمنة: تُرفض الأعلام غير المعروفة
والاختصارات الغامضة.
الأعلام المرفوضة بحسب ملف تعريف safe-bin:

[//]: # "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 على أنها **نص حرفي** وقت التنفيذ (من دون توسيع glob
ومن دون توسيع `$VARS`) لمقاطع stdin-only، بحيث لا يمكن استخدام أنماط مثل `*` أو `$HOME/...`
لتهريب قراءات الملفات.
كما يجب أن تُحل الملفات الثنائية الآمنة من أدلة ملفات ثنائية موثوقة (الافتراضيات النظامية بالإضافة إلى
`tools.exec.safeBinTrustedDirs` الاختيارية). لا تُعد إدخالات `PATH` موثوقة تلقائيًا أبدًا.
أدلة الملفات الثنائية الآمنة الموثوقة الافتراضية محدودة عمدًا: `/bin` و`/usr/bin`.
إذا كان الملف الثنائي الآمن لديك موجودًا في مسارات مدير الحزم/المستخدم (مثل
`/opt/homebrew/bin` أو `/usr/local/bin` أو `/opt/local/bin` أو `/snap/bin`)، فأضفها صراحةً
إلى `tools.exec.safeBinTrustedDirs`.
لا يتم السماح تلقائيًا بسلاسل الصدفة وإعادات التوجيه في وضع قائمة السماح.

يُسمح بسلاسل الصدفة (`&&` و`||` و`;`) عندما يستوفي كل مقطع من المستوى الأعلى شروط قائمة السماح
(بما في ذلك الملفات الثنائية الآمنة أو السماح التلقائي لـ skill). أما إعادات التوجيه فلا تزال غير مدعومة في وضع قائمة السماح.
يتم رفض استبدال الأوامر (`$()` / backticks) أثناء تحليل قائمة السماح، بما في ذلك داخل
علامات الاقتباس المزدوجة؛ استخدم علامات الاقتباس المفردة إذا كنت تحتاج إلى نص `$()` حرفي.
في موافقات تطبيق macOS المصاحب، يُعامل نص الصدفة الخام الذي يحتوي على بنية تحكم أو توسيع للصدفة
(`&&` و`||` و`;` و`|` و`` ` `` و`$` و`<` و`>` و`(` و`)`) على أنه عدم تطابق مع قائمة السماح ما لم يكن
الملف الثنائي للصدفة نفسه موجودًا في قائمة السماح.
وبالنسبة إلى مغلفات الصدفة (`bash|sh|zsh ... -c/-lc`)، تُختزل تجاوزات env على مستوى الطلب إلى
قائمة سماح صغيرة وصريحة (`TERM` و`LANG` و`LC_*` و`COLORTERM` و`NO_COLOR` و`FORCE_COLOR`).
وبالنسبة إلى قرارات `allow-always` في وضع قائمة السماح، تحتفظ مغلفات الإرسال المعروفة
(`env` و`nice` و`nohup` و`stdbuf` و`timeout`) بمسارات الملفات التنفيذية الداخلية بدلًا من
مسارات المغلفات. كما يتم أيضًا فك مغلفات مضاعفات الصدفة (`busybox` و`toybox`) لتطبيقات الصدفة المصغرة (`sh` و`ash`
وغيرها) بحيث تُحفَظ الملفات التنفيذية الداخلية بدلًا من الملفات الثنائية الخاصة بالمضاعف. وإذا تعذر
فك مغلف أو مضاعف بأمان، فلن يتم حفظ أي إدخال في قائمة السماح تلقائيًا.
إذا أضفت مفسرات مثل `python3` أو `node` إلى قائمة السماح، ففضّل ضبط `tools.exec.strictInlineEval=true` حتى تظل عمليات eval المضمنة تتطلب موافقة صريحة. في الوضع الصارم، يمكن لـ `allow-always` مع ذلك حفظ عمليات استدعاء المفسر/السكربت غير الضارة، لكن وسائل حمل inline-eval لا تُحفَظ تلقائيًا.

الملفات الثنائية الآمنة الافتراضية:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut` و`uniq` و`head` و`tail` و`tr` و`wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

لا يتضمن القائمة الافتراضية `grep` و`sort`. وإذا اخترت تفعيله، فأبقِ إدخالات قائمة السماح الصريحة
لسير العمل غير المعتمد على stdin الخاصة بهما.
بالنسبة إلى `grep` في وضع safe-bin، قدّم النمط باستخدام `-e`/`--regexp`؛ إذ يتم
رفض صيغة النمط الموضعي حتى لا يمكن تهريب معاملات الملفات كوسائط موضعية ملتبسة.

### الملفات الثنائية الآمنة مقابل قائمة السماح

| الموضوع | `tools.exec.safeBins` | قائمة السماح (`exec-approvals.json`) |
| ---------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
| الهدف | السماح التلقائي لمرشحات stdin الضيقة | الوثوق الصريح بملفات تنفيذية محددة |
| نوع المطابقة | اسم الملف التنفيذي + سياسة argv الخاصة بالملف الثنائي الآمن | نمط glob لمسار الملف التنفيذي المحلول |
| نطاق الوسائط | مقيّد بملف تعريف safe-bin وقواعد الرموز الحرفية | مطابقة المسار فقط؛ أما الوسائط فهي من مسؤوليتك |
| أمثلة نموذجية | `head` و`tail` و`tr` و`wc` | `jq` و`python3` و`node` و`ffmpeg` وCLI مخصصة |
| أفضل استخدام | تحويلات نصية منخفضة المخاطر داخل pipelines | أي أداة ذات سلوك أوسع أو آثار جانبية |

مكان الإعداد:

- تأتي `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`). تتجاوز مفاتيح ملفات التعريف لكل وكيل المفاتيح العامة.
- توجد إدخالات قائمة السماح في الملف المحلي على المضيف `~/.openclaw/exec-approvals.json` تحت `agents.<id>.allowlist` (أو عبر Control UI / `openclaw approvals allowlist ...`).
- يحذر `openclaw security audit` باستخدام `tools.exec.safe_bins_interpreter_unprofiled` عندما تظهر ملفات المفسر/بيئة التشغيل الثنائية في `safeBins` من دون ملفات تعريف صريحة.
- يمكن لـ `openclaw doctor --fix` إنشاء إدخالات `safeBinProfiles.<bin>` المخصصة المفقودة على شكل `{}` (راجِعها وشدّدها بعد ذلك). لا يتم إنشاء ملفات المفسر/بيئة التشغيل الثنائية تلقائيًا.

مثال على ملف تعريف مخصص:
__OC_I18N_900005__
إذا اخترت صراحةً إضافة `jq` إلى `safeBins`، فسيظل OpenClaw يرفض الدالة المضمنة `env` في وضع safe-bin
حتى لا يتمكن `jq -n env` من تفريغ بيئة عملية المضيف من دون مسار صريح في قائمة السماح
أو مطالبة موافقة.

## التحرير في Control UI

استخدم بطاقة **Control UI → Nodes → Exec approvals** لتحرير القيم الافتراضية، وتجاوزات
كل وكيل، وقوائم السماح. اختر نطاقًا (القيم الافتراضية أو وكيلًا)، وعدّل السياسة،
وأضف/أزل أنماط قائمة السماح، ثم اضغط **حفظ**. تعرض الواجهة بيانات **آخر استخدام**
لكل نمط حتى تتمكن من إبقاء القائمة مرتبة.

يختار محدد الهدف **Gateway** (الموافقات المحلية) أو **Node**. يجب أن تعلن العقد
`system.execApprovals.get/set` (تطبيق macOS أو مضيف عقدة بدون واجهة).
إذا لم تعلن عقدة ما عن موافقات التنفيذ بعد، فحرّر ملفها المحلي
`~/.openclaw/exec-approvals.json` مباشرةً.

CLI: يدعم `openclaw approvals` تحرير gateway أو node (راجع [CLI للموافقات](/cli/approvals)).

## تدفق الموافقة

عندما تكون هناك حاجة إلى مطالبة، يبث gateway الحدث `exec.approval.requested` إلى عملاء المشغّلين.
يقوم Control UI وتطبيق macOS بحسمه عبر `exec.approval.resolve`، ثم يمرّر gateway
الطلب المعتمد إلى مضيف node.

بالنسبة إلى `host=node`، تتضمن طلبات الموافقة حمولة معيارية `systemRunPlan`. يستخدم gateway
هذه الخطة كسياق الأمر/cwd/الجلسة المرجعي عند تمرير طلبات `system.run`
المعتمدة.

وهذا مهم بالنسبة إلى كمون الموافقة غير المتزامنة:

- يقوم مسار تنفيذ العقدة بإعداد خطة معيارية واحدة مسبقًا
- يخزن سجل الموافقة تلك الخطة وبيانات الربط الوصفية الخاصة بها
- وبعد الموافقة، تعيد مكالمة `system.run` النهائية الممررة استخدام الخطة المخزنة
  بدلًا من الثقة في تعديلات لاحقة من المستدعي
- إذا غيّر المستدعي `command` أو `rawCommand` أو `cwd` أو `agentId` أو
  `sessionKey` بعد إنشاء طلب الموافقة، يرفض gateway
  التشغيل الممرر باعتباره عدم تطابق في الموافقة

## أوامر المفسر/بيئة التشغيل

تكون عمليات تشغيل المفسر/بيئة التشغيل المدعومة بالموافقة محافظة عمدًا:

- يتم دائمًا ربط سياق argv/cwd/env المطابق.
- تُربط صيغ سكربتات الصدفة المباشرة وصيغ ملفات بيئة التشغيل المباشرة - بأفضل جهد - بلقطة
  لملف محلي ملموس واحد.
- تُفك صيغ مغلفات مدير الحزم الشائعة التي لا تزال تُحل إلى ملف محلي مباشر واحد (مثل
  `pnpm exec` و`pnpm node` و`npm exec` و`npx`) قبل الربط.
- إذا لم يتمكن OpenClaw من تحديد ملف محلي ملموس واحد بالضبط لأمر مفسر/بيئة تشغيل
  (مثل سكربتات الحزم، أو صيغ eval، أو سلاسل محملات خاصة ببيئات تشغيل، أو صيغ
  متعددة الملفات وملتبسة)، فسيُرفض التنفيذ المدعوم بالموافقة بدلًا من الادعاء بوجود تغطية دلالية
  لا يملكها.
- بالنسبة إلى تدفقات العمل هذه، ففضّل sandboxing أو حدًا منفصلًا للمضيف أو
  سير عمل صريحًا موثوقًا لقائمة السماح/الوصول الكامل حيث يقبل المشغّل الدلالات الأوسع لبيئة التشغيل.

عندما تكون الموافقات مطلوبة، تعيد أداة التنفيذ مباشرةً معرّف موافقة. استخدم هذا المعرّف
لربط أحداث النظام اللاحقة (`Exec finished` / `Exec denied`). وإذا لم يصل أي قرار قبل
انتهاء المهلة، فسيُعامل الطلب على أنه مهلة موافقة ويظهر كسبب للرفض.

### سلوك تسليم المتابعة

بعد انتهاء تنفيذ غير متزامن تمت الموافقة عليه، يرسل OpenClaw دور `agent` متابعة إلى الجلسة نفسها.

- إذا وُجد هدف تسليم خارجي صالح (قناة قابلة للتسليم مع الهدف `to`)، يستخدم تسليم المتابعة تلك القناة.
- في تدفقات webchat فقط أو الجلسات الداخلية من دون هدف خارجي، يبقى تسليم المتابعة على مستوى الجلسة فقط (`deliver: false`).
- إذا طلب أحد المستدعين صراحةً تسليمًا خارجيًا صارمًا من دون قناة خارجية قابلة للحل، يفشل الطلب مع `INVALID_REQUEST`.
- إذا كان `bestEffortDeliver` مفعّلًا ولم يمكن حل أي قناة خارجية، فسيتم خفض التسليم إلى مستوى الجلسة فقط بدلًا من الفشل.

يتضمن مربع حوار التأكيد:

- الأمر + الوسائط
- cwd
- معرّف الوكيل
- مسار الملف التنفيذي المحلول
- بيانات المضيف + السياسة الوصفية

الإجراءات:

- **السماح مرة واحدة** → التشغيل الآن
- **السماح دائمًا** → الإضافة إلى قائمة السماح + التشغيل
- **رفض** → الحظر

## تمرير الموافقة إلى قنوات الدردشة

يمكنك تمرير مطالبات موافقة التنفيذ إلى أي قناة دردشة (بما في ذلك قنوات الإضافات) والموافقة
عليها باستخدام `/approve`. يستخدم هذا مسار التسليم الصادر العادي.

الإعداد:
__OC_I18N_900006__
الرد في الدردشة:
__OC_I18N_900007__
يعالج الأمر `/approve` كلًا من موافقات التنفيذ وموافقات الإضافات. إذا لم يطابق المعرّف أي موافقة تنفيذ معلّقة، فإنه يتحقق تلقائيًا من موافقات الإضافات بدلًا من ذلك.

### تمرير موافقة الإضافات

يستخدم تمرير موافقة الإضافات مسار التسليم نفسه المستخدم لموافقات التنفيذ، لكنه يملك
إعدادًا مستقلًا خاصًا به تحت `approvals.plugin`. لا يؤثر تفعيل أحدهما أو تعطيله في الآخر.
__OC_I18N_900008__
شكل الإعداد مطابق تمامًا لـ `approvals.exec`: تعمل `enabled` و`mode` و`agentFilter` و`sessionFilter` و`targets` بالطريقة نفسها.

تعرض القنوات التي تدعم الردود التفاعلية المشتركة أزرار الموافقة نفسها لكل من موافقات التنفيذ
وموافقات الإضافات. أما القنوات التي لا تملك واجهة تفاعلية مشتركة فتعود إلى النص العادي مع
تعليمات `/approve`.

### الموافقات داخل الدردشة نفسها على أي قناة

عندما ينشأ طلب موافقة تنفيذ أو إضافة من سطح دردشة قابل للتسليم، يمكن الآن للدردشة نفسها
الموافقة عليه باستخدام `/approve` افتراضيًا. ينطبق هذا على قنوات مثل Slack وMatrix وMicrosoft Teams بالإضافة إلى تدفقات Web UI وواجهة الطرفية الموجودة مسبقًا.

يستخدم هذا المسار المشترك للأوامر النصية نموذج مصادقة القناة العادي لتلك المحادثة. وإذا كانت
الدردشة الأصلية تستطيع بالفعل إرسال الأوامر واستلام الردود، فلن تعود طلبات الموافقة تحتاج إلى
مهايئ تسليم أصلي منفصل فقط كي تبقى معلّقة.

كما يدعم Discord وTelegram أيضًا `/approve` داخل الدردشة نفسها، لكن تلك القنوات لا تزال تستخدم
قائمة الموافقين المحلولة الخاصة بها للتخويل حتى عند تعطيل تسليم الموافقة الأصلي.

بالنسبة إلى Telegram وغيره من عملاء الموافقة الأصليين الذين يستدعون Gateway مباشرةً،
فإن هذا الاحتياط مقيّد عمدًا بحالات فشل "تعذر العثور على الموافقة". أما
الرفض/الخطأ الحقيقي لموافقة التنفيذ فلا يُعاد تجربته بصمت كموافقة إضافة.

### تسليم الموافقة الأصلي

يمكن لبعض القنوات أيضًا أن تعمل كعملاء موافقة أصليين. يضيف العملاء الأصليون رسائل مباشرة للموافقين، وتوزيعًا إلى الدردشة الأصلية،
وتجربة مستخدم تفاعلية للموافقة خاصة بالقناة فوق تدفق `/approve` المشترك داخل الدردشة نفسها.

عندما تتوفر بطاقات/أزرار الموافقة الأصلية، تكون واجهة المستخدم الأصلية تلك هي المسار الأساسي
الموجّه للوكيل. يجب ألا يعرض الوكيل أيضًا أمر دردشة نصي مكررًا من نوع
`/approve` إلا إذا كانت نتيجة الأداة تفيد بأن موافقات الدردشة غير متاحة أو
أن الموافقة اليدوية هي المسار الوحيد المتبقي.

النموذج العام:

- تظل سياسة تنفيذ المضيف هي التي تحدد ما إذا كانت موافقة التنفيذ مطلوبة
- يتحكم `approvals.exec` في تمرير مطالبات الموافقة إلى وجهات دردشة أخرى
- يتحكم `channels.<channel>.execApprovals` في ما إذا كانت تلك القناة تعمل كعميل موافقة أصلي

يقوم عملاء الموافقة الأصليون بتمكين التسليم إلى الرسائل المباشرة أولًا تلقائيًا عندما تكون كل الشروط التالية صحيحة:

- تدعم القناة تسليم الموافقة الأصلي
- يمكن حل الموافقين من `execApprovals.approvers` الصريح أو من
  مصادر الاحتياط الموثقة لتلك القناة
- تكون قيمة `channels.<channel>.execApprovals.enabled` غير مضبوطة أو `"auto"`

اضبط `enabled: false` لتعطيل عميل الموافقة الأصلي صراحةً. واضبط `enabled: true` لفرض
تفعيله عندما يمكن حل الموافقين. ويظل تسليم الدردشة الأصلية العامة صريحًا عبر
`channels.<channel>.execApprovals.target`.

الأسئلة الشائعة: [لماذا يوجد إعدادان لموافقات التنفيذ الخاصة بموافقات الدردشة؟](/help/faq#why-are-there-two-exec-approval-configs-for-chat-approvals)

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

تضيف عملاء الموافقة الأصليون هؤلاء توجيه الرسائل المباشرة وإمكانية التوزيع إلى القناة اختياريًا فوق
تدفق `/approve` المشترك داخل الدردشة نفسها وأزرار الموافقة المشتركة.

السلوك المشترك:

- تستخدم Slack وMatrix وMicrosoft Teams والدردشات القابلة للتسليم المماثلة نموذج مصادقة القناة العادي
  للأمر `/approve` داخل الدردشة نفسها
- عندما يتم تمكين عميل موافقة أصلي تلقائيًا، يكون هدف التسليم الأصلي الافتراضي هو الرسائل المباشرة للموافقين
- بالنسبة إلى Discord وTelegram، لا يمكن السماح أو الرفض إلا من قبل الموافقين الذين تم حلهم
- يمكن أن يكون الموافقون في Discord صريحين (`execApprovals.approvers`) أو مستنتجين من `commands.ownerAllowFrom`
- يمكن أن يكون الموافقون في Telegram صريحين (`execApprovals.approvers`) أو مستنتجين من إعداد المالك الحالي (`allowFrom`، بالإضافة إلى `defaultTo` للرسائل المباشرة حيثما كان ذلك مدعومًا)
- يمكن أن يكون الموافقون في Slack صريحين (`execApprovals.approvers`) أو مستنتجين من `commands.ownerAllowFrom`
- تحافظ أزرار Slack الأصلية على نوع معرّف الموافقة، بحيث يمكن لمعرّفات `plugin:` حل موافقات الإضافات
  من دون طبقة احتياط محلية ثانية خاصة بـ Slack
- يتعامل توجيه الرسائل المباشرة/القنوات الأصلي في Matrix واختصارات التفاعل مع كل من موافقات التنفيذ وموافقات الإضافات؛
  بينما يظل تخويل الإضافات صادرًا من `channels.matrix.dm.allowFrom`
- لا يحتاج مقدم الطلب إلى أن يكون من الموافقين
- يمكن للدردشة الأصلية الموافقة مباشرةً باستخدام `/approve` عندما تكون تلك الدردشة تدعم الأوامر والردود بالفعل
- توجّه أزرار الموافقة الأصلية في Discord حسب نوع معرّف الموافقة: تذهب معرّفات `plugin:` مباشرةً
  إلى موافقات الإضافات، وكل شيء آخر يذهب إلى موافقات التنفيذ
- تتبع أزرار الموافقة الأصلية في Telegram الاحتياط المحدود نفسه من التنفيذ إلى الإضافة كما في `/approve`
- عندما يفعّل `target` الأصلي تسليم الدردشة الأصلية، تتضمن مطالبات الموافقة نص الأمر
- تنتهي صلاحية موافقات التنفيذ المعلقة بعد 30 دقيقة افتراضيًا
- إذا لم تتمكن أي واجهة مشغّل أو عميل موافقة مُعدّ من قبول الطلب، تعود المطالبة إلى `askFallback`

يستخدم Telegram افتراضيًا الرسائل المباشرة للموافقين (`target: "dm"`). يمكنك التبديل إلى `channel` أو `both` عندما
تريد أن تظهر مطالبات الموافقة أيضًا في دردشة/موضوع Telegram الأصلي. وبالنسبة إلى موضوعات منتدى Telegram،
يحافظ OpenClaw على الموضوع لمطالبة الموافقة ولمتابعة ما بعد الموافقة.

راجع:

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

### تدفق IPC على macOS
__OC_I18N_900009__
ملاحظات أمنية:

- وضع Unix socket هو `0600`، ويتم تخزين الرمز المميز في `exec-approvals.json`.
- فحص النظير الذي يملك نفس UID.
- تحدٍ/استجابة (nonce + HMAC token + request hash) + مدة صلاحية قصيرة.

## أحداث النظام

يتم إظهار دورة حياة التنفيذ كرسائل نظام:

- `Exec running` (فقط إذا تجاوز الأمر عتبة إشعار التشغيل)
- `Exec finished`
- `Exec denied`

تُنشر هذه الرسائل في جلسة الوكيل بعد أن تبلغ العقدة عن الحدث.
تصدر موافقات تنفيذ مضيف Gateway أحداث دورة الحياة نفسها عند انتهاء الأمر (واختياريًا عند استمراره مدة أطول من العتبة).
تعيد عمليات التنفيذ المحكومة بالموافقة استخدام معرّف الموافقة نفسه باعتباره `runId` في هذه الرسائل لتسهيل الربط.

## سلوك الموافقة المرفوضة

عند رفض موافقة تنفيذ غير متزامن، يمنع OpenClaw الوكيل من إعادة استخدام
المخرجات الناتجة عن أي تشغيل سابق للأمر نفسه في الجلسة. ويتم تمرير سبب الرفض
مع إرشاد صريح بعدم توفر أي مخرجات للأمر، مما يمنع
الوكيل من الادعاء بوجود مخرجات جديدة أو تكرار الأمر المرفوض مع
نتائج قديمة من تشغيل سابق ناجح.

## الآثار المترتبة

- إن **full** قوي جدًا؛ ففضّل قوائم السماح متى أمكن.
- يبقيك **ask** ضمن الحلقة مع السماح في الوقت نفسه بموافقات سريعة.
- تمنع قوائم السماح لكل وكيل تسرب موافقات أحد الوكلاء إلى الآخرين.
- لا تنطبق الموافقات إلا على طلبات تنفيذ المضيف من **مرسلين مخولين**. لا يمكن للمرسلين غير المخولين إصدار `/exec`.
- يُعد `/exec security=full` وسيلة راحة على مستوى الجلسة للمشغلين المخولين، ويتجاوز الموافقات عمدًا.
  ولحظر تنفيذ المضيف بشكل صارم، اضبط أمان الموافقات على `deny` أو امنع أداة `exec` عبر سياسة الأداة.

ذو صلة:

- [أداة Exec](/ar/tools/exec)
- [الوضع المرتفع](/ar/tools/elevated)
- [Skills](/ar/tools/skills)

## ذو صلة

- [Exec](/ar/tools/exec) — أداة تنفيذ أوامر الصدفة
- [العزل sandboxing](/ar/gateway/sandboxing) — أوضاع العزل والوصول إلى مساحة العمل
- [الأمان](/ar/gateway/security) — نموذج الأمان والتقوية
- [Sandbox مقابل سياسة الأداة مقابل Elevated](/ar/gateway/sandbox-vs-tool-policy-vs-elevated) — متى تستخدم كلًّا منها
