CLI commands

अपडेट

openclaw update

OpenClaw को अपडेट करें और stable/extended-stable/beta/dev चैनलों के बीच स्विच करें।

यदि आपने npm/pnpm/bun के माध्यम से इंस्टॉल किया है (वैश्विक इंस्टॉल, कोई git मेटाडेटा नहीं), तो अपडेट अपडेट करना में वर्णित पैकेज-मैनेजर प्रवाह से होते हैं।

उपयोग

bash
openclaw updateopenclaw update statusopenclaw update repairopenclaw update wizardopenclaw update --channel extended-stableopenclaw update --channel betaopenclaw update --channel devopenclaw update --tag betaopenclaw update --tag mainopenclaw update --dry-runopenclaw update --no-restartopenclaw update --yesopenclaw update --acknowledge-clawhub-riskopenclaw update --jsonopenclaw --update

openclaw --update को openclaw update के रूप में फिर से लिखा जाता है (शेल और लॉन्चर स्क्रिप्ट के लिए उपयोगी)।

विकल्प

फ़्लैग विवरण
--no-restart सफल अपडेट के बाद Gateway सेवा को फिर से शुरू करना छोड़ें। पुनः आरंभ करने वाले पैकेज-मैनेजर अपडेट, कमांड के सफल होने से पहले सत्यापित करते हैं कि पुनः आरंभ की गई सेवा अपेक्षित संस्करण रिपोर्ट करती है।
--channel <stable|extended-stable|beta|dev> अपडेट चैनल निर्धारित करें और कोर अपडेट सफल होने के बाद इसे बनाए रखें। Extended-stable केवल पैकेज के लिए है।
--tag <dist-tag|version|spec> केवल इस अपडेट के लिए पैकेज लक्ष्य को ओवरराइड करें। इसे प्रभावी extended-stable चैनल के साथ संयोजित नहीं किया जा सकता, जिसका सत्यापित सटीक लक्ष्य अनिवार्य है। अन्य पैकेज इंस्टॉल के लिए, main को github:openclaw/openclaw#main पर मैप किया जाता है; चरणबद्ध वैश्विक npm इंस्टॉल से पहले GitHub/git स्रोत विनिर्देशों को एक अस्थायी tarball में पैक किया जाता है।
--dry-run कॉन्फ़िगरेशन लिखे, इंस्टॉल किए, Plugin सिंक किए या पुनः आरंभ किए बिना नियोजित कार्रवाइयों (चैनल/टैग/लक्ष्य/पुनः आरंभ प्रवाह) का पूर्वावलोकन करें।
--json मशीन-पठनीय UpdateRunResult JSON प्रिंट करें। जब किसी प्रबंधित Plugin को सुधार की आवश्यकता हो तब postUpdate.plugins.warnings, बीटा-चैनल Plugin फ़ॉलबैक विवरण, और अपडेट के बाद सिंक के दौरान npm Plugin आर्टिफ़ैक्ट विचलन मिलने पर postUpdate.plugins.integrityDrifts शामिल होते हैं।
--timeout <seconds> प्रत्येक चरण की समय-सीमा। डिफ़ॉल्ट 1800
--yes पुष्टिकरण संकेतों को छोड़ें (उदाहरण के लिए डाउनग्रेड पुष्टिकरण)।
--acknowledge-clawhub-risk इंटरैक्टिव संकेत के बिना, अपडेट के बाद Plugin सिंक को सामुदायिक ClawHub विश्वास चेतावनियों से आगे जारी रहने दें। इसके बिना, जब OpenClaw संकेत नहीं दे सकता, तो जोखिमपूर्ण सामुदायिक रिलीज़ छोड़ दी जाती हैं और अपरिवर्तित रहती हैं। आधिकारिक ClawHub पैकेज और बंडल किए गए Plugin स्रोत इस संकेत को बायपास करते हैं।

