Exec टूल

कार्यस्थान में शेल कमांड चलाएँ। exec एक परिवर्तनकारी शेल सतह है: चयनित होस्ट या सैंडबॉक्स फ़ाइलसिस्टम जहाँ भी अनुमति देता है, वहाँ कमांड फ़ाइलें बना, संपादित या हटा सकते हैं। write, edit, या apply_patch जैसे OpenClaw फ़ाइलसिस्टम टूल अक्षम करने से exec केवल-पढ़ने योग्य नहीं हो जाता।

process के माध्यम से अग्रभूमि और पृष्ठभूमि निष्पादन का समर्थन करता है। यदि process की अनुमति नहीं है, तो exec समकालिक रूप से चलता है और yieldMs/background को अनदेखा करता है। पृष्ठभूमि सत्र प्रति एजेंट के दायरे में होते हैं; process केवल उसी एजेंट के सत्र देखता है।

पैरामीटर

टिप्पणियाँ:

• host केवल auto, sandbox, gateway, या node स्वीकार करता है। यह होस्टनाम चयनकर्ता नहीं है; होस्टनाम जैसे मान कमांड चलने से पहले अस्वीकार कर दिए जाते हैं।
• प्रति-कॉल host=node की अनुमति auto से है; प्रति-कॉल host=gateway की अनुमति केवल तभी है जब कोई सैंडबॉक्स रनटाइम सक्रिय न हो।
• बिना किसी अतिरिक्त कॉन्फ़िगरेशन के भी host=auto सामान्य रूप से काम करता है: सैंडबॉक्स न होने पर यह gateway में रिज़ॉल्व होता है; सक्रिय सैंडबॉक्स होने पर यह सैंडबॉक्स में ही रहता है।
• elevated सैंडबॉक्स से निकलकर कॉन्फ़िगर किए गए होस्ट पथ पर जाता है: डिफ़ॉल्ट रूप से gateway, या tools.exec.host=node (या सत्र डिफ़ॉल्ट host=node) होने पर node। यह केवल तभी उपलब्ध है जब वर्तमान सत्र/प्रदाता के लिए उन्नत पहुँच सक्षम हो।
• gateway/node अनुमोदन होस्ट अनुमोदन फ़ाइल द्वारा नियंत्रित होते हैं।
• node के लिए युग्मित Node (सहयोगी ऐप या हेडलेस Node होस्ट) आवश्यक है। यदि एक से अधिक Node उपलब्ध हों, तो किसी एक को चुनने के लिए exec.node या tools.exec.node सेट करें।
• exec host=node Node के लिए एकमात्र शेल-निष्पादन पथ है; पुराना nodes.run रैपर हटा दिया गया है।
• गैर-Windows होस्ट पर, सेट होने पर exec SHELL का उपयोग करता है; यदि SHELL, fish है, तो fish से असंगत bash संरचनाओं से बचने के लिए यह PATH से bash (या sh) को प्राथमिकता देता है, फिर दोनों में से कोई भी मौजूद न होने पर SHELL का उपयोग करता है।
• Windows होस्ट पर, exec PowerShell 7 (pwsh) खोज (Program Files, ProgramW6432, फिर PATH) को प्राथमिकता देता है, फिर Windows PowerShell 5.1 का उपयोग करता है।
• गैर-Windows gateway होस्ट पर, bash और zsh exec कमांड स्टार्टअप स्नैपशॉट का उपयोग करते हैं। OpenClaw शेल स्टार्टअप फ़ाइलों से सोर्स किए जा सकने वाले उपनाम/फ़ंक्शन और एक छोटा सुरक्षित परिवेश सेट लेकर $OPENCLAW_STATE_DIR/cache/shell-snapshots/ में संग्रहीत करता है, फिर प्रत्येक exec कमांड से पहले उस स्नैपशॉट को सोर्स करता है। सीक्रेट जैसे दिखने वाले वेरिएबल बाहर रखे जाते हैं; सैंडबॉक्स और Node exec इस स्नैपशॉट का उपयोग नहीं करते। इस स्नैपशॉट पथ को अक्षम करने के लिए Gateway प्रक्रिया परिवेश में OPENCLAW_EXEC_SHELL_SNAPSHOT=0 सेट करें।
• होस्ट निष्पादन (gateway/node) बाइनरी हाइजैकिंग या इंजेक्ट किए गए कोड को रोकने के लिए env.PATH और लोडर ओवरराइड (LD_*/DYLD_*) अस्वीकार करता है।
• OpenClaw आरंभ किए गए कमांड परिवेश (PTY और सैंडबॉक्स निष्पादन सहित) में OPENCLAW_SHELL=exec सेट करता है, ताकि शेल/प्रोफ़ाइल नियम exec-टूल संदर्भ पहचान सकें।
• चैनल से उत्पन्न रन के लिए, चैनल द्वारा वे आईडी प्रदान किए जाने पर OpenClaw OPENCLAW_CHANNEL_CONTEXT में सीमित प्रेषक/चैट पहचान JSON पेलोड भी उपलब्ध कराता है।
• exec, openclaw channels login या /approve शेल कमांड नहीं चला सकता: openclaw channels login एक इंटरैक्टिव चैनल-प्रमाणीकरण प्रवाह है और /approve को शेल के बजाय अनुमोदन कमांड हैंडलर से होकर जाना आवश्यक है। चैनल लॉगिन gateway होस्ट के टर्मिनल में चलाएँ, या उपलब्ध होने पर चैनल-विशिष्ट लॉगिन एजेंट टूल का उपयोग करें (उदाहरण के लिए whatsapp_login)।
• महत्वपूर्ण: सैंडबॉक्सिंग डिफ़ॉल्ट रूप से बंद है। यदि सैंडबॉक्सिंग बंद है, तो अंतर्निहित host=auto, gateway में रिज़ॉल्व होता है। स्पष्ट host=sandbox फिर भी gateway होस्ट पर चुपचाप चलने के बजाय सुरक्षित रूप से विफल होता है। सैंडबॉक्सिंग सक्षम करें या अनुमोदनों के साथ host=gateway का उपयोग करें।
• स्क्रिप्ट पूर्व-जाँच (सामान्य Python/Node शेल-सिंटैक्स त्रुटियों के लिए) केवल प्रभावी workdir सीमा के भीतर की फ़ाइलों की जाँच करती है। यदि कोई स्क्रिप्ट पथ workdir के बाहर रिज़ॉल्व होता है, तो उस फ़ाइल की पूर्व-जाँच छोड़ दी जाती है। host=gateway और प्रभावी नीति ask=off के साथ security=full होने पर पूर्व-जाँच पूरी तरह छोड़ दी जाती है।
• अभी शुरू होने वाले लंबे कार्य को एक बार शुरू करें और, सक्षम होने तथा कमांड द्वारा आउटपुट देने या विफल होने पर, स्वचालित पूर्णता वेक पर निर्भर रहें। लॉग, स्थिति, इनपुट या हस्तक्षेप के लिए process का उपयोग करें; sleep लूप, timeout लूप या बार-बार पोलिंग से शेड्यूलिंग का अनुकरण न करें।
• एजेंट द्वारा शुरू किए गए पृष्ठभूमि कमांड पूर्ण होने तक Web, iOS और Android के पृष्ठभूमि-कार्य दृश्यों में दिखाई देते हैं। पूर्णता Heartbeat द्वारा एजेंट को फिर जगाने से पहले कार्य लेजर को अंतिम रूप दिया जाता है।
• जो कार्य बाद में या किसी समय-सारणी के अनुसार होना चाहिए, उसके लिए exec sleep/delay पैटर्न के बजाय cron का उपयोग करें।

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

