Persetujuan eksekusi — lanjutan

Topik persetujuan exec lanjutan: jalur cepat safeBins, pengikatan interpreter/runtime, dan penerusan persetujuan ke saluran chat (termasuk pengiriman native). Untuk kebijakan inti dan alur persetujuan, lihat Persetujuan exec.

Bin aman (hanya stdin)

tools.exec.safeBins menamai biner hanya stdin (misalnya cut) yang berjalan dalam mode daftar yang diizinkan tanpa entri daftar yang diizinkan eksplisit. Bin aman menolak argumen file posisional dan token yang menyerupai path, sehingga hanya dapat beroperasi pada aliran masuk. Perlakukan ini sebagai jalur cepat terbatas untuk filter aliran, bukan daftar kepercayaan umum.

Bin aman default:

cut, uniq, head, tail, tr, wc

grep dan sort tidak ada dalam daftar default. Jika Anda mengaktifkannya, pertahankan entri daftar yang diizinkan eksplisit untuk alur kerja non-stdin-nya. Untuk grep dalam mode bin aman, berikan pola dengan -e/--regexp; bentuk pola posisional ditolak agar operand file tidak dapat diselundupkan sebagai argumen posisional yang ambigu.

Validasi argv dan flag yang ditolak

Validasi bersifat deterministik hanya berdasarkan bentuk argv (tanpa pemeriksaan keberadaan sistem file host), sehingga mencegah perilaku oracle keberadaan file akibat perbedaan izin/tolak. Opsi yang berorientasi pada file ditolak untuk bin aman default; validasi opsi panjang bersifat gagal-tertutup (flag tidak dikenal dan singkatan ambigu ditolak). Flag boolean hanya-baca yang dikenali dari bin default (misalnya wc -l, tr -d, uniq -c) diterima, sedangkan flag pendek yang tidak dikenali tetap gagal-tertutup dan dialihkan ke persetujuan manual.

Flag yang ditolak berdasarkan profil bin aman:

• 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

Bin aman juga memaksa token argv diperlakukan sebagai teks literal saat eksekusi (tanpa globbing dan tanpa ekspansi $VARS) untuk segmen hanya stdin, sehingga pola seperti * atau $HOME/... tidak dapat digunakan untuk menyelundupkan pembacaan file. awk, sed, dan jq selalu ditolak sebagai bin aman karena semantiknya tidak dapat divalidasi sebagai hanya stdin: jq dapat membaca data lingkungan dan memuat kode jq dari modul atau file startup. Gunakan entri daftar yang diizinkan eksplisit atau prompt persetujuan untuk alat tersebut, bukan safeBins.

Direktori biner tepercaya

Bin aman harus di-resolve dari direktori biner tepercaya (default sistem ditambah tools.exec.safeBinTrustedDirs opsional). Entri PATH tidak pernah dipercaya secara otomatis. Direktori tepercaya default sengaja dibuat minimal: /bin, /usr/bin. Jika executable bin aman Anda berada di path pengelola paket/pengguna (misalnya /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin), tambahkan secara eksplisit ke tools.exec.safeBinTrustedDirs.

Perangkaian shell, wrapper, dan multiplexer

Perangkaian shell (&&, ||, ;) diizinkan jika setiap segmen tingkat atas memenuhi daftar yang diizinkan (termasuk bin aman atau izin otomatis skill). Pengalihan tetap tidak didukung dalam mode daftar yang diizinkan. Substitusi perintah ($() / backtick) ditolak selama penguraian daftar yang diizinkan, termasuk di dalam tanda kutip ganda; gunakan tanda kutip tunggal jika Anda memerlukan teks $() literal.