कोई --verbose फ़्लैग नहीं है। नियोजित कार्रवाइयों का पूर्वावलोकन करने के लिए --dry-run, मशीन-पठनीय परिणामों के लिए --json, और केवल चैनल/उपलब्धता के लिए openclaw update status --json का उपयोग करें। Gateway कंसोल वर्बोसिटी (--verbose) और फ़ाइल लॉग स्तर (logging.level: "debug"/"trace") स्वतंत्र नियंत्रण हैं; देखें Gateway लॉगिंग

update status

सक्रिय अपडेट चैनल, git टैग/ब्रांच/SHA (केवल स्रोत चेकआउट), और अपडेट की उपलब्धता दिखाएँ।

bash
openclaw update statusopenclaw update status --jsonopenclaw update status --timeout 10
फ़्लैग डिफ़ॉल्ट विवरण
--json false मशीन-पठनीय स्थिति JSON प्रिंट करें।
--timeout <seconds> 3 जाँचों की समय-सीमा।

Extended-stable पैकेज इंस्टॉल के लिए, स्थिति अग्रभूमि अपडेट के समान सार्वजनिक चयनकर्ता और सटीक-पैकेज सत्यापन करती है। यदि इंस्टॉल किया गया संस्करण नया है, तो यह ahead of extended-stable रिपोर्ट कर सकती है। JSON विफलताओं में registry.reason (selector_missing, selector_query_failed, exact_package_mismatch, या unsupported_git_channel) शामिल होते हैं।

update repair

कोर पैकेज पहले ही बदल जाने, लेकिन बाद का सुधार कार्य ठीक से पूरा न होने पर अपडेट अंतिमकरण फिर से चलाएँ। यह उस स्थिति के लिए समर्थित पुनर्प्राप्ति पथ है, जब openclaw update ने नया कोर पैकेज इंस्टॉल कर दिया हो, लेकिन कोर के बाद का Plugin सिंक, प्रबंधित npm Plugin मेटाडेटा, रजिस्ट्री रीफ़्रेश या Doctor सुधार अभिसरित न हुआ हो।

bash
openclaw update repairopenclaw update repair --channel betaopenclaw update repair --acknowledge-clawhub-riskopenclaw update repair --json
फ़्लैग विवरण
--channel <stable|extended-stable|beta|dev> सुधार से पहले कोर अपडेट चैनल बनाए रखें। Extended-stable के लिए, bare/default या latest अभिप्राय का अनुसरण करने वाले योग्य आधिकारिक npm Plugin, इंस्टॉल किए गए सटीक कोर संस्करण को लक्षित करते हैं। कॉन्फ़िगरेशन बदले बिना Git चेकआउट पर Extended-stable सुधार अस्वीकार कर दिया जाता है।
--json मशीन-पठनीय अंतिमकरण JSON प्रिंट करें।
--timeout <seconds> सुधार चरणों की समय-सीमा। डिफ़ॉल्ट 1800
--yes पुष्टिकरण संकेत छोड़ें।
--acknowledge-clawhub-risk openclaw update जैसा ही व्यवहार।
--no-restart समानता के लिए स्वीकार किया जाता है; सुधार कभी भी Gateway को पुनः आरंभ नहीं करता।

update repair, openclaw doctor --fix चलाता है, सुधारे गए कॉन्फ़िगरेशन और इंस्टॉल रिकॉर्ड पुनः लोड करता है, सक्रिय अपडेट चैनल के लिए ट्रैक किए गए Plugin सिंक करता है, प्रबंधित npm Plugin इंस्टॉल अपडेट करता है, अनुपलब्ध कॉन्फ़िगर किए गए Plugin पेलोड सुधारता है, Plugin रजिस्ट्री रीफ़्रेश करता है और अभिसरित इंस्टॉल-रिकॉर्ड मेटाडेटा लिखता है। यह नया कोर पैकेज इंस्टॉल नहीं करता और Gateway को पुनः आरंभ नहीं करता।

update wizard

