---
read_when:
    - exec अनुमोदनों या अनुमति-सूचियों को कॉन्फ़िगर करना
    - macOS ऐप में exec अनुमोदन UX लागू करना
    - सैंडबॉक्स से बाहर निकलने वाले प्रॉम्प्ट और उनके निहितार्थों की समीक्षा करना
sidebarTitle: Exec approvals
summary: 'होस्ट exec अनुमोदन: नीति नियंत्रण, अनुमति-सूचियाँ और YOLO/सख्त कार्यप्रवाह'
title: Exec अनुमोदन
x-i18n:
    generated_at: "2026-07-27T18:38:45Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 2bd09746375061232e9094b8803d33859cac4c13c7bde14a059b7d52e48b5de8
    source_path: tools/exec-approvals.md
    workflow: 16
---

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

`deny`, `allowlist`, `ask`, `auto`, `full`,
Codex Guardian मैपिंग और ACPX हार्नेस अनुमतियों के मोड-प्रथम अवलोकन के लिए,
[अनुमति मोड](/hi/tools/permission-modes) देखें।

<Note>
प्रभावी नीति `tools.exec.*` और अनुमोदन डिफ़ॉल्ट में से **अधिक कठोर** होती है:
अनुमोदन केवल कॉन्फ़िगरेशन-व्युत्पन्न सुरक्षा/पूछताछ को अधिक कठोर कर सकते हैं, कभी
उन्हें शिथिल नहीं कर सकते। यदि कोई अनुमोदन फ़ील्ड छोड़ा गया है, तो
`tools.exec` मान उपयोग होता है। होस्ट Exec उस मशीन पर स्थानीय अनुमोदन स्थिति
का भी उपयोग करता है—निष्पादन होस्ट की अनुमोदन फ़ाइल में होस्ट-स्थानीय
`ask: "always"`, सत्र या कॉन्फ़िगरेशन डिफ़ॉल्ट द्वारा `ask: "on-miss"` का अनुरोध किए जाने पर भी,
पूछना जारी रखता है।
</Note>

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

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`                            | स्थानीय अनुरोधित नीति को स्थानीय होस्ट अनुमोदन फ़ाइल के साथ एक चरण में सिंक्रनाइज़ करता है। |

<Note>
प्रति-सत्र `/exec` ओवरराइड शामिल नहीं हैं। संबंधित सत्र के वर्तमान डिफ़ॉल्ट का निरीक्षण करने के लिए उसमें `/exec` चलाएँ। [सत्र ओवरराइड](/hi/tools/exec#session-overrides-exec) देखें।
</Note>

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

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

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

<Tip>
नेटिव चैट अनुमोदन क्लाइंट लंबित अनुमोदन संदेश पर चैनल-विशिष्ट सुविधाएँ पहले से
जोड़ सकते हैं। Matrix प्रतिक्रिया शॉर्टकट जोड़ता है (`✅` एक बार अनुमति दें,
`♾️` हमेशा अनुमति दें, `❌` अस्वीकार करें), जबकि फ़ॉलबैक के रूप में
संदेश में `/approve ...` भी बना रहता है।
</Tip>

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

अनुमोदन निष्पादन होस्ट की स्थानीय 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`

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

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

### `exec.ask`

