موافقات التنفيذ

موافقات التنفيذ هي آلية الحماية في التطبيق المرافق / مضيف Node للسماح لوكيل يعمل ضمن بيئة معزولة بتشغيل الأوامر على مضيف فعلي (gateway أو node). لا تُشغَّل الأوامر إلا عند توافق السياسة + قائمة السماح + موافقة المستخدم (الاختيارية) جميعًا. تُطبَّق الموافقات فوق سياسة الأدوات وبوابة الصلاحيات المرتفعة (يتجاوزها full المرتفع).

للحصول على نظرة عامة مرتبة حسب الوضع حول deny وallowlist وask وauto وfull وتعيين Codex Guardian وأذونات حاضنة ACPX، راجع أوضاع الأذونات.

نطاق التطبيق

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

• مضيف Gateway -> عملية openclaw على جهاز Gateway.
• مضيف Node -> مشغّل Node (التطبيق المرافق لنظام macOS أو مضيف Node دون واجهة رسومية).

نموذج الثقة

• يُعد المتصلون المصادق عليهم عبر Gateway مشغّلين موثوقين لذلك الـ Gateway.
• توسّع عُقد Node المقترنة قدرة المشغّل الموثوق هذه إلى مضيف Node.
• تقلل الموافقات مخاطر التنفيذ العرضي، لكنها ليست حدًا للمصادقة لكل مستخدم ولا سياسة للقراءة فقط من نظام الملفات.
• بعد الموافقة، يمكن للأمر تعديل الملفات وفق أذونات نظام ملفات المضيف أو البيئة المعزولة المحددة.
• تربط عمليات مضيف Node الموافق عليها سياق التنفيذ القياسي: دليل العمل الحالي، ووسائط argv الدقيقة، وربط البيئة عند وجوده، ومسار الملف التنفيذي المثبّت عند انطباقه.
• بالنسبة إلى نصوص الصدفة البرمجية والاستدعاءات المباشرة لملفات المفسّر/بيئة التشغيل، يحاول OpenClaw أيضًا ربط مُعامل واحد لملف محلي محدد. إذا تغيّر ذلك الملف بعد الموافقة وقبل التنفيذ، تُرفض العملية بدلًا من تنفيذ محتوى متغير.
• ربط الملفات هو إجراء بأفضل جهد ممكن، وليس نموذجًا شاملًا لكل مسار تحميل خاص بالمفسّرات/بيئات التشغيل. إذا تعذّر تحديد ملف محلي محدد واحد بالضبط، يرفض OpenClaw إنشاء عملية مدعومة بالموافقة بدلًا من الادعاء بتغطية كاملة.

الفصل في macOS

• تعيد خدمة مضيف Node توجيه system.run إلى تطبيق macOS عبر IPC محلي.
• يفرض تطبيق macOS الموافقات وينفّذ الأمر ضمن سياق واجهة المستخدم.

فحص السياسة الفعلية

مرجع CLI الكامل (العلامات، ومخرجات JSON، والإضافة إلى قائمة السماح/الإزالة منها): CLI للموافقات.

عندما يطلب نطاق محلي host=node، يفيد exec-policy show بأن ذلك النطاق تديره Node في وقت التشغيل بدلًا من اعتبار ملف الموافقات المحلي مصدر الحقيقة.

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

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

توجد الموافقات في ملف JSON محلي على مضيف التنفيذ. عند تعيين OPENCLAW_STATE_DIR، يتبع الملف دليل الحالة ذاك؛ وإلا فإنه يستخدم دليل حالة OpenClaw الافتراضي:

$OPENCLAW_STATE_DIR/exec-approvals.json# otherwise~/.openclaw/exec-approvals.json

يتبع مقبس الموافقات الافتراضي الجذر نفسه: $OPENCLAW_STATE_DIR/exec-approvals.sock، أو ~/.openclaw/exec-approvals.sock عندما لا يكون المتغير معيّنًا.

