---
read_when:
    - تكوين الحاويات الآمنة أو ملفات تعريف الحاويات الآمنة المخصصة
    - إعادة توجيه الموافقات إلى Slack/Discord/Telegram أو قنوات دردشة أخرى
    - تنفيذ عميل موافقات أصلي لقناة
summary: 'موافقات exec المتقدمة: الحاويات الثنائية الآمنة، ربط المفسّر، تمرير الموافقة، التسليم الأصلي'
title: موافقات التنفيذ — متقدمة
x-i18n:
    generated_at: "2026-05-07T01:55:29Z"
    model: gpt-5.5
    provider: openai
    source_hash: d876efbfa34ef951b47cbfec9cc6a6a69a69f5b84365165d423d251163373040
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

موضوعات متقدمة في موافقات exec: المسار السريع `safeBins`، وربط المفسّر/بيئة التشغيل،
وتمرير الموافقات إلى قنوات الدردشة (بما في ذلك التسليم الأصلي).
للاطلاع على السياسة الأساسية وتدفق الموافقات، راجع [موافقات Exec](/ar/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 فقط (من دون فحوصات وجود على نظام ملفات المضيف)،
ما يمنع سلوك كاشف وجود الملفات الناتج عن اختلافات السماح/المنع. تُرفض الخيارات
الموجّهة للملفات في الثنائيات الآمنة الافتراضية؛ وتُتحقق الخيارات الطويلة بطريقة
تغلق عند الفشل (تُرفض الرايات غير المعروفة والاختصارات الملتبسة).

الرايات المرفوضة حسب ملف تعريف الثنائي الآمن:

[//]: # "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 فقط، لذلك
لا يمكن استخدام أنماط مثل `*` أو `$HOME/...` لتمرير قراءات ملفات خفية.

### أدلة الثنائيات الموثوقة

يجب أن تُحلّ الثنائيات الآمنة من أدلة ثنائيات موثوقة (افتراضيات النظام بالإضافة
إلى `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` و`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 لمسار الملف التنفيذي المحلول، أو نمط 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` لكل وكيل). تتجاوز مفاتيح ملف التعريف لكل وكيل المفاتيح العامة.
- توجد إدخالات قائمة السماح في `~/.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_900000__
إذا أدخلت `jq` صراحة في `safeBins`، فسيظل OpenClaw يرفض `env` المدمج في وضع
الثنائيات الآمنة حتى لا يتمكن `jq -n env` من تفريغ بيئة عملية المضيف من دون مسار
قائمة سماح صريح أو مطالبة موافقة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا تم تكوين عميل موافقة أصلي لكن لا يوجد وقت تشغيل أصلي نشط للقناة
الأصلية، يُبقي OpenClaw مطالبة `/approve` المحلية الحتمية مرئية. إذا كان وقت التشغيل الأصلي نشطًا وحاول التسليم لكن لم
يتلقَّ أي هدف البطاقة، يرسل OpenClaw إشعار رجوع في الدردشة نفسها يتضمن
أمر `/approve <id> <decision>` الدقيق بحيث يمكن حل الطلب مع ذلك.

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

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

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

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

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

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

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

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

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

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

تستخدم أوامر المجموعات الحساسة الخاصة بالمالك فقط مثل `/diagnostics` و`/export-trajectory` توجيهًا خاصًا
بالمالك لمطالبات الموافقة والنتائج النهائية. يحاول OpenClaw أولًا استخدام مسار خاص على
نفس السطح الذي شغّل فيه المالك الأمر. إذا لم يكن لذلك السطح مسار مالك خاص، فإنه يعود
إلى أول مسار مالك متاح من `commands.ownerAllowFrom`، بحيث يستطيع أمر مجموعة Discord
مع ذلك إرسال الموافقة والنتيجة إلى DM مالك Telegram عندما تكون Telegram هي الواجهة الخاصة
الأساسية المكوّنة. لا تحصل دردشة المجموعة إلا على إقرار قصير.

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

راجع:

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

### تدفق IPC في macOS
__OC_I18N_900004__
ملاحظات الأمان:

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

## ذات صلة

- [موافقات exec](/ar/tools/exec-approvals) — السياسة الأساسية وتدفق الموافقة
- [أداة exec](/ar/tools/exec)
- [الوضع المرتفع](/ar/tools/elevated)
- [Skills](/ar/tools/skills) — سلوك السماح التلقائي المدعوم بالمهارات