Plugins

Plugins, OpenClaw में चैनल, मॉडल प्रदाता, एजेंट हार्नेस, टूल, स्किल, स्पीच, रियलटाइम ट्रांसक्रिप्शन, वॉइस, मीडिया की समझ, जनरेशन, वेब फ़ेच, वेब सर्च और अन्य रनटाइम क्षमताएँ जोड़कर उसका विस्तार करते हैं।

Plugin इंस्टॉल करने, Gateway पुनः आरंभ करने, रनटाइम द्वारा उसे लोड किए जाने की पुष्टि करने और सामान्य सेटअप विफलताओं का समाधान खोजने के लिए इस पृष्ठ का उपयोग करें। केवल कमांड वाले उदाहरणों के लिए Plugins प्रबंधित करें देखें। बंडल किए गए, आधिकारिक बाहरी और केवल-स्रोत Plugins की जनरेट की गई सूची के लिए Plugin सूची देखें।

आवश्यकताएँ

• एक OpenClaw चेकआउट या इंस्टॉलेशन, जिसमें openclaw CLI उपलब्ध हो
• चुने गए स्रोत (ClawHub, npm या किसी git होस्ट) तक नेटवर्क पहुँच
• उस Plugin के सेटअप दस्तावेज़ों में बताए गए सभी Plugin-विशिष्ट क्रेडेंशियल, कॉन्फ़िगरेशन कुंजियाँ या OS टूल
• आपके चैनलों को सेवा देने वाले Gateway को पुनः लोड या पुनः आरंभ करने की अनुमति

त्वरित शुरुआत

openclaw plugins search "calendar"

# ClawHub से।openclaw plugins install clawhub:<package> # npm से।openclaw plugins install npm:<package> # git से।openclaw plugins install git:github.com/<owner>/<repo>@<ref> # किसी स्थानीय डेवलपमेंट चेकआउट से।openclaw plugins install ./my-pluginopenclaw plugins install --link ./my-plugin

openclaw plugins enable <plugin-id>

openclaw gateway restart

openclaw plugins inspect <plugin-id> --runtime --json

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

इंस्टॉलेशन स्रोत चुनें

बिना-उपसर्ग वाले पैकेज स्पेक का विशेष संगतता व्यवहार होता है: बंडल किए गए 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: true,    allow: ["voice-call"],    deny: ["untrusted-plugin"],    load: { paths: ["~/Projects/oss/voice-call-plugin"] },    slots: { memory: "memory-core" },    entries: {      "voice-call": { enabled: true, config: { provider: "twilio" } },    },  },}

मुख्य नीति नियम:

• 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 मॉडल संदर्भ पुराने कॉन्फ़िगरेशन हैं जिन्हें डॉक्टर सुधारता है, जबकि बंडल किया गया codex Plugin मानक 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 status --deep --require-rpcopenclaw plugins inspect <plugin-id> --runtime --jsonopenclaw gateway restart

Plugin के इंस्टॉल, अपडेट और अनइंस्टॉल से Plugin स्रोत में बदलाव होने पर प्रबंधित Gateway अपने-आप पुनः आरंभ होते हैं। VPS या कंटेनर इंस्टॉलेशन में सुनिश्चित करें कि कोई भी मैन्युअल पुनः आरंभ केवल रैपर या सुपरवाइज़र को नहीं, बल्कि आपके चैनलों को सेवा देने वाले वास्तविक 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 के स्वामित्व में होनी चाहिए:

sudo chown -R 1000:1000 /path/to/openclaw-config /path/to/openclaw-workspace

यदि आप जानबूझकर OpenClaw को रूट के रूप में चलाते हैं, तो इसके बजाय प्रबंधित Plugin रूट का स्वामित्व रूट पर ठीक करें:

sudo chown -R root:root /path/to/openclaw-config/npm

स्वामित्व ठीक करने के बाद openclaw doctor --fix या openclaw plugins registry --refresh फिर से चलाएँ, ताकि स्थायी Plugin रजिस्ट्री ठीक की गई फ़ाइलों से मेल खाए।

धीमा Plugin टूल सेटअप

यदि टूल तैयार करते समय एजेंट टर्न रुके हुए दिखाई दें, तो ट्रेस लॉगिंग सक्षम करें और Plugin टूल फ़ैक्टरी की टाइमिंग पंक्तियाँ जाँचें:

openclaw config set logging.level traceopenclaw logs --follow

इसे खोजें:

[trace:plugin-tools] फ़ैक्टरी टाइमिंग ...

सारांश में कुल फ़ैक्टरी समय और सबसे धीमी Plugin टूल फ़ैक्टरियाँ सूचीबद्ध होती हैं, जिनमें Plugin आईडी, घोषित टूल नाम, परिणाम का आकार और यह जानकारी शामिल होती है कि टूल वैकल्पिक है या नहीं। जब किसी एक फ़ैक्टरी को कम-से-कम 1s लगता है या Plugin टूल फ़ैक्टरी की कुल तैयारी में कम-से-कम 5s लगते हैं, तो धीमी पंक्तियों को चेतावनियों के रूप में दिखाया जाता है।

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

यदि कोई एक Plugin टाइमिंग में सबसे अधिक समय लेता है, तो उसके रनटाइम पंजीकरणों की जाँच करें:

openclaw plugins inspect <plugin-id> --runtime --json

फिर उस Plugin को अपडेट करें, फिर से इंस्टॉल करें या अक्षम करें। Plugin लेखकों को महँगी निर्भरता लोडिंग टूल फ़ैक्टरी के भीतर करने के बजाय टूल निष्पादन पथ के पीछे ले जानी चाहिए।

निर्भरता रूट, पैकेज मेटाडेटा सत्यापन, रजिस्ट्री रिकॉर्ड, स्टार्टअप रीलोड व्यवहार और पुराने डेटा की सफ़ाई के लिए Plugin निर्भरता रिज़ॉल्यूशन देखें।

संबंधित

• Plugin प्रबंधित करें - सूची बनाने, इंस्टॉल करने, अपडेट करने, अनइंस्टॉल करने और प्रकाशित करने के कमांड उदाहरण
• openclaw plugins - संपूर्ण CLI संदर्भ
• Plugin इन्वेंट्री - जनरेट की गई बंडल और बाहरी Plugin सूची
• Plugin संदर्भ - प्रत्येक Plugin के लिए जनरेट किए गए संदर्भ पृष्ठ
• सामुदायिक Plugin - ClawHub खोज और दस्तावेज़ PR नीति
• Plugin निर्भरता रिज़ॉल्यूशन - इंस्टॉल रूट, रजिस्ट्री रिकॉर्ड और रनटाइम सीमाएँ
• Plugin बनाना - नेटिव Plugin लेखन मार्गदर्शिका
• Plugin SDK अवलोकन - रनटाइम पंजीकरण, हुक और API फ़ील्ड
• Plugin मैनिफ़ेस्ट - मैनिफ़ेस्ट और पैकेज मेटाडेटा