تأییدهای اجرا — پیشرفته

موضوعات پیشرفتهٔ تأیید اجرای فرمان: مسیر سریع safeBins، مقیدسازی مفسر/محیط اجرا و بازارسال تأیید به کانال‌های گفت‌وگو (از جمله تحویل بومی). برای سیاست اصلی و جریان تأیید، به تأییدهای اجرا مراجعه کنید.

باینری‌های امن (فقط stdin)

tools.exec.safeBins باینری‌های فقط stdin (برای مثال cut) را مشخص می‌کند که در حالت فهرست مجاز، بدون ورودی‌های صریح فهرست مجاز اجرا می‌شوند. باینری‌های امن آرگومان‌های مکانی فایل و توکن‌های شبیه مسیر را رد می‌کنند؛ بنابراین فقط می‌توانند روی جریان ورودی کار کنند. این قابلیت را مسیری سریع و محدود برای پالایه‌های جریان در نظر بگیرید، نه فهرستی عمومی از موارد مورد اعتماد.

باینری‌های امن پیش‌فرض:

cut، uniq، head، tail، tr، wc

grep و sort در فهرست پیش‌فرض نیستند. اگر آن‌ها را فعال می‌کنید، ورودی‌های صریح فهرست مجاز را برای گردش‌کارهای غیر stdin آن‌ها نگه دارید. برای grep در حالت باینری امن، الگو را با -e/--regexp ارائه کنید؛ شکل مکانی الگو رد می‌شود تا عملوندهای فایل نتوانند در قالب آرگومان‌های مکانی مبهم پنهان شوند.

اعتبارسنجی Argv و پرچم‌های ردشده

اعتبارسنجی فقط بر اساس شکل argv و به‌صورت قطعی انجام می‌شود (بدون بررسی وجود فایل در سامانهٔ فایل میزبان)؛ این کار از رفتار پیشگوی وجود فایل ناشی از تفاوت‌های اجازه/رد جلوگیری می‌کند. گزینه‌های فایل‌محور برای باینری‌های امن پیش‌فرض رد می‌شوند؛ گزینه‌های بلند به‌صورت fail-closed اعتبارسنجی می‌شوند (پرچم‌های ناشناخته و اختصارات مبهم رد می‌شوند). پرچم‌های بولی فقط‌خواندنی شناخته‌شدهٔ باینری‌های پیش‌فرض (برای مثال wc -l، tr -d، uniq -c) پذیرفته می‌شوند، درحالی‌که پرچم‌های کوتاه ناشناخته به‌صورت fail-closed باقی می‌مانند و به تأیید دستی واگذار می‌شوند.

پرچم‌های ردشده بر اساس نمایهٔ باینری امن:

• 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
• tail: --follow، --retry، -F، -f
• wc: --files0-from

باینری‌های امن همچنین توکن‌های argv را وادار می‌کنند هنگام اجرا به‌عنوان متن تحت‌اللفظی در نظر گرفته شوند (بدون globbing و بدون گسترش $VARS)؛ بنابراین در قطعه‌های فقط stdin، الگوهایی مانند * یا $HOME/... نمی‌توانند برای پنهان‌سازی خواندن فایل استفاده شوند. awk، sed و jq همیشه به‌عنوان باینری امن رد می‌شوند، زیرا معنای آن‌ها را نمی‌توان به حالت فقط stdin محدود و اعتبارسنجی کرد: jq می‌تواند داده‌های محیط را بخواند و کد jq را از ماژول‌ها یا فایل‌های راه‌اندازی بارگذاری کند. برای این ابزارها به‌جای safeBins، از یک ورودی صریح فهرست مجاز یا اعلان تأیید استفاده کنید.

پوشه‌های باینری مورد اعتماد

