Persetujuan exec OpenClaw tingkat lanjut

Halaman inti persetujuan exec menjelaskan kebijakan dan permintaan persetujuannya. Halaman tingkat lanjut adalah tempat bagian-bagian rawannya berada: biner mana yang boleh melewati daftar izin karena hanya bisa membaca stdin, bagaimana gateway mengikat perintah interpreter ke file persis yang akan dijalankannya, scope apa yang dibutuhkan dasbor untuk menyetujui apa pun, dan bagaimana permintaan persetujuan sampai ke saluran chat lalu kembali sebagai keputusan. Berikut ringkasan halaman tersebut.

Safe bins

• Pengaturan safe bins menyebutkan biner khusus stdin yang berjalan dalam mode allowlist tanpa entri eksplisit, secara default cut, uniq, head, tail, tr, dan wc; biner ini menolak argumen file posisional dan token yang menyerupai path, memperlakukan argumen sebagai teks literal tanpa globbing atau ekspansi variabel, dan validasinya deterministik hanya dari bentuk argumen, dengan flag panjang yang tidak dikenal dan singkatan yang ambigu ditolak secara fail-closed, sedangkan flag pendek yang tidak dikenali diteruskan ke kebijakan persetujuan.
• grep dan sort bukan safe bins default dan tetap memakai entri daftar izin eksplisit untuk alur kerja mereka yang tidak berbasis stdin, dengan grep dalam mode safe-bin hanya menerima pola melalui flag pola eksplisit; awk, sed, dan jq selalu ditolak sebagai safe bins karena semantiknya tidak dapat divalidasi sebagai khusus stdin; interpreter dan runtime tidak boleh ditambahkan sama sekali, safe bins kustom memerlukan profil eksplisit, audit memperingatkan tentang biner interpreter tanpa profil, dan perbaikan doctor dapat membuat kerangka profil kustom kosong untuk diperketat kemudian.
• Safe bins harus di-resolve dari direktori tepercaya, yaitu dua path sistem default, dan entri search path tidak pernah otomatis dipercaya, sehingga path package manager harus dimasukkan ke daftar direktori tepercaya secara eksplisit; daftar flag yang ditolak per profil memblokir opsi yang membaca file, seperti flag rekursif dan flag file pada grep, opsi output dan daftar file pada sort, follow pada tail, dan opsi daftar file pada wc.
• Chaining shell diizinkan jika setiap segmen tingkat atas memenuhi daftar izin, pengalihan (redirection) tetap tidak didukung, substitusi perintah ditolak bahkan di dalam tanda kutip ganda, wrapper shell memangkas override environment dari permintaan menjadi daftar kecil, keputusan allow-always menyimpan executable bagian dalam di balik wrapper transparan dan meng-unwrap applet multiplexer shell, dan evaluasi inline ketat membuat eval inline tetap harus ditinjau saat interpreter masuk daftar izin.

Pengiriman ke sesi hanya mengontrol di mana permintaan persetujuan muncul. Pengiriman itu sendiri tidak memberi wewenang kepada setiap peserta chat tersebut untuk menyetujui.

Pengikatan interpreter dan scope approvals

Eksekusi interpreter yang bergantung pada persetujuan sengaja dibuat konservatif. Argumen, direktori kerja, dan environment yang persis diikat; di gateway, seluruh rantai dispatch eksternal, yaitu setiap executable wrapper dan executable terakhir, diikat sebelum ditinjau dan diperiksa ulang sebelum diluncurkan, executable terlindungi berdasarkan path aslinya dan executable yang dapat ditulisi juga berdasarkan hash kontennya, sehingga executable baru yang muncul lebih awal di search path akan membuat eksekusi ditolak. Skrip langsung dan file runtime diikat ke satu snapshot file, wrapper package manager yang umum di-unwrap terlebih dahulu, dan jika gateway tidak dapat mengidentifikasi tepat satu file lokal (seperti pada skrip paket, bentuk eval, atau rantai loader), eksekusi berbasis persetujuan ditolak alih-alih berpura-pura mencakupnya. Dalam mode otomatis, peninjau hanya menangani rantai yang terikat sepenuhnya: wrapper perintah shell, penetapan environment, applet, dan dispatch builtin melewati peninjauan otomatis dan mengambil jalur persetujuan manusia satu kali, wrapper shell login dan interaktif memerlukan manusia karena file startup-nya berada di luar pengikatan, dan opsi pemuatan kode interaktif tetap ditolak. Saat persetujuan diperlukan, alat langsung mengembalikan ID persetujuan, keputusan yang tidak pernah datang dianggap timeout dan ditampilkan sebagai penolakan perintah host, dengan sesi asal dilanjutkan agar agen melihat bahwa perintah tidak dijalankan, dan persetujuan yang tertunda kedaluwarsa setelah 30 menit. Menyelesaikan persetujuan memerlukan scope approvals khusus, yang tidak tercakup oleh write, dan dokumentasi menyebutnya otoritas setingkat eksekusi jarak jauh yang harus diberikan dengan sengaja, bahkan kepada antarmuka persetujuan yang kecil.

