Tools

Exec अनुमोदन

Exec अनुमोदन किसी सैंडबॉक्स किए गए एजेंट को वास्तविक होस्ट (gateway या node) पर कमांड चलाने देने के लिए सहायक ऐप / Node होस्ट सुरक्षा-सीमा हैं। कमांड केवल तभी चलते हैं जब नीति + अनुमति-सूची + (वैकल्पिक) उपयोगकर्ता अनुमोदन सभी सहमत हों। अनुमोदन टूल नीति और उन्नत गेटिंग के ऊपर लागू होते हैं (उन्नत full उन्हें छोड़ देता है)।

deny, allowlist, ask, auto, full, Codex Guardian मैपिंग और ACPX हार्नेस अनुमतियों के मोड-प्रथम अवलोकन के लिए, अनुमति मोड देखें।

यह कहाँ लागू होता है

Exec अनुमोदन निष्पादन होस्ट पर स्थानीय रूप से लागू किए जाते हैं:

  • Gateway होस्ट -> Gateway मशीन पर openclaw प्रक्रिया।
  • Node होस्ट -> Node रनर (macOS सहायक ऐप या हेडलेस Node होस्ट)।

विश्वास मॉडल

  • Gateway-प्रमाणित कॉलर उस Gateway के लिए विश्वसनीय ऑपरेटर होते हैं।
  • युग्मित Node उस विश्वसनीय ऑपरेटर क्षमता को Node होस्ट तक विस्तारित करते हैं।
  • अनुमोदन आकस्मिक निष्पादन के जोखिम को घटाते हैं, लेकिन वे प्रति-उपयोगकर्ता प्रमाणीकरण सीमा या फ़ाइल-सिस्टम केवल-पठन नीति नहीं हैं।
  • अनुमोदन मिलने के बाद, कोई कमांड चयनित होस्ट या सैंडबॉक्स फ़ाइल-सिस्टम अनुमतियों के अनुसार फ़ाइलों को बदल सकता है।
  • अनुमोदित Node-होस्ट रन विहित निष्पादन संदर्भ को बाँधते हैं: cwd, सटीक argv, उपलब्ध होने पर env बाइंडिंग, और लागू होने पर पिन किया गया निष्पादन योग्य पथ।
  • शेल स्क्रिप्ट और प्रत्यक्ष इंटरप्रेटर/रनटाइम फ़ाइल आह्वान के लिए, OpenClaw एक ठोस स्थानीय फ़ाइल ऑपरेंड को भी बाँधने का प्रयास करता है। यदि वह फ़ाइल अनुमोदन के बाद लेकिन निष्पादन से पहले बदलती है, तो बदली हुई सामग्री चलाने के बजाय रन अस्वीकार कर दिया जाता है।
  • फ़ाइल बाइंडिंग सर्वोत्तम-प्रयास है, प्रत्येक इंटरप्रेटर/रनटाइम लोडर पथ का पूर्ण मॉडल नहीं। यदि ठीक एक ठोस स्थानीय फ़ाइल की पहचान नहीं की जा सकती, तो OpenClaw पूर्ण कवरेज का दिखावा करने के बजाय अनुमोदन-समर्थित रन जारी करने से मना करता है।

macOS विभाजन

  • Node होस्ट सेवा स्थानीय IPC पर system.run को macOS ऐप को अग्रेषित करती है।
  • macOS ऐप अनुमोदन लागू करता है और UI संदर्भ में कमांड निष्पादित करता है।

प्रभावी नीति का निरीक्षण

कमांड यह क्या दिखाता है
openclaw approvals get / --gateway / --node <id|name|ip> अनुरोधित नीति, होस्ट नीति स्रोत और प्रभावी परिणाम।
openclaw exec-policy show स्थानीय मशीन का मर्ज किया गया दृश्य।
openclaw exec-policy set / preset स्थानीय अनुरोधित नीति को स्थानीय होस्ट अनुमोदन फ़ाइल के साथ एक चरण में सिंक्रनाइज़ करता है।