باینری‌های امن باید از پوشه‌های باینری مورد اعتماد تفکیک شوند (پیش‌فرض‌های سیستم به‌علاوهٔ 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.entries.*.tools.exec.safeBins مختص هر عامل) می‌آید.
• safeBinTrustedDirs از پیکربندی (tools.exec.safeBinTrustedDirs یا agents.entries.*.tools.exec.safeBinTrustedDirs مختص هر عامل) می‌آید.
• safeBinProfiles از پیکربندی (tools.exec.safeBinProfiles یا agents.entries.*.tools.exec.safeBinProfiles مختص هر عامل) می‌آید. کلیدهای نمایهٔ مختص هر عامل، کلیدهای سراسری را بازنویسی می‌کنند.
• ورودی‌های فهرست مجاز در فایل تأییدهای محلی میزبان زیر agents.<id>.allowlist (یا از طریق رابط کنترل / openclaw approvals allowlist ...) قرار دارند.
• openclaw security audit با tools.exec.safe_bins_interpreter_unprofiled هشدار می‌دهد که باینری‌های مفسر/محیط اجرا بدون نمایه‌های صریح در safeBins ظاهر شوند.
• openclaw doctor --fix می‌تواند ورودی‌های سفارشی مفقود safeBinProfiles.<bin> را به‌صورت {} ایجاد کند (پس از آن بازبینی و محدودشان کنید). باینری‌های مفسر/محیط اجرا به‌طور خودکار ایجاد نمی‌شوند.

نمونهٔ نمایهٔ سفارشی:

{  tools: {    exec: {      safeBins: ["myfilter"],      safeBinProfiles: {        myfilter: {          minPositional: 0,          maxPositional: 0,          allowedValueFlags: ["-n", "--limit"],          deniedFlags: ["-f", "--file", "-c", "--command"],        },      },    },  },}

فرمان‌های مفسر/محیط اجرا

اجراهای مفسر/محیط اجرا با پشتوانهٔ تأیید عمداً محافظه‌کارانه هستند:

• زمینهٔ دقیق argv/cwd/env همیشه مقید می‌شود.
• شکل‌های مستقیم اسکریپت پوسته و فایل مستقیم محیط اجرا، به بهترین نحو ممکن، به یک تصویر لحظه‌ای مشخص از فایل محلی مقید می‌شوند.
• شکل‌های متداول پوشانندهٔ مدیر بسته که همچنان به یک فایل مستقیم محلی تفکیک می‌شوند (برای مثال pnpm exec، pnpm node، npm exec، npx) پیش از مقیدسازی باز می‌شوند.
• اگر OpenClaw نتواند برای یک فرمان مفسر/محیط اجرا دقیقاً یک فایل محلی مشخص را شناسایی کند (برای مثال اسکریپت‌های بسته، شکل‌های eval، زنجیره‌های بارگذار مختص محیط اجرا یا شکل‌های مبهم چندفایلی)، اجرای با پشتوانهٔ تأیید رد می‌شود، به‌جای آنکه پوشش معنایی‌ای را ادعا کند که ندارد.
• برای این گردش‌کارها، محیط ایزوله، یک مرز میزبان جداگانه یا یک گردش‌کار صریح و مورد اعتماد مبتنی بر فهرست مجاز/کامل را ترجیح دهید که در آن اپراتور معنای گسترده‌تر محیط اجرا را می‌پذیرد.

وقتی تأیید لازم باشد، ابزار اجرا بلافاصله با یک شناسهٔ تأیید بازمی‌گردد. از آن شناسه برای هم‌بسته‌سازی رویدادهای سیستمی اجرای تأییدشدهٔ بعدی (Exec finished و Exec running در صورت پیکربندی) استفاده کنید. اگر پیش از پایان مهلت هیچ تصمیمی دریافت نشود، درخواست به‌عنوان پایان مهلت تأیید در نظر گرفته می‌شود و به‌شکل رد نهایی فرمان میزبان نمایش داده می‌شود. برای تأییدهای ناهمگام عامل اصلی که نشست مبدأ دارند، OpenClaw همچنین آن نشست را با یک پیگیری داخلی از سر می‌گیرد تا عامل متوجه شود فرمان اجرا نشده است، به‌جای آنکه بعداً برای جبران نتیجهٔ مفقود اقدام کند. تأییدهای اجرای در انتظار به‌طور پیش‌فرض پس از 30 دقیقه منقضی می‌شوند.

