Skip to main content
OpenClaw को अद्यतित रखें। Docker, Podman और Kubernetes इमेज बदलने के लिए, कंटेनर इमेज अपग्रेड करना देखें। Gateway तत्पर होने से पहले स्टार्टअप-सुरक्षित अपग्रेड कार्य चलाता है और यदि माउंट की गई स्थिति को मैन्युअल सुधार की आवश्यकता हो, तो बंद हो जाता है।

अनुशंसित: openclaw update

आपके इंस्टॉलेशन प्रकार (npm, pnpm, Bun या git) का पता लगाता है, नवीनतम संस्करण प्राप्त करता है, openclaw doctor चलाता है और Gateway को पुनः आरंभ करता है।
चैनल बदलें या किसी विशिष्ट संस्करण को लक्षित करें:
openclaw update में --verbose फ़्लैग नहीं है (इंस्टॉलर में है)। निदान के लिए नियोजित कार्रवाइयों का पूर्वावलोकन करने हेतु --dry-run, संरचित परिणामों के लिए --json, या चैनल और उपलब्धता स्थिति की जाँच के लिए openclaw update status --json का उपयोग करें। --channel beta beta npm dist-tag को प्राथमिकता देता है, लेकिन beta टैग के अनुपलब्ध होने या उसका संस्करण नवीनतम स्थिर रिलीज़ से पुराना होने पर stable/latest पर लौट जाता है। इसके बजाय मूल npm beta dist-tag पर पिन किए गए एकबारगी पैकेज अपडेट के लिए --tag beta का उपयोग करें। --channel extended-stable केवल पैकेज के लिए है और इंस्टॉलेशन केवल अग्रभूमि में ही होता है। OpenClaw सार्वजनिक npm extended-stable चयनकर्ता को पढ़ता है, चुने गए सटीक पैकेज को सत्यापित करता है और उसी सटीक संस्करण को इंस्टॉल करता है। रजिस्ट्री डेटा अनुपलब्ध या असंगत होने पर प्रक्रिया सुरक्षित रूप से विफल होती है; यह कभी भी latest पर वापस नहीं जाती। यदि चुना गया संस्करण इंस्टॉल किए गए संस्करण से पुराना है, तो सामान्य डाउनग्रेड पुष्टि फिर भी लागू होती है। सफल कोर अपडेट के बाद CLI चैनल को सहेजता है; प्रत्यक्ष npm install -g openclaw@extended-stable update.channel को अपडेट नहीं करता। कोर बदलने के बाद, bare/default या latest अभिप्राय वाले पात्र आधिकारिक npm plugins उसी सटीक कोर संस्करण पर अभिसरित होते हैं। सटीक पिन और स्पष्ट गैर-latest टैग, तृतीय-पक्ष plugins तथा गैर-npm स्रोत अपरिवर्तित रहते हैं। वर्तमान OpenClaw संस्करणों द्वारा बनाए गए कैटलॉग इंस्टॉलेशन उस डिफ़ॉल्ट अभिप्राय को बनाए रखते हैं। केवल सटीक संस्करण वाले पुराने रिकॉर्ड पिन किए हुए रहते हैं, क्योंकि OpenClaw किसी पुराने स्वचालित पिन और उपयोगकर्ता पिन के बीच सुरक्षित रूप से अंतर नहीं कर सकता; उस plugin को सटीक-कोर ट्रैकिंग में वापस शामिल करने के लिए extended-stable चैनल पर openclaw plugins update @openclaw/name एक बार चलाएँ। --channel dev एक स्थायी, बदलता रहने वाला GitHub main चेकआउट प्रदान करता है। एकबारगी पैकेज अपडेट के लिए, --tag main, github:openclaw/openclaw#main पैकेज स्पेसिफ़िकेशन से मैप होता है और लक्षित पैकेज प्रबंधक (npm/pnpm/bun) के माध्यम से उसे सीधे इंस्टॉल करता है। प्रबंधित plugins के लिए, beta रिलीज़ का अनुपलब्ध होना चेतावनी है, विफलता नहीं: plugin के अपने दर्ज किए गए default/latest रिलीज़ पर लौटने के बावजूद कोर अपडेट सफल हो सकता है। चैनल के अर्थ के लिए रिलीज़ चैनल देखें।

