Yürütme onayları — gelişmiş

Gelişmiş exec onayı konuları: safeBins hızlı yolu, yorumlayıcı/çalışma zamanı bağlama ve sohbet kanallarına onay iletme (yerel iletim dahil). Temel politika ve onay akışı için bkz. Exec onayları.

​

Güvenli ikililer (yalnızca stdin)

tools.exec.safeBins, açık izin listesi girdileri olmadan izin listesi modunda çalışabilen küçük bir yalnızca stdin ikili listesini (örneğin cut) tanımlar. Güvenli ikililer konumsal dosya argümanlarını ve yol benzeri tokenları reddeder, bu yüzden yalnızca gelen akış üzerinde çalışabilirler. Bunu genel bir güven listesi olarak değil, akış filtreleri için dar bir hızlı yol olarak ele alın. Varsayılan güvenli ikililer: cut, uniq, head, tail, tr, wc grep ve sort varsayılan listede yoktur. Dahil etmeyi seçerseniz, stdin dışı iş akışları için açık izin listesi girdilerini koruyun. Güvenli ikili modunda grep için deseni -e/--regexp ile sağlayın; dosya operandlarının belirsiz konumsallar olarak gizlice sokulamaması için konumsal desen biçimi reddedilir.

​

Argv doğrulaması ve reddedilen bayraklar

Doğrulama yalnızca argv biçiminden deterministiktir (ana makine dosya sistemi varlık denetimi yoktur); bu, izin/verme farklarından dosya varlığı oracle davranışını engeller. Varsayılan güvenli ikililer için dosya odaklı seçenekler reddedilir; uzun seçenekler kapalı başarısız olacak şekilde doğrulanır (bilinmeyen bayraklar ve belirsiz kısaltmalar reddedilir). Güvenli ikili profiline göre reddedilen bayraklar:

• 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

Güvenli ikililer ayrıca, stdin’e özel segmentler için argv tokenlarının yürütme zamanında değişmez metin olarak ele alınmasını zorunlu kılar (globbing yok ve $VARS genişletmesi yok); böylece * veya $HOME/... gibi desenler dosya okumalarını gizlice sokmak için kullanılamaz.

​

Güvenilen ikili dizinleri

Güvenli ikililer güvenilen ikili dizinlerinden çözümlenmelidir (sistem varsayılanları artı isteğe bağlı tools.exec.safeBinTrustedDirs). PATH girdilerine hiçbir zaman otomatik olarak güvenilmez. Varsayılan güvenilen dizinler kasıtlı olarak minimaldir: /bin, /usr/bin. Güvenli ikili yürütülebiliriniz paket yöneticisi/kullanıcı yollarında bulunuyorsa (örneğin /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin), bunları açıkça tools.exec.safeBinTrustedDirs içine ekleyin.

​

Kabuk zincirleme, sarmalayıcılar ve çoklayıcılar