رفتار تحویل پیگیری

پس از پایان اجرای ناهمگام تأییدشده، OpenClaw یک نوبت پیگیری agent به همان نشست ارسال می‌کند. تأییدهای ناهمگام ردشده نیز برای وضعیت رد از همان مسیر پیگیری نشست اصلی استفاده می‌کنند، اما واگذاری‌های محیط اجرای ارتقایافته را ثبت نمی‌کنند و فرمان را اجرا نمی‌کنند. موارد ردشده‌ای که نشست اصلی قابل ازسرگیری ندارند، یا سرکوب می‌شوند یا در صورت وجود مسیر مستقیم امن، از طریق آن گزارش می‌شوند.

• اگر مقصد تحویل خارجی معتبری وجود داشته باشد (کانال قابل تحویل به‌همراه مقصد to)، تحویل پیگیری از آن کانال استفاده می‌کند.
• در جریان‌های فقط گفت‌وگوی وب یا نشست داخلی بدون مقصد خارجی، تحویل پیگیری فقط در نشست باقی می‌ماند (deliver: false).
• اگر فراخواننده‌ای صراحتاً تحویل خارجی سخت‌گیرانه را بدون کانال خارجی قابل تفکیک درخواست کند، درخواست با INVALID_REQUEST شکست می‌خورد.
• اگر bestEffortDeliver فعال باشد و هیچ کانال خارجی‌ای قابل تفکیک نباشد، تحویل به‌جای شکست خوردن به حالت فقط نشست تنزل می‌یابد.

دامنه‌های حداقلی برای کارخواه‌های شخص ثالث

تفکیک تأیید Gateway با دامنهٔ اختصاصی operator.approvals محافظت می‌شود. این موضوع هم برای متد مختص مالک exec.approval.resolve و هم متد مستقل از نوع approval.resolve صدق می‌کند؛ operator.write آن را در بر نمی‌گیرد. داشبوردها و یکپارچه‌سازی‌ها باید فقط دامنه‌های مورد نیاز متدهایی را درخواست کنند که استفاده می‌کنند. دسترسی تفکیک تأیید را اختیاری در سطح اجرای از راه دور در نظر بگیرید و operator.approvals را آگاهانه اعطا کنید، حتی زمانی که کارخواه فقط یک رابط تأیید کوچک ارائه می‌کند.

بازارسال تأیید به کانال‌های گفت‌وگو

می‌توانید اعلان‌های درخواست تأیید exec را به هر کانال چتی (از جمله کانال‌های Plugin) هدایت کنید و آن‌ها را با /approve تأیید کنید. این کار از پایپ‌لاین عادی تحویل خروجی استفاده می‌کند.

پیکربندی:

