---
read_when:
    - تهيئة موافقات exec أو قوائم السماح
    - تنفيذ واجهة تجربة المستخدم لموافقات exec في تطبيق macOS
    - مراجعة مطالبات الهروب من العزل وتداعياتها
summary: موافقات exec، وقوائم السماح، ومطالبات الهروب من العزل
title: موافقات exec
x-i18n:
    generated_at: "2026-04-21T07:27:17Z"
    model: gpt-5.4
    provider: openai
    source_hash: 0738108dd21e24eb6317d437b7ac693312743eddc3ec295ba62c4e60356cb33e
    source_path: tools/exec-approvals.md
    workflow: 15
---

# موافقات exec

تمثل موافقات exec **حاجز الأمان في التطبيق المرافق / مضيف Node** الذي يسمح
لوكيل معزول بتشغيل أوامر على مضيف حقيقي (`gateway` أو `node`). فكر فيها
كقفل أمان: لا يُسمح بالأوامر إلا عندما تتفق السياسة + قائمة السماح + (الموافقة الاختيارية من المستخدم) جميعًا.
تأتي موافقات exec **بالإضافة** إلى سياسة الأدوات وبوابة elevated (إلا إذا كان elevated مضبوطًا على `full`، إذ يتجاوز الموافقات).
وتكون السياسة الفعالة هي **الأشد** بين الإعدادات الافتراضية لـ `tools.exec.*` والموافقات؛ وإذا أُغفل حقل من حقول الموافقات، تُستخدم قيمة `tools.exec`.
ويستخدم 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` يبلغ عن هذا النطاق على أنه مُدار بواسطة node في وقت التشغيل بدل
الادعاء بأن ملف الموافقات المحلي هو مصدر الحقيقة الفعلي.

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

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

## أين يُطبّق

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

- **مضيف gateway** → عملية `openclaw` على جهاز gateway
- **مضيف node** → مشغل node ‏(تطبيق macOS المرافق أو مضيف node headless)

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

- المستدعون المصادق عليهم عبر Gateway هم مشغلون موثوقون لذلك Gateway.
- توسّع Nodes المقترنة قدرة المشغل الموثوق هذه إلى مضيف node.
- تقلل موافقات exec خطر التنفيذ العرضي، لكنها ليست حد مصادقة لكل مستخدم.
- تربط عمليات التشغيل الموافق عليها على مضيف node سياق التنفيذ القياسي: `cwd` القياسي، و`argv` الدقيق، وربط `env`
  عند وجوده، ومسار الملف التنفيذي المثبت عندما ينطبق ذلك.
- بالنسبة إلى نصوص shell البرمجية واستدعاءات الملفات المباشرة للمفسر/بيئة التشغيل، يحاول 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" من دون موافقة

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

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

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

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

تمييز مهم:

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

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

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

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

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

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

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

## مفاتيح السياسة

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

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

### Ask (`exec.ask`)

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

### رجوع ask الاحتياطي (`askFallback`)

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

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

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

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

أمثلة:

- `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` عند التحميل.
أما سلاسل shell مثل `echo ok && pwd` فلا تزال تتطلب أن يطابق كل مقطع علوي قواعد قائمة السماح.

أمثلة:

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

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

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

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

عند تمكين **Auto-allow skill CLIs**، تُعامل الملفات التنفيذية المشار إليها بواسطة Skills المعروفة
على أنها ضمن قائمة السماح على Nodes ‏(Node في macOS أو مضيف node headless). ويستخدم هذا
`skills.bins` عبر Gateway RPC لجلب قائمة skill bin. عطّل هذا إذا كنت تريد قوائم سماح يدوية صارمة.

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

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

## Safe bins ‏(stdin-only)

يعرّف `tools.exec.safeBins` قائمة صغيرة من الثنائيات **stdin-only** ‏(مثل `cut`)
يمكنها العمل في وضع قائمة السماح **من دون** إدخالات صريحة في قائمة السماح. ترفض Safe bins
وسائط الملفات الموضعية والرموز الشبيهة بالمسارات، لذلك لا يمكنها العمل إلا على الدفق الوارد.
تعامل مع هذا على أنه مسار سريع ضيق لمرشحات الدفق، وليس قائمة ثقة عامة.
**لا** تضف ثنائيات المفسرات أو بيئات التشغيل (مثل `python3` أو `node` أو `ruby` أو `bash` أو `sh` أو `zsh`) إلى `safeBins`.
إذا كان الأمر قادرًا بطبيعته على تقييم الكود أو تنفيذ أوامر فرعية أو قراءة الملفات، ففضّل إدخالات قائمة السماح الصريحة وأبقِ مطالبات الموافقة مفعلة.
يجب أن تعرّف Safe bins المخصصة ملف تعريف صريحًا في `tools.exec.safeBinProfiles.<bin>`.
يكون التحقق حتميًا اعتمادًا فقط على شكل argv ‏(من دون فحوصات لوجود الملفات على نظام ملفات المضيف)، مما
يمنع سلوك oracle لوجود الملفات نتيجة اختلافات السماح/الرفض.
وتُرفض الخيارات الموجهة للملفات بالنسبة إلى Safe bins الافتراضية (مثل `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`).
كما تفرض Safe bins أيضًا سياسة أعلام صريحة لكل ثنائي للخيارات التي تكسر
سلوك stdin-only ‏(مثل `sort -o/--output/--compress-program` وأعلام grep التكرارية).
يتم التحقق من الخيارات الطويلة بطريقة fail-closed في وضع safe-bin: تُرفض الأعلام غير المعروفة والاختصارات الملتبسة.
الأعلام المرفوضة بحسب ملف تعريف 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"

تفرض Safe bins أيضًا التعامل مع رموز argv على أنها **نص حرفي** وقت التنفيذ (من دون توسيع glob
ومن دون توسيع `$VARS`) لمقاطع stdin-only، بحيث لا يمكن استخدام أنماط مثل `*` أو `$HOME/...`
لتهريب قراءات ملفات.
كما يجب أن تُحل Safe bins من أدلة ثنائيات موثوقة (الإعدادات الافتراضية للنظام بالإضافة إلى
`tools.exec.safeBinTrustedDirs` الاختيارية). ولا تُعد إدخالات `PATH` موثوقة تلقائيًا أبدًا.
وتكون أدلة safe-bin الموثوقة الافتراضية محدودة عمدًا: `/bin`, `/usr/bin`.
إذا كان الملف التنفيذي لـ safe-bin موجودًا في مسارات مدير الحزم/المستخدم (مثل
`/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`)، فأضفها صراحةً
إلى `tools.exec.safeBinTrustedDirs`.
ولا يُسمح تلقائيًا بسلاسل shell وعمليات إعادة التوجيه في وضع قائمة السماح.

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

Safe bins الافتراضية:

[//]: # "SAFE_BIN_DEFAULTS:START"

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

[//]: # "SAFE_BIN_DEFAULTS:END"

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

### Safe bins مقابل قائمة السماح

| الموضوع | `tools.exec.safeBins` | قائمة السماح (`exec-approvals.json`) |
| ---------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
| الهدف | السماح التلقائي لمرشحات stdin الضيقة | منح ثقة صريحة لملفات تنفيذية محددة |
| نوع المطابقة | اسم الملف التنفيذي + سياسة argv الخاصة بـ safe-bin | نمط 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**. ويجب أن تعلن Nodes
عن `system.execApprovals.get/set` ‏(تطبيق macOS أو مضيف node headless).
إذا كانت Node لا تعلن عن موافقات exec بعد، فحرّر ملفها المحلي
`~/.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`
الموافق عليها.

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

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

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

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

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

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

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

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

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

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

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

الإجراءات:

- **Allow once** → التشغيل الآن
- **Always allow** → الإضافة إلى قائمة السماح + التشغيل
- **Deny** → الحظر

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

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

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

### تمرير موافقات Plugin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الأسئلة الشائعة: [لماذا توجد إعداداتان لموافقات exec بالنسبة إلى موافقات الدردشة؟](/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:` تحليل موافقات Plugin
  من دون طبقة رجوع احتياطي ثانية محلية في Slack