बिना अनुमोदन वाला होस्ट exec, gateway और Node (mode=full) के लिए डिफ़ॉल्ट है—यह होस्ट-नीति के डिफ़ॉल्ट से आता है, host=auto से नहीं। यदि आप अनुमोदन/अनुमति-सूची व्यवहार चाहते हैं, तो tools.exec.mode सेट करें और होस्ट अनुमोदन फ़ाइल को अधिक सख्त बनाएँ; Exec अनुमोदन देखें। सैंडबॉक्स स्थिति की परवाह किए बिना gateway या Node रूटिंग बाध्य करने के लिए, tools.exec.host सेट करें या /exec host=... का उपयोग करें।

उदाहरण:

{  tools: {    exec: {      pathPrepend: ["~/bin", "/opt/oss/bin"],    },  },}

मोड

tools.exec.mode मानक स्थायी नीति नियंत्रण है। रनटाइम सुरक्षा और अनुमोदन व्यवहार इससे निर्धारित होते हैं।

प्रति-सत्र /exec ask=always स्थायी मोड की परवाह किए बिना हर बार मानव से पूछता है।

स्वचालित-समीक्षा अनुमोदन केवल एक बार उपयोग होता है। Gateway पर, OpenClaw समीक्षक को समाधान किया गया निष्पादन-योग्य पथ देता है और निष्पादन को उसी पथ से बाँध देता है। जिन कमांड को एक प्रवर्तनीय निष्पादन योजना में सीमित नहीं किया जा सकता—जैसे heredocs, shell expansions, या असमर्थित wrapper quoting—वे मानव अनुमोदन पर वापस जाते हैं, भले ही मॉडल अन्यथा उन्हें अनुमति देता।