अपडेट चैनल चुनने और बाद में Gateway को पुनः आरंभ करना है या नहीं इसकी पुष्टि करने के लिए इंटरैक्टिव प्रवाह (डिफ़ॉल्ट रूप से पुनः आरंभ)। git चेकआउट के बिना dev चुनने पर एक चेकआउट बनाने का प्रस्ताव मिलता है।

फ़्लैग डिफ़ॉल्ट विवरण
--timeout <seconds> 1800 प्रत्येक अपडेट चरण की समय-सीमा।

यह क्या करता है

चैनलों को स्पष्ट रूप से स्विच करना (--channel ...) इंस्टॉल विधि को भी संरेखित रखता है:

  • dev -> git चेकआउट सुनिश्चित करता है (डिफ़ॉल्ट ~/openclaw, या जब OPENCLAW_HOME सेट हो तब $OPENCLAW_HOME/openclaw; इसे OPENCLAW_GIT_DIR से ओवरराइड करें), इसे अपडेट करता है, और उस चेकआउट से वैश्विक CLI इंस्टॉल करता है।
  • stable -> latest का उपयोग करके npm से इंस्टॉल करता है।
  • extended-stable -> सार्वजनिक npm extended-stable चयनकर्ता का समाधान करता है, चुने गए सटीक पैकेज को सत्यापित करता है और उसी सटीक संस्करण को इंस्टॉल करता है। यह किसी अन्य चयनकर्ता पर फ़ॉलबैक नहीं करता और Git चेकआउट के लिए अस्वीकार कर दिया जाता है।
  • beta -> npm dist-tag beta को प्राथमिकता देता है, और बीटा अनुपलब्ध होने या वर्तमान स्थिर रिलीज़ से पुराना होने पर latest पर फ़ॉलबैक करता है।

पुनः आरंभ हस्तांतरण

Gateway कोर ऑटो-अपडेटर (कॉन्फ़िगरेशन के माध्यम से सक्षम होने पर) लाइव Gateway अनुरोध हैंडलर के बाहर CLI अपडेट पथ लॉन्च करता है। कंट्रोल-प्लेन update.run पैकेज-मैनेजर अपडेट और पर्यवेक्षित git-चेकआउट अपडेट, लाइव Gateway प्रक्रिया के अंदर पैकेज ट्री बदलने या dist/ को पुनः बनाने के बजाय समान प्रबंधित-सेवा हस्तांतरण का उपयोग करते हैं: Gateway एक अलग किया गया सहायक शुरू करके बाहर निकल जाता है, और वह सहायक Gateway प्रक्रिया ट्री के बाहर से openclaw update --yes --json चलाता है। यदि हस्तांतरण उपलब्ध नहीं है, तो update.run मैन्युअल रूप से चलाने के लिए सुरक्षित शेल कमांड सहित एक संरचित प्रतिक्रिया लौटाता है।

संग्रहीत extended-stable चयनों को update.checkOnStart सक्षम होने पर केवल-पढ़ने योग्य स्टार्टअप और 24-घंटे के अपडेट संकेत मिलते हैं। ये जाँचें कभी कोई अपडेट लागू नहीं करतीं, हैंडऑफ़ शुरू नहीं करतीं, Gateway को पुनः आरंभ नहीं करतीं, stable विलंब/jitter का उपयोग नहीं करतीं, या beta पोलिंग आवृत्ति का उपयोग नहीं करतीं। स्पष्ट फ़ोरग्राउंड अपडेट, संग्रहीत update.channel: "extended-stable" वाले बिना विकल्प के फ़ोरग्राउंड अपडेट, माँग पर स्थिति, और उनका प्रबंधित Gateway हैंडऑफ़ समर्थित रहते हैं।

