Exec अनुमोदन — उन्नत

उन्नत exec-अनुमोदन विषय: safeBins फ़ास्ट-पाथ, इंटरप्रेटर/रनटाइम बाइंडिंग, और चैट चैनलों पर अनुमोदन अग्रेषण (नेटिव डिलीवरी सहित)। मुख्य नीति और अनुमोदन प्रवाह के लिए, Exec अनुमोदन देखें।

सुरक्षित बिन (केवल stdin)

tools.exec.safeBins केवल stdin बाइनरियों (उदाहरण के लिए cut) को निर्दिष्ट करता है, जो स्पष्ट अनुमति-सूची प्रविष्टियों के बिना अनुमति-सूची मोड में चलती हैं। सुरक्षित बिन स्थितीय फ़ाइल आर्ग्युमेंट और पथ-जैसे टोकन अस्वीकार करते हैं, इसलिए वे केवल आने वाली स्ट्रीम पर कार्य कर सकते हैं। इसे स्ट्रीम फ़िल्टर के लिए सीमित फ़ास्ट-पाथ मानें, सामान्य विश्वसनीयता सूची नहीं।

इंटरप्रेटर या रनटाइम बाइनरियों (उदाहरण के लिए python3, node, ruby, bash, sh, zsh) को safeBins में न जोड़ें। यदि कोई कमांड कोड का मूल्यांकन, सबकमांड निष्पादित, या डिज़ाइन के अनुसार फ़ाइलें पढ़ सकता है, तो स्पष्ट अनुमति-सूची प्रविष्टियों को प्राथमिकता दें और अनुमोदन प्रॉम्प्ट सक्षम रखें। कस्टम सुरक्षित बिन को tools.exec.safeBinProfiles.<bin> में एक स्पष्ट प्रोफ़ाइल परिभाषित करनी होगी।

डिफ़ॉल्ट सुरक्षित बिन: cut, uniq, head, tail, tr, wc grep और sort डिफ़ॉल्ट सूची में नहीं हैं। यदि आप इन्हें चुनते हैं, तो इनके गैर-stdin वर्कफ़्लो के लिए स्पष्ट अनुमति-सूची प्रविष्टियाँ रखें। सुरक्षित-बिन मोड में grep के लिए, पैटर्न को -e/--regexp के साथ दें; स्थितीय पैटर्न रूप अस्वीकार किया जाता है, ताकि फ़ाइल ऑपरेंड को संदिग्ध स्थितीय आर्ग्युमेंट के रूप में छिपाया न जा सके।

Argv सत्यापन और अस्वीकृत फ़्लैग

सत्यापन केवल argv के आकार से नियतात्मक रूप से किया जाता है (होस्ट फ़ाइल सिस्टम में अस्तित्व की कोई जाँच नहीं), जिससे अनुमति/अस्वीकृति के अंतर से फ़ाइल-अस्तित्व ऑरेकल व्यवहार रोका जाता है। डिफ़ॉल्ट सुरक्षित बिन के लिए फ़ाइल-उन्मुख विकल्प अस्वीकार किए जाते हैं; लंबे विकल्पों का सत्यापन फ़ेल-क्लोज़्ड होता है (अज्ञात फ़्लैग और संदिग्ध संक्षिप्त रूप अस्वीकार किए जाते हैं)। डिफ़ॉल्ट बिन के मान्यताप्राप्त केवल-पढ़ने योग्य बूलियन फ़्लैग (उदाहरण के लिए wc -l, tr -d, uniq -c) स्वीकार किए जाते हैं, जबकि अज्ञात छोटे फ़्लैग फ़ेल-क्लोज़्ड रहते हैं और मैन्युअल अनुमोदन पर भेजे जाते हैं। सुरक्षित-बिन प्रोफ़ाइल के अनुसार अस्वीकृत फ़्लैग:

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

सुरक्षित बिन, केवल-stdin खंडों के लिए निष्पादन के समय argv टोकन को शाब्दिक टेक्स्ट मानना भी अनिवार्य करते हैं (कोई ग्लॉबिंग और कोई $VARS विस्तार नहीं), ताकि * या $HOME/... जैसे पैटर्न का उपयोग फ़ाइल-पठन छिपाने के लिए न किया जा सके। awk, sed, और jq को सुरक्षित बिन के रूप में हमेशा अस्वीकार किया जाता है, क्योंकि उनके अर्थविज्ञान को केवल stdin तक सीमित होने के लिए सत्यापित नहीं किया जा सकता: jq पर्यावरण डेटा पढ़ सकता है और मॉड्यूल या स्टार्टअप फ़ाइलों से jq कोड लोड कर सकता है। इन टूल के लिए safeBins के बजाय स्पष्ट अनुमति-सूची प्रविष्टि या अनुमोदन प्रॉम्प्ट का उपयोग करें।

विश्वसनीय बाइनरी डायरेक्टरियाँ