पूर्ण CLI संदर्भ (फ़्लैग, JSON आउटपुट, अनुमति-सूची में जोड़ना/हटाना): अनुमोदन CLI

जब कोई स्थानीय दायरा host=node का अनुरोध करता है, तो exec-policy show स्थानीय अनुमोदन फ़ाइल को सत्य का स्रोत मानने के बजाय उस दायरे को रनटाइम पर Node-प्रबंधित बताता है।

यदि सहायक ऐप UI उपलब्ध नहीं है, तो सामान्यतः संकेत दिखाने वाला कोई भी अनुरोध पूछताछ फ़ॉलबैक (डिफ़ॉल्ट: deny) द्वारा हल किया जाता है।

सेटिंग और संग्रहण

अनुमोदन निष्पादन होस्ट की स्थानीय JSON फ़ाइल में रहते हैं। जब OPENCLAW_STATE_DIR सेट होता है, तो फ़ाइल उस स्थिति निर्देशिका का अनुसरण करती है; अन्यथा यह डिफ़ॉल्ट OpenClaw स्थिति निर्देशिका का उपयोग करती है:

text
$OPENCLAW_STATE_DIR/exec-approvals.json# अन्यथा~/.openclaw/exec-approvals.json

डिफ़ॉल्ट अनुमोदन सॉकेट उसी रूट का अनुसरण करता है: $OPENCLAW_STATE_DIR/exec-approvals.sock, या वेरिएबल के सेट न होने पर ~/.openclaw/exec-approvals.sock

स्थिति निर्देशिकाएँ स्वतंत्र विश्वास दायरे हैं। जब OPENCLAW_STATE_DIR किसी अन्य स्थान की ओर संकेत करता है, तो OpenClaw कभी ~/.openclaw/exec-approvals.json को आयात या संग्रहित नहीं करता; कस्टम स्थिति निर्देशिका के लिए अनुमोदन अलग से कॉन्फ़िगर करें। Doctor भी पुराने plugin-binding-approvals.json को केवल तभी आयात करता है जब वह सक्रिय स्थिति निर्देशिका से संबंधित हो।

उदाहरण स्कीमा:

json
{  "version": 1,  "socket": {    "path": "~/.openclaw/exec-approvals.sock",    "token": "base64url-token"  },  "defaults": {    "security": "deny",    "ask": "on-miss",    "askFallback": "deny",    "autoAllowSkills": false  },  "agents": {    "main": {      "security": "allowlist",      "ask": "on-miss",      "askFallback": "deny",      "autoAllowSkills": true,      "allowlist": [        {          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",          "pattern": "~/Projects/**/bin/rg",          "argPattern": "sha256:argv:...",          "source": "allow-always",          "lastUsedAt": 1737150000000,          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"        },        {          "pattern": "~/Projects/**/bin/git"        }      ]    }  }}

नीति नियंत्रण

tools.exec.mode

tools.exec.mode होस्ट Exec के लिए पसंदीदा सामान्यीकृत नीति सतह है:

मान व्यवहार
deny होस्ट Exec को अवरुद्ध करें।
allowlist बिना पूछे केवल अनुमति-सूचीबद्ध कमांड चलाएँ।
ask अनुमति-सूची नीति उपयोग करें और मेल न मिलने पर पूछें।
auto अनुमति-सूची नीति उपयोग करें, निर्धारक मिलान सीधे चलाएँ और अनुमोदन न मिलने के मामलों को मानव अनुमोदन मार्ग पर फ़ॉलबैक करने से पहले OpenClaw के नेटिव स्वचालित समीक्षक को भेजें।
full अनुमोदन संकेतों के बिना होस्ट Exec चलाएँ।

Doctor सेवामुक्त स्थायी tools.exec.security / tools.exec.ask युग्म को tools.exec.mode में माइग्रेट करता है।

exec.security

security"deny" | "allowlist" | "full"
  • deny - सभी होस्ट Exec अनुरोध अवरुद्ध करें।
  • allowlist - केवल अनुमति-सूचीबद्ध कमांड की अनुमति दें।
  • full - सभी को अनुमति दें (उन्नत के समतुल्य)।

