openclaw update
OpenClaw को सुरक्षित रूप से अपडेट करें और stable/beta/dev चैनलों के बीच स्विच करें।
अगर आपने npm/pnpm/bun के जरिए इंस्टॉल किया है (global install, कोई git metadata नहीं),
तो अपडेट Updating में दिए package-manager flow के जरिए होते हैं।
उपयोग
विकल्प
--no-restart: सफल अपडेट के बाद Gateway सेवा को दोबारा शुरू करना छोड़ें। Gateway को दोबारा शुरू करने वाले package-manager अपडेट, command के सफल होने से पहले सत्यापित करते हैं कि दोबारा शुरू की गई सेवा अपेक्षित अपडेटेड version रिपोर्ट कर रही है।--channel <stable|beta|dev>: अपडेट चैनल सेट करें (git + npm; config में कायम रखा जाता है)।--tag <dist-tag|version|spec>: केवल इस अपडेट के लिए package target को override करें। Package installs के लिए,maingithub:openclaw/openclaw#mainपर map होता है; GitHub/git source specs को staged global npm install से पहले अस्थायी tarball में pack किया जाता है।--dry-run: config लिखे बिना, install किए बिना, plugins sync किए बिना, या restart किए बिना नियोजित update actions (channel/tag/target/restart flow) का preview करें।--json: machine-readableUpdateRunResultJSON print करें, जिसमेंpostUpdate.plugins.warningsशामिल होता है जब core update सफल होने के बाद corrupt या unloadable managed plugins को repair की जरूरत होती है, beta-channel plugin fallback details जब किसी plugin की beta release नहीं होती, औरpostUpdate.plugins.integrityDriftsजब post-update plugin sync के दौरान npm plugin artifact drift detected होता है।--timeout <seconds>: प्रत्येक step का timeout (default 1800s है)।--yes: confirmation prompts छोड़ें (उदाहरण के लिए downgrade confirmation)।--acknowledge-clawhub-risk: community ClawHub trust warnings की समीक्षा के बाद, post-update plugin sync को interactive prompt के बिना जारी रखने दें। इसके बिना, risky community ClawHub plugin releases skip कर दी जाती हैं और जब OpenClaw prompt नहीं कर सकता तो unchanged छोड़ दी जाती हैं। Official ClawHub packages और bundled OpenClaw plugin sources इस release-trust prompt को bypass करते हैं।
openclaw update में --verbose flag नहीं है। नियोजित
channel/tag/install/restart actions का preview करने के लिए --dry-run, machine-readable
results के लिए --json, और जब आपको केवल channel और
availability details चाहिए हों तो openclaw update status --json का उपयोग करें। अगर आप update के आसपास Gateway logs debug कर रहे हैं,
तो console verbosity और file log level अलग हैं: Gateway --verbose
terminal/WebSocket output को प्रभावित करता है, जबकि file logs के लिए config में logging.level: "debug" या
"trace" चाहिए। Gateway logging देखें।
Nix mode (
OPENCLAW_NIX_MODE=1) में, mutating openclaw update runs disabled हैं। इसके बजाय इस install के लिए Nix source या flake input update करें; nix-openclaw के लिए agent-first Quick Start का उपयोग करें। openclaw update status और openclaw update --dry-run read-only बने रहते हैं।update status
Active update channel + git tag/branch/SHA (source checkouts के लिए), और update availability दिखाएं।
--json: machine-readable status JSON print करें।--timeout <seconds>: checks के लिए timeout (default 3s है)।
update repair
Core package पहले ही बदल चुका हो लेकिन बाद का
repair work साफ़ तौर पर finish न हुआ हो, तो update finalization दोबारा चलाएं। यह supported recovery path है जब
openclaw update ने नया core package install कर दिया हो लेकिन post-core plugin sync,
managed npm plugin metadata, registry refresh, या doctor repair को अभी भी
converge होना हो।
--channel <stable|beta|dev>: repair से पहले update channel persist करें और उस channel के विरुद्ध plugin convergence चलाएं।--json: machine-readable finalization JSON print करें।--timeout <seconds>: repair steps के लिए timeout (default1800)।--yes: confirmation prompts छोड़ें।--acknowledge-clawhub-risk: community ClawHub trust warnings की समीक्षा के बाद, repair-time plugin convergence को interactive prompt के बिना जारी रखने दें। Official ClawHub packages और bundled OpenClaw plugin sources इस release-trust prompt को bypass करते हैं।--no-restart: update command parity के लिए accepted है; repair Gateway को कभी restart नहीं करता।
openclaw update repair openclaw doctor --fix चलाता है, repaired
config और install records reload करता है, active update channel के लिए tracked plugins sync करता है,
managed npm plugin installs update करता है, missing configured plugin payloads repair करता है,
plugin registry refresh करता है, और converged install-record metadata लिखता है।
यह नया core package install नहीं करता और Gateway को restart नहीं करता।
update wizard
Update channel चुनने और update के बाद Gateway को restart करना है या नहीं इसकी पुष्टि करने के लिए interactive flow
(default restart करना है)। अगर आप git checkout के बिना dev चुनते हैं, तो यह
एक बनाने की पेशकश करता है।
विकल्प:
--timeout <seconds>: हर update step के लिए timeout (default1800)
यह क्या करता है
जब आप channels को स्पष्ट रूप से switch करते हैं (--channel ...), OpenClaw
install method को भी aligned रखता है:
dev→ git checkout सुनिश्चित करता है (default:~/openclaw, याOPENCLAW_HOMEset होने पर$OPENCLAW_HOME/openclaw;OPENCLAW_GIT_DIRसे override करें), उसे update करता है, और उस checkout से global CLI install करता है।stable→latestका उपयोग करके npm से install करता है।beta→ npm dist-tagbetaको prefer करता है, लेकिन जब beta missing हो या current stable release से पुराना हो तोlatestपर fall back करता है।
update.run
package-manager updates और supervised git-checkout updates भी live Gateway process के अंदर package tree replace करने या
dist/ rebuild करने के बजाय
managed-service handoff का उपयोग करते हैं। Gateway detached helper शुरू करता है,
exit करता है, और helper Gateway process tree के बाहर से normal openclaw update --yes --json CLI path चलाता है।
अगर वह handoff unavailable हो, तो
update.run manually चलाने के लिए safe shell command के साथ structured response return करता है।
Package-manager installs के लिए, openclaw update package manager invoke करने से पहले target package
version resolve करता है। npm global installs staged
install का उपयोग करते हैं: OpenClaw नए package को temporary npm prefix में install करता है, वहां packaged dist inventory verify करता है,
फिर उस clean package tree को real global prefix में swap करता है।
अगर verification fail होती है, तो post-update doctor, plugin sync, और
restart work suspect tree से नहीं चलते। जब installed version
पहले से target से match करता हो, तब भी command global package install refresh करता है,
फिर plugin sync, core-command completion refresh, और restart work चलाता है। इससे
packaged sidecars और channel-owned plugin records installed OpenClaw build के साथ aligned रहते हैं,
जबकि full plugin-command completion rebuilds को explicit openclaw completion --write-state runs के लिए छोड़ा जाता है।
जब local managed Gateway service installed हो और restart enabled हो,
तो package-manager और git-checkout updates package tree replace करने या checkout/build output mutate करने से पहले
running service को stop करते हैं। फिर updater
updated install से service metadata refresh करता है, service restart करता है,
और Gateway: restarted and verified. report करने से पहले restarted Gateway verify करता है। Package-manager updates अतिरिक्त रूप से verify करते हैं
कि restarted Gateway expected package version report करता है; git-checkout updates
rebuild के बाद gateway health और service readiness verify करते हैं। macOS पर,
post-update check active profile के लिए LaunchAgent loaded/running है और configured loopback port healthy है, यह भी verify करता है। अगर plist installed है
लेकिन launchd उसे supervise नहीं कर रहा, तो OpenClaw LaunchAgent को
automatically re-bootstrap करता है, फिर health/version/channel readiness checks दोबारा चलाता है। Fresh
bootstrap RunAtLoad job को directly load करता है, इसलिए update recovery
नई spawned Gateway को तुरंत kickstart -k नहीं करता। अगर Gateway फिर भी
healthy नहीं होता, तो command non-zero exit करता है और restart log path
साथ में explicit restart, reinstall, और package rollback instructions print करता है। अगर restart
नहीं चल सकता, तो command manual openclaw gateway restart hint के साथ Gateway: restart skipped (...) या
Gateway: restart failed: ... print करता है।
--no-restart के साथ, package replacement या git rebuild फिर भी चलता है लेकिन
managed service stop या restart नहीं की जाती, इसलिए running Gateway में old
code तब तक रह सकता है जब तक आप उसे manually restart न करें।
Control-plane response shape
जबupdate.run Gateway control plane के जरिए
package-manager install या supervised git checkout पर invoke होता है, तो handler
Gateway exit के बाद जारी रहने वाले CLI update से handoff initiation को अलग report करता है:
ok: true,result.status: "skipped",result.reason: "managed-service-handoff-started", औरhandoff.status: "started"का अर्थ है कि Gateway ने managed-service handoff बनाया और अपना restart schedule किया ताकि detached helper live service process के बाहरopenclaw update --yes --jsonचला सके।ok: false,result.reason: "managed-service-handoff-unavailable", औरhandoff.status: "unavailable"का अर्थ है कि OpenClaw safe handoff के लिए supervising service boundary और durable service identity नहीं ढूंढ सका। उदाहरण के लिए, systemd handoff को OpenClaw unit identity (OPENCLAW_SYSTEMD_UNIT) चाहिए, केवल ambient systemd process markers नहीं। Response मेंhandoff.commandशामिल होता है, Gateway के बाहर से चलाने के लिए shell command।ok: false,result.reason: "managed-service-handoff-failed"का अर्थ है कि Gateway ने handoff बनाने की कोशिश की लेकिन detached helper spawn नहीं कर सका।
sentinel payload Gateway exit से पहले अब भी लिखा जाता है, और CLI
handoff managed-service restart health checks complete होने के बाद उसी restart sentinel को update करता है।
Handoff के दौरान, sentinel
stats.reason: "restart-health-pending" carry कर सकता है जिसमें कोई success continuation नहीं होता; restarted Gateway उसे polling करता रहता है और continuation केवल तब fire करता है जब CLI
ने service health verify करके final ok
result के साथ sentinel rewrite कर दिया हो। openclaw status और openclaw status --all उस sentinel के pending या failed होने पर Update restart
row दिखाते हैं, और update.status latest sentinel refresh करके
return करता है।
Git checkout flow
Channel selection
stable: latest non-beta tag checkout करें, फिर build और doctor करें।beta: latest-betatag prefer करें, लेकिन beta missing या older होने पर latest stable tag पर fall back करें।dev:maincheckout करें, फिर fetch और rebase करें।
Update steps
पूर्व-जांच बिल्ड (केवल विकास)
अस्थायी कार्य-वृक्ष में TypeScript बिल्ड चलाता है। यदि टिप विफल होती है, तो नवीनतम बिल्ड-योग्य कमिट खोजने के लिए 10 कमिट तक पीछे जाता है। इस पूर्व-जांच के दौरान lint भी चलाने के लिए
OPENCLAW_UPDATE_PREFLIGHT_LINT=1 सेट करें; lint सीमित सीरियल मोड में चलता है क्योंकि उपयोगकर्ता अपडेट होस्ट अक्सर CI रनर से छोटे होते हैं।निर्भरताएँ इंस्टॉल करें
रिपॉजिटरी पैकेज मैनेजर का उपयोग करता है। pnpm चेकआउट के लिए, अपडेटर pnpm कार्यक्षेत्र के अंदर
npm run build चलाने के बजाय आवश्यकता पड़ने पर pnpm को बूटस्ट्रैप करता है (पहले corepack के माध्यम से, फिर अस्थायी npm install pnpm@11 फ़ॉलबैक से)।@beta रिलीज़ आज़माते हैं। यदि Plugin की कोई beta रिलीज़ नहीं है, तो OpenClaw दर्ज किए गए डिफ़ॉल्ट/latest spec पर वापस जाता है और उसे चेतावनी के रूप में रिपोर्ट करता है। npm Plugins के लिए, OpenClaw तब भी वापस जाता है जब beta पैकेज मौजूद हो लेकिन इंस्टॉल सत्यापन में विफल हो जाए। ये Plugin फ़ॉलबैक चेतावनियाँ कोर अपडेट को विफल नहीं करतीं। सटीक संस्करण और स्पष्ट टैग फिर से नहीं लिखे जाते।
अपडेट के बाद की Plugin सिंक विफलताएँ, जो किसी प्रबंधित Plugin तक सीमित हैं और जिन्हें सिंक पथ बायपास कर सकता है (उदाहरण के लिए, किसी गैर-आवश्यक Plugin के लिए अप्राप्य npm registry), कोर अपडेट सफल होने के बाद चेतावनियों के रूप में रिपोर्ट की जाती हैं। JSON परिणाम शीर्ष-स्तरीय अपडेट
status: "ok" रखता है और openclaw update repair तथा openclaw plugins inspect <id> --runtime --json मार्गदर्शन के साथ postUpdate.plugins.status: "warning" रिपोर्ट करता है। अनपेक्षित अपडेटर या सिंक अपवाद अब भी अपडेट परिणाम को विफल करते हैं। Plugin इंस्टॉल या अपडेट त्रुटि ठीक करें, फिर openclaw update repair दोबारा चलाएँ।प्रति-Plugin सिंक चरण के बाद, openclaw update Gateway को फिर से शुरू करने से पहले अनिवार्य पोस्ट-कोर convergence पास चलाता है: यह गायब कॉन्फ़िगर किए गए Plugin payloads की मरम्मत करता है, डिस्क पर हर सक्रिय ट्रैक किए गए इंस्टॉल रिकॉर्ड को सत्यापित करता है, और स्थिर रूप से जाँचता है कि उसका package.json parse किया जा सकता है (और कोई स्पष्ट रूप से घोषित main मौजूद है)। इस पास से आई विफलताएँ — और अमान्य OpenClaw config snapshot — postUpdate.plugins.status: "error" लौटाती हैं और शीर्ष-स्तरीय अपडेट status को "error" में बदल देती हैं, इसलिए openclaw update non-zero के साथ बाहर निकलता है और Gateway को असत्यापित Plugin सेट के साथ फिर से शुरू नहीं किया जाता। त्रुटि में संरचित postUpdate.plugins.warnings[].guidance पंक्तियाँ शामिल होती हैं, जो आगे की कार्रवाई के लिए openclaw update repair और openclaw plugins inspect <id> --runtime --json की ओर संकेत करती हैं। Disabled Plugin entries और ऐसे records जो trusted-source-linked official sync targets नहीं हैं, यहाँ छोड़ दिए जाते हैं, ठीक उसी तरह जैसे missing-payload check द्वारा उपयोग की गई skipDisabledPlugins नीति में होता है, इसलिए कोई stale disabled Plugin record अन्यथा मान्य अपडेट को रोक नहीं सकता।जब अपडेट किया गया Gateway शुरू होता है, Plugin लोडिंग केवल सत्यापन के लिए होती है: startup package managers नहीं चलाता और dependency trees को mutate नहीं करता। Package-manager update.run restarts CLI managed-service path को सौंपे जाते हैं, इसलिए package swap पुराने Gateway process के बाहर होता है और service health checks तय करते हैं कि अपडेट को complete के रूप में report किया जा सकता है या नहीं।यदि pnpm bootstrap फिर भी विफल होता है, तो updater checkout के अंदर npm run build आज़माने के बजाय package-manager-specific error के साथ जल्दी रुक जाता है।--update संक्षिप्त रूप
openclaw --update को openclaw update में फिर से लिखा जाता है (shells और launcher scripts के लिए उपयोगी)।
संबंधित
openclaw doctor(git checkouts पर पहले update चलाने का प्रस्ताव देता है)- विकास चैनल
- अपडेट करना
- CLI संदर्भ