Codex app-server कमांड अनुमोदन, जिन पर स्पष्ट runtime या मूल नीति से पहले ही निर्णय नहीं हुआ है, मानव अनुमोदन मार्ग का उपयोग करते हैं। OpenClaw इन अनुरोधों के लिए अपने कॉन्फ़िगर किए गए exec समीक्षक को नहीं चलाता, क्योंकि Codex ऐसा प्रवर्तनीय समाधान किया गया निष्पादन-योग्य पथ उपलब्ध नहीं कराता जो समीक्षा निर्णय को Codex द्वारा चलाए जाने वाले कमांड से बाँध सके।

इनलाइन eval (strictInlineEval)

जब tools.exec.strictInlineEval, true होता है, तो इनलाइन interpreter-eval रूपों के लिए समीक्षक या स्पष्ट अनुमोदन आवश्यक है: python -c, node -e, ruby -e, perl -e, php -r, lua -e, osascript -e, और अन्य समर्थित interpreters तथा command carriers में इसी तरह के रूप (awk, find -exec, make, sed, xargs, और अधिक)। mode=auto में, सामान्य exec अनुमोदन पथ मूल स्वचालित समीक्षक को स्पष्ट रूप से कम-जोखिम वाले एकबारगी कमांड की अनुमति देने दे सकता है; सीधे node-host system.run कॉल के लिए फिर भी स्पष्ट अनुमोदन आवश्यक है, क्योंकि वे कमांड को मानव अनुमोदन मार्ग पर नहीं भेज सकते। यदि समीक्षक पूछने को कहता है, तो अनुरोध मानव के पास जाता है। allow-always फिर भी सौम्य interpreter/script आमंत्रणों को स्थायी बना सकता है, लेकिन inline-eval रूप स्थायी अनुमति नियम नहीं बनते।

PATH प्रबंधन

• host=gateway: आपके login-shell PATH को exec परिवेश में मिलाता है। Host निष्पादन के लिए env.PATH ओवरराइड अस्वीकृत किए जाते हैं। daemon स्वयं फिर भी न्यूनतम PATH के साथ चलता है:
  • macOS: /opt/homebrew/bin, /usr/local/bin, /usr/bin, /bin
  • Linux: /usr/local/bin, /usr/bin, /bin
  • स्टार्टअप के दौरान उपयोगकर्ता shell कॉन्फ़िगरेशन (जैसे ~/.zshenv या /etc/zshenv) को प्राथमिकता वाले पथों को ओवरराइड करने से रोकने के लिए, निष्पादन से ठीक पहले shell कमांड के भीतर अंतिम PATH में tools.exec.pathPrepend प्रविष्टियाँ सुरक्षित रूप से आगे जोड़ी जाती हैं।
