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

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

بین‌های امن (فقط 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 را در زمان اجرا برای بخش‌های فقط stdin مجبور می‌کنند به‌صورت متن تحت‌اللفظی رفتار شوند (بدون globbing و بدون گسترش $VARS)، بنابراین الگوهایی مانند * یا $HOME/... نمی‌توانند برای پنهان‌کردن خواندن فایل استفاده شوند.

دایرکتوری‌های باینری قابل اعتماد

بین‌های امن باید از دایرکتوری‌های باینری قابل اعتماد resolve شوند (پیش‌فرض‌های سیستم به‌علاوه tools.exec.safeBinTrustedDirs اختیاری). ورودی‌های PATH هرگز به‌صورت خودکار قابل اعتماد نمی‌شوند. دایرکتوری‌های قابل اعتماد پیش‌فرض عمداً حداقلی هستند: /bin، /usr/bin. اگر فایل اجرایی بین امن شما در مسیرهای مدیر بسته/کاربر قرار دارد (برای مثال /opt/homebrew/bin، /usr/local/bin، /opt/local/bin، /snap/bin)، آن‌ها را صراحتاً به tools.exec.safeBinTrustedDirs اضافه کنید.

زنجیره‌سازی shell، wrapperها و multiplexerها

زنجیره‌سازی shell (&&، ||، ;) زمانی مجاز است که هر بخش سطح‌بالا فهرست مجاز را برآورده کند (از جمله بین‌های امن یا اجازه خودکار skill). تغییرمسیرها همچنان در حالت فهرست مجاز پشتیبانی نمی‌شوند. جایگزینی فرمان ($() / backticks) هنگام تجزیه فهرست مجاز رد می‌شود، از جمله داخل دابل‌کوتیشن؛ اگر به متن تحت‌اللفظی $() نیاز دارید از سینگل‌کوتیشن استفاده کنید.

در تأییدهای برنامه همراه macOS، متن خام shell که شامل کنترل shell یا نحو گسترش (&&، ||، ;، |، `، $، <، >، (، )) باشد، به‌عنوان عدم تطابق فهرست مجاز تلقی می‌شود، مگر اینکه خود باینری shell در فهرست مجاز باشد.

برای wrapperهای shell (bash|sh|zsh ... -c/-lc)، بازنویسی‌های env با دامنه درخواست به یک فهرست مجاز کوچک و صریح کاهش می‌یابند (TERM، LANG، LC_*، COLORTERM، NO_COLOR، FORCE_COLOR).

برای تصمیم‌های allow-always در حالت فهرست مجاز، wrapperهای dispatch شناخته‌شده (env، flock، nice، nohup، stdbuf، timeout) مسیر فایل اجرایی داخلی را به‌جای مسیر wrapper پایدار می‌کنند. multiplexerهای shell (busybox، toybox) برای appletهای shell (sh، ash و غیره) به همین شکل باز می‌شوند. اگر یک wrapper یا multiplexer نتواند با اطمینان باز شود، هیچ ورودی فهرست مجاز به‌صورت خودکار پایدار نمی‌شود.

اگر مفسرهایی مانند python3 یا node را در فهرست مجاز قرار می‌دهید، tools.exec.strictInlineEval=true را ترجیح دهید تا eval درون‌خطی همچنان به تأیید صریح نیاز داشته باشد. در حالت strict، allow-always همچنان می‌تواند فراخوانی‌های بی‌خطر مفسر/اسکریپت را پایدار کند، اما حامل‌های inline-eval به‌صورت خودکار پایدار نمی‌شوند.

بین‌های امن در برابر فهرست مجاز

محل پیکربندی:

• safeBins از config می‌آید (tools.exec.safeBins یا agents.list[].tools.exec.safeBins برای هر agent).
• safeBinTrustedDirs از config می‌آید (tools.exec.safeBinTrustedDirs یا agents.list[].tools.exec.safeBinTrustedDirs برای هر agent).
• safeBinProfiles از config می‌آید (tools.exec.safeBinProfiles یا agents.list[].tools.exec.safeBinProfiles برای هر agent). کلیدهای پروفایل هر agent کلیدهای سراسری را override می‌کنند.
• ورودی‌های فهرست مجاز در فایل تأییدهای محلی میزبان زیر agents.<id>.allowlist قرار دارند (یا از طریق Control UI / openclaw approvals allowlist ...).
• openclaw security audit وقتی بین‌های مفسر/زمان اجرا بدون پروفایل‌های صریح در safeBins ظاهر شوند، با tools.exec.safe_bins_interpreter_unprofiled هشدار می‌دهد.
• openclaw doctor --fix می‌تواند ورودی‌های سفارشی مفقود safeBinProfiles.<bin> را به‌صورت {} scaffold کند (پس از آن بازبینی و سخت‌گیرانه‌تر کنید). بین‌های مفسر/زمان اجرا به‌صورت خودکار scaffold نمی‌شوند.

نمونه پروفایل سفارشی: OC_I18N_900000 اگر صراحتاً jq را وارد safeBins کنید، OpenClaw همچنان builtin مربوط به env را در حالت بین امن رد می‌کند تا jq -n env نتواند محیط فرایند میزبان را بدون مسیر فهرست مجاز صریح یا اعلان تأیید dump کند.

فرمان‌های مفسر/زمان اجرا

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

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

وقتی تأییدها لازم باشند، ابزار exec بلافاصله با یک شناسه تأیید برمی‌گردد. از آن شناسه برای همبسته‌سازی رویدادهای سیستم اجرای تأییدشده بعدی (Exec finished، و در صورت پیکربندی Exec running) استفاده کنید. اگر پیش از timeout تصمیمی نرسد، درخواست به‌عنوان timeout تأیید تلقی می‌شود و به‌صورت رد نهایی فرمان میزبان نمایش داده می‌شود. برای تأییدهای async مربوط به main-agent با session مبدأ، OpenClaw همچنین آن session را با یک followup داخلی از سر می‌گیرد تا agent مشاهده کند که فرمان اجرا نشده است، به‌جای اینکه بعداً نتیجه مفقود را repair کند.

رفتار تحویل followup

پس از پایان یک exec async تأییدشده، OpenClaw یک turn بعدی agent را به همان session می‌فرستد. تأییدهای async ردشده از همان مسیر followup مربوط به main-session برای وضعیت رد استفاده می‌کنند، اما handoffهای زمان اجرای ارتقایافته را ثبت نمی‌کنند و فرمان را اجرا نمی‌کنند. ردهایی که main session قابل ازسرگیری ندارند یا suppress می‌شوند یا از طریق یک مسیر مستقیم امن، در صورت وجود، گزارش می‌شوند.

• اگر یک هدف تحویل خارجی معتبر وجود داشته باشد (کانال قابل تحویل به‌علاوه هدف to)، تحویل followup از همان کانال استفاده می‌کند.
• در جریان‌های فقط webchat یا internal-session بدون هدف خارجی، تحویل followup فقط در session باقی می‌ماند (deliver: false).
• اگر یک caller صراحتاً تحویل خارجی strict را بدون کانال خارجی قابل resolve درخواست کند، درخواست با INVALID_REQUEST شکست می‌خورد.
• اگر bestEffortDeliver فعال باشد و هیچ کانال خارجی‌ای resolve نشود، تحویل به‌جای شکست، به حالت فقط session تنزل داده می‌شود.

ارسال تأیید به کانال‌های چت

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

Config: OC_I18N_900001 پاسخ در چت: OC_I18N_900002 فرمان /approve هم تأییدهای exec و هم تأییدهای Plugin را مدیریت می‌کند. اگر ID با تأیید exec در انتظار تطبیق نداشته باشد، به‌صورت خودکار تأییدهای Plugin را بررسی می‌کند.

ارسال تأیید Plugin

ارسال تأیید Plugin از همان pipeline تحویل تأییدهای exec استفاده می‌کند، اما config مستقل خود را زیر approvals.plugin دارد. فعال یا غیرفعال‌کردن یکی بر دیگری اثر نمی‌گذارد. برای رفتار authoring مربوط به Plugin، فیلدهای درخواست، و معناشناسی تصمیم، درخواست‌های مجوز Plugin را ببینید. OC_I18N_900003 شکل config با approvals.exec یکسان است: enabled، mode، agentFilter، sessionFilter، و targets به همان شیوه کار می‌کنند.

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

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

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

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

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

برای Telegram و دیگر کلاینت‌های تأیید بومی که مستقیماً Gateway را فراخوانی می‌کنند، این fallback عمداً به خطاهای «تأیید یافت نشد» محدود شده است. یک رد/خطای واقعی تأیید exec به‌صورت خاموش دوباره به‌عنوان تأیید Plugin تلاش نمی‌شود.

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

برخی کانال‌ها می‌توانند به‌عنوان کلاینت‌های تأیید بومی نیز عمل کنند. کلاینت‌های بومی، DMهای تأییدکننده، fanout چت مبدأ، و تجربه کاربری تعاملی تأیید ویژه کانال را روی جریان مشترک /approve در همان چت اضافه می‌کنند.

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

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

مدل عمومی:

• سیاست exec میزبان همچنان تصمیم می‌گیرد که آیا تأیید exec لازم است یا نه
• approvals.exec ارسال promptهای تأیید به مقصدهای چت دیگر را کنترل می‌کند
• channels.<channel>.execApprovals کنترل می‌کند که آیا کلاینت‌های بومی ویژه کانال مانند Discord، Slack، Telegram و موارد مشابه فعال باشند یا نه
• تأییدهای Plugin در Slack می‌توانند وقتی درخواست از Slack می‌آید و تأییدکنندگان Plugin در Slack حل می‌شوند، از کلاینت تأیید بومی Slack استفاده کنند؛ approvals.plugin نیز می‌تواند تأییدهای Plugin را حتی وقتی تأییدهای exec در Slack غیرفعال هستند، به sessionها یا هدف‌های Slack هدایت کند
• کارت‌های تأیید بومی Google Chat تأییدهای exec و Plugin را که از فضاها یا threadهای Google Chat سرچشمه می‌گیرند مدیریت می‌کنند، وقتی تأییدکنندگان پایدار users/<id> از dm.allowFrom یا defaultTo حل شوند؛ آن‌ها از رویدادهای reaction برای تصمیم‌ها استفاده نمی‌کنند
• تحویل تأیید reaction در WhatsApp و Signal با approvals.exec و approvals.plugin محدود می‌شود؛ آن‌ها بلوک‌های channels.<channel>.execApprovals ندارند

کلاینت‌های تأیید بومی وقتی همه این موارد درست باشند، تحویل DM-first را به‌صورت خودکار فعال می‌کنند:

• کانال از تحویل تأیید بومی پشتیبانی کند
• تأییدکنندگان بتوانند از 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: برای هدایت promptهای تأیید به WhatsApp از approvals.exec و approvals.plugin استفاده کنید
• Signal: برای هدایت promptهای تأیید به Signal از approvals.exec و approvals.plugin استفاده کنید

این کلاینت‌های تأیید بومی، مسیریابی DM و fanout اختیاری کانال را روی جریان مشترک /approve در همان چت و دکمه‌های تأیید مشترک اضافه می‌کنند.

رفتار مشترک:

• Slack، Matrix، Microsoft Teams و چت‌های قابل تحویل مشابه از مدل عادی احراز هویت کانال برای /approve در همان چت استفاده می‌کنند
• وقتی یک کلاینت تأیید بومی به‌صورت خودکار فعال می‌شود، هدف پیش‌فرض تحویل بومی DMهای تأییدکننده است
• برای Discord و Telegram، فقط تأییدکنندگان حل‌شده می‌توانند تأیید یا رد کنند
• تأییدکنندگان Discord می‌توانند صریح (execApprovals.approvers) باشند یا از commands.ownerAllowFrom استنباط شوند
• تأییدکنندگان Telegram می‌توانند صریح (execApprovals.approvers) باشند یا از commands.ownerAllowFrom استنباط شوند
• تأییدکنندگان Slack می‌توانند صریح (execApprovals.approvers) باشند یا از commands.ownerAllowFrom استنباط شوند
• DMهای تأیید Plugin در Slack از تأییدکنندگان Plugin در Slack از allowFrom و مسیریابی پیش‌فرض account استفاده می‌کنند، نه از تأییدکنندگان exec در Slack
• دکمه‌های بومی Slack نوع شناسه تأیید را حفظ می‌کنند، بنابراین شناسه‌های plugin: می‌توانند تأییدهای Plugin را بدون لایه fallback محلی دوم در Slack حل کنند
• کارت‌های بومی Google Chat fallback دستی /approve را در متن پیام حفظ می‌کنند اما callbackهای دکمه کارت فقط tokenهای action مبهم را حمل می‌کنند؛ شناسه تأیید و تصمیم از state معلق سمت سرور بازیابی می‌شوند
• تأییدهای emoji در WhatsApp فقط وقتی هر دو prompt exec و Plugin را مدیریت می‌کنند که خانواده forwarding سطح بالا و منطبق فعال باشد و به WhatsApp route شود؛ forwarding فقط-هدف WhatsApp روی مسیر forwarding مشترک باقی می‌ماند مگر اینکه با همان هدف مبدأ بومی مطابقت داشته باشد
• تأییدهای reaction در Signal فقط وقتی هر دو prompt exec و Plugin را مدیریت می‌کنند که خانواده forwarding سطح بالا و منطبق فعال باشد و به Signal route شود. تأییدهای exec مستقیم در همان چت Signal می‌توانند fallback محلی /approve را بدون تأییدکنندگان صریح suppress کنند؛ حل reaction در Signal همچنان به تأییدکنندگان صریح Signal از channels.signal.allowFrom یا defaultTo نیاز دارد.
• مسیریابی DM/کانال بومی Matrix و میانبرهای reaction هر دو تأیید exec و Plugin را مدیریت می‌کنند؛ مجوزدهی Plugin همچنان از channels.matrix.dm.allowFrom می‌آید
• promptهای بومی Matrix محتوای رویداد سفارشی com.openclaw.approval را در نخستین رویداد prompt شامل می‌شوند تا کلاینت‌های Matrix آگاه از OpenClaw بتوانند state ساخت‌یافته تأیید را بخوانند، در حالی که کلاینت‌های stock fallback ساده متنی /approve را نگه می‌دارند
• درخواست‌کننده لازم نیست تأییدکننده باشد
• چت مبدأ وقتی همان چت از قبل از فرمان‌ها و پاسخ‌ها پشتیبانی می‌کند، می‌تواند مستقیماً با /approve تأیید کند
• دکمه‌های تأیید بومی Discord بر اساس نوع شناسه تأیید route می‌شوند: شناسه‌های plugin: مستقیماً به تأییدهای Plugin می‌روند، و هر چیز دیگر به تأییدهای exec می‌رود
• دکمه‌های تأیید بومی Telegram همان fallback محدود exec-to-plugin را مانند /approve دنبال می‌کنند
• وقتی target بومی تحویل در چت مبدأ را فعال می‌کند، promptهای تأیید متن فرمان را شامل می‌شوند
• تأییدهای exec معلق به‌صورت پیش‌فرض پس از ۳۰ دقیقه منقضی می‌شوند
• اگر هیچ رابط کاربری operator یا کلاینت تأیید پیکربندی‌شده‌ای نتواند درخواست را بپذیرد، prompt به askFallback برمی‌گردد

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

Telegram به‌صورت پیش‌فرض از DMهای تأییدکننده (target: "dm") استفاده می‌کند. وقتی می‌خواهید promptهای تأیید در چت/موضوع Telegram مبدأ نیز ظاهر شوند، می‌توانید به channel یا both تغییر دهید. برای topicهای forum در Telegram، OpenClaw topic را برای prompt تأیید و پیگیری پس از تأیید حفظ می‌کند.

ببینید:

• Discord
• Telegram

جریان IPC در macOS

OC_I18N_900004 نکات امنیتی:

• حالت Unix socket برابر 0600، token در exec-approvals.json ذخیره می‌شود.
• بررسی peer با UID یکسان.
• challenge/response (nonce + HMAC token + request hash) + TTL کوتاه.

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

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

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

یک مورد مشخص در Telegram، supergroup عملیاتی با topicهای forum و دو account ربات Telegram است. مقدار to نام supergroup را مشخص می‌کند، accountId account ربات را انتخاب می‌کند، و threadId topic forum را انتخاب می‌کند: OC_I18N_900005 با این تنظیم، تأییدهای exec ارسال‌شده توسط account Telegram با نام ops-bot در topic 77 از چت -1001234567890 پست می‌شوند. هدفی بدون accountId از account پیش‌فرض کانال استفاده می‌کند، و هدفی بدون threadId در مقصد سطح بالا پست می‌شود.

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

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

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

برخی کانال‌ها سخت‌گیرتر هستند. Discord، Telegram، Matrix، DMهای تأیید بومی Slack، و کلاینت‌های تأیید بومی مشابه، از فهرست‌های تأییدکننده حل‌شده خود برای مجوزدهی تأیید استفاده می‌کنند. برای مثال، یک prompt تأیید topic در forum Telegram می‌تواند برای همه افراد در topic قابل مشاهده باشد، اما فقط شناسه‌های عددی کاربر Telegram که از channels.telegram.execApprovals.approvers یا commands.ownerAllowFrom حل شده‌اند می‌توانند آن را تأیید یا رد کنند.

مرتبط

• تأییدهای Exec — سیاست اصلی و جریان تأیید
• ابزار Exec
• حالت elevated
• Skills — رفتار auto-allow پشتیبانی‌شده با skill