Gateway/Node होस्ट के लिए डिफ़ॉल्ट full है; इसके बजाय sandbox होस्ट का डिफ़ॉल्ट deny होता है।

exec.ask

ask"off" | "on-miss" | "always"

होस्ट Exec के लिए कॉन्फ़िगर की गई पूछताछ नीति। tools.exec.ask और होस्ट अनुमोदन डिफ़ॉल्ट से आधारभूत अनुमोदन संकेत व्यवहार नियंत्रित करती है। डिफ़ॉल्ट off है। प्रति-कॉल ask टूल पैरामीटर (Exec टूल देखें) केवल उस आधाररेखा को कठोर कर सकता है, और प्रभावी होस्ट पूछताछ off होने पर चैनल से उत्पन्न मॉडल कॉल इसे अनदेखा करते हैं।

  • off - कभी संकेत न दिखाएँ।
  • on-miss - केवल अनुमति-सूची से मिलान न होने पर संकेत दिखाएँ।
  • always - प्रत्येक कमांड पर संकेत दिखाएँ। प्रभावी पूछताछ मोड always होने पर allow-always स्थायी विश्वास संकेतों को नहीं दबाता।

askFallback

askFallback"deny" | "allowlist" | "full"

जब संकेत आवश्यक हो लेकिन कोई UI उपलब्ध न हो (या संकेत का समय समाप्त हो जाए), तब समाधान। छोड़े जाने पर डिफ़ॉल्ट deny होता है।

  • deny - अवरुद्ध करें।
  • allowlist - केवल अनुमति-सूची से मिलान होने पर अनुमति दें।
  • full - अनुमति दें।

tools.exec.strictInlineEval

strictInlineEvalboolean

true होने पर, इनलाइन कोड-मूल्यांकन रूपों को केवल अनुमोदन द्वारा चलने योग्य मानता है, भले ही इंटरप्रेटर बाइनरी स्वयं अनुमति-सूचीबद्ध हो। उन इंटरप्रेटर लोडर के लिए गहन सुरक्षा जो एक स्थिर फ़ाइल ऑपरेंड से साफ़-साफ़ मैप नहीं होते।

सख्त मोड द्वारा पकड़े जाने वाले उदाहरण: python -c, node -e/--eval/-p, ruby -e, perl -e/-E, php -r, lua -e, osascript -e (साथ ही awk, sed, make, find -exec और xargs इनलाइन रूप)।

सख्त मोड में इन कमांड को समीक्षक या स्पष्ट अनुमोदन चाहिए। tools.exec.mode: "auto" के साथ, कमांड की लागू करने योग्य योजना होने पर समीक्षक एक कम-जोखिम निष्पादन की अनुमति दे सकता है; अन्यथा OpenClaw किसी मानव से पूछता है। समीक्षक फ़ॉलबैक तक पहुँचने वाले Codex app-server कमांड अनुमोदन किसी मानव से पूछते हैं, क्योंकि उनके अनुमोदन अनुरोध लागू करने योग्य हल किए गए निष्पादन योग्य को उजागर नहीं करते। allow-always इनलाइन-मूल्यांकन कमांड के लिए नई अनुमति-सूची प्रविष्टियाँ स्थायी नहीं करता।

tools.exec.commandHighlighting

commandHighlightingbooleandefault: false

केवल प्रस्तुति: सक्षम होने पर, OpenClaw पार्सर-व्युत्पन्न कमांड विस्तार संलग्न कर सकता है, ताकि वेब अनुमोदन संकेत कमांड टोकन हाइलाइट कर सकें। यह security, ask, अनुमति-सूची मिलान, सख्त इनलाइन-मूल्यांकन व्यवहार, अनुमोदन अग्रेषण या कमांड निष्पादन को नहीं बदलता।

वैश्विक रूप से tools.exec.commandHighlighting के अंतर्गत या प्रति एजेंट agents.entries.*.tools.exec.commandHighlighting के अंतर्गत सेट करें।

YOLO मोड (बिना अनुमोदन)