كانت الإصدارات السابقة لـ 2026.6.6 تحفظ الملف دائمًا في ~/.openclaw. إذا كان OPENCLAW_STATE_DIR يشير إلى مكان آخر وما زال ملف موافقات موجودًا في الدليل الافتراضي، فشغّل openclaw doctor --fix مباشرة مرة واحدة لاستيراده إلى دليل الحالة (تُؤرشف النسخة الأصلية بلاحقة .migrated). يمكن أيضًا لأداة الفحص التفاعلية معاينة الاستيراد وتأكيده. لا تستورد عمليات التحديث المؤتمتة وإصلاح مراقبة Gateway عبر أدلة الحالة مطلقًا: يجب ألا يستحوذ دليل حالة مؤقت أو تجهيزي على موافقات التثبيت الافتراضي. ينطبق الحد نفسه على استيراد ملفات plugin-binding-approvals.json القديمة إلى حالة SQLite المشتركة.

مثال على المخطط:

{  "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",          "source": "allow-always",          "lastUsedAt": 1737150000000,          "lastUsedCommand": "rg -n TODO",          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"        }      ]    }  }}

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

tools.exec.mode

يمثل tools.exec.mode سطح السياسة الموحّد المفضّل لتنفيذ المضيف:

يظل tools.exec.security / tools.exec.ask القديمان مدعومين ويستمران في التطبيق حيثما لا يكون mode معيّنًا في ذلك النطاق.

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

أمثلة يلتقطها الوضع الصارم: python -c، وnode -e/--eval/-p، وruby -e، وperl -e/-E، وphp -r، وlua -e، وosascript -e (وكذلك الصيغ المضمّنة في awk وsed وmake وfind -exec وxargs).

في الوضع الصارم، تحتاج هذه الأوامر إلى موافقة المراجع أو موافقة صريحة. مع tools.exec.mode: "auto"، قد يمنح المراجع تنفيذًا واحدًا منخفض المخاطر عندما يكون للأمر مخطط قابل للإنفاذ؛ وإلا يطلب OpenClaw موافقة بشرية. تطلب موافقات أوامر Codex app-server التي تصل إلى الإجراء الاحتياطي للمراجع موافقة بشرية لأن طلبات الموافقة الخاصة بها لا تكشف ملفًا تنفيذيًا محلولًا وقابلًا للإنفاذ. لا ينشئ allow-always إدخالات جديدة دائمة في قائمة السماح لأوامر التقييم المضمّن.

tools.exec.commandHighlighting

عيّنه عموميًا ضمن tools.exec.commandHighlighting أو لكل وكيل ضمن agents.list[].tools.exec.commandHighlighting.

وضع YOLO (دون موافقة)

لتشغيل تنفيذ المضيف دون مطالبات موافقة، افتح كلتا طبقتي السياسة: سياسة التنفيذ المطلوبة في إعداد OpenClaw (tools.exec.*) و سياسة الموافقات المحلية للمضيف في ملف موافقات مضيف التنفيذ.

القيمة الافتراضية لـ askFallback عند إغفالها هي deny. عيّن askFallback للمضيف إلى full صراحةً عندما ينبغي أن يؤدي تعذر عرض مطالبة الموافقة في واجهة المستخدم إلى السماح.

يمكن لموفّري الخدمات المدعومين بـ CLI، الذين يوفّرون وضع أذونات غير تفاعلي خاصًا بهم، اتباع هذه السياسة. يضيف Claude CLI الخيار --permission-mode bypassPermissions عندما تكون سياسة التنفيذ الفعلية في OpenClaw هي YOLO. بالنسبة إلى جلسات Claude المباشرة التي يديرها OpenClaw، تكون سياسة التنفيذ الفعلية في OpenClaw هي المرجع الحاسم بدلًا من وضع الأذونات الأصلي في Claude: تُوحِّد YOLO عمليات التشغيل المباشر إلى --permission-mode bypassPermissions، بينما تُوحِّد سياسة التنفيذ الفعلية المقيِّدة عمليات التشغيل المباشر إلى --permission-mode default، حتى إذا حدّدت وسيطات الواجهة الخلفية الخام لـ Claude وضعًا آخر.

إذا أردت إعدادًا أكثر تحفظًا، فشدّد سياسة التنفيذ في OpenClaw مجددًا إلى allowlist / on-miss أو deny.

إعداد دائم «دون مطالبة مطلقًا» على مضيف Gateway

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

openclaw approvals set --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

اختصار محلي

openclaw exec-policy preset yolo

يحدّث كلًا من tools.exec.host/security/ask المحلي والقيم الافتراضية لملف الموافقات المحلي (بما فيها askFallback: "full"). وقد صُمّم عمدًا للعمل محليًا فقط. لتغيير موافقات مضيف Gateway أو مضيف Node عن بُعد، استخدم openclaw approvals set --gateway أو openclaw approvals set --node <id|name|ip>.

الإعدادات المسبقة المضمّنة الأخرى: cautious (host=gateway، وsecurity=allowlist، وask=on-miss، وaskFallback=deny) وdeny-all (host=gateway، وsecurity=deny، وask=off، وaskFallback=deny). طبّقها بالطريقة نفسها: openclaw exec-policy preset cautious.

لتعيين حقول منفردة بدلًا من إعداد مسبق كامل، استخدم openclaw exec-policy set --host <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> مع أي مجموعة فرعية من هذه العلامات.

مضيف Node

طبّق ملف الموافقات نفسه على 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 اختصارًا للطوارئ يتجاوز موافقات التنفيذ فقط عندما تُحلّ كل من السياسة المطلوبة وملف موافقات المضيف إلى security: "full" وask: "off". ويظل ملف المضيف الأكثر تقييدًا، مثل ask: "always"، يطلب الموافقة.

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

قائمة السماح (لكل وكيل)

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

يمكن أن تكون الأنماط إما أنماط glob لمسارات الملفات التنفيذية المحلولة أو أنماط glob لأسماء الأوامر المجرّدة. لا تطابق الأسماء المجرّدة إلا الأوامر المستدعاة عبر PATH، لذا يمكن أن يطابق rg المسار /opt/homebrew/bin/rg عندما يكون الأمر هو rg، لكن ليس ./rg أو /tmp/rg. استخدم نمط glob للمسار للوثوق بموقع ملف تنفيذي محدد.

تُنقل إدخالات agents.default القديمة إلى agents.main عند التحميل. ولا تزال سلاسل الصدفة مثل echo ok && pwd تتطلب استيفاء كل مقطع من المستوى الأعلى لقواعد قائمة السماح.

أمثلة:

• rg
• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

تقييد الوسيطات باستخدام argPattern

أضف argPattern عندما ينبغي لإدخال في قائمة السماح مطابقة ملف تنفيذي وشكل محدد للوسيطات. يستخدم OpenClaw دلالات التعبيرات النمطية في ECMAScript (JavaScript) على كل مضيف، ويقيّم التعبير مقابل وسيطات الأمر المحللة، مع استبعاد رمز الملف التنفيذي (argv[0]). بالنسبة إلى الإدخالات المكتوبة يدويًا، تُربط الوسيطات بمسافة واحدة، لذا ثبّت النمط عند الحاجة إلى مطابقة تامة.

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

يسمح هذا الإدخال بـ python3 safe.py؛ أما python3 other.py فلا يطابق قائمة السماح. إذا وُجد أيضًا إدخال يعتمد على المسار فقط للملف التنفيذي نفسه، فلا يزال بإمكان الوسيطات غير المطابقة الرجوع إلى ذلك الإدخال المعتمد على المسار فقط. احذف الإدخال المعتمد على المسار فقط عندما يكون الهدف هو تقييد الملف التنفيذي بالوسيطات المعلنة.

تستخدم الإدخالات المحفوظة بواسطة تدفقات الموافقة تنسيق فاصل داخليًا لمطابقة argv مطابقة تامة. يُفضّل استخدام واجهة المستخدم أو تدفق الموافقة لإعادة إنشاء هذه الإدخالات بدلًا من تحرير القيمة المرمّزة يدويًا. إذا تعذّر على OpenClaw تحليل argv لمقطع أمر، فلن تتطابق الإدخالات التي تحتوي على argPattern.

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

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

عند تفعيل السماح التلقائي بواجهات CLI الخاصة بـ Skills (autoAllowSkills)، تُعامل الملفات التنفيذية المشار إليها بواسطة Skills المعروفة كعناصر مسموح بها في Nodes (Node الخاصة بـ macOS أو مضيف Node دون واجهة). يستخدم ذلك skills.bins عبر استدعاء RPC في Gateway لجلب قائمة الملفات التنفيذية الخاصة بـ Skills. عطّل هذا الخيار إذا كنت تريد قوائم سماح يدوية صارمة.

الملفات التنفيذية الآمنة وإعادة توجيه الموافقات

للحصول على تفاصيل الملفات التنفيذية الآمنة (المسار السريع المعتمد على stdin فقط)، وربط المفسّر، وكيفية إعادة توجيه مطالبات الموافقة إلى Slack/Discord/Telegram (أو تشغيلها كعملاء موافقة أصليين)، راجع موافقات التنفيذ - متقدم.

التحرير عبر واجهة التحكم

استخدم بطاقة Control UI -> Nodes -> Exec approvals لتحرير القيم الافتراضية، والتجاوزات الخاصة بكل وكيل، وقوائم السماح. اختر نطاقًا (Defaults أو وكيلًا)، وعدّل السياسة، وأضف أنماط قائمة السماح أو أزلها، ثم اختر Save. تعرض واجهة المستخدم بيانات وصفية لآخر استخدام لكل نمط كي تتمكن من إبقاء القائمة مرتبة.

يختار محدد الهدف Gateway (الموافقات المحلية) أو Node. يجب أن تعلن Nodes دعم system.execApprovals.get/set (تطبيق macOS أو مضيف Node دون واجهة). إذا لم تعلن Node دعم موافقات التنفيذ بعد، فحرّر ملف الموافقات المحلي الخاص بها مباشرةً.

تمتلك بعض مضيفات Node، ومنها تطبيق Windows المرافق، تنسيقًا مختلفًا لسياسة الموافقات. تعرض واجهة التحكم هذه السياسات الأصلية للمضيف للقراءة فقط. استخدم التطبيق المرافق أو openclaw approvals set --node <id|name|ip> مع شكل السياسة الأصلي لتحريرها؛ راجع CLI للموافقات.

CLI: يدعم openclaw approvals تحرير Gateway أو Node؛ راجع CLI للموافقات.

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

عندما تكون المطالبة مطلوبة، يبث Gateway الحدث exec.approval.requested إلى عملاء المشغّلين. تحلّه واجهة التحكم وتطبيق macOS عبر exec.approval.resolve، ثم يعيد Gateway توجيه الطلب المعتمد إلى مضيف Node.

بالنسبة إلى host=node، تتضمن طلبات الموافقة حمولة systemRunPlan معيارية. يستخدم Gateway هذه الخطة بوصفها السياق المرجعي للأمر/cwd/الجلسة عند إعادة توجيه طلبات system.run المعتمدة:

• يُعدّ مسار التنفيذ في Node خطة معيارية واحدة مسبقًا.
• يخزّن سجل الموافقة تلك الخطة وبيانات الربط الوصفية الخاصة بها.
• بعد الموافقة، يعيد استدعاء system.run النهائي المُعاد توجيهه استخدام الخطة المخزنة بدلًا من الوثوق بتعديلات لاحقة من المستدعي.
• إذا غيّر المستدعي command أو rawCommand أو cwd أو agentId أو sessionKey بعد إنشاء طلب الموافقة، يرفض Gateway التشغيل المُعاد توجيهه بسبب عدم تطابق الموافقة.

أحداث النظام وحالات الرفض

تنشر دورة حياة التنفيذ رسالة نظام Exec finished إلى جلسة الوكيل بعد أن تبلغ Node عن الاكتمال. ويمكن لـ OpenClaw أيضًا إصدار إشعار بأن التنفيذ جارٍ بمجرد منح الموافقة، بعد انقضاء tools.exec.approvalRunningNoticeMs (القيمة الافتراضية 10000، وتؤدي 0 إلى تعطيله). تُعد موافقات التنفيذ المرفوضة نهائية لأمر المضيف: فلا يُشغّل الأمر.

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

تصدر موافقات تنفيذ مضيف Gateway حدث دورة حياة الاكتمال نفسه. تعيد عمليات التنفيذ الخاضعة للموافقة استخدام معرّف الموافقة لربط الطلب المعلّق برسالة اكتماله/رفضه (Exec finished (gateway id=...) / Exec denied (gateway id=...)).

الآثار المترتبة

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

ذو صلة