<ParamField path="ask" type='"off" | "on-miss" | "always"'>
  होस्ट Exec के लिए कॉन्फ़िगर की गई पूछताछ नीति। `tools.exec.ask` और
  होस्ट अनुमोदन डिफ़ॉल्ट से आधारभूत अनुमोदन संकेत व्यवहार नियंत्रित करती है।
  डिफ़ॉल्ट `off` है। प्रति-कॉल `ask` टूल पैरामीटर ([Exec टूल](/hi/tools/exec#parameters)
  देखें) केवल उस आधाररेखा को कठोर कर सकता है, और प्रभावी होस्ट पूछताछ
  `off` होने पर चैनल से उत्पन्न मॉडल कॉल इसे अनदेखा करते हैं।

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

</ParamField>

### `askFallback`

<ParamField path="askFallback" type='"deny" | "allowlist" | "full"'>
  जब संकेत आवश्यक हो लेकिन कोई UI उपलब्ध न हो (या संकेत का समय समाप्त हो जाए),
  तब समाधान। छोड़े जाने पर डिफ़ॉल्ट `deny` होता है।

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

</ParamField>

### `tools.exec.strictInlineEval`

<ParamField path="strictInlineEval" type="boolean">
  `true` होने पर, इनलाइन कोड-मूल्यांकन रूपों को केवल अनुमोदन द्वारा
  चलने योग्य मानता है, भले ही इंटरप्रेटर बाइनरी स्वयं अनुमति-सूचीबद्ध हो।
  उन इंटरप्रेटर लोडर के लिए गहन सुरक्षा जो एक स्थिर फ़ाइल ऑपरेंड से साफ़-साफ़ मैप नहीं होते।
</ParamField>

सख्त मोड द्वारा पकड़े जाने वाले उदाहरण: `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`

<ParamField path="commandHighlighting" type="boolean" default="false">
  केवल प्रस्तुति: सक्षम होने पर, OpenClaw पार्सर-व्युत्पन्न कमांड विस्तार संलग्न
  कर सकता है, ताकि वेब अनुमोदन संकेत कमांड टोकन हाइलाइट कर सकें। यह
  `security`, `ask`, अनुमति-सूची मिलान, सख्त इनलाइन-मूल्यांकन
  व्यवहार, अनुमोदन अग्रेषण या कमांड निष्पादन को **नहीं** बदलता।
</ParamField>

वैश्विक रूप से `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`                     |

<Warning>
**महत्वपूर्ण अंतर:**

- `tools.exec.host=auto` चुनता है कि exec **कहाँ** चलता है: उपलब्ध होने पर sandbox में, अन्यथा gateway पर।
- YOLO चुनता है कि host exec को **कैसे** स्वीकृति दी जाती है: `security=full` और `ask=off`।
- YOLO कॉन्फ़िगर की गई host exec नीति के ऊपर कोई अलग अनुमान-आधारित कमांड-अस्पष्टीकरण स्वीकृति गेट या स्क्रिप्ट-प्रीफ्लाइट अस्वीकृति परत **नहीं** जोड़ता।
- `auto` sandbox किए गए सत्र से gateway रूटिंग को मुक्त ओवरराइड नहीं बनाता। प्रति-कॉल `host=node` अनुरोध की अनुमति `auto` से है; `host=gateway` की अनुमति `auto` से केवल तब है, जब कोई sandbox रनटाइम सक्रिय न हो। स्थिर गैर-स्वचालित डिफ़ॉल्ट के लिए, `tools.exec.host` सेट करें या स्पष्ट रूप से `/exec host=...` का उपयोग करें।

</Warning>

अपने स्वयं के गैर-इंटरैक्टिव अनुमति मोड उपलब्ध कराने वाले 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 "कभी प्रॉम्प्ट न करें" सेटअप

<Steps>
  <Step title="अनुरोधित कॉन्फ़िगरेशन नीति सेट करें">
    ```bash
    openclaw config set tools.exec.host gateway
    openclaw config set tools.exec.mode full
    openclaw gateway restart
    ```
  </Step>
  <Step title="host स्वीकृति फ़ाइल का मिलान करें">
    ```bash
    openclaw approvals set --stdin <<'EOF'
    {
      version: 1,
      defaults: {
        security: "full",
        ask: "off",
        askFallback: "full"
      }
    }
    EOF
    ```
  </Step>
</Steps>

### स्थानीय शॉर्टकट

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

<Note>
**केवल-स्थानीय सीमाएँ:**

- `openclaw exec-policy` node स्वीकृतियों को सिंक्रनाइज़ नहीं करता।
- `openclaw exec-policy set --host node` अस्वीकार कर दिया जाता है।
- Node exec स्वीकृतियाँ रनटाइम पर node से प्राप्त की जाती हैं, इसलिए node-लक्षित अपडेट में `openclaw approvals --node ...` का उपयोग करना आवश्यक है।

</Note>

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

- `/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` का उपयोग करता है। यदि सख्त मैन्युअल
अनुमति-सूचियाँ चाहिए, तो इसे अक्षम करें।

<Warning>
- यह एक **अंतर्निहित सुविधाजनक अनुमति-सूची** है, जो मैन्युअल पथ अनुमति-सूची प्रविष्टियों से अलग है।
- यह विश्वसनीय ऑपरेटर परिवेशों के लिए अभिप्रेत है, जहाँ Gateway और node एक ही भरोसा सीमा में हों।
- यदि सख्त स्पष्ट भरोसा आवश्यक है, तो `autoAllowSkills: false` रखें और केवल मैन्युअल पथ अनुमति-सूची प्रविष्टियों का उपयोग करें।

</Warning>

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

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

## 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](/hi/cli/approvals) देखें।

CLI: `openclaw approvals` gateway या node संपादन का समर्थन करता है — देखें
[स्वीकृति CLI](/hi/cli/approvals)।

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

प्रॉम्प्ट आवश्यक होने पर 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` टूल अस्वीकार करें।

## संबंधित

<CardGroup cols={2}>
  <Card title="Exec अनुमोदन - उन्नत" href="/hi/tools/exec-approvals-advanced" icon="gear">
    सुरक्षित बिन, इंटरप्रेटर बाइंडिंग और चैट पर अनुमोदन अग्रेषण।
  </Card>
  <Card title="Exec टूल" href="/hi/tools/exec" icon="terminal">
    शेल कमांड निष्पादन टूल।
  </Card>
  <Card title="उन्नत मोड" href="/hi/tools/elevated" icon="shield-exclamation">
    आपातकालीन पथ, जो अनुमोदनों को भी छोड़ देता है।
  </Card>
  <Card title="सैंडबॉक्सिंग" href="/hi/gateway/sandboxing" icon="box">
    सैंडबॉक्स मोड और वर्कस्पेस एक्सेस।
  </Card>
  <Card title="सुरक्षा" href="/hi/gateway/security" icon="lock">
    सुरक्षा मॉडल और सुदृढ़ीकरण।
  </Card>
  <Card title="सैंडबॉक्स बनाम टूल नीति बनाम उन्नत मोड" href="/hi/gateway/sandbox-vs-tool-policy-vs-elevated" icon="sliders">
    प्रत्येक नियंत्रण का उपयोग कब करें।
  </Card>
  <Card title="Skills" href="/hi/tools/skills" icon="sparkles">
    Skill-समर्थित स्वचालित अनुमति व्यवहार।
  </Card>
</CardGroup>