Pada persetujuan aplikasi pendamping macOS, teks shell mentah yang berisi sintaks kontrol atau ekspansi shell (&&, ||, ;, |, `, $, <, >, (, )) diperlakukan sebagai ketidakcocokan daftar yang diizinkan kecuali biner shell itu sendiri ada dalam daftar yang diizinkan.

Untuk wrapper shell (bash|sh|zsh ... -c/-lc), override env dengan cakupan permintaan dibatasi menjadi daftar yang diizinkan eksplisit berukuran kecil (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR).

Untuk keputusan allow-always dalam mode daftar yang diizinkan, wrapper pengiriman transparan (misalnya env, flock, nice, nohup, stdbuf, timeout) menyimpan path executable bagian dalam, bukan path wrapper. Multiplexer shell (busybox, toybox) diurai untuk applet shell (sh, ash, dan sebagainya) dengan cara yang sama. Jika wrapper atau multiplexer tidak dapat diurai dengan aman, tidak ada entri daftar yang diizinkan yang disimpan secara otomatis.

Jika Anda memasukkan interpreter seperti python3 atau node ke daftar yang diizinkan, utamakan tools.exec.strictInlineEval=true agar evaluasi inline tetap memerlukan persetujuan eksplisit. Dalam mode ketat, allow-always masih dapat menyimpan pemanggilan interpreter/skrip yang aman, tetapi pembawa evaluasi inline tidak disimpan secara otomatis.

Bin aman versus daftar yang diizinkan

Lokasi konfigurasi:

• safeBins berasal dari konfigurasi (tools.exec.safeBins atau agents.list[].tools.exec.safeBins per agen).
• safeBinTrustedDirs berasal dari konfigurasi (tools.exec.safeBinTrustedDirs atau agents.list[].tools.exec.safeBinTrustedDirs per agen).
• safeBinProfiles berasal dari konfigurasi (tools.exec.safeBinProfiles atau agents.list[].tools.exec.safeBinProfiles per agen). Kunci profil per agen menimpa kunci global.
• entri daftar yang diizinkan berada dalam file persetujuan lokal-host di bawah agents.<id>.allowlist (atau melalui UI Kontrol / openclaw approvals allowlist ...).
• openclaw security audit memperingatkan dengan tools.exec.safe_bins_interpreter_unprofiled ketika bin interpreter/runtime muncul di safeBins tanpa profil eksplisit.
• openclaw doctor --fix dapat membuat kerangka entri safeBinProfiles.<bin> kustom yang belum ada sebagai {} (tinjau dan perketat setelahnya). Bin interpreter/runtime tidak dibuatkan kerangka secara otomatis.

Contoh profil kustom:

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

Perintah interpreter/runtime

Eksekusi interpreter/runtime yang didukung persetujuan sengaja dibuat konservatif:

• Konteks argv/cwd/env yang tepat selalu diikat.
• Bentuk skrip shell langsung dan file runtime langsung diikat sebisa mungkin ke satu snapshot file lokal yang konkret.
• Bentuk wrapper pengelola paket umum yang masih di-resolve ke satu file lokal langsung (misalnya pnpm exec, pnpm node, npm exec, npx) diurai sebelum pengikatan.
• Jika OpenClaw tidak dapat mengidentifikasi tepat satu file lokal konkret untuk perintah interpreter/runtime (misalnya skrip paket, bentuk evaluasi, rantai loader khusus runtime, atau bentuk multi-file yang ambigu), eksekusi yang didukung persetujuan ditolak alih-alih mengklaim cakupan semantik yang tidak dimilikinya.
• Untuk alur kerja tersebut, utamakan sandboxing, batas host terpisah, atau alur kerja penuh/daftar yang diizinkan tepercaya yang eksplisit, tempat operator menerima semantik runtime yang lebih luas.

Saat persetujuan diwajibkan, alat exec segera mengembalikan id persetujuan. Gunakan id tersebut untuk mengorelasikan peristiwa sistem eksekusi yang disetujui selanjutnya (Exec finished, dan Exec running jika dikonfigurasi). Jika tidak ada keputusan sebelum batas waktu, permintaan diperlakukan sebagai waktu persetujuan habis dan ditampilkan sebagai penolakan perintah host terminal. Untuk persetujuan asinkron agen utama dengan sesi asal, OpenClaw juga melanjutkan sesi tersebut dengan tindak lanjut internal agar agen mengamati bahwa perintah tidak dijalankan, alih-alih kemudian memperbaiki hasil yang hilang. Persetujuan exec yang tertunda kedaluwarsa setelah 30 menit secara default.

Perilaku pengiriman tindak lanjut

Setelah exec asinkron yang disetujui selesai, OpenClaw mengirim giliran tindak lanjut agent ke sesi yang sama. Persetujuan asinkron yang ditolak menggunakan jalur tindak lanjut sesi utama yang sama untuk status penolakan, tetapi tidak mendaftarkan serah-terima runtime dengan hak lebih tinggi dan tidak menjalankan perintah. Penolakan tanpa sesi utama yang dapat dilanjutkan akan ditekan atau dilaporkan melalui rute langsung yang aman jika tersedia.

• Jika tersedia target pengiriman eksternal yang valid (saluran yang dapat mengirim ditambah target to), pengiriman tindak lanjut menggunakan saluran tersebut.
• Dalam alur hanya webchat atau sesi internal tanpa target eksternal, pengiriman tindak lanjut tetap hanya melalui sesi (deliver: false).
• Jika pemanggil secara eksplisit meminta pengiriman eksternal ketat tanpa saluran eksternal yang dapat di-resolve, permintaan gagal dengan INVALID_REQUEST.
• Jika bestEffortDeliver diaktifkan dan tidak ada saluran eksternal yang dapat di-resolve, pengiriman diturunkan menjadi hanya melalui sesi alih-alih gagal.

Cakupan minimal untuk klien pihak ketiga

Resolusi persetujuan Gateway dilindungi oleh cakupan khusus operator.approvals. Ini berlaku untuk metode khusus pemilik exec.approval.resolve maupun metode tanpa bergantung jenis approval.resolve; operator.write tidak mencakupnya. Dasbor dan integrasi sebaiknya hanya meminta cakupan yang diperlukan oleh metode yang digunakannya. Perlakukan akses resolusi persetujuan sebagai kewenangan setingkat eksekusi jarak jauh dan berikan operator.approvals secara sengaja, bahkan ketika klien hanya menampilkan UI persetujuan kecil.

Penerusan persetujuan ke saluran chat

Anda dapat meneruskan prompt persetujuan exec ke kanal chat mana pun (termasuk kanal plugin) dan menyetujuinya dengan /approve. Ini menggunakan pipeline pengiriman keluar normal.

Konfigurasi:

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

Balas di chat:

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

Perintah /approve menangani persetujuan exec dan persetujuan plugin. Jika ID tidak cocok dengan persetujuan exec yang tertunda, perintah tersebut secara otomatis memeriksa persetujuan plugin sebagai gantinya. Fallback ini terbatas pada kegagalan "persetujuan tidak ditemukan"; penolakan/kesalahan persetujuan exec yang sebenarnya tidak secara diam-diam dicoba ulang sebagai persetujuan plugin.

Penerusan persetujuan plugin

Penerusan persetujuan plugin menggunakan pipeline pengiriman yang sama dengan persetujuan exec, tetapi memiliki konfigurasi independennya sendiri di bawah approvals.plugin. Mengaktifkan atau menonaktifkan salah satunya tidak memengaruhi yang lain. Untuk perilaku penulisan plugin, bidang permintaan, dan semantik keputusan, lihat Permintaan izin plugin.

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

Bentuk konfigurasinya identik dengan approvals.exec: enabled, mode, agentFilter, sessionFilter, dan targets bekerja dengan cara yang sama.

Kanal yang mendukung balasan interaktif bersama merender tombol persetujuan yang sama untuk persetujuan exec dan plugin. Kanal tanpa UI interaktif bersama menggunakan teks biasa dengan instruksi /approve sebagai fallback. Permintaan persetujuan plugin dapat membatasi keputusan yang tersedia: permukaan persetujuan menggunakan kumpulan keputusan yang dinyatakan oleh permintaan, dan Gateway menolak upaya untuk mengirimkan keputusan yang tidak ditawarkan.

Persetujuan dalam chat yang sama di kanal mana pun

Ketika permintaan persetujuan exec atau plugin berasal dari permukaan chat yang dapat menerima pengiriman, chat yang sama dapat menyetujuinya dengan /approve secara default. Ini berlaku untuk Slack, Matrix, Microsoft Teams, dan chat serupa yang dapat menerima pengiriman, selain alur UI Web dan UI terminal yang sudah ada, dengan menggunakan model autentikasi kanal normal untuk percakapan tersebut. Jika chat asal sudah dapat mengirim perintah dan menerima balasan, permintaan persetujuan tidak lagi memerlukan adaptor pengiriman native terpisah hanya agar tetap tertunda.

Discord, Telegram, dan bot QQ juga mendukung /approve dalam chat yang sama, tetapi kanal tersebut tetap menggunakan daftar pemberi persetujuan yang telah diresolusi untuk otorisasi meskipun pengiriman persetujuan native dinonaktifkan.

Pengiriman persetujuan native

Beberapa kanal juga dapat bertindak sebagai klien persetujuan native: Discord, Slack, Telegram, Matrix, dan bot QQ. Klien native menambahkan DM pemberi persetujuan, fanout chat asal, dan UX persetujuan interaktif khusus kanal di atas alur /approve bersama dalam chat yang sama.

Ketika kartu/tombol persetujuan native tersedia, UI native tersebut merupakan jalur utama yang ditampilkan kepada agen. Agen tidak boleh turut menggemakan perintah chat biasa /approve yang duplikat, kecuali hasil alat menyatakan persetujuan chat tidak tersedia atau persetujuan manual merupakan satu-satunya jalur yang tersisa.

Jika klien persetujuan native dikonfigurasi tetapi tidak ada runtime native yang aktif untuk kanal asal, OpenClaw mempertahankan prompt lokal deterministik /approve agar tetap terlihat. Jika runtime native aktif dan mencoba melakukan pengiriman tetapi tidak ada target yang menerima kartu, OpenClaw mengirimkan pemberitahuan fallback dalam chat yang sama dengan perintah /approve <id> <decision> yang persis agar permintaan tetap dapat diselesaikan.

Model umum:

• kebijakan exec host tetap menentukan apakah persetujuan exec diperlukan
• approvals.exec mengontrol penerusan prompt persetujuan ke tujuan chat lain
• channels.<channel>.execApprovals mengontrol apakah Discord, Slack, Telegram, bot QQ, dan klien native khusus kanal serupa diaktifkan
• Persetujuan plugin Slack dapat menggunakan klien persetujuan native Slack ketika permintaan berasal dari Slack dan pemberi persetujuan plugin Slack dapat diresolusi; approvals.plugin juga dapat merutekan persetujuan plugin ke sesi atau target Slack meskipun persetujuan exec Slack dinonaktifkan
• Kartu persetujuan native Google Chat menangani persetujuan exec dan plugin yang berasal dari ruang atau utas Google Chat ketika pemberi persetujuan users/<id> yang stabil dapat diresolusi dari dm.allowFrom atau defaultTo; kartu tersebut tidak menggunakan peristiwa reaksi untuk keputusan
• Pengiriman persetujuan melalui reaksi WhatsApp dan Signal dikendalikan oleh approvals.exec dan approvals.plugin; keduanya tidak memiliki blok channels.<channel>.execApprovals

Klien persetujuan native secara otomatis mengaktifkan pengiriman yang memprioritaskan DM ketika semua kondisi berikut terpenuhi:

• kanal mendukung pengiriman persetujuan native
• pemberi persetujuan dapat diresolusi dari execApprovals.approvers eksplisit atau identitas pemilik seperti commands.ownerAllowFrom
• channels.<channel>.execApprovals.enabled tidak disetel atau "auto"

Setel enabled: false untuk menonaktifkan klien persetujuan native secara eksplisit. Setel enabled: true untuk memaksanya aktif ketika pemberi persetujuan dapat diresolusi. Pengiriman publik ke chat asal tetap harus dinyatakan secara eksplisit melalui channels.<channel>.execApprovals.target. Ketika target native mengaktifkan pengiriman ke chat asal, prompt persetujuan menyertakan teks perintah.

FAQ: Mengapa ada dua konfigurasi persetujuan exec untuk persetujuan chat?

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• Bot QQ: channels.qqbot.execApprovals.*
• Google Chat: konfigurasikan pemberi persetujuan yang stabil dengan channels.googlechat.dm.allowFrom atau channels.googlechat.defaultTo; blok execApprovals tidak diperlukan
• WhatsApp: gunakan approvals.exec dan approvals.plugin untuk merutekan prompt persetujuan ke WhatsApp
• Signal: gunakan approvals.exec dan approvals.plugin untuk merutekan prompt persetujuan ke Signal

Perutean khusus klien native:

• Telegram secara default menggunakan DM pemberi persetujuan (target: "dm"). Beralihlah ke channel atau both agar prompt persetujuan juga ditampilkan di chat/topik Telegram asal. Untuk topik forum Telegram, OpenClaw mempertahankan topik untuk prompt persetujuan dan tindak lanjut setelah persetujuan.
• Pemberi persetujuan Discord dan Telegram dapat ditentukan secara eksplisit (execApprovals.approvers) atau disimpulkan dari commands.ownerAllowFrom; hanya pemberi persetujuan yang telah diresolusi yang dapat menyetujui atau menolak.
• Pemberi persetujuan Slack dapat ditentukan secara eksplisit (execApprovals.approvers) atau disimpulkan dari commands.ownerAllowFrom. DM persetujuan plugin Slack menggunakan pemberi persetujuan plugin Slack dari allowFrom dan perutean default akun, bukan pemberi persetujuan exec Slack. Tombol native Slack mempertahankan jenis ID persetujuan, sehingga ID plugin: dapat menyelesaikan persetujuan plugin tanpa lapisan fallback lokal Slack kedua.
• Kartu native Google Chat mempertahankan fallback manual /approve dalam teks pesan, tetapi callback tombol kartu hanya membawa token tindakan opak; ID persetujuan dan keputusan dipulihkan dari status tertunda di sisi server.
• Persetujuan emoji WhatsApp menangani prompt exec dan plugin ketika keluarga penerusan tingkat atas yang sesuai merutekannya ke WhatsApp. Prompt asal native diikat secara langsung; pengiriman mode target bersama mengikat metadata persetujuan bertipe yang sama ke tanda terima pesan WhatsApp yang diterima.
• Persetujuan reaksi Signal menangani prompt exec dan plugin hanya ketika keluarga penerusan tingkat atas yang sesuai diaktifkan dan merutekannya ke Signal. Persetujuan exec Signal langsung dalam chat yang sama dapat meniadakan fallback lokal /approve tanpa pemberi persetujuan eksplisit; resolusi reaksi Signal tetap memerlukan pemberi persetujuan Signal eksplisit dari channels.signal.allowFrom atau defaultTo.
• Perutean DM/kanal native Matrix dan pintasan reaksi menangani persetujuan exec dan plugin; otorisasi plugin tetap berasal dari channels.matrix.dm.allowFrom. Prompt native Matrix menyertakan konten peristiwa kustom com.openclaw.approval pada peristiwa prompt pertama agar klien Matrix yang mendukung OpenClaw dapat membaca status persetujuan terstruktur sementara klien standar tetap menggunakan fallback teks biasa /approve.
• Tombol persetujuan native Discord dan Telegram membawa jenis pemilik exec atau plugin secara eksplisit dalam data callback privat transport dan hanya meresolusi pemilik tersebut. Kontrol /approve lama yang tidak memiliki jenis tetap menjadi jalur kompatibilitas terbatas: kontrol tersebut hanya mencoba jenis pemilik yang boleh disetujui oleh pelaku, melanjutkan hanya setelah hasil persetujuan-tidak-ditemukan, dan tidak pernah menyimpulkan kepemilikan dari ID persetujuan.
• Pemohon tidak harus menjadi pemberi persetujuan.
• Jika tidak ada UI operator atau klien persetujuan yang dikonfigurasi yang dapat menerima permintaan, prompt menggunakan askFallback sebagai fallback.

Perintah grup sensitif khusus pemilik seperti /diagnostics dan /export-trajectory menggunakan perutean pemilik privat untuk prompt persetujuan dan hasil akhir. OpenClaw terlebih dahulu mencoba rute privat pada permukaan yang sama tempat pemilik menjalankan perintah. Jika permukaan tersebut tidak memiliki rute pemilik privat, OpenClaw menggunakan rute pemilik pertama yang tersedia dari commands.ownerAllowFrom sebagai fallback, sehingga perintah grup Discord tetap dapat mengirimkan persetujuan dan hasil ke DM Telegram pemilik ketika Telegram dikonfigurasi sebagai antarmuka privat utama. Chat grup hanya menerima pemberitahuan singkat.

Lihat:

• Discord
• Telegram
• Bot QQ

Aplikasi operator seluler resmi

Aplikasi resmi iOS dan Android juga dapat meninjau persetujuan exec tertunda yang dimiliki Gateway ketika koneksi operator.admin digunakan, atau ketika perangkat operator.approvals yang dipasangkan secara eksplisit ditargetkan oleh permintaan. Aplikasi tersebut membaca rekaman tahan lama yang telah disanitasi yang sama dengan yang digunakan oleh UI Kontrol, mengirimkan keputusan yang menyadari jenis, dan menampilkan hasil jawaban pertama kanonis dari Gateway. Apple Watch mencerminkan prompt persetujuan ini melalui iPhone yang dipasangkan, dengan tindakan izinkan-sekali dan tolak. Mode Gateway Watch langsung tidak meninjau persetujuan.

Hilangnya tanda terima penyelesaian tidak menjadikan pilihan yang dikirimkan bersifat otoritatif: aplikasi menonaktifkan kontrol dan membaca kembali rekaman. Jika permukaan lain menang, aplikasi menampilkan keputusan yang tercatat tersebut. Prompt tertunda tetap terikat pada Gateway yang menerbitkannya, sehingga mengganti Gateway aktif tidak dapat mengalihkan ID persetujuan lama.

Alur IPC macOS

Gateway -> Layanan Node (WS)                 |  IPC (UDS + token + HMAC + TTL)                 v             Aplikasi Mac (UI + persetujuan + system.run)

Catatan keamanan:

• Mode soket Unix 0600, token disimpan di exec-approvals.json.
• Pemeriksaan peer dengan UID yang sama.
• Tantangan/respons (nonce + token HMAC + hash permintaan) + TTL singkat.

FAQ

Kapan accountId dan threadId digunakan pada target persetujuan?

Gunakan accountId ketika kanal memiliki beberapa identitas yang dikonfigurasi dan prompt persetujuan harus dikirim melalui satu akun tertentu. Gunakan threadId ketika tujuan mendukung topik atau utas dan prompt harus tetap berada di dalam utas tersebut, bukan di chat tingkat atas.

Contoh konkret Telegram adalah supergrup operasi dengan topik forum dan dua akun bot Telegram. Nilai to menamai supergrup, accountId memilih akun bot, dan threadId memilih topik forum:

{  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",        },      },    },  },}

Dengan penyiapan tersebut, persetujuan eksekusi yang diteruskan diposting oleh akun Telegram ops-bot ke topik 77 dari obrolan -1001234567890. Target tanpa accountId menggunakan akun default kanal, dan target tanpa threadId memposting ke tujuan tingkat teratas.

Ketika persetujuan dikirim ke suatu sesi, apakah siapa pun dalam sesi tersebut dapat menyetujuinya?

Tidak. Pengiriman sesi hanya mengontrol tempat perintah konfirmasi muncul. Hal tersebut tidak dengan sendirinya memberikan wewenang kepada setiap peserta dalam obrolan itu untuk memberikan persetujuan.

Untuk /approve umum dalam obrolan yang sama, pengirim harus sudah memiliki wewenang untuk menjalankan perintah dalam sesi kanal tersebut. Jika kanal menyediakan pemberi persetujuan eksplisit, mereka dapat mengesahkan tindakan /approve meskipun tidak memiliki wewenang untuk menjalankan perintah lain dalam sesi tersebut.

Beberapa kanal menerapkan aturan yang lebih ketat. DM persetujuan native Discord, Telegram, Matrix, dan Slack, serta klien persetujuan native serupa menggunakan daftar pemberi persetujuan yang telah diresolusi untuk otorisasi persetujuan. Misalnya, perintah konfirmasi persetujuan dalam topik forum Telegram dapat terlihat oleh semua orang dalam topik tersebut, tetapi hanya ID pengguna Telegram numerik yang diresolusi dari channels.telegram.execApprovals.approvers atau commands.ownerAllowFrom yang dapat menyetujui atau menolaknya.

Terkait

• Persetujuan eksekusi — kebijakan inti dan alur persetujuan
• Alat eksekusi
• Mode dengan hak akses lebih tinggi
• Skills — perilaku izin otomatis yang didukung skill