الانتقال إلى المحتوى الرئيسي

موافقات Exec

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

أين يُطبَّق

تُفرض موافقات Exec محليًا على مضيف التنفيذ:
  • مضيف gateway ← عملية openclaw على جهاز gateway
  • مضيف node ← مشغّل العقدة (تطبيق macOS المرافق أو مضيف عقدة بلا واجهة)
ملاحظة حول نموذج الثقة:
  • يُعد المتصلون الموثَّقون لدى Gateway مشغّلين موثوقين لذلك Gateway.
  • تمدّ العقد المقترنة هذه القدرة الموثوقة للمشغّل إلى مضيف العقدة.
  • تقلل موافقات Exec من خطر التنفيذ غير المقصود، لكنها ليست حد مصادقة لكل مستخدم.
  • تربط التشغيلات الموافق عليها على مضيف العقدة سياق التنفيذ القياسي: cwd القياسي وargv الدقيق وربط env عند وجوده، ومسار الملف التنفيذي المثبّت عند انطباقه.
  • بالنسبة إلى نصوص shell وعمليات استدعاء ملفات المفسّر/بيئة التشغيل المباشرة، يحاول OpenClaw أيضًا ربط مُعامل ملف محلي ملموس واحد. إذا تغيّر هذا الملف المرتبط بعد الموافقة ولكن قبل التنفيذ، يُرفض التشغيل بدلًا من تنفيذ محتوى تغيّر عن المعتمد.
  • إن ربط الملف هذا هو عمدًا محاولة بأفضل جهد، وليس نموذجًا دلاليًا كاملًا لكل مسارات تحميل المفسّرات/بيئات التشغيل. وإذا تعذّر على وضع الموافقة تحديد ملف محلي ملموس واحد بالضبط لربطه، فإنه يرفض إنشاء تشغيل مدعوم بموافقة بدلًا من الادعاء بتغطية كاملة.
التقسيم على macOS:
  • خدمة مضيف node تمرر system.run إلى تطبيق macOS عبر IPC محلي.
  • تطبيق macOS يفرض الموافقات + ينفّذ الأمر في سياق واجهة المستخدم.

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

توجد الموافقات في ملف JSON محلي على مضيف التنفيذ: ~/.openclaw/exec-approvals.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” بدون موافقات

إذا كنت تريد أن يعمل host 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: داخل sandbox عند توفره، وإلا فعلى gateway.
  • يحدد YOLO كيفية الموافقة على host exec: ‏security=full مع ask=off.
  • لا يجعل auto التوجيه إلى gateway تجاوزًا مجانيًا من جلسة داخل sandbox. يُسمح بطلب host=node لكل استدعاء من auto، ولا يُسمح بـ host=gateway من auto إلا عندما لا تكون هناك بيئة تشغيل sandbox نشطة. إذا أردت افتراضيًا ثابتًا غير auto، فاضبط tools.exec.host أو استخدم /exec host=... صراحة.
إذا أردت إعدادًا أكثر تحفظًا، فأعد إحكام أي من الطبقتين إلى allowlist / on-miss أو deny. إعداد دائم لمضيف gateway مع “عدم السؤال مطلقًا”:
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
ثم اضبط ملف موافقات المضيف ليطابق ذلك:
openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
بالنسبة إلى مضيف node، طبّق ملف الموافقات نفسه على تلك العقدة بدلًا من ذلك:
openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
اختصار خاص بالجلسة فقط:
  • /exec security=full ask=off يغيّر الجلسة الحالية فقط.
  • /elevated full هو اختصار للطوارئ يتخطى أيضًا موافقات exec لتلك الجلسة.
إذا بقي ملف موافقات المضيف أكثر تقييدًا من الإعدادات، فإن سياسة المضيف الأشد تقييدًا تظل هي السارية.

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

الأمان (exec.security)

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

السؤال (exec.ask)

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