npm और git इंस्टॉलेशन के बीच स्विच करें

इंस्टॉलेशन प्रकार बदलने के लिए चैनलों का उपयोग करें। अपडेटर आपकी स्थिति, कॉन्फ़िगरेशन, क्रेडेंशियल और कार्यक्षेत्र को ~/.openclaw में बनाए रखता है; यह केवल यह बदलता है कि CLI और Gateway किस OpenClaw कोड इंस्टॉलेशन का उपयोग करते हैं।
पहले इंस्टॉलेशन मोड में बदलाव का पूर्वावलोकन करें:
dev git चेकआउट सुनिश्चित करता है, उसे बिल्ड करता है और उस चेकआउट से ग्लोबल CLI इंस्टॉल करता है। stable, extended-stable और beta चैनल पैकेज इंस्टॉलेशन का उपयोग करते हैं। git चेकआउट पर extended-stable को किसी परिवर्तन या रूपांतरण के बिना अस्वीकार कर दिया जाता है। यदि Gateway पहले से इंस्टॉल है, तो openclaw update सेवा मेटाडेटा को रीफ़्रेश करता है और उसे पुनः आरंभ करता है, जब तक कि आप --no-restart न दें। प्रबंधित Gateway सेवा वाले पैकेज इंस्टॉलेशन में, openclaw update उस सेवा द्वारा उपयोग किए गए पैकेज रूट को लक्षित करता है। यदि शेल का openclaw कमांड किसी अलग इंस्टॉलेशन से आता है, तो अपडेटर दोनों रूट और प्रबंधित सेवा का Node पथ प्रिंट करता है तथा पैकेज बदलने से पहले उस Node संस्करण की लक्षित रिलीज़ की engines.node आवश्यकता के विरुद्ध जाँच करता है।

स्रोत-चेकआउट सर्वर (संदर्भ स्क्रिप्ट)

सर्वर पर git चेकआउट से सीधे Gateway चलाने वाली टीमें उस चेकआउट के भीतर से scripts/update-gateway.sh का उपयोग करके उसे अपडेट कर सकती हैं। यह एक कुशल स्रोत-सर्वर अपडेट का संदर्भ है: यह उन ट्रैक किए गए बिल्ड आउटपुट को पुनर्स्थापित करता है जिन्हें pnpm build फिर से लिखता है, किसी भी अन्य स्थानीय बदलाव पर सुरक्षित रूप से विफल होता है, main को फ़ास्ट-फ़ॉरवर्ड करता है (या स्थानीय सर्वर शाखा को origin/main पर रीबेस करता है), निर्भरताएँ इंस्टॉल करता है, स्वच्छ बिल्ड बनाता है और Gateway को पुनः आरंभ करता है।
कस्टम सेवा यूनिट के लिए पुनः आरंभ कमांड बदलें या उसे पूरी तरह छोड़ दें:
साधारण एकल-उपयोगकर्ता स्रोत इंस्टॉलेशन के लिए, इसके बजाय openclaw update --channel dev को प्राथमिकता दें — यह आपके लिए चेकआउट, बिल्ड और Gateway के पुनः आरंभ को प्रबंधित करता है।

विकल्प: इंस्टॉलर फिर से चलाएँ

ऑनबोर्डिंग छोड़ने के लिए --no-onboard जोड़ें। किसी विशिष्ट इंस्टॉलेशन प्रकार को बाध्य करने के लिए, --install-method git --no-onboard या --install-method npm --no-onboard दें। यदि npm पैकेज इंस्टॉलेशन चरण के बाद openclaw update विफल हो जाए, तो इसके बजाय इंस्टॉलर फिर से चलाएँ। यह अपडेटर को कॉल नहीं करता; यह ग्लोबल पैकेज इंस्टॉलेशन सीधे चलाता है और आंशिक रूप से अपडेट किए गए npm इंस्टॉलेशन को पुनर्प्राप्त कर सकता है।
--version के साथ पुनर्प्राप्ति को किसी विशिष्ट संस्करण या dist-tag पर पिन करें:

