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

موضوعات متقدمة لموافقات التنفيذ: المسار السريع safeBins، وربط المفسّر/وقت التشغيل، وتمرير الموافقات إلى قنوات الدردشة (بما في ذلك التسليم الأصلي). للسياسة الأساسية وتدفق الموافقة، راجع موافقات التنفيذ.

​

الثنائيات الآمنة (stdin فقط)

يعرّف tools.exec.safeBins قائمة صغيرة من الثنائيات الخاصة بـ stdin فقط (مثل cut) التي يمكن تشغيلها في وضع قائمة السماح من دون إدخالات صريحة في قائمة السماح. ترفض الثنائيات الآمنة وسائط الملفات الموضعية والرموز الشبيهة بالمسارات، لذلك لا يمكنها العمل إلا على التدفق الوارد. تعامل مع هذا كمسار سريع ضيق لمرشحات التدفق، وليس كقائمة ثقة عامة. الثنائيات الآمنة الافتراضية: cut, uniq, head, tail, tr, wc لا يوجد grep وsort في القائمة الافتراضية. إذا اخترت تفعيلهما، فأبق إدخالات قائمة سماح صريحة لتدفقات عملهما غير المعتمدة على stdin. بالنسبة إلى grep في وضع الثنائية الآمنة، قدّم النمط باستخدام -e/--regexp؛ يُرفض شكل النمط الموضعي حتى لا يمكن تهريب معاملات الملفات كوسائط موضعية ملتبسة.

​

التحقق من argv والرايات المرفوضة

التحقق حتمي من شكل argv فقط (من دون فحوص وجود على نظام ملفات المضيف)، ما يمنع سلوك كشف وجود الملفات من فروق السماح/الرفض. تُرفض الخيارات الموجهة للملفات في الثنائيات الآمنة الافتراضية؛ وتُتحقق الخيارات الطويلة بنهج الفشل المغلق (تُرفض الرايات غير المعروفة والاختصارات الملتبسة). الرايات المرفوضة حسب ملف تعريف الثنائية الآمنة:

• 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

تجبر الثنائيات الآمنة أيضًا رموز 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 حفظ استدعاءات مفسّر/سكريبت حميدة، لكن حوامل التقييم المضمّن لا تُحفظ تلقائيًا.

​

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

موقع الإعدادات:

• يأتي 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. 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 اثنان لموافقات الدردشة؟

• 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
• 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 — السياسة الأساسية وتدفق الموافقة
• أداة Exec
• الوضع المرتفع
• Skills — سلوك السماح التلقائي المدعوم بالمهارة