> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# موافقات التنفيذ — متقدمة

موضوعات متقدمة لموافقات التنفيذ: المسار السريع `safeBins`، وربط المفسّر/وقت التشغيل،
وتمرير الموافقات إلى قنوات الدردشة (بما في ذلك التسليم الأصلي).
للسياسة الأساسية وتدفق الموافقة، راجع [موافقات التنفيذ](/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`.

### ربط الصدفة، والمغلّفات، والمضاعفات

يُسمح بربط الصدفة (`&&`، و`||`، و`;`) عندما يحقق كل مقطع على المستوى الأعلى
قائمة السماح (بما في ذلك الثنائيات الآمنة أو السماح التلقائي للـ Skills). تبقى عمليات إعادة التوجيه
غير مدعومة في وضع قائمة السماح. يُرفض استبدال الأوامر (`$()` / العلامات الخلفية)
أثناء تحليل قائمة السماح، بما في ذلك داخل علامات الاقتباس المزدوجة؛ استخدم علامات الاقتباس المفردة
إذا احتجت إلى نص `$()` حرفي.

في موافقات التطبيق المصاحب على 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 لمسار الملف التنفيذي المحلول، أو 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` باستخدام `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 تحديد ملف محلي ملموس واحد بالضبط لأمر مفسّر/وقت تشغيل
  (مثل سكريبتات الحزم، أو أشكال eval، أو سلاسل التحميل الخاصة بوقت التشغيل، أو أشكال الملفات المتعددة الملتبسة)،
  فيُرفض التنفيذ المدعوم بالموافقة بدلًا من ادعاء تغطية دلالية لا يملكها.
* لهذه التدفقات، فضّل العزل، أو حد مضيف منفصلًا، أو قائمة سماح/تدفق عمل كاملًا موثوقًا صراحة
  حيث يقبل المشغّل دلالات وقت التشغيل الأوسع.

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

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

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

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

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

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

الإعدادات:
**OC\_I18N\_900001**
الرد في الدردشة:
**OC\_I18N\_900002**
يتعامل أمر `/approve` مع موافقات التنفيذ وموافقات Plugin معًا. إذا لم يطابق المعرّف موافقة تنفيذ معلقة، فإنه يتحقق تلقائيًا من موافقات Plugin بدلًا من ذلك.

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

يستخدم تمرير موافقات Plugin مسار التسليم نفسه مثل موافقات التنفيذ، لكنه يملك
إعداداته المستقلة ضمن `approvals.plugin`. لا يؤثر تفعيل أحدهما أو تعطيله في الآخر.
لسلوك تأليف Plugin، وحقول الطلب، ودلالات القرار، راجع
[طلبات أذونات Plugin](/plugins/plugin-permission-requests).
**OC\_I18N\_900003**
شكل الإعدادات مطابق لـ `approvals.exec`: تعمل `enabled`، و`mode`، و`agentFilter`،
و`sessionFilter`، و`targets` بالطريقة نفسها.

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

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

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

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

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

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

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

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

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

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

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

* لا تزال سياسة exec للمضيف تقرر ما إذا كانت موافقة exec مطلوبة
* يتحكم `approvals.exec` في تمرير مطالبات الموافقة إلى وجهات دردشة أخرى
* يتحكم `channels.<channel>.execApprovals` فيما إذا كان عملاء Discord وSlack وTelegram وما شابهها
  الأصليون الخاصون بالقنوات مفعّلين
* يمكن لموافقات Slack Plugin استخدام عميل الموافقة الأصلي في Slack عندما يأتي الطلب من Slack
  ويتم حل موافقي Slack Plugin؛ ويمكن لـ `approvals.plugin` أيضا توجيه موافقات Plugin إلى جلسات
  أو أهداف Slack حتى عند تعطيل موافقات Slack exec
* تتعامل بطاقات الموافقة الأصلية في 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`.

الأسئلة الشائعة: [لماذا توجد إعدادات موافقة 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.*`
* Google Chat: اضبط الموافقين المستقرين باستخدام `channels.googlechat.dm.allowFrom` أو
  `channels.googlechat.defaultTo`؛ لا تلزم كتلة `execApprovals`
* WhatsApp: استخدم `approvals.exec` و`approvals.plugin` لتوجيه مطالبات الموافقة إلى WhatsApp
* Signal: استخدم `approvals.exec` و`approvals.plugin` لتوجيه مطالبات الموافقة إلى Signal

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

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

* تستخدم دردشات Slack وMatrix وMicrosoft Teams وما شابهها القابلة للتسليم نموذج مصادقة القناة العادي
  لـ `/approve` في الدردشة نفسها
* عندما يفعّل عميل موافقة أصلي نفسه تلقائيا، يكون هدف التسليم الأصلي الافتراضي هو رسائل الموافقين المباشرة
* بالنسبة إلى Discord وTelegram، لا يمكن إلا للموافقين المحلولين الموافقة أو الرفض
* يمكن أن يكون موافقو Discord صريحين (`execApprovals.approvers`) أو مستنتجين من `commands.ownerAllowFrom`
* يمكن أن يكون موافقو Telegram صريحين (`execApprovals.approvers`) أو مستنتجين من `commands.ownerAllowFrom`
* يمكن أن يكون موافقو Slack صريحين (`execApprovals.approvers`) أو مستنتجين من `commands.ownerAllowFrom`
* تستخدم رسائل موافقة Slack Plugin المباشرة موافقي Slack Plugin من `allowFrom` وتوجيه الحساب الافتراضي،
  وليس موافقي Slack exec
* تحفظ أزرار Slack الأصلية نوع معرّف الموافقة، لذلك يمكن لمعرّفات `plugin:` حل موافقات Plugin
  دون طبقة رجوع محلية ثانية خاصة بـ Slack
* تحفظ بطاقات Google Chat الأصلية رجوع `/approve` اليدوي في نص الرسالة، لكن استدعاءات أزرار البطاقة
  لا تحمل إلا رموز إجراءات مبهمة؛ ويُستعاد معرّف الموافقة والقرار من الحالة المعلّقة على جانب الخادم
* تتعامل موافقات رموز WhatsApp التعبيرية مع مطالبات exec وPlugin فقط عندما تكون عائلة التمرير العليا المطابقة
  مفعّلة وتوجّه إلى WhatsApp؛ ويبقى تمرير WhatsApp الموجّه إلى الهدف فقط على
  مسار التمرير المشترك ما لم يطابق هدف الأصل الأصلي نفسه
* تتعامل موافقات تفاعل Signal مع مطالبات exec وPlugin فقط عندما تكون عائلة التمرير العليا المطابقة
  مفعّلة وتوجّه إلى Signal. يمكن لموافقات Signal exec المباشرة في الدردشة نفسها
  إخفاء رجوع `/approve` المحلي دون موافقين صريحين؛ ولا يزال حل تفاعل Signal
  يتطلب موافقي Signal صريحين من `channels.signal.allowFrom` أو `defaultTo`.
* يتعامل توجيه الرسائل المباشرة/القنوات الأصلي في 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
أن يظل يرسل الموافقة والنتيجة إلى رسالة Telegram المباشرة الخاصة بالمالك عندما يكون Telegram هو الواجهة
الخاصة الأساسية المضبوطة. لا تتلقى دردشة المجموعة إلا إقرارا قصيرا.

يضبط Telegram افتراضيا رسائل الموافقين المباشرة (`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 + تجزئة الطلب) + TTL قصير.

## الأسئلة الشائعة

### متى سيُستخدم `accountId` و`threadId` على هدف موافقة؟

استخدم `accountId` عندما تكون لدى القناة هويات متعددة مضبوطة ويجب أن تغادر مطالبة الموافقة
عبر حساب محدد واحد. استخدم `threadId` عندما تدعم الوجهة المواضيع أو
السلاسل ويجب أن تبقى المطالبة داخل تلك السلسلة بدلا من الدردشة العلوية.

حالة Telegram ملموسة هي مجموعة عمليات فائقة ذات مواضيع منتدى وحسابي روبوت Telegram.
تسمّي قيمة `to` المجموعة الفائقة، ويحدد `accountId` حساب الروبوت، ويحدد `threadId`
موضوع المنتدى:
**OC\_I18N\_900005**
مع هذا الإعداد، تُنشر موافقات exec الممررة بواسطة حساب Telegram `ops-bot` داخل الموضوع
`77` من الدردشة `-1001234567890`. يستخدم الهدف الذي لا يحتوي على `accountId` الحساب الافتراضي للقناة، و
ينشر الهدف الذي لا يحتوي على `threadId` إلى الوجهة العلوية.

### عندما تُرسل الموافقات إلى جلسة، هل يمكن لأي شخص في تلك الجلسة الموافقة عليها؟

لا. يتحكم تسليم الجلسة فقط في مكان ظهور المطالبة. ولا يفوض بحد ذاته كل
مشارك في تلك الدردشة للموافقة.

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

بعض القنوات أكثر صرامة. يستخدم Discord وTelegram وMatrix ورسائل موافقة Slack الأصلية المباشرة وما شابهها
من عملاء الموافقة الأصليين قوائم الموافقين المحلولة لديهم لتفويض الموافقة. على سبيل المثال،
يمكن أن تكون مطالبة موافقة موضوع منتدى Telegram مرئية للجميع في الموضوع، لكن لا يمكن إلا لمعرّفات مستخدمي
Telegram الرقمية المحلولة من `channels.telegram.execApprovals.approvers` أو
`commands.ownerAllowFrom` الموافقة عليها أو رفضها.

## ذات صلة

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