• host=sandbox: कंटेनर के भीतर sh -lc (login shell) चलाता है, इसलिए /etc/profile, PATH को रीसेट कर सकता है। OpenClaw प्रोफ़ाइल स्रोत करने के बाद एक आंतरिक env var के माध्यम से env.PATH को आगे जोड़ता है (कोई shell interpolation नहीं); tools.exec.pathPrepend यहाँ भी लागू होता है।
• host=node: आपके द्वारा दिए गए केवल गैर-अवरुद्ध env ओवरराइड Node को भेजे जाते हैं। Host निष्पादन के लिए env.PATH ओवरराइड अस्वीकृत होते हैं और Node hosts द्वारा अनदेखे किए जाते हैं। यदि आपको किसी Node पर अतिरिक्त PATH प्रविष्टियों की आवश्यकता है, तो Node host सेवा परिवेश (systemd/launchd) कॉन्फ़िगर करें या टूल को मानक स्थानों पर इंस्टॉल करें।

प्रति-एजेंट Node बाइंडिंग (कॉन्फ़िगरेशन में कुंजीयुक्त एजेंट ID का उपयोग करें):

openclaw config get agents.entriesopenclaw config set 'agents.entries.main.tools.exec.node' "node-id-or-name"

Control UI: डिवाइस पृष्ठ में उन्हीं सेटिंग्स के लिए एक छोटा "Exec node binding" पैनल शामिल है।

सत्र ओवरराइड (/exec)

host, security, ask, और node के लिए प्रति-सत्र डिफ़ॉल्ट सेट करने हेतु /exec का उपयोग करें। वर्तमान मान दिखाने के लिए बिना तर्कों के /exec भेजें।

उदाहरण:

/exec host=auto security=allowlist ask=on-miss node=mac-1

/exec को केवल चैनल अनुमत-सूचियों/पेयरिंग और पहुँच समूहों के माध्यम से अधिकृत प्रेषकों के लिए स्वीकार किया जाता है। पहुँच-समूह प्रवर्तन हमेशा चालू रहता है। यह केवल सत्र स्थिति अपडेट करता है और कॉन्फ़िगरेशन नहीं लिखता। अधिकृत बाहरी चैनल प्रेषक ये सत्र डिफ़ॉल्ट सेट कर सकते हैं। आंतरिक Gateway/webchat क्लाइंट को इन्हें स्थायी बनाने के लिए operator.admin की आवश्यकता होती है।

Exec को पूरी तरह अक्षम करने के लिए, इसे टूल नीति (tools.deny: ["exec"] या प्रति-एजेंट) द्वारा अस्वीकार करें। Host अनुमोदन तब तक लागू रहते हैं, जब तक आप स्पष्ट रूप से security=full और ask=off सेट नहीं करते।

Exec अनुमोदन (सहयोगी ऐप / Node host)

Sandbox किए गए एजेंटों को Gateway या Node host पर exec चलने से पहले प्रति-अनुरोध अनुमोदन की आवश्यकता हो सकती है। नीति, अनुमत-सूची और UI प्रवाह के लिए Exec अनुमोदन देखें।