विकल्प: मैन्युअल npm, pnpm या bun

पर्यवेक्षित इंस्टॉलेशन के लिए openclaw update को प्राथमिकता दें: यह पैकेज बदलने की प्रक्रिया को चल रही Gateway सेवा के साथ समन्वित कर सकता है। यदि आप पर्यवेक्षित इंस्टॉलेशन को मैन्युअल रूप से अपडेट करते हैं, तो पहले प्रबंधित Gateway को रोकें। पैकेज प्रबंधक फ़ाइलों को उसी स्थान पर बदलते हैं और अन्यथा चल रहा Gateway बदलाव के बीच में कोर या plugin फ़ाइलें लोड करने का प्रयास कर सकता है। पैकेज प्रबंधक का कार्य पूरा होने के बाद Gateway को पुनः आरंभ करें, ताकि वह नए इंस्टॉलेशन को अपना सके। रूट-स्वामित्व वाले Linux सिस्टम-ग्लोबल इंस्टॉलेशन में, यदि openclaw update EACCES के साथ विफल हो जाए, तो मैन्युअल बदलाव के दौरान Gateway को रोके रखते हुए सिस्टम npm से पुनर्प्राप्त करें। उसी प्रोफ़ाइल के फ़्लैग/वातावरण का उपयोग करें जिसका आप सामान्यतः उस Gateway के लिए उपयोग करते हैं। /usr/bin/npm को उस सिस्टम npm से बदलें जो आपके होस्ट पर रूट-स्वामित्व वाले ग्लोबल प्रीफ़िक्स का स्वामी है:
फिर सत्यापित करें:
जब openclaw update किसी ग्लोबल npm इंस्टॉलेशन को प्रबंधित करता है, तो वह पहले लक्ष्य को एक अस्थायी npm प्रीफ़िक्स में इंस्टॉल करता है। उम्मीदवार पैकेज preinstall के दौरान होस्ट के Node संस्करण को सत्यापित करता है; उसके बाद ही OpenClaw पैकेज की गई dist सूची सत्यापित करता है और स्वच्छ पैकेज ट्री को वास्तविक ग्लोबल प्रीफ़िक्स में बदलता है। अपेक्षित सूची में पैक किया गया पूर्णता गार्ड शामिल नहीं किया जाता और उसे केवल preinstall के सफल होने के बाद हटाया जाता है, इसलिए छोड़ी गई लाइफ़साइकल स्क्रिप्ट भी बदलाव से पहले विफल होती हैं। npm 12 और नए संस्करणों में, अपडेटर केवल उम्मीदवार OpenClaw लाइफ़साइकल को स्वीकृति देता है; ट्रांज़िटिव निर्भरता स्क्रिप्ट अवरुद्ध रहती हैं। इससे npm द्वारा पुराने पैकेज की बासी फ़ाइलों पर नया पैकेज चढ़ाने से बचाव होता है। यदि इंस्टॉल कमांड विफल होता है, तो OpenClaw --omit=optional के साथ एक बार फिर प्रयास करता है, जिससे उन होस्ट को सहायता मिलती है जहाँ वैकल्पिक नेटिव निर्भरताएँ कंपाइल नहीं हो सकतीं। OpenClaw द्वारा प्रबंधित npm अपडेट और plugin-अपडेट कमांड चाइल्ड npm प्रक्रिया के लिए npm की min-release-age सप्लाई-चेन क्वारंटीन (या पुरानी before कॉन्फ़िगरेशन कुंजी) को भी साफ़ करते हैं। वह नीति सामान्य सुरक्षा के लिए है, लेकिन स्पष्ट OpenClaw अपडेट का अर्थ है “चुनी गई रिलीज़ अभी इंस्टॉल करें।”
यदि pnpm 11 ने OpenClaw 2026.7.1 इंस्टॉल किया था, तो वह मैन्युअल कमांड एक बार चलाएँ। वह रिलीज़ pnpm 11 के पृथक ग्लोबल-पैकेज लेआउट से पहले की है, इसलिए उसका अपडेटर किसी अन्य npm इंस्टॉलेशन को चल रहा CLI समझ सकता है। बाद की रिलीज़ pnpm स्वामित्व बनाए रखती हैं और अपडेट के दौरान प्रतिस्थापन पैकेज रूट का अनुसरण करती हैं। वे स्वामी प्रबंधक द्वारा बताए गए ग्लोबल bin डायरेक्टरी का भी उपयोग करती हैं और परिवर्तन से पहले रुक जाती हैं, जब उपलब्ध pnpm कमांड कोई अन्य ग्लोबल रूट या प्रमुख संस्करण बताता है, या जब आह्वान करने वाला पैकेज अनाथ हो अथवा वहाँ एकमात्र सक्रिय OpenClaw इंस्टॉलेशन न हो। यदि OpenClaw किसी अन्य पैकेज के साथ pnpm 11 ग्लोबल इंस्टॉल समूह साझा करता है, तो स्वचालित अपडेटर समूह बदलने से पहले रुक जाता है। मूल अल्पविराम से अलग किए गए समूह को मैन्युअल रूप से अपडेट करें, ताकि उसके सहोदर पैकेज और बिल्ड नीति अक्षुण्ण रहें।