الاحتياط عند السؤال (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 ثابت يُستخدم لهوية واجهة المستخدم (اختياري)
  • last used الطابع الزمني لآخر استخدام
  • last used command
  • last resolved path

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

عند تمكين السماح التلقائي لـ CLI الخاصة بـ Skills، تُعامل الملفات التنفيذية المشار إليها من Skills المعروفة على أنها موجودة في قائمة السماح على العقد (عقدة macOS أو مضيف عقدة بلا واجهة). يستخدم هذا skills.bins عبر Gateway RPC لجلب قائمة bin الخاصة بالمهارة. عطّل هذا إذا أردت قوائم سماح يدوية صارمة. ملاحظات ثقة مهمة:
  • هذه قائمة سماح ضمنية لتسهيل الاستخدام، منفصلة عن إدخالات قائمة السماح اليدوية للمسارات.
  • وهي مخصصة لبيئات المشغّل الموثوق حيث يكون Gateway والعقدة ضمن حد الثقة نفسه.
  • إذا كنت تحتاج إلى ثقة صريحة صارمة، فأبقِ autoAllowSkills: false واستخدم فقط إدخالات قائمة السماح اليدوية للمسارات.

الملفات التنفيذية الآمنة (stdin-only)

يعرّف tools.exec.safeBins قائمة صغيرة من الملفات التنفيذية stdin-only (مثل cut) يمكن تشغيلها في وضع قائمة السماح من دون إدخالات صريحة في قائمة السماح. ترفض الملفات التنفيذية الآمنة وسائط الملفات الموضعية والرموز الشبيهة بالمسارات، لذلك لا يمكنها العمل إلا على الدفق الوارد. تعامل مع هذا كمسار سريع ضيق لمرشحات الدفق، وليس كقائمة ثقة عامة. لا تضف ملفات تنفيذية للمفسّرات أو بيئات التشغيل (مثل python3 أو node أو ruby أو bash أو sh أو zsh) إلى safeBins. إذا كان الأمر قادرًا على تقييم شيفرة، أو تنفيذ أوامر فرعية، أو قراءة ملفات بطبيعته، ففضّل إدخالات قائمة السماح الصريحة وأبقِ مطالبات الموافقة مفعلة. يجب أن تعرّف الملفات التنفيذية الآمنة المخصصة ملف تعريف صريحًا في tools.exec.safeBinProfiles.<bin>. التحقق حتمي ويعتمد فقط على شكل argv (من دون فحوص وجود ملفات على نظام ملفات المضيف)، مما يمنع سلوك الاستدلال على وجود الملفات من اختلافات السماح/المنع. تُرفض الخيارات الموجّهة للملفات بالنسبة إلى الملفات التنفيذية الآمنة الافتراضية (مثل 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 التكرارية). تُتحقق الخيارات الطويلة بطريقة fail-closed في وضع safe-bin: تُرفض الأعلام غير المعروفة والاختصارات الملتبسة. الأعلام المرفوضة حسب ملف تعريف safe-bin:
  • 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 على أنها نص حرفي وقت التنفيذ (من دون globbing ومن دون توسيع $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. لا يُسمح تلقائيًا بسلاسل shell وإعادات التوجيه في وضع قائمة السماح. يُسمح بسلاسل shell (&&, ||, ;) عندما يستوفي كل مقطع علوي شروط قائمة السماح (بما في ذلك الملفات التنفيذية الآمنة أو السماح التلقائي لـ Skills). تظل إعادات التوجيه غير مدعومة في وضع قائمة السماح. يُرفض استبدال الأوامر ($() / 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) تحفظ مسارات الملفات التنفيذية الداخلية بدلًا من مسارات المغلفات. كما تُفكك مضاعِفات shell (busybox, toybox) أيضًا لتطبيقات shell الصغيرة (sh, ash, وغيرها) بحيث تُحفَظ الملفات التنفيذية الداخلية بدلًا من ملفات multiplexer التنفيذية. وإذا تعذّر فك مغلف أو multiplexer بأمان، فلن يُحفَظ أي إدخال في قائمة السماح تلقائيًا. إذا وضعت مفسّرات مثل python3 أو node في قائمة السماح، ففضّل tools.exec.strictInlineEval=true حتى يظل inline eval يتطلب موافقة صريحة. في الوضع الصارم، يمكن لـ allow-always مع ذلك حفظ استدعاءات المفسّر/النص البرمجي السليمة، لكن حوامل inline-eval لا تُحفَظ تلقائيًا. الملفات التنفيذية الآمنة الافتراضية: cut, uniq, head, tail, tr, wc لا يوجد grep وsort في القائمة الافتراضية. إذا اخترت إضافتهما، فأبقِ إدخالات قائمة السماح الصريحة لتدفقات العمل غير المعتمدة على stdin الخاصة بهما. بالنسبة إلى grep في وضع safe-bin، قدّم النمط باستخدام -e/--regexp؛ ويُرفض شكل النمط الموضعي حتى لا يمكن تهريب معاملات الملفات كوسائط موضعية ملتبسة.

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

الموضوعtools.exec.safeBinsقائمة السماح (exec-approvals.json)
الهدفالسماح التلقائي لمرشحات stdin الضيقةالثقة الصريحة في ملفات تنفيذية محددة
نوع المطابقةاسم الملف التنفيذي + سياسة argv الخاصة بـ safe-binنمط glob لمسار الملف التنفيذي المحلول
نطاق الوسائطمقيّد بملف تعريف safe-bin وقواعد الرموز الحرفيةمطابقة المسار فقط؛ أما الوسائط فمسؤوليتها عليك
أمثلة شائعةhead, tail, tr, wcjq, 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_900004 إذا اخترت صراحة إضافة jq إلى safeBins، فسيظل OpenClaw يرفض builtin env في وضع safe-bin حتى لا يستطيع jq -n env تفريغ متغيرات بيئة عملية المضيف من دون مسار صريح في قائمة السماح أو مطالبة موافقة.

التحرير في Control UI

استخدم بطاقة Control UI → Nodes → Exec approvals لتحرير الافتراضيات، والتجاوزات لكل وكيل، وقوائم السماح. اختر نطاقًا (الافتراضيات أو وكيلًا)، وعدّل السياسة، وأضف/أزل أنماط قائمة السماح، ثم احفظ. تعرض واجهة المستخدم بيانات آخر استخدام لكل نمط حتى تتمكن من إبقاء القائمة مرتبة. يختار محدد الهدف Gateway (الموافقات المحلية) أو Node. يجب على العقد أن تعلن system.execApprovals.get/set (تطبيق macOS أو مضيف عقدة بلا واجهة). إذا كانت العقدة لا تعلن موافقات exec بعد، فحرّر ملفها المحلي ~/.openclaw/exec-approvals.json مباشرة. CLI: يدعم openclaw approvals تحرير gateway أو node (انظر Approvals CLI).

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

عندما تكون المطالبة مطلوبة، يبث gateway الحدث exec.approval.requested إلى عملاء المشغّل. وتحل Control UI وتطبيق macOS ذلك عبر exec.approval.resolve، ثم يمرّر gateway الطلب الموافق عليه إلى مضيف العقدة. بالنسبة إلى host=node، تتضمن طلبات الموافقة حمولة systemRunPlan قياسية. ويستخدم gateway هذه الخطة بوصفها سياق الأمر/‏cwd/الجلسة المعتمد عند تمرير طلبات system.run الموافق عليها. وهذا مهم لزمن تأخر الموافقة غير المتزامن:
  • يُعد مسار exec الخاص بالعقدة خطة قياسية واحدة مقدمًا
  • ويخزّن سجل الموافقة تلك الخطة وبيانات الربط الخاصة بها
  • وبمجرد الموافقة، يعيد استدعاء system.run النهائي استخدام الخطة المخزنة بدلًا من الوثوق بتعديلات لاحقة من جهة المستدعي
  • وإذا غيّر المستدعي command أو rawCommand أو cwd أو agentId أو sessionKey بعد إنشاء طلب الموافقة، يرفض gateway التشغيل المُمرّر باعتباره عدم تطابق مع الموافقة

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

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

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

بعد انتهاء exec غير المتزامن الموافق عليه، يرسل OpenClaw دور agent متابعة إلى الجلسة نفسها.
  • إذا وُجد هدف تسليم خارجي صالح (قناة قابلة للتسليم مع الهدف to)، تستخدم المتابعة تلك القناة.
  • في تدفقات webchat فقط أو الجلسات الداخلية من دون هدف خارجي، يبقى تسليم المتابعة داخل الجلسة فقط (deliver: false).
  • إذا طلب المستدعي صراحة تسليمًا خارجيًا صارمًا من دون قناة خارجية قابلة للحل، يفشل الطلب مع INVALID_REQUEST.
  • إذا كان bestEffortDeliver مفعّلًا ولم يمكن حل أي قناة خارجية، فيُخفَّض التسليم إلى داخل الجلسة فقط بدلًا من الفشل.
يتضمن مربع حوار التأكيد:
  • الأمر + الوسائط
  • cwd
  • معرّف الوكيل
  • مسار الملف التنفيذي المحلول
  • بيانات المضيف + السياسة
الإجراءات:
  • Allow once → شغّل الآن
  • Always allow → أضف إلى قائمة السماح + شغّل
  • Deny → احظر

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

يمكنك تمرير مطالبات موافقة exec إلى أي قناة دردشة (بما في ذلك قنوات plugin) والموافقة عليها باستخدام /approve. يستخدم هذا مسار التسليم الصادر العادي. الإعدادات: OC_I18N_900005 الرد في الدردشة: OC_I18N_900006 يتعامل الأمر /approve مع كل من موافقات exec وموافقات plugin. إذا لم يطابق المعرّف موافقة exec معلقة، فإنه يتحقق تلقائيًا من موافقات plugin بدلًا من ذلك.

تمرير موافقة plugin

يستخدم تمرير موافقة plugin مسار التسليم نفسه المستخدم لموافقات exec لكنه يملك إعدادات مستقلة خاصة به تحت approvals.plugin. لا يؤثر تمكين أحدهما أو تعطيله على الآخر. OC_I18N_900007 بنية الإعدادات مطابقة لـ approvals.exec: تعمل enabled وmode وagentFilter وsessionFilter وtargets بالطريقة نفسها. تعرض القنوات التي تدعم الردود التفاعلية المشتركة أزرار الموافقة نفسها لكل من موافقات exec وplugin. أما القنوات التي لا تدعم واجهة تفاعلية مشتركة فترجع إلى نص عادي مع تعليمات /approve.

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

عندما ينشأ طلب موافقة exec أو plugin من سطح دردشة قابل للتسليم، يمكن للدردشة نفسها الآن الموافقة عليه باستخدام /approve افتراضيًا. ينطبق هذا على قنوات مثل Slack وMatrix و Microsoft Teams بالإضافة إلى تدفقات Web UI وواجهة الطرفية الحالية. يستخدم مسار الأوامر النصية المشترك هذا نموذج المصادقة العادي للقناة لتلك المحادثة. وإذا كانت الدردشة الأصلية تستطيع بالفعل إرسال الأوامر واستلام الردود، فلن تعود طلبات الموافقة بحاجة إلى مهايئ تسليم محلي منفصل لمجرد البقاء معلقة. يدعم كل من Discord وTelegram أيضًا /approve في الدردشة نفسها، لكن هاتين القناتين ما زالتا تستخدمان قائمة الموافقين المحلولة الخاصة بهما للتفويض حتى عند تعطيل التسليم المحلي للموافقات. وبالنسبة إلى Telegram والعملاء المحليين الآخرين للموافقات الذين يستدعون Gateway مباشرة، فإن هذا الاحتياط مقيد عمدًا بحالات فشل “الموافقة غير موجودة”. ولا يُعاد بصمت محاولة رفض/خطأ موافقة exec الحقيقية على أنها موافقة plugin.

التسليم المحلي للموافقة

يمكن لبعض القنوات أيضًا أن تعمل كعملاء موافقة محليين. يضيف العملاء المحليون الرسائل الخاصة بالموافقين، والتوزيع في دردشة المنشأ، وتجربة استخدام تفاعلية خاصة بالقناة للموافقة فوق تدفق /approve المشترك في الدردشة نفسها. عندما تكون بطاقات/أزرار الموافقة المحلية متاحة، تكون هذه الواجهة المحلية هي المسار الأساسي المواجه للوكيل. لا ينبغي للوكيل أيضًا أن يكرر أمر /approve بنص عادي ما لم تذكر نتيجة الأداة أن موافقات الدردشة غير متاحة أو أن الموافقة اليدوية هي المسار الوحيد المتبقي. النموذج العام:
  • ما زالت سياسة host exec هي التي تحدد ما إذا كانت موافقة exec مطلوبة
  • يتحكم approvals.exec في تمرير مطالبات الموافقة إلى وجهات دردشة أخرى
  • يتحكم channels.<channel>.execApprovals فيما إذا كانت تلك القناة تعمل كعميل موافقة محلي
يقوم عملاء الموافقة المحليون بالتمكين التلقائي للتسليم الخاص بالرسائل المباشرة أولًا عندما تكون جميع الشروط التالية صحيحة:
  • تدعم القناة التسليم المحلي للموافقة
  • يمكن حل الموافقين من execApprovals.approvers الصريح أو من مصادر الاحتياط الموثقة لتلك القناة
  • تكون 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.*
تضيف عملاء الموافقة المحليون هؤلاء توجيه الرسائل الخاصة وخيار التوزيع على القناة فوق تدفق /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 في Matrix فتبقى على مساري /approve المشترك في الدردشة نفسها وتمرير approvals.plugin الاختياري
  • لا يلزم أن يكون مقدّم الطلب من الموافقين
  • يمكن للدردشة الأصلية الموافقة مباشرة باستخدام /approve عندما تكون تلك الدردشة تدعم بالفعل الأوامر والردود
  • توجّه أزرار الموافقة المحلية في Discord بحسب نوع معرّف الموافقة: تذهب معرّفات plugin: مباشرة إلى موافقات plugin، وكل شيء آخر يذهب إلى موافقات exec
  • تتبع أزرار الموافقة المحلية في Telegram الاحتياط المحدود نفسه من exec إلى plugin كما في /approve
  • عندما يفعّل target المحلي التسليم إلى دردشة المنشأ، تتضمن مطالبات الموافقة نص الأمر
  • تنتهي صلاحية موافقات exec المعلقة بعد 30 دقيقة افتراضيًا
  • إذا لم توجد واجهة مشغّل أو عميل موافقة مهيأ يمكنه قبول الطلب، تعود المطالبة إلى askFallback
يكون الوضع الافتراضي في Telegram هو الرسائل الخاصة للموافقين (target: "dm"). يمكنك التبديل إلى channel أو both عندما تريد أن تظهر مطالبات الموافقة أيضًا في دردشة/موضوع Telegram الأصلي. وبالنسبة إلى موضوعات منتديات Telegram، يحتفظ OpenClaw بالموضوع لكل من مطالبة الموافقة والمتابعة بعد الموافقة. راجع:

تدفق IPC على macOS

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

أحداث النظام

يظهر مسار حياة Exec كرسائل نظام:
  • Exec running (فقط إذا تجاوز الأمر عتبة إشعار التشغيل)
  • Exec finished
  • Exec denied
تُنشر هذه الرسائل في جلسة الوكيل بعد أن تُبلغ العقدة عن الحدث. تُصدر موافقات exec على مضيف gateway أحداث دورة الحياة نفسها عندما ينتهي الأمر (واختياريًا عندما يستمر التشغيل فترة أطول من العتبة). تعيد execات التي تخضع لبوابة الموافقة استخدام معرّف الموافقة كـ runId في هذه الرسائل لتسهيل الربط.

سلوك الرفض عند عدم الموافقة

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

الآثار

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

ذو صلة