जब कोई स्थानीय प्रबंधित Gateway सेवा इंस्टॉल हो और पुनः आरंभ सक्षम हो, तो पैकेज-मैनेजर और git-checkout अपडेट पैकेज ट्री को बदलने या checkout/build आउटपुट में परिवर्तन करने से पहले चल रही सेवा को रोक देते हैं। इसके बाद अपडेटर सेवा मेटाडेटा रीफ़्रेश करता है, सेवा को पुनः आरंभ करता है, और Gateway: restarted and verified. रिपोर्ट करने से पहले पुनः आरंभ किए गए Gateway को सत्यापित करता है। पैकेज-मैनेजर अपडेट इसके अतिरिक्त सत्यापित करते हैं कि पुनः आरंभ किया गया Gateway अपेक्षित पैकेज संस्करण रिपोर्ट करता है; git-checkout अपडेट पुनर्निर्माण के बाद Gateway की स्थिति और सेवा की तैयारी सत्यापित करते हैं।

पैकेज-मैनेजर अपडेट सामान्यतः प्रबंधित सेवा में दर्ज Node बाइनरी का उपयोग जारी रखते हैं। यदि वह Node लक्ष्य रिलीज़ नहीं चला सकता, लेकिन वर्तमान CLI Node चला सकता है और यह प्रमाणित हो कि सेवा अपडेट किए जा रहे पैकेज से संबंधित है, तो पुनः आरंभ-सक्षम अपडेट अंतिमकरण के लिए वर्तमान Node का उपयोग करता है और सेवा मेटाडेटा को उस runtime के लिए दोबारा लिखता है। --no-restart सेवा मेटाडेटा की मरम्मत नहीं कर सकता, इसलिए वही runtime असंगति पैकेज में परिवर्तन से पहले प्रक्रिया रोक देती है।

macOS पर, अपडेट-पश्चात जाँच यह भी सत्यापित करती है कि सक्रिय प्रोफ़ाइल के लिए LaunchAgent लोड/चल रहा है और कॉन्फ़िगर किया गया loopback पोर्ट स्वस्थ है। यदि plist इंस्टॉल है लेकिन launchd उसकी निगरानी नहीं कर रहा है, तो OpenClaw LaunchAgent को स्वचालित रूप से फिर से bootstrap करता है और स्वास्थ्य/संस्करण/ चैनल तत्परता जाँचें दोबारा चलाता है (एक नया bootstrap RunAtLoad जॉब को सीधे लोड करता है, इसलिए पुनर्प्राप्ति नए शुरू किए गए Gateway को तुरंत kickstart -k नहीं करती)। यदि Gateway फिर भी स्वस्थ नहीं होता, तो कमांड गैर-शून्य स्थिति के साथ समाप्त होता है और पुनः आरंभ लॉग पथ के साथ पुनः आरंभ, पुनः इंस्टॉल और पैकेज rollback निर्देश प्रिंट करता है।

यदि पुनः आरंभ नहीं चल सकता, तो कमांड मैन्युअल openclaw gateway restart संकेत के साथ Gateway: restart skipped (...) या Gateway: restart failed: ... प्रिंट करता है। --no-restart के साथ पैकेज प्रतिस्थापन या git पुनर्निर्माण फिर भी चलता है, लेकिन प्रबंधित सेवा को रोका या पुनः आरंभ नहीं किया जाता, इसलिए चलता हुआ Gateway तब तक पुराने कोड का उपयोग करता रहता है जब तक आप उसे मैन्युअल रूप से पुनः आरंभ नहीं करते।

कंट्रोल-प्लेन प्रतिक्रिया का स्वरूप