सुरक्षित बिन को विश्वसनीय बाइनरी डायरेक्टरियों (सिस्टम डिफ़ॉल्ट और वैकल्पिक tools.exec.safeBinTrustedDirs) से रिज़ॉल्व होना चाहिए। PATH प्रविष्टियों को कभी स्वतः विश्वसनीय नहीं माना जाता। डिफ़ॉल्ट विश्वसनीय डायरेक्टरियाँ जानबूझकर न्यूनतम हैं: /bin, /usr/bin। यदि आपका सुरक्षित-बिन निष्पादनीय पैकेज-मैनेजर/उपयोगकर्ता पथों (उदाहरण के लिए /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin) में स्थित है, तो उन्हें tools.exec.safeBinTrustedDirs में स्पष्ट रूप से जोड़ें।

शेल चेनिंग, रैपर और मल्टीप्लेक्सर

शेल चेनिंग (&&, ||, ;) की अनुमति तब होती है, जब प्रत्येक शीर्ष-स्तरीय खंड अनुमति-सूची को संतुष्ट करता है (सुरक्षित बिन या skill स्वतः-अनुमति सहित)। अनुमति-सूची मोड में रीडायरेक्शन अब भी असमर्थित हैं। कमांड प्रतिस्थापन ($() / बैकटिक) अनुमति-सूची पार्सिंग के दौरान अस्वीकार किया जाता है, दोहरे उद्धरण-चिह्नों के भीतर भी; यदि आपको शाब्दिक $() टेक्स्ट चाहिए, तो एकल उद्धरण-चिह्नों का उपयोग करें। macOS सहयोगी ऐप के अनुमोदनों में, शेल नियंत्रण या विस्तार सिंटैक्स (&&, ||, ;, |, `, $, <, >, (, )) वाला रॉ शेल टेक्स्ट अनुमति-सूची मिस माना जाता है, जब तक शेल बाइनरी स्वयं अनुमति-सूची में न हो। शेल रैपर (bash|sh|zsh ... -c/-lc) के लिए, अनुरोध-स्कोप वाले env ओवरराइड को एक छोटी स्पष्ट अनुमति-सूची (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR) तक सीमित किया जाता है। अनुमति-सूची मोड में allow-always निर्णयों के लिए, पारदर्शी डिस्पैच रैपर (उदाहरण के लिए env, flock, nice, nohup, stdbuf, timeout) रैपर पथ के बजाय आंतरिक निष्पादनीय पथ को स्थायी करते हैं। शेल मल्टीप्लेक्सर (busybox, toybox) को भी इसी तरह शेल ऐपलेट (sh, ash, आदि) के लिए अनरैप किया जाता है। यदि किसी रैपर या मल्टीप्लेक्सर को सुरक्षित रूप से अनरैप नहीं किया जा सकता, तो कोई अनुमति-सूची प्रविष्टि स्वतः स्थायी नहीं की जाती। यदि आप python3 या node जैसे इंटरप्रेटर को अनुमति-सूची में रखते हैं, तो tools.exec.strictInlineEval=true को प्राथमिकता दें, ताकि इनलाइन मूल्यांकन के लिए फिर भी स्पष्ट अनुमोदन आवश्यक रहे। सख़्त मोड में, allow-always फिर भी अहानिकर इंटरप्रेटर/स्क्रिप्ट आह्वान स्थायी कर सकता है, लेकिन इनलाइन-मूल्यांकन वाहक स्वतः स्थायी नहीं किए जाते।

सुरक्षित बिन बनाम अनुमति-सूची

विषय	`tools.exec.safeBins`	अनुमति-सूची (`exec-approvals.json`)
लक्ष्य	सीमित stdin फ़िल्टर को स्वतः अनुमति देना	विशिष्ट निष्पादनीयों पर स्पष्ट रूप से विश्वास करना
मिलान प्रकार	निष्पादनीय नाम + सुरक्षित-बिन argv नीति	रिज़ॉल्व किए गए निष्पादनीय पथ का ग्लॉब, या PATH से चलाए गए कमांड के लिए केवल कमांड-नाम का ग्लॉब
आर्ग्युमेंट स्कोप	सुरक्षित-बिन प्रोफ़ाइल और शाब्दिक-टोकन नियमों द्वारा सीमित	डिफ़ॉल्ट रूप से पथ मिलान; वैकल्पिक `argPattern` पार्स किए गए argv को सीमित कर सकता है
सामान्य उदाहरण	`head`, `tail`, `tr`, `wc`	`jq`, `python3`, `node`, `ffmpeg`, कस्टम CLI
सर्वोत्तम उपयोग	पाइपलाइन में कम जोखिम वाले टेक्स्ट रूपांतरण	व्यापक व्यवहार या दुष्प्रभाव वाला कोई भी टूल

कॉन्फ़िगरेशन स्थान:

safeBins कॉन्फ़िगरेशन (tools.exec.safeBins या प्रति-एजेंट agents.entries.*.tools.exec.safeBins) से आता है।
safeBinTrustedDirs कॉन्फ़िगरेशन (tools.exec.safeBinTrustedDirs या प्रति-एजेंट agents.entries.*.tools.exec.safeBinTrustedDirs) से आता है।
safeBinProfiles कॉन्फ़िगरेशन (tools.exec.safeBinProfiles या प्रति-एजेंट agents.entries.*.tools.exec.safeBinProfiles) से आता है। प्रति-एजेंट प्रोफ़ाइल कुंजियाँ वैश्विक कुंजियों को ओवरराइड करती हैं।
अनुमति-सूची प्रविष्टियाँ agents.<id>.allowlist के अंतर्गत होस्ट-स्थानीय अनुमोदन फ़ाइल में रहती हैं (या Control UI / openclaw approvals allowlist ... के माध्यम से)।
जब इंटरप्रेटर/रनटाइम बिन स्पष्ट प्रोफ़ाइल के बिना safeBins में दिखाई देते हैं, तो openclaw security audit, tools.exec.safe_bins_interpreter_unprofiled के साथ चेतावनी देता है।
openclaw doctor --fix अनुपस्थित कस्टम safeBinProfiles.<bin> प्रविष्टियों को {} के रूप में स्कैफ़ोल्ड कर सकता है (बाद में समीक्षा करके उन्हें अधिक सख़्त करें)। इंटरप्रेटर/रनटाइम बिन स्वतः स्कैफ़ोल्ड नहीं किए जाते।

कस्टम प्रोफ़ाइल का उदाहरण:

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

इंटरप्रेटर/रनटाइम कमांड

अनुमोदन-समर्थित इंटरप्रेटर/रनटाइम रन जानबूझकर रूढ़िवादी हैं:

सटीक argv/cwd/env संदर्भ हमेशा बाइंड किया जाता है।
प्रत्यक्ष शेल स्क्रिप्ट और प्रत्यक्ष रनटाइम फ़ाइल रूपों को सर्वोत्तम प्रयास के आधार पर एक ठोस स्थानीय फ़ाइल स्नैपशॉट से बाइंड किया जाता है।
सामान्य पैकेज-मैनेजर रैपर रूप, जो फिर भी एक प्रत्यक्ष स्थानीय फ़ाइल में रिज़ॉल्व होते हैं (उदाहरण के लिए pnpm exec, pnpm node, npm exec, npx), बाइंडिंग से पहले अनरैप किए जाते हैं।
यदि OpenClaw किसी इंटरप्रेटर/रनटाइम कमांड के लिए ठीक एक ठोस स्थानीय फ़ाइल की पहचान नहीं कर सकता (उदाहरण के लिए पैकेज स्क्रिप्ट, मूल्यांकन रूप, रनटाइम-विशिष्ट लोडर चेन, या संदिग्ध बहु-फ़ाइल रूप), तो ऐसी अर्थगत कवरेज का दावा करने के बजाय अनुमोदन-समर्थित निष्पादन अस्वीकार कर दिया जाता है।
ऐसे वर्कफ़्लो के लिए, सैंडबॉक्सिंग, एक अलग होस्ट सीमा, या स्पष्ट विश्वसनीय अनुमति-सूची/पूर्ण वर्कफ़्लो को प्राथमिकता दें, जहाँ ऑपरेटर व्यापक रनटाइम अर्थविज्ञान स्वीकार करता है।

जब अनुमोदन आवश्यक होते हैं, exec टूल एक अनुमोदन आईडी के साथ तुरंत लौटता है। बाद में आने वाले अनुमोदित-रन सिस्टम इवेंट (Exec finished, और कॉन्फ़िगर होने पर Exec running) को सहसंबद्ध करने के लिए उस आईडी का उपयोग करें। यदि टाइमआउट से पहले कोई निर्णय नहीं आता, तो अनुरोध को अनुमोदन टाइमआउट माना जाता है और टर्मिनल होस्ट-कमांड अस्वीकृति के रूप में दिखाया जाता है। मूल सत्र वाले मुख्य-एजेंट के असिंक्रोनस अनुमोदनों के लिए, OpenClaw उस सत्र को एक आंतरिक फ़ॉलोअप के साथ फिर से शुरू भी करता है, ताकि एजेंट यह देख सके कि कमांड नहीं चला, बजाय इसके कि बाद में अनुपस्थित परिणाम को सुधारने का प्रयास करे। लंबित exec अनुमोदन डिफ़ॉल्ट रूप से 30 मिनट बाद समाप्त हो जाते हैं।

फ़ॉलोअप डिलीवरी व्यवहार

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

यदि कोई मान्य बाहरी डिलीवरी लक्ष्य मौजूद है (डिलीवरी-योग्य चैनल और लक्ष्य to), तो फ़ॉलोअप डिलीवरी उस चैनल का उपयोग करती है।
बिना बाहरी लक्ष्य वाले केवल-webchat या आंतरिक-सत्र प्रवाहों में, फ़ॉलोअप डिलीवरी केवल सत्र तक सीमित रहती है (deliver: false)।
यदि कॉलर किसी रिज़ॉल्व किए जा सकने वाले बाहरी चैनल के बिना स्पष्ट रूप से सख़्त बाहरी डिलीवरी का अनुरोध करता है, तो अनुरोध INVALID_REQUEST के साथ विफल हो जाता है।
यदि bestEffortDeliver सक्षम है और कोई बाहरी चैनल रिज़ॉल्व नहीं किया जा सकता, तो विफल होने के बजाय डिलीवरी को केवल सत्र तक डाउनग्रेड कर दिया जाता है।

तृतीय-पक्ष क्लाइंट के लिए न्यूनतम स्कोप

Gateway अनुमोदन रिज़ॉल्यूशन को समर्पित operator.approvals स्कोप द्वारा सुरक्षित किया जाता है। यह स्वामी-विशिष्ट exec.approval.resolve विधि और प्रकार-निरपेक्ष approval.resolve विधि, दोनों पर लागू होता है; operator.write इसे अपने अंतर्गत नहीं लेता। डैशबोर्ड और एकीकरण को केवल उन विधियों के लिए आवश्यक स्कोप का अनुरोध करना चाहिए जिनका वे उपयोग करते हैं। अनुमोदन-रिज़ॉल्यूशन एक्सेस को रिमोट-निष्पादन-स्तर का अधिकार मानें और operator.approvals सोच-समझकर प्रदान करें, भले ही क्लाइंट केवल एक छोटा अनुमोदन UI प्रस्तुत करता हो।

चैट चैनलों पर अनुमोदन अग्रेषण

आप exec अनुमोदन प्रॉम्प्ट को किसी भी चैट चैनल (Plugin चैनलों सहित) पर अग्रेषित कर सकते हैं और उन्हें /approve से अनुमोदित कर सकते हैं। यह सामान्य आउटबाउंड डिलीवरी पाइपलाइन का उपयोग करता है। कॉन्फ़िगरेशन:

{
  approvals: {
    exec: {
      enabled: true,
      mode: "session", // "session" | "targets" | "both"
      agentFilter: ["main"],
      sessionFilter: ["discord"], // सबस्ट्रिंग या रेगेक्स
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}

चैट में उत्तर दें:

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

/approve कमांड exec अनुमोदन और Plugin अनुमोदन, दोनों को संभालता है। यदि ID किसी लंबित exec अनुमोदन से मेल नहीं खाती, तो यह इसके बजाय स्वचालित रूप से Plugin अनुमोदनों की जाँच करता है। यह फ़ॉलबैक केवल “अनुमोदन नहीं मिला” विफलताओं तक सीमित है; वास्तविक exec अनुमोदन अस्वीकृति/त्रुटि होने पर Plugin अनुमोदन के रूप में चुपचाप पुनः प्रयास नहीं किया जाता।

Plugin अनुमोदन अग्रेषण

Plugin अनुमोदन अग्रेषण exec अनुमोदनों वाली ही डिलीवरी पाइपलाइन का उपयोग करता है, लेकिन इसका अपना स्वतंत्र कॉन्फ़िगरेशन approvals.plugin के अंतर्गत होता है। किसी एक को सक्षम या अक्षम करने से दूसरा प्रभावित नहीं होता। Plugin लेखन व्यवहार, अनुरोध फ़ील्ड और निर्णय अर्थ-विज्ञान के लिए Plugin अनुमति अनुरोध देखें।

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

कॉन्फ़िगरेशन की संरचना approvals.exec के समान है: enabled, mode, agentFilter, sessionFilter और targets उसी तरह काम करते हैं। साझा इंटरैक्टिव उत्तरों का समर्थन करने वाले चैनल exec और Plugin अनुमोदनों, दोनों के लिए समान अनुमोदन बटन रेंडर करते हैं। साझा इंटरैक्टिव UI के बिना चैनल /approve निर्देशों वाले सादे टेक्स्ट पर फ़ॉलबैक करते हैं। Plugin अनुमोदन अनुरोध उपलब्ध निर्णयों को सीमित कर सकते हैं: अनुमोदन सतहें अनुरोध के घोषित निर्णय सेट का उपयोग करती हैं और Gateway ऐसा निर्णय सबमिट करने के प्रयासों को अस्वीकार करता है जिसकी पेशकश नहीं की गई थी।

किसी भी चैनल पर उसी चैट से अनुमोदन

जब कोई exec या Plugin अनुमोदन अनुरोध किसी डिलीवरी-योग्य चैट सतह से शुरू होता है, तो डिफ़ॉल्ट रूप से वही चैट उसे /approve से अनुमोदित कर सकती है। यह मौजूदा वेब UI और टर्मिनल UI प्रवाहों के अतिरिक्त Slack, Matrix, Microsoft Teams और इसी तरह की डिलीवरी-योग्य चैट पर लागू होता है और उस वार्तालाप के लिए सामान्य चैनल प्रमाणीकरण मॉडल का उपयोग करता है। यदि मूल चैट पहले से कमांड भेज और उत्तर प्राप्त कर सकती है, तो अनुमोदन अनुरोधों को केवल लंबित बने रहने के लिए अब अलग नेटिव डिलीवरी अडैप्टर की आवश्यकता नहीं होती। Discord, Telegram और QQ bot भी उसी चैट में /approve का समर्थन करते हैं, लेकिन नेटिव अनुमोदन डिलीवरी अक्षम होने पर भी वे चैनल प्राधिकरण के लिए अपनी निर्धारित अनुमोदक सूची का उपयोग करते हैं।

नेटिव अनुमोदन डिलीवरी

कुछ चैनल नेटिव अनुमोदन क्लाइंट के रूप में भी कार्य कर सकते हैं: Discord, Slack, Telegram, Matrix और QQ bot। नेटिव क्लाइंट साझा समान-चैट /approve प्रवाह के अतिरिक्त अनुमोदक DM, मूल चैट में फ़ैनआउट और चैनल-विशिष्ट इंटरैक्टिव अनुमोदन UX जोड़ते हैं। नेटिव अनुमोदन कार्ड/बटन उपलब्ध होने पर वह नेटिव UI एजेंट के लिए प्राथमिक मार्ग होता है। एजेंट को डुप्लिकेट सादा चैट /approve कमांड भी नहीं दोहराना चाहिए, जब तक टूल परिणाम यह न बताए कि चैट अनुमोदन अनुपलब्ध हैं या मैन्युअल अनुमोदन ही एकमात्र शेष मार्ग है। यदि कोई नेटिव अनुमोदन क्लाइंट कॉन्फ़िगर है, लेकिन मूल चैनल के लिए कोई नेटिव रनटाइम सक्रिय नहीं है, तो OpenClaw स्थानीय निर्धारक /approve प्रॉम्प्ट को दृश्यमान रखता है। यदि नेटिव रनटाइम सक्रिय है और डिलीवरी का प्रयास करता है, लेकिन किसी लक्ष्य को कार्ड प्राप्त नहीं होता, तो OpenClaw सटीक /approve <id> <decision> कमांड के साथ उसी चैट में फ़ॉलबैक सूचना भेजता है, ताकि अनुरोध फिर भी हल किया जा सके। सामान्य मॉडल:

होस्ट exec नीति अब भी तय करती है कि exec अनुमोदन आवश्यक है या नहीं
approvals.exec अनुमोदन प्रॉम्प्ट को अन्य चैट गंतव्यों पर अग्रेषित करना नियंत्रित करता है
channels.<channel>.execApprovals नियंत्रित करता है कि Discord, Slack, Telegram, QQ bot और इसी तरह के चैनल-विशिष्ट नेटिव क्लाइंट सक्षम हैं या नहीं
जब अनुरोध Slack से आता है और Slack Plugin अनुमोदक निर्धारित होते हैं, तो Slack Plugin अनुमोदन Slack के नेटिव अनुमोदन क्लाइंट का उपयोग कर सकते हैं; Slack exec अनुमोदन अक्षम होने पर भी approvals.plugin Plugin अनुमोदनों को Slack सत्रों या लक्ष्यों पर रूट कर सकता है
स्थिर users/<id> अनुमोदक dm.allowFrom या defaultTo से निर्धारित होने पर Google Chat नेटिव अनुमोदन कार्ड, Google Chat स्पेस या थ्रेड से शुरू होने वाले exec और Plugin अनुमोदनों को संभालते हैं; वे निर्णयों के लिए प्रतिक्रिया ईवेंट का उपयोग नहीं करते
WhatsApp और Signal प्रतिक्रिया अनुमोदन डिलीवरी approvals.exec और approvals.plugin द्वारा नियंत्रित होती है; उनमें channels.<channel>.execApprovals ब्लॉक नहीं होते

इन सभी शर्तों के सत्य होने पर नेटिव अनुमोदन क्लाइंट स्वचालित रूप से DM-प्रथम डिलीवरी सक्षम करते हैं:

चैनल नेटिव अनुमोदन डिलीवरी का समर्थन करता है
अनुमोदकों को स्पष्ट execApprovals.approvers या commands.ownerAllowFrom जैसी स्वामी पहचान से निर्धारित किया जा सकता है
channels.<channel>.execApprovals.enabled सेट नहीं है या "auto" है

किसी नेटिव अनुमोदन क्लाइंट को स्पष्ट रूप से अक्षम करने के लिए enabled: false सेट करें। अनुमोदक निर्धारित होने पर उसे बलपूर्वक सक्षम करने के लिए enabled: true सेट करें। सार्वजनिक मूल-चैट डिलीवरी channels.<channel>.execApprovals.target के माध्यम से स्पष्ट रहती है। जब नेटिव target मूल-चैट डिलीवरी सक्षम करता है, तो अनुमोदन प्रॉम्प्ट में कमांड टेक्स्ट शामिल होता है। अक्सर पूछे जाने वाले प्रश्न: चैट अनुमोदनों के लिए दो exec अनुमोदन कॉन्फ़िगरेशन क्यों हैं?

Discord: channels.discord.execApprovals.*
Slack: channels.slack.execApprovals.*
Telegram: channels.telegram.execApprovals.*
QQ bot: channels.qqbot.execApprovals.*
Google Chat: channels.googlechat.dm.allowFrom या channels.googlechat.defaultTo से स्थिर अनुमोदक कॉन्फ़िगर करें; किसी execApprovals ब्लॉक की आवश्यकता नहीं है
WhatsApp: अनुमोदन प्रॉम्प्ट को WhatsApp पर रूट करने के लिए approvals.exec और approvals.plugin का उपयोग करें
Signal: अनुमोदन प्रॉम्प्ट को Signal पर रूट करने के लिए approvals.exec और approvals.plugin का उपयोग करें

नेटिव-क्लाइंट-विशिष्ट रूटिंग:

Telegram डिफ़ॉल्ट रूप से अनुमोदक DM (target: "dm") का उपयोग करता है। मूल Telegram चैट/विषय में भी अनुमोदन प्रॉम्प्ट दिखाने के लिए channel या both पर स्विच करें। Telegram फ़ोरम विषयों के लिए OpenClaw अनुमोदन प्रॉम्प्ट और अनुमोदन-पश्चात फ़ॉलो-अप में विषय को बनाए रखता है।
Discord और Telegram अनुमोदक स्पष्ट (execApprovals.approvers) हो सकते हैं या commands.ownerAllowFrom से अनुमानित किए जा सकते हैं; केवल निर्धारित अनुमोदक ही अनुमोदन या अस्वीकृति कर सकते हैं।
Slack अनुमोदक स्पष्ट (execApprovals.approvers) हो सकते हैं या commands.ownerAllowFrom से अनुमानित किए जा सकते हैं। Slack Plugin अनुमोदन DM, Slack exec अनुमोदकों के बजाय allowFrom और खाता डिफ़ॉल्ट रूटिंग से Slack Plugin अनुमोदकों का उपयोग करते हैं। Slack नेटिव बटन अनुमोदन ID प्रकार को बनाए रखते हैं, इसलिए plugin: ID दूसरी Slack-स्थानीय फ़ॉलबैक परत के बिना Plugin अनुमोदनों को हल कर सकती हैं।
Google Chat नेटिव कार्ड संदेश टेक्स्ट में मैन्युअल /approve फ़ॉलबैक बनाए रखते हैं, लेकिन कार्ड बटन कॉलबैक केवल अपारदर्शी कार्रवाई टोकन ले जाते हैं; अनुमोदन ID और निर्णय सर्वर-साइड लंबित स्थिति से पुनर्प्राप्त किए जाते हैं।
जब मेल खाने वाला शीर्ष-स्तरीय अग्रेषण परिवार WhatsApp पर रूट करता है, तो WhatsApp इमोजी अनुमोदन exec और Plugin, दोनों प्रॉम्प्ट संभालते हैं। नेटिव-मूल प्रॉम्प्ट सीधे बाइंड होते हैं; साझा लक्ष्य-मोड डिलीवरी उसी टाइप किए गए अनुमोदन मेटाडेटा को स्वीकृत WhatsApp संदेश रसीद से बाइंड करती है।
Signal प्रतिक्रिया अनुमोदन exec और Plugin, दोनों प्रॉम्प्ट केवल तभी संभालते हैं, जब मेल खाने वाला शीर्ष-स्तरीय अग्रेषण परिवार सक्षम हो और Signal पर रूट करता हो। सीधे समान-चैट Signal exec अनुमोदन स्पष्ट अनुमोदकों के बिना स्थानीय /approve फ़ॉलबैक को दबा सकते हैं; Signal प्रतिक्रिया समाधान के लिए अब भी channels.signal.allowFrom या defaultTo से स्पष्ट Signal अनुमोदक आवश्यक हैं।
Matrix नेटिव DM/चैनल रूटिंग और प्रतिक्रिया शॉर्टकट exec और Plugin, दोनों अनुमोदनों को संभालते हैं; Plugin प्राधिकरण अब भी channels.matrix.dm.allowFrom से आता है। Matrix नेटिव प्रॉम्प्ट पहले प्रॉम्प्ट ईवेंट पर com.openclaw.approval कस्टम ईवेंट सामग्री शामिल करते हैं, ताकि OpenClaw-संगत Matrix क्लाइंट संरचित अनुमोदन स्थिति पढ़ सकें, जबकि सामान्य क्लाइंट सादा-टेक्स्ट /approve फ़ॉलबैक बनाए रखें।
नेटिव Discord और Telegram अनुमोदन बटन ट्रांसपोर्ट-निजी कॉलबैक डेटा में स्पष्ट exec या Plugin स्वामी प्रकार ले जाते हैं और केवल उसी स्वामी को हल करते हैं। प्रकार-विहीन पुराने /approve नियंत्रण सीमित संगतता मार्ग बने रहते हैं: वे केवल उन्हीं स्वामी प्रकारों को आज़माते हैं जिन्हें कर्ता अनुमोदित कर सकता है, केवल अनुमोदन-नहीं-मिला परिणाम के बाद आगे बढ़ते हैं और अनुमोदन ID से कभी स्वामित्व का अनुमान नहीं लगाते।
अनुरोधकर्ता का अनुमोदक होना आवश्यक नहीं है।
यदि कोई ऑपरेटर UI या कॉन्फ़िगर किया गया अनुमोदन क्लाइंट अनुरोध स्वीकार नहीं कर सकता, तो प्रॉम्प्ट askFallback पर फ़ॉलबैक करता है।

/diagnostics और /export-trajectory जैसे संवेदनशील, केवल-स्वामी समूह कमांड अनुमोदन प्रॉम्प्ट और अंतिम परिणामों के लिए निजी स्वामी रूटिंग का उपयोग करते हैं। OpenClaw पहले उसी सतह पर निजी रूट का प्रयास करता है जहाँ स्वामी ने कमांड चलाया था। यदि उस सतह पर कोई निजी स्वामी रूट नहीं है, तो यह commands.ownerAllowFrom से पहले उपलब्ध स्वामी रूट पर फ़ॉलबैक करता है, ताकि Discord समूह कमांड तब भी अनुमोदन और परिणाम स्वामी के Telegram DM पर भेज सके, जब Telegram कॉन्फ़िगर किया गया प्राथमिक निजी इंटरफ़ेस हो। समूह चैट को केवल एक संक्षिप्त पावती मिलती है। देखें:

आधिकारिक मोबाइल ऑपरेटर ऐप

आधिकारिक iOS और Android ऐप, operator.admin कनेक्शन उपयोग किए जाने पर या अनुरोध द्वारा उनके युग्मित operator.approvals डिवाइस को स्पष्ट रूप से लक्षित किए जाने पर, Gateway के स्वामित्व वाले लंबित exec अनुमोदनों की समीक्षा भी कर सकते हैं। वे Control UI द्वारा उपयोग किया जाने वाला वही साफ़ किया गया टिकाऊ रिकॉर्ड पढ़ते हैं, प्रकार-जागरूक निर्णय सबमिट करते हैं और Gateway का प्रामाणिक पहले-उत्तर परिणाम प्रदर्शित करते हैं। Apple Watch इन अनुमोदन प्रॉम्प्ट को युग्मित iPhone के माध्यम से प्रतिबिंबित करती है, जिसमें एक बार अनुमति देने और अस्वीकार करने की कार्रवाइयाँ होती हैं। प्रत्यक्ष Watch Gateway मोड अनुमोदनों की समीक्षा नहीं करता। समाधान पावती खो जाने से सबमिट किया गया विकल्प प्रामाणिक नहीं बन जाता: ऐप नियंत्रण अक्षम करता है और रिकॉर्ड को फिर पढ़ता है। यदि किसी अन्य सतह ने जीत हासिल की, तो ऐप रिकॉर्ड किया गया निर्णय दिखाता है। लंबित प्रॉम्प्ट उन्हें जारी करने वाले Gateway से बंधे रहते हैं, इसलिए सक्रिय Gateway बदलने से पुरानी अनुमोदन ID पुनर्निर्देशित नहीं हो सकती।

macOS IPC प्रवाह

Gateway -> Node सेवा (WS)
                 |  IPC (UDS + टोकन + HMAC + TTL)
                 v
             Mac ऐप (UI + अनुमोदन + system.run)

सुरक्षा टिप्पणियाँ:

Unix सॉकेट मोड 0600, टोकन exec-approvals.json में संग्रहीत।
समान-UID पीयर जाँच।
चुनौती/प्रतिक्रिया (nonce + HMAC टोकन + अनुरोध हैश) + छोटी TTL।

अक्सर पूछे जाने वाले प्रश्न

किसी अनुमोदन लक्ष्य पर `accountId` और `threadId` का उपयोग कब किया जाएगा?

जब चैनल में कई कॉन्फ़िगर की गई पहचान हों और अनुमोदन प्रॉम्प्ट को किसी विशिष्ट खाते के माध्यम से बाहर जाना हो, तब accountId का उपयोग करें। जब गंतव्य विषयों या थ्रेड का समर्थन करता हो और प्रॉम्प्ट को शीर्ष-स्तरीय चैट के बजाय उसी थ्रेड में रहना हो, तब threadId का उपयोग करें। एक ठोस Telegram उदाहरण फ़ोरम विषयों और दो Telegram bot खातों वाला संचालन सुपरग्रुप है। to मान सुपरग्रुप को नामित करता है, accountId bot खाते का चयन करता है और threadId फ़ोरम विषय का चयन करता है:

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

इस सेटअप के साथ, अग्रेषित exec अनुमोदन ops-bot Telegram खाते द्वारा चैट -1001234567890 के विषय 77 में पोस्ट किए जाते हैं। accountId के बिना लक्ष्य चैनल के डिफ़ॉल्ट खाते का उपयोग करता है, और threadId के बिना लक्ष्य शीर्ष-स्तरीय गंतव्य पर पोस्ट करता है।

जब अनुमोदन किसी सत्र में भेजे जाते हैं, तो क्या उस सत्र में कोई भी उन्हें अनुमोदित कर सकता है?

नहीं। सत्र में डिलीवरी केवल यह नियंत्रित करती है कि प्रॉम्प्ट कहाँ दिखाई देता है। यह अपने आप उस चैट के प्रत्येक प्रतिभागी को अनुमोदन देने के लिए अधिकृत नहीं करती। सामान्य समान-चैट /approve के लिए, प्रेषक को उस चैनल सत्र में कमांड के लिए पहले से अधिकृत होना चाहिए। यदि चैनल स्पष्ट अनुमोदनकर्ताओं को उपलब्ध कराता है, तो वे अनुमोदनकर्ता /approve क्रिया को अधिकृत कर सकते हैं, भले ही वे उस सत्र में अन्यथा कमांड के लिए अधिकृत न हों। कुछ चैनल अधिक सख्त होते हैं। Discord, Telegram, Matrix, Slack के नेटिव अनुमोदन DM और इसी तरह के नेटिव अनुमोदन क्लाइंट, अनुमोदन प्राधिकरण के लिए अपनी निर्धारित अनुमोदनकर्ता सूचियों का उपयोग करते हैं। उदाहरण के लिए, Telegram फ़ोरम-विषय का अनुमोदन प्रॉम्प्ट विषय में सभी को दिखाई दे सकता है, लेकिन केवल channels.telegram.execApprovals.approvers या commands.ownerAllowFrom से निर्धारित संख्यात्मक Telegram उपयोगकर्ता ID ही उसे अनुमोदित या अस्वीकार कर सकती हैं।

Overview

Plugins

Plugin guides

Building plugins

Skills

Automation

Tools

Agent coordination

Exec अनुमोदन — उन्नत

सुरक्षित बिन (केवल stdin)

Argv सत्यापन और अस्वीकृत फ़्लैग

विश्वसनीय बाइनरी डायरेक्टरियाँ

शेल चेनिंग, रैपर और मल्टीप्लेक्सर

सुरक्षित बिन बनाम अनुमति-सूची

इंटरप्रेटर/रनटाइम कमांड

फ़ॉलोअप डिलीवरी व्यवहार

तृतीय-पक्ष क्लाइंट के लिए न्यूनतम स्कोप

चैट चैनलों पर अनुमोदन अग्रेषण

Plugin अनुमोदन अग्रेषण

किसी भी चैनल पर उसी चैट से अनुमोदन

नेटिव अनुमोदन डिलीवरी

आधिकारिक मोबाइल ऑपरेटर ऐप

macOS IPC प्रवाह

अक्सर पूछे जाने वाले प्रश्न

किसी अनुमोदन लक्ष्य पर `accountId` और `threadId` का उपयोग कब किया जाएगा?

जब अनुमोदन किसी सत्र में भेजे जाते हैं, तो क्या उस सत्र में कोई भी उन्हें अनुमोदित कर सकता है?

संबंधित

​सुरक्षित बिन (केवल stdin)

​Argv सत्यापन और अस्वीकृत फ़्लैग

​विश्वसनीय बाइनरी डायरेक्टरियाँ

​शेल चेनिंग, रैपर और मल्टीप्लेक्सर

​सुरक्षित बिन बनाम अनुमति-सूची

​इंटरप्रेटर/रनटाइम कमांड

​फ़ॉलोअप डिलीवरी व्यवहार

​तृतीय-पक्ष क्लाइंट के लिए न्यूनतम स्कोप

​चैट चैनलों पर अनुमोदन अग्रेषण

​Plugin अनुमोदन अग्रेषण

​किसी भी चैनल पर उसी चैट से अनुमोदन

​नेटिव अनुमोदन डिलीवरी

​आधिकारिक मोबाइल ऑपरेटर ऐप

​macOS IPC प्रवाह

​अक्सर पूछे जाने वाले प्रश्न

​किसी अनुमोदन लक्ष्य पर accountId और threadId का उपयोग कब किया जाएगा?

​जब अनुमोदन किसी सत्र में भेजे जाते हैं, तो क्या उस सत्र में कोई भी उन्हें अनुमोदित कर सकता है?

​संबंधित

सुरक्षित बिन (केवल stdin)

Argv सत्यापन और अस्वीकृत फ़्लैग

विश्वसनीय बाइनरी डायरेक्टरियाँ

शेल चेनिंग, रैपर और मल्टीप्लेक्सर

सुरक्षित बिन बनाम अनुमति-सूची

इंटरप्रेटर/रनटाइम कमांड

फ़ॉलोअप डिलीवरी व्यवहार

तृतीय-पक्ष क्लाइंट के लिए न्यूनतम स्कोप

चैट चैनलों पर अनुमोदन अग्रेषण

Plugin अनुमोदन अग्रेषण

किसी भी चैनल पर उसी चैट से अनुमोदन

नेटिव अनुमोदन डिलीवरी

आधिकारिक मोबाइल ऑपरेटर ऐप

macOS IPC प्रवाह

अक्सर पूछे जाने वाले प्रश्न

किसी अनुमोदन लक्ष्य पर `accountId` और `threadId` का उपयोग कब किया जाएगा?

जब अनुमोदन किसी सत्र में भेजे जाते हैं, तो क्या उस सत्र में कोई भी उन्हें अनुमोदित कर सकता है?

संबंधित