تأییدیه‌های اجرا

تأییدهای اجرا، سازوکار حفاظتی برنامه همراه / میزبان Node برای اجازه‌دادن به عامل سندباکس‌شده جهت اجرای فرمان‌ها روی یک میزبان واقعی (gateway یا node) هستند. فرمان‌ها فقط زمانی اجرا می‌شوند که سیاست + فهرست مجاز + تأیید کاربر (اختیاری) همگی موافق باشند. تأییدها علاوه بر سیاست ابزار و محدودیت دسترسی ارتقایافته اعمال می‌شوند (حالت ارتقایافته full از آن‌ها صرف‌نظر می‌کند).

برای نمایی کلی با محوریت حالت‌های deny، allowlist، ask، auto، full، نگاشت Codex Guardian و مجوزهای چارچوب ACPX، به حالت‌های مجوز مراجعه کنید.

محل اعمال

تأییدهای اجرا به‌صورت محلی روی میزبان اجرا اعمال می‌شوند:

• میزبان Gateway -> فرایند openclaw روی دستگاه Gateway.
• میزبان Node -> اجراکننده Node (برنامه همراه macOS یا میزبان Node بدون رابط گرافیکی).

مدل اعتماد

• فراخوان‌هایی که با Gateway احراز هویت شده‌اند، برای آن Gateway گردانندگان مورداعتماد محسوب می‌شوند.
• Nodeهای جفت‌شده، این قابلیت گرداننده مورداعتماد را به میزبان Node گسترش می‌دهند.
• تأییدها خطر اجرای تصادفی را کاهش می‌دهند، اما مرز احراز هویت برای هر کاربر یا سیاست فقط‌خواندنی سیستم فایل نیستند.
• پس از تأیید، فرمان می‌تواند مطابق مجوزهای سیستم فایل میزبان یا سندباکس انتخاب‌شده، فایل‌ها را تغییر دهد.
• اجراهای تأییدشده روی میزبان Node، زمینه اجرای کانونی را مقید می‌کنند: cwd، argv دقیق، اتصال env در صورت وجود، و مسیر ثابت‌شده فایل اجرایی در موارد مقتضی.
• برای اسکریپت‌های پوسته و فراخوانی مستقیم فایل توسط مفسر/محیط اجرا، OpenClaw همچنین تلاش می‌کند یک عملوند مشخصِ فایل محلی را مقید کند. اگر آن فایل پس از تأیید اما پیش از اجرا تغییر کند، به‌جای اجرای محتوای تغییریافته، اجرا رد می‌شود.
• مقیدسازی فایل بر پایه بهترین تلاش است و مدل کاملی از همه مسیرهای بارگذاری مفسر/محیط اجرا نیست. اگر نتوان دقیقاً یک فایل محلی مشخص را شناسایی کرد، OpenClaw به‌جای وانمودکردن پوشش کامل، از ایجاد اجرای متکی بر تأیید خودداری می‌کند.

تفکیک در macOS

• سرویس میزبان Node، system.run را از طریق IPC محلی به برنامه macOS ارسال می‌کند.
• برنامه macOS تأییدها را اعمال می‌کند و فرمان را در زمینه رابط کاربری اجرا می‌کند.

بررسی سیاست مؤثر

مرجع کامل CLI (پرچم‌ها، خروجی JSON، افزودن/حذف فهرست مجاز): CLI تأییدها.

وقتی یک حوزه محلی host=node را درخواست می‌کند، exec-policy show به‌جای آنکه فایل تأییدهای محلی را منبع حقیقت در نظر بگیرد، آن حوزه را هنگام اجرا تحت مدیریت Node گزارش می‌کند.

اگر رابط کاربری برنامه همراه در دسترس نباشد، هر درخواستی که در حالت عادی اعلان تأیید نمایش می‌دهد، با بازگشت پرسش (پیش‌فرض: deny) تعیین تکلیف می‌شود.

تنظیمات و ذخیره‌سازی