जब update.run किसी पैकेज-मैनेजर इंस्टॉल या पर्यवेक्षित git checkout पर Gateway कंट्रोल प्लेन के माध्यम से चलता है, तो हैंडलर हैंडऑफ़ आरंभ को उस CLI अपडेट से अलग रिपोर्ट करता है जो Gateway के बंद होने के बाद जारी रहता है:

  • ok: true, result.status: "skipped", result.reason: "managed-service-handoff-started", और handoff.status: "started": Gateway ने प्रबंधित-सेवा हैंडऑफ़ बनाया और अपना पुनः आरंभ निर्धारित किया, ताकि अलग किया गया सहायक लाइव सेवा प्रक्रिया के बाहर openclaw update --yes --json चला सके।
  • ok: false, result.reason: "managed-service-handoff-unavailable", और handoff.status: "unavailable": OpenClaw सुरक्षित हैंडऑफ़ के लिए पर्यवेक्षण करने वाली सेवा सीमा और स्थायी सेवा पहचान नहीं खोज सका (उदाहरण के लिए, systemd हैंडऑफ़ को OPENCLAW_SYSTEMD_UNIT यूनिट पहचान की आवश्यकता होती है, केवल परिवेशी systemd प्रक्रिया मार्करों की नहीं)। प्रतिक्रिया में handoff.command, Gateway के बाहर से चलाने वाला shell कमांड शामिल होता है।
  • ok: false, result.reason: "managed-service-handoff-failed": Gateway ने हैंडऑफ़ बनाने का प्रयास किया, लेकिन अलग किए गए सहायक को शुरू नहीं कर सका।

sentinel पेलोड Gateway के बंद होने से पहले लिखा जाता है, और CLI हैंडऑफ़ प्रबंधित-सेवा पुनः आरंभ की स्वास्थ्य जाँचें पूरी होने के बाद उसी restart sentinel को अपडेट करता है। हैंडऑफ़ के दौरान sentinel में stats.reason: "restart-health-pending" हो सकता है और कोई सफलता निरंतरता नहीं होती; पुनः आरंभ किया गया Gateway इसे पोल करता है और निरंतरता तभी सक्रिय करता है जब CLI सेवा स्वास्थ्य सत्यापित करके sentinel को अंतिम ok परिणाम के साथ दोबारा लिख चुका हो। जब वह sentinel लंबित या विफल हो, तब openclaw status और openclaw status --all एक Update restart पंक्ति दिखाते हैं, और update.status रीफ़्रेश करके नवीनतम sentinel लौटाता है।

Git checkout प्रवाह

चैनल चयन

  • stable: नवीनतम गैर-beta टैग checkout करें, फिर build और doctor चलाएँ।
  • beta: नवीनतम -beta टैग को प्राथमिकता दें, और beta अनुपलब्ध या पुराना होने पर नवीनतम stable टैग पर वापस जाएँ।
  • dev: main checkout करें, फिर fetch और rebase करें।
  • extended-stable: Git checkouts के लिए असमर्थित; checkout में कोई परिवर्तन नहीं होता।