- تتعامل عمليات التوجيه الأصلية للرسائل المباشرة/القنوات واختصارات التفاعل في Matrix مع كل من موافقات exec وPlugin؛
  وتأتي صلاحية Plugin مع ذلك من `channels.matrix.dm.allowFrom`
- لا يلزم أن يكون الطالب من بين الموافقين
- يمكن للدردشة الأصلية الموافقة مباشرةً باستخدام `/approve` عندما تكون تلك الدردشة تدعم الأوامر والردود بالفعل
- تقوم أزرار الموافقة الأصلية في Discord بالتوجيه بحسب نوع معرّف الموافقة: إذ تنتقل معرّفات `plugin:` مباشرةً
  إلى موافقات Plugin، وكل ما عدا ذلك ينتقل إلى موافقات exec
- تتبع أزرار الموافقة الأصلية في Telegram الرجوع الاحتياطي المقيّد نفسه من exec إلى Plugin كما في `/approve`
- عندما يمكّن `target` الأصلي تسليم دردشة المنشأ، تتضمن مطالبات الموافقة نص الأمر
- تنتهي صلاحية موافقات exec المعلّقة بعد 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) + TTL قصير.

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

يتم عرض دورة حياة exec كرسائل نظام:

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

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

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

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

## التداعيات

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

ذو صلة:

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

## ذو صلة

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