Kabuk zincirleme (&&, ||, ;), her üst düzey segment izin listesini karşıladığında (güvenli ikililer veya skill otomatik izni dahil) izinlidir. Yönlendirmeler izin listesi modunda desteklenmemeye devam eder. Komut ikamesi ($() / ters tırnaklar), çift tırnakların içinde olsa bile izin listesi ayrıştırması sırasında reddedilir; değişmez $() metnine ihtiyacınız varsa tek tırnak kullanın. macOS yardımcı uygulama onaylarında, kabuk denetimi veya genişletme söz dizimi (&&, ||, ;, |, `, $, <, >, (, )) içeren ham kabuk metni, kabuk ikilisinin kendisi izin listesine alınmadıkça izin listesi eşleşmesi yokmuş gibi ele alınır. Kabuk sarmalayıcıları (bash|sh|zsh ... -c/-lc) için istek kapsamlı ortam geçersiz kılmaları küçük ve açık bir izin listesine indirgenir (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR). İzin listesi modundaki allow-always kararları için bilinen dağıtım sarmalayıcıları (env, flock, nice, nohup, stdbuf, timeout), sarmalayıcı yolu yerine içteki yürütülebilir yolu kalıcılaştırır. Kabuk çoklayıcıları (busybox, toybox) kabuk applet’leri (sh, ash vb.) için aynı şekilde açılır. Bir sarmalayıcı veya çoklayıcı güvenle açılamazsa, otomatik olarak hiçbir izin listesi girdisi kalıcılaştırılmaz. python3 veya node gibi yorumlayıcıları izin listesine alırsanız, satır içi eval’in yine de açık onay gerektirmesi için tools.exec.strictInlineEval=true tercih edin. Katı modda allow-always, zararsız yorumlayıcı/betik çağrılarını yine de kalıcılaştırabilir, ancak satır içi eval taşıyıcıları otomatik olarak kalıcılaştırılmaz.

​

Güvenli ikililer ve izin listesi

Yapılandırma konumu:

• safeBins yapılandırmadan gelir (tools.exec.safeBins veya ajan başına agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs yapılandırmadan gelir (tools.exec.safeBinTrustedDirs veya ajan başına agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles yapılandırmadan gelir (tools.exec.safeBinProfiles veya ajan başına agents.list[].tools.exec.safeBinProfiles). Ajan başına profil anahtarları global anahtarları geçersiz kılar.
• izin listesi girdileri ana makineye yerel onay dosyasında agents.<id>.allowlist altında (veya Control UI / openclaw approvals allowlist ... üzerinden) bulunur.
• openclaw security audit, yorumlayıcı/çalışma zamanı ikilileri açık profiller olmadan safeBins içinde göründüğünde tools.exec.safe_bins_interpreter_unprofiled ile uyarır.
• openclaw doctor --fix, eksik özel safeBinProfiles.<bin> girdilerini {} olarak iskeleleyebilir (sonrasında gözden geçirip sıkılaştırın). Yorumlayıcı/çalışma zamanı ikilileri otomatik olarak iskelelenmez.

Özel profil örneği: OC_I18N_900000 jq’yu açıkça safeBins içine dahil ederseniz, OpenClaw güvenli ikili modunda env builtin’ini yine de reddeder; böylece jq -n env, açık bir izin listesi yolu veya onay istemi olmadan ana makine süreç ortamını dökemez.

​

Yorumlayıcı/çalışma zamanı komutları

Onay destekli yorumlayıcı/çalışma zamanı çalıştırmaları kasıtlı olarak muhafazakardır:

• Tam argv/cwd/env bağlamı her zaman bağlanır.
• Doğrudan kabuk betiği ve doğrudan çalışma zamanı dosyası biçimleri en iyi çabayla tek bir somut yerel dosya anlık görüntüsüne bağlanır.
• Yine de tek bir doğrudan yerel dosyaya çözümlenen yaygın paket yöneticisi sarmalayıcı biçimleri (örneğin pnpm exec, pnpm node, npm exec, npx) bağlamadan önce açılır.
• OpenClaw bir yorumlayıcı/çalışma zamanı komutu için tam olarak bir somut yerel dosya belirleyemezse (örneğin paket betikleri, eval biçimleri, çalışma zamanına özgü yükleyici zincirleri veya belirsiz çoklu dosya biçimleri), onay destekli yürütme kapsamadığı anlamsal kapsamı iddia etmek yerine reddedilir.
• Bu iş akışları için sandboxing, ayrı bir ana makine sınırı veya operatörün daha geniş çalışma zamanı semantiğini kabul ettiği açıkça güvenilen bir izin listesi/tam iş akışı tercih edin.

Onay gerektiğinde exec aracı hemen bir onay id’siyle döner. Daha sonra onaylanan çalıştırma sistem olaylarını (Exec finished ve yapılandırıldığında Exec running) ilişkilendirmek için bu id’yi kullanın. Zaman aşımından önce karar gelmezse istek onay zaman aşımı olarak ele alınır ve terminal ana makine komutu reddi olarak gösterilir. Kaynak oturumu olan ana ajan async onayları için OpenClaw, komutun çalışmadığını ajanın gözlemlemesi ve daha sonra eksik sonucu onarmaya çalışmaması için o oturumu dahili bir takip ile de sürdürür.

​

Takip iletimi davranışı

Onaylanan async exec bittikten sonra OpenClaw aynı oturuma bir takip agent turu gönderir. Reddedilen async onayları ret durumu için aynı ana oturum takip yolunu kullanır, ancak yükseltilmiş çalışma zamanı devirleri kaydetmez ve komutu çalıştırmaz. Sürdürülebilir ana oturumu olmayan retler ya bastırılır ya da mevcut olduğunda güvenli bir doğrudan rota üzerinden raporlanır.

• Geçerli bir harici iletim hedefi varsa (iletilebilir kanal artı hedef to), takip iletimi o kanalı kullanır.
• Yalnızca webchat veya harici hedefi olmayan dahili oturum akışlarında takip iletimi yalnızca oturumda kalır (deliver: false).
• Bir çağıran çözümlenebilir harici kanal olmadan açıkça katı harici iletim isterse istek INVALID_REQUEST ile başarısız olur.
• bestEffortDeliver etkinse ve harici kanal çözümlenemiyorsa, iletim başarısız olmak yerine yalnızca oturuma düşürülür.

​

Onayları sohbet kanallarına iletme

Exec onay istemlerini herhangi bir sohbet kanalına (Plugin kanalları dahil) iletebilir ve bunları /approve ile onaylayabilirsiniz. Bu, normal giden iletim işlem hattını kullanır. Yapılandırma: OC_I18N_900001 Sohbette yanıtlayın: OC_I18N_900002 /approve komutu hem exec onaylarını hem de Plugin onaylarını işler. ID bekleyen bir exec onayıyla eşleşmezse, otomatik olarak Plugin onaylarını denetler.

​

Plugin onayı iletme

Plugin onayı iletme, exec onaylarıyla aynı iletim işlem hattını kullanır ancak approvals.plugin altında kendi bağımsız yapılandırmasına sahiptir. Birini etkinleştirmek veya devre dışı bırakmak diğerini etkilemez. Plugin yazma davranışı, istek alanları ve karar semantiği için bkz. Plugin izin istekleri. OC_I18N_900003 Yapılandırma şekli approvals.exec ile aynıdır: enabled, mode, agentFilter, sessionFilter ve targets aynı şekilde çalışır. Paylaşılan etkileşimli yanıtları destekleyen kanallar hem exec hem de Plugin onayları için aynı onay düğmelerini işler. Paylaşılan etkileşimli UI olmayan kanallar, /approve yönergeleriyle düz metne geri döner. Plugin onay istekleri kullanılabilir kararları sınırlayabilir. Onay yüzeyleri isteğin beyan ettiği karar kümesini kullanır ve Gateway sunulmamış bir kararı gönderme girişimlerini reddeder.

​

Herhangi bir kanalda aynı sohbet onayları

Bir exec veya Plugin onay isteği iletilebilir bir sohbet yüzeyinden kaynaklandığında, aynı sohbet artık varsayılan olarak /approve ile bunu onaylayabilir. Bu, mevcut Web UI ve terminal UI akışlarına ek olarak Slack, Matrix ve Microsoft Teams gibi kanallar için geçerlidir. Bu paylaşılan metin-komut yolu, ilgili konuşma için normal kanal kimlik doğrulama modelini kullanır. Kaynak sohbet zaten komut gönderebiliyor ve yanıt alabiliyorsa, onay isteklerinin beklemede kalmak için artık ayrı bir yerel teslim adaptörüne ihtiyacı yoktur. Discord ve Telegram aynı sohbet içinde /approve komutunu da destekler, ancak bu kanallar yerel onay teslimi devre dışı olduğunda bile yetkilendirme için çözümlenmiş onaylayan listesini kullanmaya devam eder. Gateway’i doğrudan çağıran Telegram ve diğer yerel onay istemcileri için bu geri dönüş, kasıtlı olarak “onay bulunamadı” hatalarıyla sınırlandırılmıştır. Gerçek bir exec onay reddi/hatası sessizce Plugin onayı olarak yeniden denenmez.

​

Yerel onay teslimi

Bazı kanallar yerel onay istemcileri olarak da davranabilir. Yerel istemciler, paylaşılan aynı sohbet /approve akışının üzerine onaylayan DM’leri, kaynak sohbet yayılımını ve kanala özgü etkileşimli onay kullanıcı deneyimini ekler. Yerel onay kartları/düğmeleri kullanılabilir olduğunda, bu yerel kullanıcı arayüzü birincil agent’a dönük yoldur. Araç sonucu sohbet onaylarının kullanılamadığını veya el ile onayın kalan tek yol olduğunu söylemedikçe agent ayrıca yinelenen bir düz sohbet /approve komutunu da yankılamamalıdır. Yerel bir onay istemcisi yapılandırılmış ancak kaynak kanal için etkin bir yerel çalışma zamanı yoksa, OpenClaw yerel deterministik /approve istemini görünür tutar. Yerel çalışma zamanı etkinse ve teslimi dener ancak hiçbir hedef kartı almazsa, OpenClaw isteğin yine de çözülebilmesi için tam /approve <id> <decision> komutuyla aynı sohbet geri dönüş bildirimi gönderir. Genel model:

• host exec ilkesi, exec onayının gerekip gerekmediğine hâlâ karar verir
• approvals.exec, onay istemlerinin diğer sohbet hedeflerine iletilmesini denetler
• channels.<channel>.execApprovals, Discord, Slack, Telegram ve benzeri kanala özgü yerel istemcilerin etkin olup olmadığını denetler
• Slack Plugin onayları, istek Slack’ten geldiğinde ve Slack Plugin onaylayanları çözümlendiğinde Slack’in yerel onay istemcisini kullanabilir; approvals.plugin, Slack exec onayları devre dışı olsa bile Plugin onaylarını Slack oturumlarına veya hedeflerine yönlendirebilir
• Google Chat yerel onay kartları, kararlı users/<id> onaylayanları dm.allowFrom veya defaultTo üzerinden çözümlendiğinde Google Chat alanlarından ya da iş parçacıklarından kaynaklanan exec ve Plugin onaylarını işler; kararlar için tepki olaylarını kullanmazlar
• WhatsApp ve Signal tepki onayı teslimi approvals.exec ve approvals.plugin ile sınırlanır; channels.<channel>.execApprovals blokları yoktur

Yerel onay istemcileri, aşağıdakilerin tümü doğru olduğunda DM öncelikli teslimi otomatik etkinleştirir:

• kanal yerel onay teslimini destekler
• onaylayanlar açık execApprovals.approvers veya commands.ownerAllowFrom gibi sahip kimliği üzerinden çözümlenebilir
• channels.<channel>.execApprovals.enabled ayarlanmamıştır veya "auto" değerindedir

Bir yerel onay istemcisini açıkça devre dışı bırakmak için enabled: false ayarlayın. Onaylayanlar çözümlendiğinde zorla açmak için enabled: true ayarlayın. Genel kaynak sohbet teslimi channels.<channel>.execApprovals.target üzerinden açık kalır. SSS: Sohbet onayları için neden iki exec onay yapılandırması var?

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• Google Chat: kararlı onaylayanları channels.googlechat.dm.allowFrom veya channels.googlechat.defaultTo ile yapılandırın; execApprovals bloğu gerekmez
• WhatsApp: onay istemlerini WhatsApp’a yönlendirmek için approvals.exec ve approvals.plugin kullanın
• Signal: onay istemlerini Signal’e yönlendirmek için approvals.exec ve approvals.plugin kullanın

Bu yerel onay istemcileri, paylaşılan aynı sohbet /approve akışı ve paylaşılan onay düğmelerinin üzerine DM yönlendirme ve isteğe bağlı kanal yayılımı ekler. Paylaşılan davranış:

• Slack, Matrix, Microsoft Teams ve benzeri teslim edilebilir sohbetler, aynı sohbet /approve için normal kanal kimlik doğrulama modelini kullanır
• bir yerel onay istemcisi otomatik etkinleştiğinde, varsayılan yerel teslim hedefi onaylayan DM’leridir
• Discord ve Telegram için yalnızca çözümlenmiş onaylayanlar onaylayabilir veya reddedebilir
• Discord onaylayanları açık (execApprovals.approvers) olabilir veya commands.ownerAllowFrom üzerinden çıkarılabilir
• Telegram onaylayanları açık (execApprovals.approvers) olabilir veya commands.ownerAllowFrom üzerinden çıkarılabilir
• Slack onaylayanları açık (execApprovals.approvers) olabilir veya commands.ownerAllowFrom üzerinden çıkarılabilir
• Slack Plugin onay DM’leri, Slack exec onaylayanlarını değil, allowFrom ve hesap varsayılan yönlendirmesinden gelen Slack Plugin onaylayanlarını kullanır
• Slack yerel düğmeleri onay kimliği türünü korur, böylece plugin: kimlikleri ikinci bir Slack’e yerel geri dönüş katmanı olmadan Plugin onaylarını çözebilir
• Google Chat yerel kartları, ileti metninde el ile /approve geri dönüşünü korur ancak kart düğmesi geri çağırmaları yalnızca opak eylem belirteçleri taşır; onay kimliği ve karar sunucu tarafındaki bekleyen durumdan kurtarılır
• WhatsApp emoji onayları, hem exec hem de Plugin istemlerini yalnızca eşleşen üst düzey iletme ailesi etkinleştirildiğinde ve WhatsApp’a yönlendirdiğinde işler; yalnızca hedefe yönelik WhatsApp iletimi, aynı yerel kaynak hedefle eşleşmediği sürece paylaşılan iletme yolunda kalır
• Signal tepki onayları, hem exec hem de Plugin istemlerini yalnızca eşleşen üst düzey iletme ailesi etkinleştirildiğinde ve Signal’e yönlendirdiğinde işler. Doğrudan aynı sohbet Signal exec onayları, açık onaylayanlar olmadan yerel /approve geri dönüşünü bastırabilir; Signal tepki çözümlemesi yine de channels.signal.allowFrom veya defaultTo içinden açık Signal onaylayanları gerektirir.
• Matrix yerel DM/kanal yönlendirmesi ve tepki kısayolları hem exec hem de Plugin onaylarını işler; Plugin yetkilendirmesi yine de channels.matrix.dm.allowFrom içinden gelir
• Matrix yerel istemleri, OpenClaw uyumlu Matrix istemcilerinin yapılandırılmış onay durumunu okuyabilmesi ve standart istemcilerin düz metin /approve geri dönüşünü koruması için ilk istem olayında com.openclaw.approval özel olay içeriğini içerir
• isteği yapan kişinin onaylayan olması gerekmez
• kaynak sohbet, o sohbet zaten komutları ve yanıtları destekliyorsa doğrudan /approve ile onaylayabilir
• yerel Discord onay düğmeleri onay kimliği türüne göre yönlendirir: plugin: kimlikleri doğrudan Plugin onaylarına gider, diğer her şey exec onaylarına gider
• yerel Telegram onay düğmeleri /approve ile aynı sınırlandırılmış exec’ten Plugin’e geri dönüşü izler
• yerel target kaynak sohbet teslimini etkinleştirdiğinde, onay istemleri komut metnini içerir
• bekleyen exec onayları varsayılan olarak 30 dakika sonra sona erer
• hiçbir operatör kullanıcı arayüzü veya yapılandırılmış onay istemcisi isteği kabul edemiyorsa, istem askFallback değerine geri döner

/diagnostics ve /export-trajectory gibi hassas, yalnızca sahip komutları, onay istemleri ve nihai sonuçlar için özel sahip yönlendirmesi kullanır. OpenClaw önce sahibin komutu çalıştırdığı aynı yüzeyde özel bir rota dener. Bu yüzeyde özel sahip rotası yoksa, commands.ownerAllowFrom içinden ilk kullanılabilir sahip rotasına geri döner; böylece bir Discord grup komutu, Telegram yapılandırılmış birincil özel arayüz olduğunda onayı ve sonucu yine de sahibin Telegram DM’ine gönderebilir. Grup sohbeti yalnızca kısa bir alındı bildirimi alır. Telegram varsayılan olarak onaylayan DM’lerini (target: "dm") kullanır. Onay istemlerinin kaynak Telegram sohbetinde/konusunda da görünmesini istediğinizde channel veya both değerine geçebilirsiniz. Telegram forum konuları için OpenClaw, onay istemi ve onay sonrası takip iletisi için konuyu korur. Bkz.:

• Discord
• Telegram

​

macOS IPC akışı

OC_I18N_900004 Güvenlik notları:

• Unix soket modu 0600, belirteç exec-approvals.json içinde saklanır.
• Aynı UID eş denetimi.
• Sınama/yanıt (nonce + HMAC token + istek karması) + kısa TTL.

​

SSS

​

Bir onay hedefinde accountId ve threadId ne zaman kullanılır?

Kanalda birden fazla yapılandırılmış kimlik olduğunda ve onay isteminin belirli bir hesap üzerinden çıkması gerektiğinde accountId kullanın. Hedef konuları veya iş parçacıklarını desteklediğinde ve istemin üst düzey sohbet yerine o iş parçacığının içinde kalması gerektiğinde threadId kullanın. Somut bir Telegram örneği, forum konuları ve iki Telegram bot hesabı olan bir operasyon süper grubudur. to değeri süper grubu adlandırır, accountId bot hesabını seçer ve threadId forum konusunu seçer: OC_I18N_900005 Bu kurulumla, iletilen exec onayları ops-bot Telegram hesabı tarafından -1001234567890 sohbetinin 77 konusuna gönderilir. accountId olmayan bir hedef kanalın varsayılan hesabını kullanır ve threadId olmayan bir hedef üst düzey hedefe gönderir.

​

Onaylar bir oturuma gönderildiğinde, o oturumdaki herkes onları onaylayabilir mi?

Hayır. Oturum teslimi yalnızca istemin nerede görüneceğini denetler. Tek başına o sohbetteki her katılımcıya onaylama yetkisi vermez. Genel aynı sohbet /approve için gönderenin o kanal oturumunda komutlar için zaten yetkili olması gerekir. Kanal açık onay onaylayanları sunuyorsa, bu onaylayanlar o oturumda aksi halde komut yetkisine sahip olmasalar bile /approve eylemini yetkilendirebilir. Bazı kanallar daha katıdır. Discord, Telegram, Matrix, Slack yerel onay DM’leri ve benzeri yerel onay istemcileri, onay yetkilendirmesi için çözümlenmiş onaylayan listelerini kullanır. Örneğin, bir Telegram forum konusu onay istemi konudaki herkes tarafından görülebilir, ancak yalnızca channels.telegram.execApprovals.approvers veya commands.ownerAllowFrom üzerinden çözümlenen sayısal Telegram kullanıcı kimlikleri onu onaylayabilir ya da reddedebilir.

​

İlgili

• Exec onayları — temel ilke ve onay akışı
• Exec aracı
• Yükseltilmiş mod
• Skills — skill destekli otomatik izin verme davranışı