Meneruskan ke chat

• Blok penerusan persetujuan exec mengirim permintaan persetujuan ke saluran chat mana pun melalui pipeline keluar biasa, dalam mode session, targets, atau both, dengan filter agen dan sesi serta target berupa saluran plus penerima; agen hanya meneruskan perintah approve dari persetujuan yang benar-benar tertunda dengan ID persisnya, ID polos atau karangan tidak menyetujui apa pun, izin allow-once hanya mencakup satu perintah, dan perintah yang sama menyelesaikan persetujuan plugin jika ID-nya bukan persetujuan exec yang tertunda, dengan keluarga plugin yang dikonfigurasi secara terpisah.
• Chat asal dapat menyetujui secara default di Slack, Matrix, Teams, dan permukaan serupa yang dapat menerima pengiriman, sedangkan Discord, Telegram, dan bot QQ menggunakan daftar pemberi persetujuan yang sudah di-resolve, bahkan di chat yang sama; klien persetujuan native menambahkan pesan langsung ke pemberi persetujuan, penyebaran ke chat asal, dan kartu interaktif, yang diaktifkan per saluran dengan pemberi persetujuan yang dapat di-resolve, dengan Telegram default ke mode otomatis dan pesan ke pemberi persetujuan, dan kartu yang tidak mencapai target mana pun beralih ke pemberitahuan di chat yang sama beserta perintah persisnya.
• Target dapat membawa ID akun untuk mengirim melalui satu akun bot tertentu dan ID thread agar tetap berada di dalam topik forum; aplikasi seluler resmi meninjau persetujuan yang tertunda melalui koneksi admin atau saat perangkat persetujuannya ditargetkan, dan membaca ulang catatannya saat konfirmasi penerimaan hilang; dan jalur macOS berjalan melalui socket milik pengguna yang sama dengan token, challenge, dan masa berlaku yang singkat.

Persetujuan exec OpenClaw adalah kebijakan inti yang diperluas oleh halaman ini, dan sandboxing OpenClaw adalah batas yang lebih disukai dokumentasi untuk alur kerja yang tidak dapat dicakup oleh pengikatan.

Mengapa jalur cepatnya sempit

Seluruh desain safe-bin bertumpu pada satu sifat: biner yang hanya bisa membaca stdin-nya tidak dapat membocorkan file yang tidak dimaksudkan untuk diekspos oleh kebijakan. Setiap aturan berasal dari sana: penolakan path posisional, argumen literal, flag file yang ditolak, larangan terhadap interpreter dan jq, serta direktori tepercaya yang menghentikan biner tiruan yang muncul lebih awal di search path. Begitu sebuah alat dapat membuka file atau mengevaluasi kode, dokumentasi mengarahkannya ke daftar izin dengan permintaan persetujuan. Telegram di Diali dan Slack di Diali adalah dua saluran Diali tempat permintaan persetujuan yang diteruskan dapat masuk.

Di Diali

Di Diali, konfigurasi runtime dibuat dari dasbor dan diganti pada setiap rilis, dan setiap runtime pelanggan adalah batasnya sendiri. OpenClaw yang di-hosting di Diali menjelaskan asisten yang di-hosting, dan halaman keamanan Diali menjelaskan kontrol di sekitar setiap perintah yang dijalankannya.

• Safe bins hanya membaca stdin; interpreter tidak pernah memenuhi syarat.
• Eksekusi interpreter mengikat seluruh rantai atau ditolak.
• Menyetujui memerlukan scope approvals, bukan write.