उन्नत npm इंस्टॉलेशन विषय

OpenClaw पैकेज किए गए ग्लोबल इंस्टॉलेशन को रनटाइम पर केवल-पढ़ने योग्य मानता है, भले ही ग्लोबल पैकेज डायरेक्टरी वर्तमान उपयोगकर्ता द्वारा लिखने योग्य हो। Plugin पैकेज इंस्टॉलेशन उपयोगकर्ता कॉन्फ़िगरेशन डायरेक्टरी के अंतर्गत OpenClaw-स्वामित्व वाले npm/git रूट में रहते हैं और Gateway स्टार्टअप OpenClaw पैकेज ट्री में बदलाव नहीं करता।कुछ Linux npm सेटअप /usr/lib/node_modules/openclaw जैसी रूट-स्वामित्व वाली डायरेक्टरियों के अंतर्गत ग्लोबल पैकेज इंस्टॉल करते हैं। OpenClaw उस लेआउट का समर्थन करता है, क्योंकि plugin इंस्टॉल/अपडेट कमांड उस ग्लोबल पैकेज डायरेक्टरी के बाहर लिखते हैं।
OpenClaw को उसके कॉन्फ़िगरेशन/स्थिति रूट पर लिखने की पहुँच दें, ताकि स्पष्ट plugin इंस्टॉलेशन, plugin अपडेट और doctor सफ़ाई अपने बदलाव सहेज सकें:
पैकेज अपडेट और स्पष्ट plugin इंस्टॉलेशन से पहले, OpenClaw लक्षित वॉल्यूम के लिए सर्वोत्तम-प्रयास वाली डिस्क स्थान जाँच करता है। कम स्थान जाँचे गए पथ के साथ चेतावनी उत्पन्न करता है, लेकिन अपडेट को अवरुद्ध नहीं करता, क्योंकि जाँच के बाद फ़ाइल-सिस्टम कोटा, स्नैपशॉट और नेटवर्क वॉल्यूम बदल सकते हैं। वास्तविक पैकेज-प्रबंधक इंस्टॉलेशन और इंस्टॉलेशन-पश्चात सत्यापन ही प्रामाणिक रहते हैं।

स्वचालित अपडेटर

