Skip to main content

​
openclaw update

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

​
उपयोग

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

​
विकल्प

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

​
update status

सक्रिय अपडेट चैनल, git टैग/ब्रांच/SHA (केवल स्रोत चेकआउट), और अपडेट की उपलब्धता दिखाएँ।
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 सुधार अभिसरित न हुआ हो।
update repair, openclaw doctor --fix चलाता है, सुधारे गए कॉन्फ़िगरेशन और इंस्टॉल रिकॉर्ड पुनः लोड करता है, सक्रिय अपडेट चैनल के लिए ट्रैक किए गए Plugin सिंक करता है, प्रबंधित npm Plugin इंस्टॉल अपडेट करता है, अनुपलब्ध कॉन्फ़िगर किए गए Plugin पेलोड सुधारता है, Plugin रजिस्ट्री रीफ़्रेश करता है और अभिसरित इंस्टॉल-रिकॉर्ड मेटाडेटा लिखता है। यह नया कोर पैकेज इंस्टॉल नहीं करता और Gateway को पुनः आरंभ नहीं करता।

​
update wizard

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

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

चैनलों को स्पष्ट रूप से स्विच करना (--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 में कोई परिवर्तन नहीं होता।

​
अपडेट चरण

1

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

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

चैनल बदलें

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

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

केवल dev।
4

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

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

Rebase

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

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

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

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

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

doctor चलाएँ

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

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 चेतावनियाँ मुख्य अपडेट को विफल नहीं करतीं। सटीक संस्करण और स्पष्ट टैग कभी दोबारा नहीं लिखे जाते।
यदि किसी सटीक रूप से पिन किए गए npm plugin अपडेट का समाधान ऐसे artifact पर होता है जिसकी integrity संग्रहीत इंस्टॉल रिकॉर्ड से अलग है, तो openclaw update उस plugin artifact अपडेट को इंस्टॉल करने के बजाय निरस्त कर देता है। नए artifact पर भरोसा होने की पुष्टि करने के बाद ही plugin को स्पष्ट रूप से पुनः इंस्टॉल या अपडेट करें।
अपडेट-पश्चात plugin सिंक विफलताएँ, जो किसी प्रबंधित plugin तक सीमित हों और जिनसे सिंक पथ बचकर आगे बढ़ सकता हो (उदाहरण के लिए किसी गैर-आवश्यक plugin के लिए पहुँच से बाहर npm registry), मुख्य अपडेट सफल होने के बाद चेतावनियों के रूप में रिपोर्ट की जाती हैं। JSON परिणाम शीर्ष-स्तरीय अपडेट status: "ok" बनाए रखता है और openclaw update repair तथा openclaw plugins inspect <id> --runtime --json मार्गदर्शन के साथ postUpdate.plugins.status: "warning" रिपोर्ट करता है। अप्रत्याशित updater या sync अपवाद फिर भी अपडेट परिणाम को विफल करते हैं। plugin इंस्टॉल या अपडेट त्रुटि ठीक करें, फिर openclaw update repair दोबारा चलाएँ। जब कोई विफल अपडेट किसी प्रबंधित plugin को अनुपयोगी छोड़ देता है, तो OpenClaw उसके runtime प्रविष्टि को अक्षम करता है और ऑपरेटर द्वारा लिखी गई plugins.allow या plugins.deny नीति बदले बिना सक्रिय slots रीसेट करता है।प्रति-plugin सिंक चरण के बाद, Gateway के पुनः आरंभ होने से पहले openclaw update एक अनिवार्य मुख्य भाग के बाद अभिसरण पास चलाता है: यह अनुपलब्ध कॉन्फ़िगर किए गए plugin पेलोड की मरम्मत करता है, डिस्क पर प्रत्येक सक्रिय ट्रैक किए गए इंस्टॉल रिकॉर्ड को सत्यापित करता है, और स्थिर रूप से सत्यापित करता है कि उसका package.json पार्स किया जा सकता है (और स्पष्ट रूप से घोषित कोई भी main मौजूद है)। इस पास की विफलताएँ और अमान्य config snapshot postUpdate.plugins.status: "error" लौटाते हैं और शीर्ष-स्तरीय अपडेट status को "error" में बदल देते हैं, इसलिए openclaw update गैर-शून्य स्थिति के साथ समाप्त होता है और असत्यापित plugin सेट के साथ Gateway को पुनः आरंभ नहीं किया जाता। त्रुटि में openclaw update repair और openclaw plugins inspect <id> --runtime --json की ओर संकेत करने वाली संरचित postUpdate.plugins.warnings[].guidance पंक्तियाँ शामिल होती हैं। अक्षम plugin प्रविष्टियाँ और ऐसे रिकॉर्ड, जो trusted-source से जुड़े आधिकारिक सिंक लक्ष्य नहीं हैं, यहाँ छोड़ दिए जाते हैं (अनुपलब्ध-payload जाँच में प्रयुक्त skipDisabledPlugins नीति के अनुरूप), इसलिए कोई पुराना अक्षम plugin रिकॉर्ड अन्यथा मान्य अपडेट को अवरुद्ध नहीं कर सकता।अपडेट किया गया Gateway शुरू होने पर plugin लोडिंग केवल-सत्यापन होती है: स्टार्टअप पैकेज मैनेजर नहीं चलाता या dependency trees में परिवर्तन नहीं करता। पैकेज-मैनेजर update.run पुनः आरंभ CLI प्रबंधित-सेवा पथ को सौंपे जाते हैं, ताकि पैकेज अदला-बदली पुरानी Gateway प्रक्रिया के बाहर हो और सेवा स्वास्थ्य जाँचें निर्धारित करें कि अपडेट को पूर्ण रिपोर्ट किया जा सकता है या नहीं।
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 रन के लिए छोड़े जाते हैं।

​
संबंधित