---
read_when:
    - सुरक्षित बिन या कस्टम सुरक्षित-बिन प्रोफ़ाइल कॉन्फ़िगर करना
    - अनुमोदनों को Slack/Discord/Telegram या अन्य चैट चैनलों पर अग्रेषित करना
    - किसी चैनल के लिए नेटिव अनुमोदन क्लाइंट लागू करना
summary: 'उन्नत exec अनुमोदन: सुरक्षित बाइनरी, इंटरप्रेटर बाइंडिंग, अनुमोदन अग्रेषण, नेटिव डिलीवरी'
title: Exec अनुमोदन — उन्नत
x-i18n:
    generated_at: "2026-07-27T18:41:43Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: ac90d41f867a8ae4f14b6c9c13f3732d102a65707f456623932b858145a9bf46
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

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

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

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

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

डिफ़ॉल्ट सुरक्षित बिन:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

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

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

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

सुरक्षित-बिन प्रोफ़ाइल के अनुसार अस्वीकृत फ़्लैग:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

- `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`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

सुरक्षित बिन, केवल-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>` प्रविष्टियों को `{}` के रूप में स्कैफ़ोल्ड कर सकता है (बाद में समीक्षा करके उन्हें अधिक सख़्त करें)। इंटरप्रेटर/रनटाइम बिन स्वतः स्कैफ़ोल्ड नहीं किए जाते।

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

```json5
{
  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` से अनुमोदित कर सकते हैं। यह सामान्य आउटबाउंड डिलीवरी पाइपलाइन का उपयोग करता है।

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

```json5
{
  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 अनुमति अनुरोध](/plugins/plugin-permission-requests) देखें।

```json5
{
  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 अनुमोदन कॉन्फ़िगरेशन क्यों हैं?](/help/faq-first-run)

- 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 कॉन्फ़िगर किया गया
प्राथमिक निजी इंटरफ़ेस हो। समूह चैट को केवल एक संक्षिप्त पावती मिलती है।

देखें:

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)
- [QQ bot](/channels/qqbot)

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

आधिकारिक 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`
फ़ोरम विषय का चयन करता है:

```json5
{
  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 ही उसे अनुमोदित या अस्वीकार कर सकती हैं।

## संबंधित

- [Exec अनुमोदन](/hi/tools/exec-approvals) — मुख्य नीति और अनुमोदन प्रवाह
- [Exec टूल](/hi/tools/exec)
- [उन्नत मोड](/hi/tools/elevated)
- [Skills](/hi/tools/skills) — स्किल-समर्थित स्वतः-अनुमति व्यवहार