डिफ़ॉल्ट रूप से बंद है। इसे ~/.openclaw/openclaw.json में सक्षम करें:
Gateway स्टार्टअप पर अपडेट संकेत भी लॉग करता है (इसे update.checkOnStart: false से अक्षम करें)। सहेजे गए extended-stable चयन इस केवल-पढ़ने योग्य संकेत पथ और मौजूदा 24-घंटे के संकेत अंतराल का उपयोग करते हैं, लेकिन स्वचालित इंस्टॉलेशन, हैंडऑफ़, रीस्टार्ट, stable विलंब/जिटर या beta पोलिंग को कभी शुरू नहीं करते। डाउनग्रेड या घटना से पुनर्प्राप्ति के लिए, Gateway परिवेश में OPENCLAW_NO_AUTO_UPDATE=1 सेट करें, ताकि update.auto.enabled कॉन्फ़िगर होने पर भी स्वचालित लागूकरण अवरुद्ध रहें। स्टार्टअप अपडेट संकेत तब भी चल सकते हैं, जब तक update.checkOnStart भी अक्षम न हो। लाइव Gateway कंट्रोल-प्लेन के माध्यम से अनुरोध किए गए पैकेज-मैनेजर अपडेट (update.run) चल रही Gateway प्रक्रिया के भीतर पैकेज ट्री को प्रतिस्थापित नहीं करते। प्रबंधित सेवा इंस्टॉलेशन पर, Gateway एक अलग हैंडऑफ़ शुरू करता है, बाहर निकलता है, और सामान्य openclaw update --yes --json CLI पथ को सेवा रोकने, पैकेज प्रतिस्थापित करने, सेवा मेटाडेटा रीफ़्रेश करने, रीस्टार्ट करने, Gateway संस्करण और पहुँच-क्षमता सत्यापित करने तथा संभव होने पर इंस्टॉल किए गए लेकिन लोड न हुए macOS LaunchAgent को पुनर्प्राप्त करने देता है। यदि Gateway सुरक्षित रूप से यह हैंडऑफ़ नहीं कर सकता, तो update.run पैकेज मैनेजर को प्रक्रिया के भीतर चलाने के बजाय एक सुरक्षित शेल कमांड बताता है। Control UI साइडबार अपडेट कार्ड तब Gateway अपडेट करें दिखाता है, जब वह इस update.run प्रवाह को सीधे शुरू करेगा। इसमें ब्राउज़र-होस्टेड Control UI, रिमोट Gateways और मैन्युअल रूप से प्रबंधित स्थानीय Gateways शामिल हैं। हस्ताक्षरित macOS ऐप में, स्थानीय ऐप-स्वामित्व वाला Gateway उस कार्ड को Mac ऐप + Gateway अपडेट करें में बदल देता है। Sparkle पहले ऐप को अपडेट करता है; दोबारा लॉन्च होने के बाद, ऐप openclaw update --tag <app-version> --json चलाता है, अपने Gateway को रीस्टार्ट करता है, और सेटअप-जैसी प्रगति विंडो में स्वास्थ्य सत्यापित करता है। विंडो केवल तभी दिखाई देती है जब उस प्रबंधित Gateway को अपडेट, मरम्मत या इंस्टॉलेशन चाहिए; केवल-ऐप अपडेट सीधे ऐप में दोबारा लॉन्च होते हैं। विफलता विवरण Retry, अपडेट मार्गदर्शिका और Discord कार्रवाइयों के साथ दिखाई देते रहते हैं। ऐप इस समन्वित पथ का उपयोग रिमोट या बाहरी रूप से प्रबंधित Gateway के लिए कभी नहीं करता, किसी नए Gateway को कभी डाउनग्रेड नहीं करता और extended-stable चैनल पिन को कभी ओवरराइड नहीं करता। अपडेट सफल होने पर, ऐप किसी वास्तविक उपयोगकर्ता/चैनल इंटरैक्शन वाले सबसे हाल के शीर्ष-स्तरीय प्रत्यक्ष सत्र के लिए एक बार का स्वागत इवेंट कतार में लगाता है। Cron रन, heartbeats और केवल-बैकग्राउंड सत्र अपडेट उस चयन को नहीं बदलते। रिमोट मोड में, ऐप केवल अपने स्थानीय Mac Node रनटाइम को अपडेट करता है और इवेंट केवल तभी भेजता है जब कनेक्टेड रिमोट Gateway कम-से-कम ऐप जितना नया हो।