{  approvals: {    exec: {      enabled: true,      mode: "session", // "session" | "targets" | "both"      agentFilter: ["main"],      sessionFilter: ["discord"], // substring or regex      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

در چت پاسخ دهید:

/approve <id> allow-once/approve <id> allow-always/approve <id> deny

فرمان /approve هم تأییدهای exec و هم تأییدهای Plugin را مدیریت می‌کند. اگر شناسه با هیچ تأیید exec در حال انتظاری مطابقت نداشته باشد، به‌طور خودکار تأییدهای Plugin را بررسی می‌کند. این بازگشت فقط به خطاهای «تأیید یافت نشد» محدود است؛ رد یا خطای واقعی تأیید exec، بی‌سروصدا به‌عنوان تأیید Plugin دوباره امتحان نمی‌شود.

هدایت تأیید Plugin

هدایت تأیید Plugin از همان پایپ‌لاین تحویل تأییدهای exec استفاده می‌کند، اما پیکربندی مستقل خود را در approvals.plugin دارد. فعال یا غیرفعال‌کردن یکی بر دیگری تأثیر نمی‌گذارد. برای رفتار مربوط به ساخت Plugin، فیلدهای درخواست و معنای تصمیم‌ها، به درخواست‌های مجوز Plugin مراجعه کنید.

{  approvals: {    plugin: {      enabled: true,      mode: "targets",      agentFilter: ["main"],      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

ساختار پیکربندی با approvals.exec یکسان است: enabled، mode، agentFilter، sessionFilter و targets به همان شیوه کار می‌کنند.

کانال‌هایی که از پاسخ‌های تعاملی مشترک پشتیبانی می‌کنند، همان دکمه‌های تأیید را برای تأییدهای exec و Plugin نمایش می‌دهند. کانال‌های بدون رابط کاربری تعاملی مشترک، به متن ساده همراه با دستورالعمل‌های /approve بازمی‌گردند. درخواست‌های تأیید Plugin ممکن است تصمیم‌های در دسترس را محدود کنند: سطوح تأیید از مجموعه تصمیم‌های اعلام‌شده درخواست استفاده می‌کنند و Gateway تلاش برای ارسال تصمیمی را که ارائه نشده است رد می‌کند.

تأیید در همان چت در هر کانال

وقتی یک درخواست تأیید exec یا Plugin از یک سطح چت قابل‌تحویل سرچشمه می‌گیرد، همان چت به‌طور پیش‌فرض می‌تواند آن را با /approve تأیید کند. این موضوع، علاوه بر جریان‌های موجود رابط وب و رابط ترمینال، برای Slack، Matrix، Microsoft Teams و چت‌های قابل‌تحویل مشابه نیز صدق می‌کند و از مدل عادی احراز هویت کانال برای آن مکالمه استفاده می‌کند. اگر چت مبدأ از قبل بتواند فرمان ارسال کند و پاسخ دریافت کند، درخواست‌های تأیید دیگر فقط برای در حالت انتظار ماندن به یک آداپتور تحویل بومی جداگانه نیاز ندارند.

Discord، Telegram و ربات QQ نیز از /approve در همان چت پشتیبانی می‌کنند، اما این کانال‌ها حتی وقتی تحویل بومی تأیید غیرفعال باشد، همچنان از فهرست تأییدکنندگان تعیین‌شده خود برای مجوزدهی استفاده می‌کنند.

تحویل بومی تأیید

برخی کانال‌ها همچنین می‌توانند به‌عنوان کلاینت‌های بومی تأیید عمل کنند: Discord، Slack، Telegram، Matrix و ربات QQ. کلاینت‌های بومی، پیام‌های خصوصی تأییدکنندگان، انتشار به چت مبدأ و تجربه کاربری تعاملی تأیید مختص کانال را به جریان مشترک /approve در همان چت اضافه می‌کنند.

وقتی کارت‌ها یا دکمه‌های بومی تأیید در دسترس باشند، آن رابط بومی مسیر اصلی روبه‌روی عامل است. عامل نباید فرمان متنی ساده و تکراری /approve را نیز در چت بازتاب دهد، مگر اینکه نتیجه ابزار بگوید تأییدهای چت در دسترس نیستند یا تأیید دستی تنها مسیر باقی‌مانده است.

اگر یک کلاینت بومی تأیید پیکربندی شده باشد، اما هیچ زمان‌اجرای بومی برای کانال مبدأ فعال نباشد، OpenClaw اعلان قطعی محلی /approve را قابل‌مشاهده نگه می‌دارد. اگر زمان‌اجرای بومی فعال باشد و برای تحویل تلاش کند، اما هیچ مقصدی کارت را دریافت نکند، OpenClaw یک اعلان بازگشت در همان چت همراه با فرمان دقیق /approve <id> <decision> ارسال می‌کند تا همچنان بتوان درخواست را تعیین‌تکلیف کرد.

مدل عمومی:

• سیاست exec میزبان همچنان تعیین می‌کند که آیا تأیید exec لازم است
• approvals.exec هدایت اعلان‌های تأیید به مقصدهای چت دیگر را کنترل می‌کند
• channels.<channel>.execApprovals کنترل می‌کند که آیا کلاینت‌های بومی مختص کانال در Discord، Slack، Telegram، ربات QQ و موارد مشابه فعال باشند
• تأییدهای Plugin در Slack می‌توانند وقتی درخواست از Slack می‌آید و تأییدکنندگان Plugin در Slack تعیین می‌شوند، از کلاینت بومی تأیید Slack استفاده کنند؛ approvals.plugin همچنین می‌تواند تأییدهای Plugin را به نشست‌ها یا مقصدهای Slack هدایت کند، حتی وقتی تأییدهای exec در Slack غیرفعال‌اند
• کارت‌های بومی تأیید 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 صریح باقی می‌ماند. وقتی target بومی، تحویل به چت مبدأ را فعال می‌کند، اعلان‌های تأیید شامل متن فرمان هستند.

پرسش متداول: چرا برای تأییدهای چت دو پیکربندی تأیید exec وجود دارد؟

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• ربات QQ: channels.qqbot.execApprovals.*
• Google Chat: تأییدکنندگان پایدار را با channels.googlechat.dm.allowFrom یا channels.googlechat.defaultTo پیکربندی کنید؛ هیچ بلوک execApprovals لازم نیست
• WhatsApp: برای هدایت اعلان‌های تأیید به WhatsApp از approvals.exec و approvals.plugin استفاده کنید
• Signal: برای هدایت اعلان‌های تأیید به Signal از approvals.exec و approvals.plugin استفاده کنید

مسیریابی مختص کلاینت بومی:

• Telegram به‌طور پیش‌فرض از پیام‌های خصوصی تأییدکنندگان (target: "dm") استفاده می‌کند. برای نمایش اعلان‌های تأیید در چت یا موضوع مبدأ Telegram نیز، به channel یا both تغییر دهید. برای موضوع‌های انجمن Telegram، OpenClaw موضوع را برای اعلان تأیید و پیگیری پس از تأیید حفظ می‌کند.
• تأییدکنندگان Discord و Telegram می‌توانند صریح (execApprovals.approvers) یا از commands.ownerAllowFrom استنباط شوند؛ فقط تأییدکنندگان تعیین‌شده می‌توانند تأیید یا رد کنند.
• تأییدکنندگان Slack می‌توانند صریح (execApprovals.approvers) یا از commands.ownerAllowFrom استنباط شوند. پیام‌های خصوصی تأیید Plugin در Slack از تأییدکنندگان Plugin در Slack از allowFrom و مسیریابی پیش‌فرض حساب استفاده می‌کنند، نه تأییدکنندگان exec در Slack. دکمه‌های بومی Slack نوع شناسه تأیید را حفظ می‌کنند، بنابراین شناسه‌های plugin: می‌توانند بدون لایه بازگشت محلی دوم در Slack، تأییدهای Plugin را تعیین‌تکلیف کنند.
• کارت‌های بومی Google Chat بازگشت دستی /approve را در متن پیام حفظ می‌کنند، اما فراخوانی‌های دکمه کارت فقط توکن‌های عملیاتی مبهم را حمل می‌کنند؛ شناسه تأیید و تصمیم از وضعیت در حال انتظار سمت سرور بازیابی می‌شوند.
• تأییدهای ایموجی WhatsApp وقتی خانواده هدایت سطح‌بالای منطبق به WhatsApp مسیریابی شود، هم اعلان‌های exec و هم Plugin را مدیریت می‌کنند. اعلان‌های با مبدأ بومی مستقیماً متصل می‌شوند؛ تحویل مشترک در حالت مقصد همان فراداده نوع‌دار تأیید را به رسید پیام پذیرفته‌شده WhatsApp متصل می‌کند.
• تأییدهای واکنشی Signal فقط وقتی خانواده هدایت سطح‌بالای منطبق فعال باشد و به Signal مسیریابی شود، هم اعلان‌های exec و هم Plugin را مدیریت می‌کنند. تأییدهای مستقیم exec در همان چت Signal می‌توانند بازگشت محلی /approve را بدون تأییدکنندگان صریح سرکوب کنند؛ تعیین‌تکلیف واکنش Signal همچنان به تأییدکنندگان صریح Signal از channels.signal.allowFrom یا defaultTo نیاز دارد.
• مسیریابی بومی پیام خصوصی/کانال و میان‌برهای واکنشی Matrix، هم تأییدهای exec و هم Plugin را مدیریت می‌کنند؛ مجوزدهی Plugin همچنان از channels.matrix.dm.allowFrom می‌آید. اعلان‌های بومی Matrix در نخستین رویداد اعلان شامل محتوای رویداد سفارشی com.openclaw.approval هستند تا کلاینت‌های Matrix آگاه از OpenClaw بتوانند وضعیت ساختاریافته تأیید را بخوانند، در حالی که کلاینت‌های معمولی بازگشت متنی ساده /approve را حفظ می‌کنند.
• دکمه‌های بومی تأیید Discord و Telegram، نوع مالک صریح exec یا Plugin را در داده فراخوانی خصوصیِ انتقال حمل می‌کنند و فقط همان مالک را تعیین‌تکلیف می‌کنند. کنترل‌های قدیمی‌تر /approve که فاقد نوع هستند، یک مسیر سازگاری محدود باقی می‌مانند: آن‌ها فقط نوع‌های مالکی را امتحان می‌کنند که کنشگر مجاز به تأییدشان است، تنها پس از نتیجه «تأیید یافت نشد» ادامه می‌دهند و هرگز مالکیت را از شناسه تأیید استنباط نمی‌کنند.
• درخواست‌کننده لازم نیست تأییدکننده باشد.
• اگر هیچ رابط کاربری اپراتور یا کلاینت تأیید پیکربندی‌شده‌ای نتواند درخواست را بپذیرد، اعلان به askFallback بازمی‌گردد.

فرمان‌های حساس گروهی مختص مالک مانند /diagnostics و /export-trajectory از مسیریابی خصوصی مالک برای اعلان‌های تأیید و نتایج نهایی استفاده می‌کنند. OpenClaw ابتدا یک مسیر خصوصی را روی همان سطحی که مالک فرمان را اجرا کرده است امتحان می‌کند. اگر آن سطح مسیر خصوصی مالک نداشته باشد، به نخستین مسیر مالک در دسترس از commands.ownerAllowFrom بازمی‌گردد؛ بنابراین یک فرمان گروهی Discord همچنان می‌تواند تأیید و نتیجه را به پیام خصوصی Telegram مالک بفرستد، وقتی Telegram به‌عنوان رابط خصوصی اصلی پیکربندی شده است. چت گروهی فقط یک تأیید دریافت کوتاه می‌کند.

همچنین ببینید:

• Discord
• Telegram
• ربات QQ

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

برنامه‌های رسمی iOS و Android نیز می‌توانند تأییدهای در حال انتظار exec متعلق به Gateway را هنگام استفاده از اتصال operator.admin یا هنگامی که دستگاه جفت‌شده operator.approvals آن‌ها صریحاً در درخواست هدف قرار گرفته است، بازبینی کنند. آن‌ها همان رکورد پایدار پاک‌سازی‌شده‌ای را می‌خوانند که Control UI استفاده می‌کند، تصمیمی آگاه از نوع ارسال می‌کنند و نتیجه متعارف نخستین پاسخ Gateway را نمایش می‌دهند. Apple Watch این اعلان‌های تأیید را از طریق iPhone جفت‌شده بازتاب می‌دهد و کنش‌های یک‌بار اجازه‌دادن و ردکردن را ارائه می‌کند. حالت مستقیم Watch Gateway تأییدها را بازبینی نمی‌کند.

گم‌شدن اعلام وصول تعیین‌تکلیف، انتخاب ارسال‌شده را معتبر نمی‌کند: برنامه کنترل‌ها را غیرفعال می‌کند و رکورد را دوباره می‌خواند. اگر سطح دیگری برنده شده باشد، برنامه همان تصمیم ثبت‌شده را نمایش می‌دهد. اعلان‌های در حال انتظار همچنان به Gateway صادرکننده آن‌ها متصل می‌مانند؛ بنابراین تغییر Gateway فعال نمی‌تواند یک شناسه تأیید قدیمی را تغییر مسیر دهد.

جریان IPC در macOS

Gateway -> Node Service (WS)                 |  IPC (UDS + token + HMAC + TTL)                 v             Mac App (UI + approvals + system.run)

نکات امنیتی:

• حالت سوکت یونیکس 0600، توکن ذخیره‌شده در exec-approvals.json.
• بررسی همتای دارای UID یکسان.
• چالش/پاسخ (nonce + توکن HMAC + هش درخواست) + TTL کوتاه.

پرسش‌های متداول

چه زمانی accountId و threadId در یک مقصد تأیید استفاده می‌شوند؟

از accountId زمانی استفاده کنید که کانال چندین هویت پیکربندی‌شده دارد و اعلان تأیید باید از یک حساب مشخص خارج شود. از threadId زمانی استفاده کنید که مقصد از موضوع‌ها یا رشته‌ها پشتیبانی می‌کند و اعلان باید به‌جای چت سطح‌بالا در همان رشته باقی بماند.

یک نمونه مشخص در Telegram، یک ابرگروه عملیات با موضوع‌های انجمن و دو حساب ربات Telegram است. مقدار to نام ابرگروه را مشخص می‌کند، accountId حساب ربات را انتخاب می‌کند و threadId موضوع انجمن را انتخاب می‌کند:

{  approvals: {    exec: {      enabled: true,      mode: "targets",      targets: [        {          channel: "telegram",          to: "-1001234567890",          accountId: "ops-bot",          threadId: "77",        },      ],    },  },  channels: {    telegram: {      accounts: {        default: {          name: "Primary bot",          botToken: "env:TELEGRAM_PRIMARY_BOT_TOKEN",        },        "ops-bot": {          name: "Operations bot",          botToken: "env:TELEGRAM_OPS_BOT_TOKEN",        },      },    },  },}

با این پیکربندی، تأییدهای اجرای هدایت‌شده توسط حساب Telegram با شناسهٔ ops-bot در موضوع 77 از گفت‌وگوی -1001234567890 ارسال می‌شوند. هدفی بدون accountId از حساب پیش‌فرض کانال استفاده می‌کند و هدفی بدون threadId در مقصد سطح‌بالا ارسال می‌شود.

وقتی تأییدها به یک نشست ارسال می‌شوند، آیا هرکسی در آن نشست می‌تواند آن‌ها را تأیید کند؟

خیر. تحویل به نشست فقط محل نمایش درخواست را کنترل می‌کند و به‌خودی‌خود به همهٔ شرکت‌کنندگان آن گفت‌وگو مجوز تأیید نمی‌دهد.

برای /approve عمومی در همان گفت‌وگو، فرستنده باید از قبل مجاز به اجرای فرمان‌ها در آن نشست کانال باشد. اگر کانال تأییدکنندگان صریحی برای تأییدها ارائه کند، آن تأییدکنندگان می‌توانند کنش /approve را مجاز کنند، حتی اگر در حالت عادی مجاز به اجرای فرمان در آن نشست نباشند.

برخی کانال‌ها سخت‌گیرانه‌تر هستند. پیام‌های خصوصی بومی تأیید در Discord،‏ Telegram،‏ Matrix و Slack و همچنین کلاینت‌های بومی مشابه برای تأیید، از فهرست‌های حل‌شدهٔ تأییدکنندگان خود برای مجوزدهی تأیید استفاده می‌کنند. برای نمونه، درخواست تأیید در موضوع انجمن Telegram می‌تواند برای همهٔ افراد حاضر در موضوع قابل‌مشاهده باشد، اما فقط شناسه‌های عددی کاربران Telegram که از channels.telegram.execApprovals.approvers یا commands.ownerAllowFrom حل شده‌اند می‌توانند آن را تأیید یا رد کنند.

مرتبط

• تأییدهای اجرا — سیاست اصلی و جریان تأیید
• ابزار اجرا
• حالت ارتقایافته
• Skills — رفتار اجازه‌دهی خودکار مبتنی بر مهارت‌ها