अपडेट चरण

  • स्वच्छ worktree सत्यापित करें

    कोई भी uncommitted परिवर्तन नहीं होना चाहिए।

  • चैनल बदलें

    चयनित चैनल (टैग या शाखा) पर स्विच करता है।

  • upstream प्राप्त करें

    केवल dev।

  • प्रीफ़्लाइट build (केवल dev)

    अस्थायी worktree में TypeScript build चलाता है। यदि tip विफल हो, तो नवीनतम build योग्य commit खोजने के लिए अधिकतम 10 commits पीछे जाता है। इस प्रीफ़्लाइट के दौरान lint भी चलाने के लिए OPENCLAW_UPDATE_PREFLIGHT_LINT=1 सेट करें; lint सीमित serial मोड में चलता है क्योंकि उपयोगकर्ता अपडेट होस्ट प्रायः CI runners से छोटे होते हैं।

  • Rebase

    चयनित commit पर rebase करता है (केवल dev)।

  • निर्भरताएँ इंस्टॉल करें

    रेपो पैकेज मैनेजर का उपयोग करता है। pnpm checkouts के लिए, अपडेटर pnpm workspace के भीतर npm run build चलाने के बजाय आवश्यकतानुसार pnpm को bootstrap करता है (पहले corepack के माध्यम से, फिर अस्थायी npm install pnpm@11 fallback द्वारा)। यदि pnpm bootstrap फिर भी विफल होता है, तो अपडेटर checkout में npm run build आज़माने के बजाय पैकेज-मैनेजर-विशिष्ट त्रुटि के साथ जल्दी रुक जाता है।

  • कंट्रोल UI build करें

    Gateway और कंट्रोल UI को build करता है।

  • doctor चलाएँ

    openclaw doctor अंतिम सुरक्षित-अपडेट जाँच के रूप में चलता है।

  • plugins सिंक करें

    plugins को सक्रिय चैनल के साथ सिंक करता है। Dev में bundled plugins उपयोग होते हैं; stable और beta में npm। ट्रैक किए गए plugin इंस्टॉल अपडेट करता है।

  • Plugin सिंक विवरण

    beta चैनल पर, डिफ़ॉल्ट/latest लाइन का अनुसरण करने वाले ट्रैक किए गए npm और ClawHub plugin इंस्टॉल पहले plugin @beta रिलीज़ आज़माते हैं। यदि plugin का कोई beta रिलीज़ नहीं है, तो OpenClaw दर्ज डिफ़ॉल्ट/latest spec पर वापस जाता है और चेतावनी रिपोर्ट करता है। npm plugins के लिए, beta पैकेज मौजूद होने पर भी यदि वह इंस्टॉल सत्यापन में विफल हो, तो OpenClaw fallback करता है। ये fallback चेतावनियाँ मुख्य अपडेट को विफल नहीं करतीं। सटीक संस्करण और स्पष्ट टैग कभी दोबारा नहीं लिखे जाते।

    extended-stable मुख्य अपडेट सफल होने के बाद, मुख्य भाग के बाद plugin integrity और अभिसरण पात्र आधिकारिक npm plugins को सटीक इंस्टॉल किए गए मुख्य संस्करण पर लक्षित करते हैं। डिफ़ॉल्ट/latest intent के लिए, OpenClaw plugin @extended-stable से क्वेरी नहीं करता या npm latest पर fallback नहीं करता; यह पैकेज संस्करण इंस्टॉल किए गए मुख्य भाग से प्राप्त करता है। स्पष्ट संस्करण pins, स्पष्ट गैर-latest टैग, तृतीय-पक्ष पैकेज और गैर-npm स्रोत अपना मौजूदा intent बनाए रखते हैं।

    पैकेज-मैनेजर इंस्टॉल के लिए, openclaw update पैकेज मैनेजर चलाने से पहले लक्ष्य पैकेज संस्करण निर्धारित करता है। npm global इंस्टॉल staged इंस्टॉल का उपयोग करते हैं: OpenClaw नया पैकेज अस्थायी npm prefix में इंस्टॉल करता है, preinstall के दौरान candidate पैकेज को होस्ट Node संस्करण सत्यापित करने देता है, और वहाँ पैकेज किए गए dist inventory को सत्यापित करता है। एक पैक किया गया completion guard preinstall सफल होने तक उस inventory के बाहर रहता है, इसलिए lifecycle scripts छोड़ने वाले पैकेज मैनेजर भी सक्रियण से पहले रुक जाते हैं। npm 12 और उससे नए संस्करणों पर, अपडेटर केवल candidate OpenClaw lifecycle को स्वीकृति देता है; transitive dependency scripts अवरुद्ध रहते हैं। इसके बाद OpenClaw स्वच्छ पैकेज ट्री को वास्तविक global prefix में बदल देता है। यदि सत्यापन विफल होता है, तो अपडेट-पश्चात doctor, plugin सिंक और पुनः आरंभ कार्य संदिग्ध ट्री से नहीं चलते। इंस्टॉल किया गया संस्करण पहले से लक्ष्य से मेल खाने पर भी, कमांड global पैकेज इंस्टॉल को रीफ़्रेश करता है, फिर plugin सिंक, मुख्य-कमांड completion रीफ़्रेश और पुनः आरंभ कार्य चलाता है। इससे पैकेज किए गए sidecars और चैनल-स्वामित्व वाले plugin रिकॉर्ड इंस्टॉल किए गए OpenClaw build के साथ संरेखित रहते हैं, जबकि पूर्ण plugin-कमांड completion पुनर्निर्माण स्पष्ट openclaw completion --write-state रन के लिए छोड़े जाते हैं।

    संबंधित

    Was this useful?
    On this page

    On this page