अपडेट करने के बाद

रोलबैक

रोलबैक की दो परतें हैं:
  1. वर्तमान स्थिति बनाए रखते हुए पुराना OpenClaw कोड दोबारा इंस्टॉल करें।
  2. अपडेट-पूर्व स्थिति केवल तभी पुनर्स्थापित करें, जब पुराना कोड माइग्रेट किए गए कॉन्फ़िग या डेटाबेस का उपयोग नहीं कर सकता।
पहले केवल-कोड रोलबैक करें। स्थिति पुनर्स्थापित करने से बैकअप के बाद किए गए बदलाव मिट जाते हैं।

अपडेट करने से पहले: सत्यापित बैकअप बनाएँ

openclaw update अपडेट-पूर्व कॉन्फ़िग की स्वचालित प्रति सुरक्षित रखता है, लेकिन यह पूर्ण स्थिति पुनर्प्राप्ति बिंदु नहीं बनाता। किसी महत्वपूर्ण अपडेट से पहले, इसे स्पष्ट रूप से बनाएँ:
आर्काइव मेनिफ़ेस्ट OpenClaw संस्करण और बैकअप में शामिल स्रोत पथ दर्ज करता है। आर्काइव में क्रेडेंशियल, ऑथ प्रोफ़ाइल और चैनल स्थिति हो सकती है, इसलिए इसे केवल-स्वामी अनुमतियों और लाइव स्थिति डायरेक्टरी जैसी सुरक्षा के साथ संग्रहीत करें। शामिल और जानबूझकर छोड़ी गई फ़ाइलों के लिए बैकअप देखें। ऐसे बाइट-दर-बाइट पुनर्प्राप्ति बिंदु के लिए, जिसमें पोर्टेबल आर्काइव द्वारा छोड़ी गई अस्थिर कलाकृतियाँ भी शामिल हों, Gateway रोकें और अपने प्लेटफ़ॉर्म द्वारा प्रदान किया गया फ़ाइलसिस्टम, वॉल्यूम या VM स्नैपशॉट उपयोग करें।

पैकेज इंस्टॉलेशन रोल बैक करें

प्रकाशित संस्करण सूचीबद्ध करें, फिर ज्ञात-सही संस्करण का पूर्वावलोकन करके उसे इंस्टॉल करें:
सीधे पैकेज-मैनेजर इंस्टॉलेशन के बजाय openclaw update --tag को प्राथमिकता दी जाती है। यह डाउनग्रेड का पता लगाता है, पुष्टि माँगता है, इंस्टॉल किए गए लक्ष्य के विरुद्ध प्रबंधित Plugin अभिसरण और संगतता जाँच चलाता है, सेवा मेटाडेटा रीफ़्रेश करता है, Gateway को रीस्टार्ट करता है और चल रहे संस्करण को सत्यापित करता है। यदि सहेजा गया चैनल extended-stable है, तो --channel stable --tag <known-good-version> उपयोग करें, क्योंकि एकबारगी सटीक टैग को extended-stable चयनकर्ता के साथ जोड़ा नहीं जा सकता। पैकेज अपडेट सक्रियण से पहले उम्मीदवार को स्टेज और सत्यापित करते हैं। यदि फ़ाइलसिस्टम स्वैप या कमांड-शिम प्रतिस्थापन विफल होता है, तो OpenClaw पुराने पैकेज को स्वचालित रूप से पुनर्स्थापित करता है। सफल स्वैप के बाद, बाद में हुई Gateway स्वास्थ्य विफलता पैकेज को फिर से स्वचालित रूप से प्रतिस्थापित करने के बजाय पिछला संस्करण और मैन्युअल रोलबैक निर्देश बताती है। यदि CLI अपडेट पथ उपलब्ध नहीं है, तो वही पैकेज मैनेजर और इंस्टॉलेशन स्कोप उपयोग करें जो वर्तमान Gateway के स्वामी हैं:
जब वह मैनेजर इंस्टॉलेशन का स्वामी हो, तो npm को pnpm या bun से बदलें। घटना से पुनर्प्राप्ति के दौरान, सक्षम ऑटो-अपडेटर को तुरंत नया रिलीज़ लागू करने से रोकने के लिए Gateway परिवेश में OPENCLAW_NO_AUTO_UPDATE=1 सेट करें।