जब मानव अनुमोदन आवश्यक होता है, Node-host और गैर-मूल Gateway प्रवाह तुरंत status: "approval-pending" तथा एक अनुमोदन ID के साथ लौटते हैं। मूल चैट और Web UI Gateway प्रवाह इसके बजाय इनलाइन प्रतीक्षा कर सकते हैं और अनुमोदन के बाद अंतिम कमांड परिणाम लौटा सकते हैं। approval-pending परिणाम का अर्थ है कि कमांड शुरू नहीं हुआ है, इसलिए अग्रभूमि फ़ॉलबैक चेतावनियाँ केवल तभी दिखाई देती हैं जब अनुमोदित कमांड वास्तव में इनलाइन चलता है। अनुमोदित अतुल्यकालिक रन कमांड प्रगति और पूर्णता सिस्टम इवेंट (Exec running / Exec finished) उत्सर्जित करते हैं; अस्वीकृत या समय-समाप्त अनुमोदन अंतिम होते हैं और अस्वीकृति सिस्टम इवेंट से एजेंट सत्र को सक्रिय नहीं करते।

मूल अनुमोदन कार्ड/बटन वाले चैनलों पर, एजेंट को पहले उस मूल UI पर निर्भर रहना चाहिए और मैन्युअल /approve कमांड केवल तभी शामिल करना चाहिए जब टूल परिणाम स्पष्ट रूप से कहे कि चैट अनुमोदन अनुपलब्ध हैं या मैन्युअल अनुमोदन ही एकमात्र मार्ग है।

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

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

जब security=allowlist, shell कमांड स्वतः केवल तभी अनुमत होते हैं जब प्रत्येक pipeline खंड अनुमत-सूची में हो या सुरक्षित बिन हो। Chaining (;, &&, ||) और redirections अनुमत-सूची मोड में तब तक अस्वीकृत होते हैं, जब तक प्रत्येक शीर्ष-स्तरीय खंड अनुमत-सूची (सुरक्षित बिन सहित) को संतुष्ट न करे। Redirections असमर्थित रहते हैं। स्थायी allow-always विश्वास इस नियम को बायपास नहीं करता: chained कमांड में फिर भी प्रत्येक शीर्ष-स्तरीय खंड का मिलान आवश्यक है।

autoAllowSkills, exec अनुमोदनों में एक अलग सुविधा मार्ग है, मैन्युअल पथ अनुमत-सूची प्रविष्टियों के समान नहीं। सख्त स्पष्ट विश्वास के लिए, autoAllowSkills को अक्षम रखें।

दोनों नियंत्रणों का उपयोग अलग-अलग कार्यों के लिए करें:

• tools.exec.safeBins: छोटे, केवल-stdin स्ट्रीम फ़िल्टर।
• tools.exec.safeBinTrustedDirs: सुरक्षित-बिन निष्पादन-योग्य पथों के लिए स्पष्ट अतिरिक्त विश्वसनीय निर्देशिकाएँ।
• tools.exec.safeBinProfiles: कस्टम सुरक्षित बिन के लिए स्पष्ट argv नीति।
• अनुमत-सूची: निष्पादन-योग्य पथों के लिए स्पष्ट विश्वास।

safeBins को सामान्य अनुमत-सूची न मानें और interpreter/runtime बाइनरी (उदाहरण के लिए python3, node, ruby, bash) न जोड़ें। यदि आपको इनकी आवश्यकता है, तो स्पष्ट अनुमत-सूची प्रविष्टियों का उपयोग करें और अनुमोदन प्रॉम्प्ट सक्षम रखें।

जब interpreter/runtime safeBins प्रविष्टियों में स्पष्ट प्रोफ़ाइल नहीं होतीं, तब openclaw security audit चेतावनी देता है और openclaw doctor --fix अनुपलब्ध कस्टम safeBinProfiles प्रविष्टियों का ढाँचा तैयार कर सकता है। जब आप jq जैसे व्यापक-व्यवहार वाले बिन को स्पष्ट रूप से safeBins में वापस जोड़ते हैं, तब openclaw security audit और openclaw doctor भी चेतावनी देते हैं (jq परिवेश डेटा पढ़ सकता है और मॉड्यूल या स्टार्टअप फ़ाइलों से jq कोड लोड कर सकता है, इसलिए इसके बजाय स्पष्ट अनुमत-सूची प्रविष्टियों या अनुमोदन-गेट वाले रन को प्राथमिकता दें)। स्पष्ट रूप से सूचीबद्ध होने पर भी jq को सुरक्षित बिन के रूप में अस्वीकार किया जाता है। यदि आप interpreters को स्पष्ट रूप से अनुमत-सूची में रखते हैं, तो tools.exec.strictInlineEval सक्षम करें, ताकि इनलाइन code-eval रूपों के लिए फिर भी समीक्षक या स्पष्ट अनुमोदन आवश्यक हो।