تأییدها در یک فایل JSON محلی روی میزبان اجرا نگهداری می‌شوند. وقتی OPENCLAW_STATE_DIR تنظیم شده باشد، فایل از همان دایرکتوری وضعیت پیروی می‌کند؛ در غیر این صورت از دایرکتوری پیش‌فرض وضعیت OpenClaw استفاده می‌شود:

$OPENCLAW_STATE_DIR/exec-approvals.json# در غیر این صورت~/.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 بایگانی می‌شود). ابزار doctor تعاملی نیز می‌تواند واردسازی را پیش‌نمایش کند و تأیید بگیرد. اجراهای خودکارِ به‌روزرسانی و ترمیم نظارتی 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 که حالت مجوز غیرتعاملی خود را ارائه می‌کنند، می‌توانند از این سیاست پیروی کنند. هنگامی که سیاست مؤثر اجرای OpenClaw روی YOLO باشد، Claude CLI گزینهٔ --permission-mode bypassPermissions را اضافه می‌کند. برای نشست‌های زندهٔ 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 باشد، rg می‌تواند با /opt/homebrew/bin/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 شناخته‌شده در Nodeها (Node مربوط به macOS یا میزبان Node بدون رابط گرافیکی) در فهرست مجاز در نظر گرفته می‌شوند. این قابلیت برای دریافت فهرست باینری‌های Skill از skills.bins روی RPC مربوط به Gateway استفاده می‌کند. اگر فهرست‌های مجاز دستی و سخت‌گیرانه می‌خواهید، این گزینه را غیرفعال کنید.

باینری‌های امن و ارسال تأییدها

برای باینری‌های امن (مسیر سریع فقط از طریق stdin)، جزئیات اتصال مفسر و نحوهٔ ارسال درخواست‌های تأیید به Slack/Discord/Telegram (یا اجرای آن‌ها به‌عنوان کارخواه‌های بومی تأیید)، به تأییدهای اجرا — پیشرفته مراجعه کنید.

ویرایش رابط کنترل

برای ویرایش پیش‌فرض‌ها، بازنویسی‌های مختص عامل و فهرست‌های مجاز، از کارت رابط کنترل -> Nodeها -> تأییدهای اجرا استفاده کنید. یک دامنه (پیش‌فرض‌ها یا یک عامل) انتخاب کنید، سیاست را تغییر دهید، الگوهای فهرست مجاز را اضافه یا حذف کنید و سپس ذخیره را بزنید. رابط کاربری فرادادهٔ آخرین استفاده را برای هر الگو نشان می‌دهد تا بتوانید فهرست را مرتب نگه دارید.

انتخاب‌گر مقصد، Gateway (تأییدهای محلی) یا یک Node را انتخاب می‌کند. Nodeها باید 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 هنگام ارسال درخواست‌های تأییدشدهٔ system.run، از این طرح به‌عنوان زمینهٔ مرجع و قطعی فرمان/cwd/نشست استفاده می‌کند:

• مسیر اجرای Node از ابتدا یک طرح استاندارد آماده می‌کند.
• رکورد تأیید، آن طرح و فرادادهٔ اتصال آن را ذخیره می‌کند.
• پس از تأیید، فراخوانی نهایی و ارسال‌شدهٔ system.run به‌جای اعتماد به ویرایش‌های بعدی فراخوان، از طرح ذخیره‌شده دوباره استفاده می‌کند.
• اگر فراخوان پس از ایجاد درخواست تأیید، command، rawCommand، cwd، agentId یا sessionKey را تغییر دهد، Gateway اجرای ارسال‌شده را به‌دلیل عدم تطابق تأیید رد می‌کند.

رویدادهای سامانه و رد درخواست‌ها

چرخهٔ اجرای فرمان پس از آنکه Node تکمیل را گزارش کند، پیام سامانه‌ای Exec finished را در نشست عامل ارسال می‌کند. 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 را از طریق سیاست ابزار رد کنید.

مرتبط