अनुमोदन संकेतों के बिना होस्ट Exec चलाने के लिए, दोनों नीति परतें खोलें: OpenClaw कॉन्फ़िगरेशन में अनुरोधित Exec नीति (tools.exec.*) और निष्पादन होस्ट अनुमोदन फ़ाइल में होस्ट-स्थानीय अनुमोदन नीति।

छोड़े गए askFallback का डिफ़ॉल्ट deny होता है। जब बिना-UI वाला अनुमोदन संकेत अनुमति पर फ़ॉलबैक होना चाहिए, तब होस्ट askFallback को स्पष्ट रूप से full पर सेट करें।

परत YOLO सेटिंग
tools.exec.mode gateway/node पर full
होस्ट askFallback full

अपने स्वयं के गैर-इंटरैक्टिव अनुमति मोड उपलब्ध कराने वाले CLI-समर्थित प्रोवाइडर इस नीति का पालन कर सकते हैं। OpenClaw की प्रभावी exec नीति YOLO होने पर Claude CLI --permission-mode bypassPermissions जोड़ता है। OpenClaw द्वारा प्रबंधित Claude लाइव सत्रों के लिए, OpenClaw की प्रभावी exec नीति Claude के मूल अनुमति मोड पर प्रामाणिक होती है: YOLO लाइव लॉन्च को --permission-mode bypassPermissions में सामान्यीकृत करता है, और प्रतिबंधात्मक प्रभावी exec नीति लाइव लॉन्च को --permission-mode default में सामान्यीकृत करती है, भले ही अपरिष्कृत Claude बैकएंड आर्ग्स कोई अन्य मोड निर्दिष्ट करते हों।

यदि अधिक रूढ़िवादी सेटअप चाहिए, तो OpenClaw exec नीति को वापस allowlist / on-miss या deny तक कड़ा करें।