नीति के पूर्ण विवरण और उदाहरणों के लिए, Exec अनुमोदन और सुरक्षित बिन बनाम अनुमत-सूची देखें।

उदाहरण

अग्रभूमि:

{ "tool": "exec", "command": "ls -la" }

पृष्ठभूमि + पोल:

{"tool":"exec","command":"npm run build","yieldMs":1000}{"tool":"process","action":"poll","sessionId":"<id>"}

Polling माँग-आधारित स्थिति के लिए है, प्रतीक्षा लूप के लिए नहीं। यदि स्वचालित पूर्णता सक्रियण सक्षम है, तो आउटपुट उत्सर्जित करने या विफल होने पर कमांड सत्र को सक्रिय कर सकता है।

कुंजियाँ भेजें (tmux-शैली):

{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["Enter"]}{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["C-c"]}{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["Up","Up","Enter"]}

सबमिट करें (केवल CR भेजें):

{ "tool": "process", "action": "submit", "sessionId": "<id>" }

पेस्ट करें (डिफ़ॉल्ट रूप से bracketed):

{ "tool": "process", "action": "paste", "sessionId": "<id>", "text": "line1\nline2\n" }

apply_patch

apply_patch, संरचित बहु-फ़ाइल संपादनों के लिए exec का एक उप-टूल है। यह डिफ़ॉल्ट रूप से सक्षम है और किसी भी मॉडल प्रदाता के लिए उपलब्ध है; allowModels इसे प्रतिबंधित कर सकता है। कॉन्फ़िगरेशन का उपयोग केवल तभी करें जब आप इसे अक्षम करना चाहते हों या विशिष्ट मॉडलों तक सीमित करना चाहते हों:

{  tools: {    exec: {      applyPatch: { workspaceOnly: true, allowModels: ["gpt-5.6-sol"] },    },  },}

टिप्पणियाँ:

• टूल नीति फिर भी लागू होती है; allow: ["write"] अंतर्निहित रूप से apply_patch की अनुमति देता है।
• deny: ["write"], apply_patch को अस्वीकार नहीं करता; apply_patch को स्पष्ट रूप से अस्वीकार करें या जब पैच लेखन भी अवरुद्ध होना चाहिए, तब deny: ["group:fs"] का उपयोग करें।
• कॉन्फ़िगरेशन tools.exec.applyPatch के अंतर्गत रहता है।
• tools.exec.applyPatch.enabled का डिफ़ॉल्ट true है; टूल को अक्षम करने के लिए इसे false पर सेट करें।
• tools.exec.applyPatch.workspaceOnly का डिफ़ॉल्ट true (कार्यस्थान के भीतर सीमित) है। केवल तभी इसे false पर सेट करें, जब आप जानबूझकर चाहते हों कि apply_patch कार्यस्थान निर्देशिका के बाहर लिखे/हटाए।
• tools.exec.applyPatch.allowModels, मॉडल ID की वैकल्पिक अनुमत-सूची है (raw, जैसे gpt-5.4, या पूर्ण, जैसे openai/gpt-5.4)। सेट होने पर केवल मेल खाने वाले मॉडलों को टूल मिलता है; सेट न होने पर सभी मॉडलों को मिलता है।

संबंधित

• Exec अनुमोदन — shell कमांड के लिए अनुमोदन गेट
• Sandboxing — sandbox किए गए परिवेशों में कमांड चलाना
• पृष्ठभूमि प्रक्रिया — लंबे समय तक चलने वाला exec और process टूल
• सुरक्षा — टूल नीति और उन्नत पहुँच