आवश्यकताएँ
- एक OpenClaw चेकआउट या इंस्टॉलेशन, जिसमें
openclawCLI उपलब्ध हो - चुने गए स्रोत (ClawHub, npm या किसी git होस्ट) तक नेटवर्क पहुँच
- उस Plugin के सेटअप दस्तावेज़ों में बताए गए सभी Plugin-विशिष्ट क्रेडेंशियल, कॉन्फ़िगरेशन कुंजियाँ या OS टूल
- आपके चैनलों को सेवा देने वाले Gateway को पुनः लोड या पुनः आरंभ करने की अनुमति
त्वरित शुरुआत
1
Plugin खोजें
सार्वजनिक Plugin पैकेजों के लिए ClawHub में खोजें:सामुदायिक Plugins खोजने के लिए ClawHub प्राथमिक माध्यम है। लॉन्च बदलाव के
दौरान, सामान्य बिना-उपसर्ग वाले पैकेज स्पेक तब तक npm से इंस्टॉल होते हैं,
जब तक वे किसी आधिकारिक Plugin आईडी से मेल न खाएँ। किसी बंडल किए गए Plugin
से मेल खाने वाले कच्चे
@openclaw/* स्पेक उस बंडल की गई प्रति में
रिज़ॉल्व होते हैं। किसी स्रोत की विशेष रूप से आवश्यकता होने पर स्पष्ट स्रोत
उपसर्ग का उपयोग करें।2
Plugin इंस्टॉल करें
npm-pack: या मार्केटप्लेस स्रोतों के लिए,
स्रोत की समीक्षा करके उस पर भरोसा करने के बाद, गैर-इंटरैक्टिव इंस्टॉलेशन में
--force आवश्यक है।3
इसे कॉन्फ़िगर और सक्षम करें
Plugin-विशिष्ट सेटिंग्स को यदि
plugins.entries.<id>.config के अंतर्गत कॉन्फ़िगर करें।
यदि Plugin पहले से सक्षम नहीं है, तो उसे सक्षम करें:plugins.allow सेट है, तो Plugin के लोड होने से पहले इंस्टॉल किए गए
Plugin की आईडी उस सूची में होनी चाहिए। openclaw plugins install इंस्टॉल की गई
आईडी को मौजूदा plugins.allow सूची में जोड़ता है और उसी आईडी को
plugins.deny से हटाता है, ताकि स्पष्ट रूप से इंस्टॉल किया गया Plugin
पुनः आरंभ होने के बाद लोड हो सके।4
Gateway को पुनः लोड होने दें
Plugin कोड इंस्टॉल, अपडेट या अनइंस्टॉल करने के लिए Gateway को पुनः आरंभ
करना आवश्यक है। कॉन्फ़िगरेशन पुनः लोड सक्षम होने वाला प्रबंधित Gateway,
बदले हुए Plugin इंस्टॉलेशन रिकॉर्ड का पता लगाकर अपने-आप पुनः आरंभ हो जाता
है। अन्यथा, इसे स्वयं पुनः आरंभ करें:सक्षम/अक्षम करने पर कॉन्फ़िगरेशन और कोल्ड रजिस्ट्री अपडेट होते हैं। सक्रिय
रनटाइम सतहों का सबसे स्पष्ट प्रमाण अब भी रनटाइम निरीक्षण है।
5
रनटाइम पंजीकरण सत्यापित करें
--runtime का उपयोग करें। साधारण
inspect केवल कोल्ड मैनिफ़ेस्ट और रजिस्ट्री जाँच है।कॉन्फ़िगरेशन
इंस्टॉलेशन स्रोत चुनें
बिना-उपसर्ग वाले पैकेज स्पेक का विशेष संगतता व्यवहार होता है: बंडल किए गए
Plugin की आईडी से मेल खाने वाला बिना-उपसर्ग नाम उस बंडल स्रोत का उपयोग करता है;
आधिकारिक बाहरी Plugin की आईडी से मेल खाने वाला नाम आधिकारिक पैकेज सूची का उपयोग
करता है; लॉन्च बदलाव के दौरान अन्य सभी बिना-उपसर्ग स्पेक npm के माध्यम से
इंस्टॉल होते हैं। बंडल किए गए Plugins से मेल खाने वाले कच्चे
@openclaw/* स्पेक भी npm फ़ॉलबैक से पहले बंडल की गई प्रति में रिज़ॉल्व
होते हैं। बंडल की गई प्रति के बजाय जानबूझकर बाहरी npm पैकेज इंस्टॉल करने के लिए
npm:@openclaw/<plugin>@<version> का उपयोग करें। नियतात्मक स्रोत चयन के लिए
clawhub:, npm:, git: या
npm-pack: का उपयोग करें। पूर्ण कमांड अनुबंध के लिए
openclaw plugins देखें।
npm इंस्टॉलेशन के लिए, बिना पिन किए गए स्पेक और @latest इस OpenClaw
बिल्ड के साथ संगतता दर्शाने वाला नवीनतम स्थिर पैकेज चुनते हैं। यदि npm की
वर्तमान नवीनतम रिलीज़ इस बिल्ड द्वारा समर्थित संस्करण से नया
openclaw.compat.pluginApi या openclaw.install.minHostVersion घोषित करती है, तो OpenClaw पुराने
स्थिर संस्करणों को स्कैन करता है और उपयुक्त नवीनतम संस्करण इंस्टॉल करता है।
सटीक संस्करण और @beta जैसे स्पष्ट चैनल टैग चुने गए पैकेज पर पिन
रहते हैं और असंगत होने पर विफल होते हैं।
ऑपरेटर इंस्टॉलेशन नीति
किसी Plugin का इंस्टॉलेशन या अपडेट आगे बढ़ने से पहले विश्वसनीय स्थानीय नीति कमांड चलाने के लिएsecurity.installPolicy कॉन्फ़िगर करें। नीति को मेटाडेटा के साथ
स्टेज किया गया स्रोत पाथ मिलता है और वह इंस्टॉलेशन की अनुमति दे सकती है या उसे
रोक सकती है। यह CLI और Gateway-समर्थित, दोनों इंस्टॉलेशन/अपडेट पाथ को कवर करती
है। Plugin के before_install हुक बाद में और केवल उन OpenClaw प्रक्रियाओं
में चलते हैं जहाँ Plugin हुक लोड किए गए हों, इसलिए ऑपरेटर के स्वामित्व वाले
इंस्टॉलेशन निर्णयों के लिए इसके बजाय security.installPolicy का उपयोग करें।
बहिष्कृत --dangerously-force-unsafe-install फ़्लैग संगतता के लिए स्वीकार किया जाता है, लेकिन
कुछ नहीं करता: यह इंस्टॉलेशन नीति या OpenClaw की अंतर्निर्मित Plugin निर्भरता
प्रतिबंध-सूची को बायपास नहीं करता।
Skills और Plugins, दोनों द्वारा उपयोग किए जाने वाले साझा
security.installPolicy निष्पादन स्कीमा के लिए
Skills कॉन्फ़िगरेशन
देखें।
Plugin नीति कॉन्फ़िगर करें
सामान्य Plugin कॉन्फ़िगरेशन संरचना यह है:plugins.enabled: falseसभी Plugins को अक्षम करता है और खोज/लोड कार्य छोड़ देता है। इसके सक्रिय रहने के दौरान पुराने Plugin संदर्भ निष्क्रिय रहते हैं; यदि आप पुरानी आईडी हटाना चाहते हैं, तो डॉक्टर क्लीनअप चलाने से पहले Plugins को फिर से सक्षम करें।plugins.deny, अनुमति और प्रति-Plugin सक्षमता पर प्रभावी होता है।plugins.allowएक विशिष्ट अनुमति-सूची है। अनुमति-सूची से बाहर के Plugin-स्वामित्व वाले टूल तब भी अनुपलब्ध रहते हैं, जबtools.allowमें"*"शामिल हो।plugins.entries.<id>.enabled: falseकिसी एक Plugin के कॉन्फ़िगरेशन को रखते हुए उसे अक्षम करता है।plugins.load.pathsस्पष्ट स्थानीय Plugin फ़ाइलें या डायरेक्टरियाँ जोड़ता है। प्रबंधितplugins installस्थानीय पाथ Plugin डायरेक्टरियाँ या आर्काइव होने चाहिए; स्वतंत्र Plugin फ़ाइलों के लिएplugins.load.pathsका उपयोग करें।- वर्कस्पेस-मूल Plugins डिफ़ॉल्ट रूप से अक्षम रहते हैं; स्थानीय वर्कस्पेस कोड उपयोग करने से पहले उन्हें स्पष्ट रूप से सक्षम करें या अनुमति-सूची में जोड़ें।
- बंडल किए गए Plugins अपने अंतर्निर्मित डिफ़ॉल्ट-चालू/डिफ़ॉल्ट-बंद मेटाडेटा का पालन करते हैं, जब तक कॉन्फ़िगरेशन उसे स्पष्ट रूप से ओवरराइड न करे।
plugins.slots.<slot>(memoryयाcontextEngine) किसी विशिष्ट श्रेणी के लिए एक Plugin चुनता है। स्लॉट चयन को स्पष्ट सक्रियण माना जाता है और वह उस स्लॉट के लिए चुने गए Plugin को बलपूर्वक सक्षम करता है, भले ही वह अन्यथा ऑप्ट-इन हो।plugins.denyऔरplugins.entries.<id>.enabled: falseअब भी उसे रोकते हैं।- बंडल किए गए ऑप्ट-इन Plugins तब अपने-आप सक्रिय हो सकते हैं, जब कॉन्फ़िगरेशन उनके स्वामित्व वाली किसी सतह का नाम दे, जैसे प्रदाता/मॉडल संदर्भ, चैनल कॉन्फ़िगरेशन, CLI बैकएंड या एजेंट हार्नेस रनटाइम।
- OpenAI-परिवार की Codex रूटिंग प्रदाता और रनटाइम Plugin की
सीमाओं को अलग रखती है: पुराने Codex मॉडल संदर्भ पुराने कॉन्फ़िगरेशन हैं जिन्हें
डॉक्टर सुधारता है, जबकि बंडल किया गया
codexPlugin मानकopenai/*एजेंट संदर्भों, स्पष्टagentRuntime.id: "codex"और पुरानेcodex/*संदर्भों के लिए Codex ऐप-सर्वर रनटाइम का स्वामी है।
plugins.allow सेट न हो और गैर-बंडल Plugins वर्कस्पेस या वैश्विक Plugin
रूट से अपने-आप खोजे जाएँ, तो स्टार्टअप खोजे गए Plugin आईडी और छोटी सूचियों के
लिए एक न्यूनतम plugins.allow स्निपेट के साथ
plugins.allow is empty; discovered non-bundled plugins may auto-load: ... लॉग करता है। विश्वसनीय Plugins को
openclaw.json में कॉपी करने से पहले सूचीबद्ध Plugin आईडी पर
openclaw plugins list --enabled --verbose या
openclaw plugins inspect <id> चलाएँ। यही विश्वास-पिनिंग तब भी लागू
होती है जब निदान बताता है कि कोई Plugin without install/load-path provenance लोड हुआ: उस Plugin
आईडी का निरीक्षण करें, फिर उसे plugins.allow में पिन करें या विश्वसनीय
स्रोत से पुनः इंस्टॉल करें, ताकि OpenClaw इंस्टॉलेशन उद्गम रिकॉर्ड कर सके।
जब कॉन्फ़िगरेशन सत्यापन पुरानी Plugin आईडी, अनुमति-सूची/टूल बेमेल या पुराने
बंडल Plugin पाथ की रिपोर्ट करे, तब openclaw doctor या
openclaw doctor --fix चलाएँ।
Plugin प्रारूप समझें
OpenClaw दो Plugin प्रारूपों को पहचानता है:
दोनों प्रारूप
openclaw plugins list, openclaw plugins inspect,
openclaw plugins enable और openclaw plugins disable में दिखाई देते हैं। बंडल संगतता सीमा
के लिए Plugin बंडल और मूल Plugin लेखन के लिए
Plugins बनाना देखें।
Plugin हुक
Plugins रनटाइम पर दो अलग-अलग API के माध्यम से हुक पंजीकृत कर सकते हैं:api.on(...)रनटाइम जीवनचक्र घटनाओं के लिए टाइप किए गए हुक हैं। मिडलवेयर, नीति, संदेश पुनर्लेखन, प्रॉम्प्ट का आकार तय करने और टूल नियंत्रण के लिए यह पसंदीदा सतह है।api.registerHook(...), हुक में वर्णित आंतरिक हुक सिस्टम के लिए है। यह मुख्यतः व्यापक कमांड/जीवनचक्र सह-प्रभावों और मौजूदा HOOK-शैली स्वचालन के साथ संगतता के लिए है।
command:new, command:reset, message:sent या ऐसी ही व्यापक
घटनाओं पर प्रतिक्रिया करता है, तो api.registerHook पर्याप्त है।
Plugin द्वारा प्रबंधित आंतरिक हुक openclaw hooks list में
plugin:<id> के साथ दिखाई देते हैं। आप उन्हें openclaw hooks के
माध्यम से सक्षम या अक्षम नहीं कर सकते; इसके बजाय Plugin को सक्षम या अक्षम करें।
सक्रिय Gateway सत्यापित करें
openclaw plugins list और सामान्य openclaw plugins inspect कोल्ड कॉन्फ़िगरेशन,
मैनिफ़ेस्ट और रजिस्ट्री स्थिति पढ़ते हैं। वे यह साबित नहीं करते कि पहले से चल रहे
Gateway ने उसी Plugin कोड को आयात किया है।
जब कोई Plugin इंस्टॉल किया हुआ दिखाई दे, लेकिन लाइव चैट ट्रैफ़िक उसका उपयोग न करे:
openclaw gateway run चाइल्ड को लक्षित करे।
समस्या निवारण
जब कोई सक्षम प्रबंधित Plugin, Gateway के स्टार्टअप के दौरान पेलोड सत्यापन में
विफल होता है, तो OpenClaw उस बूट के लिए ठीक उसी इंस्टॉल किए गए Plugin रूट को
क्वारंटीन करता है और अन्य Plugin को सेवा देना जारी रखता है।
openclaw status --all,
openclaw health और openclaw doctor इसे configured-unavailable के रूप में
रिपोर्ट करते हैं। Plugin को ठीक करें या फिर से इंस्टॉल करें, फिर Gateway को पुनः
आरंभ करें। समान Plugin आईडी वाला एक स्वस्थ स्पष्ट plugins.load.paths
ओवरराइड किसी पुराने खराब इंस्टॉल के कारण क्वारंटीन नहीं किया जाता।
जब पुराना Plugin कॉन्फ़िगरेशन अब खोजे न जा सकने वाले चैनल Plugin का नाम अभी
भी रखता है, तो कॉन्फ़िगरेशन सत्यापन उस चैनल कुंजी को गंभीर विफलता के बजाय
चेतावनी में बदल देता है, जिससे Gateway का स्टार्टअप अन्य सभी चैनलों को सेवा
देना जारी रख सकता है। पुराने Plugin और चैनल प्रविष्टियाँ हटाने के लिए
openclaw doctor --fix चलाएँ। पुराने Plugin के प्रमाण के बिना अज्ञात चैनल कुंजियाँ
अब भी सत्यापन में विफल होती हैं, ताकि टाइपो दिखाई देते रहें।
जानबूझकर चैनल प्रतिस्थापन के लिए, पसंदीदा Plugin को पुराने या कम-प्राथमिकता वाले
Plugin आईडी के साथ channelConfigs.<channel-id>.preferOver घोषित करना चाहिए। यदि दोनों Plugin
स्पष्ट रूप से सक्षम हैं, तो OpenClaw उस अनुरोध को बनाए रखता है और चुपचाप एक
स्वामी चुनने के बजाय डुप्लिकेट चैनल/टूल निदान रिपोर्ट करता है।
यदि कोई इंस्टॉल किया गया पैकेज रिपोर्ट करता है कि वह requires compiled runtime output for TypeScript entry ..., तो
पैकेज को उन JavaScript फ़ाइलों के बिना प्रकाशित किया गया था जिनकी OpenClaw को
रनटाइम पर आवश्यकता होती है। प्रकाशक द्वारा कंपाइल किया हुआ JavaScript जारी
करने के बाद अपडेट करें या फिर से इंस्टॉल करें, अथवा तब तक Plugin को
अक्षम/अनइंस्टॉल करें।
अवरुद्ध Plugin पथ स्वामित्व
यदि निदान मेंblocked plugin candidate: suspicious ownership (... uid=1000, expected uid=0 or root)
दिखाई देता है और उसके बाद सत्यापन में plugin present but blocked आता है, तो OpenClaw
को ऐसी Plugin फ़ाइलें मिली हैं जिनका स्वामी उन्हें लोड करने वाली प्रक्रिया से
अलग Unix उपयोगकर्ता है। Plugin कॉन्फ़िगरेशन को यथावत रखें; फ़ाइल सिस्टम का
स्वामित्व ठीक करें या OpenClaw को उसी उपयोगकर्ता के रूप में चलाएँ जिसके पास
स्थिति निर्देशिका का स्वामित्व है।
Docker इंस्टॉलेशन के लिए, आधिकारिक इमेज node (uid 1000)
के रूप में चलती है, इसलिए होस्ट पर बाइंड-माउंट की गई OpenClaw कॉन्फ़िगरेशन और
वर्कस्पेस निर्देशिकाएँ सामान्यतः uid 1000 के स्वामित्व में होनी
चाहिए:
openclaw doctor --fix या
openclaw plugins registry --refresh फिर से चलाएँ, ताकि स्थायी Plugin रजिस्ट्री
ठीक की गई फ़ाइलों से मेल खाए।
धीमा Plugin टूल सेटअप
यदि टूल तैयार करते समय एजेंट टर्न रुके हुए दिखाई दें, तो ट्रेस लॉगिंग सक्षम करें और Plugin टूल फ़ैक्टरी की टाइमिंग पंक्तियाँ जाँचें:संबंधित
- Plugin प्रबंधित करें - सूची बनाने, इंस्टॉल करने, अपडेट करने, अनइंस्टॉल करने और प्रकाशित करने के कमांड उदाहरण
openclaw plugins- संपूर्ण CLI संदर्भ- Plugin इन्वेंट्री - जनरेट की गई बंडल और बाहरी Plugin सूची
- Plugin संदर्भ - प्रत्येक Plugin के लिए जनरेट किए गए संदर्भ पृष्ठ
- सामुदायिक Plugin - ClawHub खोज और दस्तावेज़ PR नीति
- Plugin निर्भरता रिज़ॉल्यूशन - इंस्टॉल रूट, रजिस्ट्री रिकॉर्ड और रनटाइम सीमाएँ
- Plugin बनाना - नेटिव Plugin लेखन मार्गदर्शिका
- Plugin SDK अवलोकन - रनटाइम पंजीकरण, हुक और API फ़ील्ड
- Plugin मैनिफ़ेस्ट - मैनिफ़ेस्ट और पैकेज मेटाडेटा