स्थायी gateway-host "कभी प्रॉम्प्ट न करें" सेटअप

  • अनुरोधित कॉन्फ़िगरेशन नीति सेट करें

    bash
    openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.mode fullopenclaw gateway restart
  • host स्वीकृति फ़ाइल का मिलान करें

    bash
    openclaw approvals set --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF
  • स्थानीय शॉर्टकट

    bash
    openclaw exec-policy preset yolo

    स्थानीय tools.exec.host/security/ask और स्थानीय स्वीकृति फ़ाइल के डिफ़ॉल्ट (जिसमें askFallback: "full" शामिल है) दोनों को अपडेट करता है। इसे जानबूझकर केवल स्थानीय रखा गया है। gateway-host या node-host स्वीकृतियों को दूरस्थ रूप से बदलने के लिए, openclaw approvals set --gateway या openclaw approvals set --node <id|name|ip> का उपयोग करें।

    अन्य अंतर्निहित प्रीसेट: cautious (host=gateway, security=allowlist, ask=on-miss, askFallback=deny) और deny-all (host=gateway, security=deny, ask=off, askFallback=deny)। इसी तरह लागू करें: openclaw exec-policy preset cautious

    पूर्ण प्रीसेट के बजाय अलग-अलग फ़ील्ड सेट करने के लिए, उन फ़्लैग्स के किसी भी उपसमुच्चय के साथ openclaw exec-policy set --host <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> का उपयोग करें।

    Node होस्ट

    इसके बजाय node पर वही स्वीकृति फ़ाइल लागू करें:

    bash
    openclaw approvals set --node <id|name|ip> --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

    केवल-सत्र शॉर्टकट

    • /exec security=full ask=off केवल वर्तमान सत्र को बदलता है।
    • /elevated full आपातकालीन शॉर्टकट है, जो exec स्वीकृतियों को केवल तब छोड़ता है, जब अनुरोधित नीति और host स्वीकृति फ़ाइल दोनों security: "full" और ask: "off" पर निर्धारित हों। अधिक कड़ी host फ़ाइल, जैसे ask: "always", फिर भी प्रॉम्प्ट करती है।

    यदि host स्वीकृति फ़ाइल कॉन्फ़िगरेशन से अधिक कड़ी रहती है, तो अधिक कड़ी host नीति ही प्रभावी रहती है।

    अनुमति-सूची (प्रति एजेंट)

    अनुमति-सूचियाँ प्रति एजेंट होती हैं। यदि एकाधिक एजेंट मौजूद हैं, तो macOS ऐप में वह एजेंट बदलें जिसे संपादित किया जा रहा है। पैटर्न glob मिलान हैं।

    पैटर्न समाधान किए गए बाइनरी पथ glob या केवल कमांड-नाम glob हो सकते हैं। केवल नाम उन कमांड से मेल खाते हैं जिन्हें PATH के माध्यम से चलाया गया हो, इसलिए rg, rg कमांड होने पर /opt/homebrew/bin/rg से मेल खा सकता है, लेकिन ./rg या /tmp/rg से नहीं। किसी विशिष्ट बाइनरी स्थान पर भरोसा करने के लिए पथ glob का उपयोग करें।

    पुरानी agents.default प्रविष्टियाँ लोड होने पर agents.main में माइग्रेट की जाती हैं। echo ok && pwd जैसी shell शृंखलाओं में अभी भी प्रत्येक शीर्ष-स्तरीय खंड को अनुमति-सूची नियमों को पूरा करना आवश्यक है।

    उदाहरण:

    • rg
    • ~/Projects/**/bin/peekaboo
    • ~/.local/bin/*
    • /opt/homebrew/bin/rg

    argPattern से आर्ग्युमेंट प्रतिबंधित करना

    जब अनुमति-सूची प्रविष्टि का मिलान किसी बाइनरी और किसी विशिष्ट आर्ग्युमेंट संरचना से होना चाहिए, तब argPattern जोड़ें। OpenClaw प्रत्येक होस्ट पर ECMAScript (JavaScript) रेगुलर एक्सप्रेशन सिमैंटिक्स का उपयोग करता है और एक्सप्रेशन का मूल्यांकन पार्स किए गए कमांड आर्ग्युमेंट के विरुद्ध करता है, जिसमें एक्ज़ीक्यूटेबल टोकन (argv[0]) शामिल नहीं होता। हाथ से बनाई गई प्रविष्टियों के लिए, आर्ग्युमेंट एकल स्पेस से जोड़े जाते हैं, इसलिए सटीक मिलान आवश्यक होने पर पैटर्न को एंकर करें।

    json
    {  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

    वह प्रविष्टि python3 safe.py की अनुमति देती है; python3 other.py अनुमति-सूची से मेल नहीं खाता। यदि उसी बाइनरी के लिए केवल-पथ प्रविष्टि भी मौजूद है, तो मेल न खाने वाले आर्ग्युमेंट अब भी उस केवल-पथ प्रविष्टि पर फ़ॉलबैक कर सकते हैं। जब लक्ष्य बाइनरी को घोषित आर्ग्युमेंट तक सीमित करना हो, तब केवल-पथ प्रविष्टि छोड़ दें।

    स्वीकृति प्रवाहों द्वारा सहेजी गई प्रविष्टियाँ सटीक argv मिलान के लिए आंतरिक विभाजक प्रारूप का उपयोग करती हैं। एन्कोड किए गए मान को हाथ से संपादित करने के बजाय उन प्रविष्टियों को दोबारा बनाने के लिए UI या स्वीकृति प्रवाह को प्राथमिकता दें। यदि OpenClaw किसी कमांड खंड के लिए argv पार्स नहीं कर पाता, तो argPattern वाली प्रविष्टियाँ मेल नहीं खातीं।

    जनरेट की गई allow-always प्रविष्टियाँ argv से बंधी होती हैं। नई जनरेट की गई प्रविष्टियों में argPattern शामिल होता है; पुरानी जनरेट की गई केवल-पथ प्रविष्टियों को अनदेखा किया जाता है और नई स्वीकृति आवश्यक होती है। मैन्युअल केवल-पथ नियम के लिए, source और argPattern दोनों को छोड़ दें।

    प्रत्येक अनुमति-सूची प्रविष्टि इसका समर्थन करती है:

    फ़ील्ड अर्थ
    pattern समाधान किया गया बाइनरी पथ glob या केवल कमांड-नाम glob
    argPattern ECMAScript argv regex या जनरेट किया गया सटीक-argv हैश; अनुपस्थित होने पर केवल-पथ
    id स्थिर अपारदर्शी ID; अनुपस्थित होने पर UUID के रूप में जनरेट किया जाता है
    source जनरेट की गई प्रविष्टि का स्रोत, जैसे allow-always; मैन्युअल प्रविष्टियों के लिए छोड़ दें
    commandText पुराना प्लेनटेक्स्ट इनपुट; लोड के दौरान हटा दिया जाता है
    lastUsedAt अंतिम उपयोग का टाइमस्टैम्प
    lastUsedCommand अंतिम मेल खाने वाला कमांड; जनरेट की गई हैश्ड argv प्रविष्टियों के लिए अनुपस्थित
    lastResolvedPath अंतिम समाधान किया गया बाइनरी पथ

    Skills CLI को स्वचालित अनुमति देना

    जब Skills CLI को स्वचालित अनुमति दें (autoAllowSkills) सक्षम होता है, तो ज्ञात Skills द्वारा संदर्भित एक्ज़ीक्यूटेबल को nodes (macOS node या हेडलेस node होस्ट) पर अनुमति-सूची में माना जाता है। यह Skills की बाइनरी सूची प्राप्त करने के लिए Gateway RPC पर skills.bins का उपयोग करता है। यदि सख्त मैन्युअल अनुमति-सूचियाँ चाहिए, तो इसे अक्षम करें।

    सुरक्षित बिन और स्वीकृति अग्रेषण

    सुरक्षित बिन (केवल-stdin तेज़ पथ), इंटरप्रेटर बाइंडिंग विवरण और स्वीकृति प्रॉम्प्ट को Slack/Discord/Telegram पर अग्रेषित करने (या उन्हें मूल स्वीकृति क्लाइंट के रूप में चलाने) के तरीके के लिए, Exec स्वीकृतियाँ - उन्नत देखें।

    Control UI संपादन

    डिफ़ॉल्ट, प्रति-एजेंट ओवरराइड और अनुमति-सूचियाँ संपादित करने के लिए Control UI -> Nodes -> Exec approvals कार्ड का उपयोग करें। कोई स्कोप (Defaults या कोई एजेंट) चुनें, नीति समायोजित करें, अनुमति-सूची पैटर्न जोड़ें/हटाएँ, फिर Save चुनें। UI प्रत्येक पैटर्न के लिए अंतिम-उपयोग मेटाडेटा दिखाता है, जिससे सूची व्यवस्थित रखी जा सकती है।

    लक्ष्य चयनकर्ता Gateway (स्थानीय स्वीकृतियाँ) या कोई Node चुनता है। Nodes को system.execApprovals.get/set विज्ञापित करना आवश्यक है (macOS ऐप या हेडलेस node होस्ट)। यदि कोई node अभी exec स्वीकृतियाँ विज्ञापित नहीं करता, तो उसकी स्थानीय स्वीकृति फ़ाइल सीधे संपादित करें।

    Windows कंपैनियन सहित कुछ node होस्ट के पास अलग स्वीकृति नीति प्रारूप होता है। Control UI इन होस्ट-मूल नीतियों को केवल-पढ़ने योग्य दिखाता है। उन्हें संपादित करने के लिए कंपैनियन ऐप या मूल नीति संरचना के साथ openclaw approvals set --node <id|name|ip> का उपयोग करें; स्वीकृति CLI देखें।

    CLI: openclaw approvals gateway या node संपादन का समर्थन करता है — देखें स्वीकृति CLI

    स्वीकृति प्रवाह

    प्रॉम्प्ट आवश्यक होने पर gateway exec.approval.requested को ऑपरेटर क्लाइंटों तक प्रसारित करता है। Control UI और macOS ऐप इसे exec.approval.resolve के माध्यम से हल करते हैं, फिर gateway स्वीकृत अनुरोध को node होस्ट पर अग्रेषित करता है।

    host=node के लिए, स्वीकृति अनुरोधों में एक कैनोनिकल systemRunPlan पेलोड शामिल होता है। स्वीकृत system.run अनुरोधों को अग्रेषित करते समय gateway उस योजना को प्रामाणिक कमांड/cwd/session संदर्भ के रूप में उपयोग करता है:

    • Node exec पथ पहले ही एक कैनोनिकल योजना तैयार करता है।
    • स्वीकृति रिकॉर्ड उस योजना और उसके बाइंडिंग मेटाडेटा को संग्रहीत करता है।
    • स्वीकृति मिलने के बाद, अंतिम अग्रेषित system.run कॉल बाद में किए गए कॉलर संपादनों पर भरोसा करने के बजाय संग्रहीत योजना का पुनः उपयोग करती है।
    • यदि स्वीकृति अनुरोध बनने के बाद कॉलर command, rawCommand, cwd, agentId, या sessionKey बदलता है, तो gateway अग्रेषित रन को स्वीकृति बेमेल के रूप में अस्वीकार कर देता है।

    सिस्टम इवेंट और अस्वीकृतियाँ

    Node द्वारा पूर्णता रिपोर्ट करने के बाद exec जीवनचक्र एजेंट के सत्र में एक Exec finished सिस्टम संदेश पोस्ट करता है। स्वीकृति मिलने के बाद, tools.exec.approvalRunningNoticeMs बीतने पर OpenClaw प्रगति-जारी सूचना भी भेज सकता है (डिफ़ॉल्ट 10000, 0 इसे अक्षम करता है)। अस्वीकृत exec स्वीकृतियाँ host कमांड के लिए अंतिम होती हैं: कमांड नहीं चलता।

    • मूल सत्र वाली मुख्य-एजेंट असिंक्रोनस स्वीकृतियों के लिए, OpenClaw उस सत्र में अस्वीकृति को आंतरिक फ़ॉलोअप के रूप में वापस पोस्ट करता है, ताकि एजेंट असिंक्रोनस कमांड की प्रतीक्षा बंद कर सके और अनुपस्थित-परिणाम मरम्मत से बच सके।
    • यदि कोई सत्र नहीं है या सत्र फिर से शुरू नहीं किया जा सकता, तो OpenClaw फिर भी ऑपरेटर या सीधे चैट रूट पर संक्षिप्त अस्वीकृति रिपोर्ट कर सकता है।
    • सबएजेंट और Cron सत्रों की अस्वीकृतियाँ उस सत्र में वापस पोस्ट नहीं की जातीं।

    Gateway-host exec स्वीकृतियाँ वही पूर्णता जीवनचक्र इवेंट उत्सर्जित करती हैं। स्वीकृति-गेटेड exec, लंबित अनुरोध को उसके पूर्णता/अस्वीकृति संदेश (Exec finished (gateway id=...) / Exec denied (gateway id=...)) से सहसंबद्ध करने के लिए स्वीकृति ID का पुनः उपयोग करते हैं।

    प्रभाव

    • full शक्तिशाली है; जहाँ संभव हो अनुमति-सूचियों को प्राथमिकता दें।
    • ask तेज़ स्वीकृतियों की अनुमति देते हुए भी आपको प्रक्रिया में शामिल रखता है।
    • प्रति-एजेंट अनुमति-सूचियाँ एक एजेंट की स्वीकृतियों को अन्य एजेंटों में जाने से रोकती हैं।
    • स्वीकृतियाँ केवल अधिकृत प्रेषकों से आए host exec अनुरोधों पर लागू होती हैं। अनधिकृत प्रेषक /exec जारी नहीं कर सकते।
    • /exec security=full अधिकृत ऑपरेटरों के लिए सत्र-स्तरीय सुविधा है और डिज़ाइन के अनुसार स्वीकृतियाँ छोड़ देती है। host exec को सख्ती से अवरुद्ध करने के लिए, स्वीकृति सुरक्षा को deny पर सेट करें या टूल नीति के माध्यम से exec टूल अस्वीकार करें।

    संबंधित

    Was this useful?
    On this page

    On this page