स्रोत चेकआउट रोल बैक करें

स्वच्छ चेकआउट उपयोग करें और ज्ञात-सही टैग या कमिट चुनें:
नवीनतम पर लौटने के लिए: git checkout main && git pull git अपडेट शुरू होने के बाद निर्भरता इंस्टॉलेशन, बिल्ड, UI बिल्ड या डॉक्टर विफल होने पर अपडेटर स्वचालित रूप से git चेकआउट को उसकी पिछली ब्रांच और SHA पर लौटा देता है। जब आप जानबूझकर कोई पुराना कमिट चुनते हैं, तब भी मैन्युअल चेकआउट आवश्यक है।

सत्र SQLite माइग्रेशन के पार डाउनग्रेड करना

पुराना फ़ाइल-समर्थित OpenClaw रिलीज़ शुरू करने से पहले, आर्काइव की गई पुरानी ट्रांसक्रिप्ट कलाकृतियाँ पुनर्स्थापित करने के लिए वर्तमान CLI उपयोग करें:
यह SQLite डेटा नहीं मिटाता। SQLite माइग्रेशन के बाद बनाए गए सत्र केवल SQLite में मौजूद होते हैं और पुराने रनटाइम में दिखाई नहीं देंगे। देखें सत्र SQLite माइग्रेशन के बाद डाउनग्रेड करना

स्थिति केवल आवश्यकता होने पर पुनर्स्थापित करें

यदि पुराना कोड नया कॉन्फ़िग या डेटाबेस स्कीमा नहीं पढ़ सकता, तो Gateway रोकें और सत्यापित अपडेट-पूर्व फ़ाइलसिस्टम, वॉल्यूम या VM स्नैपशॉट पुनर्स्थापित करें। पुनर्स्थापित करने से पहले वर्तमान स्थिति अलग से सुरक्षित रखें, क्योंकि इससे स्नैपशॉट के बाद किए गए बदलाव हट जाते हैं। व्यापक openclaw backup create आर्काइव निर्माण और सत्यापन का समर्थन करते हैं, लेकिन इन-प्लेस संपूर्ण-आर्काइव सक्रियण का नहीं। व्यापक आर्काइव को स्टेजिंग डायरेक्टरी में निकालें और ऑफ़लाइन पुनर्स्थापना के लिए उसकी manifest.json स्रोत-से-आर्काइव मैपिंग उपयोग करें। इसी प्रकार openclaw backup sqlite restore एक सत्यापित डेटाबेस नए लक्ष्य पर लिखता है; उस लक्ष्य को सक्रिय करना एक स्पष्ट ऑफ़लाइन ऑपरेटर चरण बना रहता है।

रोलबैक सत्यापित करें

यदि आप अटक गए हैं

  • openclaw doctor दोबारा चलाएँ और आउटपुट ध्यान से पढ़ें।
  • स्रोत चेकआउट पर openclaw update --channel dev के लिए, आवश्यकता होने पर अपडेटर pnpm को स्वतः बूटस्ट्रैप करता है। यदि आपको pnpm/corepack बूटस्ट्रैप त्रुटि दिखाई दे, तो pnpm मैन्युअल रूप से इंस्टॉल करें (या corepack को फिर से सक्षम करें) और अपडेट दोबारा चलाएँ।
  • देखें: समस्या निवारण
  • Discord पर पूछें: https://discord.gg/clawd

संबंधित