Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
openclaw update
Bezpiecznie aktualizuj OpenClaw i przełączaj się między kanałami stable/beta/dev.
Jeśli instalacja została wykonana przez npm/pnpm/bun (instalacja globalna, bez metadanych git),
aktualizacje odbywają się przez przepływ menedżera pakietów opisany w Aktualizowanie.
Użycie
Opcje
--no-restart: pomija ponowne uruchomienie usługi Gateway po udanej aktualizacji. Aktualizacje przez menedżer pakietów, które ponownie uruchamiają Gateway, weryfikują, czy ponownie uruchomiona usługa zgłasza oczekiwaną zaktualizowaną wersję, zanim polecenie zakończy się powodzeniem.--channel <stable|beta|dev>: ustawia kanał aktualizacji (git + npm; zapisywany w konfiguracji).--tag <dist-tag|version|spec>: nadpisuje docelowy pakiet tylko dla tej aktualizacji. Dla instalacji pakietowychmainmapuje się nagithub:openclaw/openclaw#main.--dry-run: pokazuje planowane działania aktualizacji (kanał/tag/cel/przepływ ponownego uruchomienia) bez zapisywania konfiguracji, instalowania, synchronizowania wtyczek ani ponownego uruchamiania.--json: wypisuje czytelny maszynowo JSONUpdateRunResult, w tympostUpdate.plugins.warnings, gdy uszkodzone lub niemożliwe do załadowania zarządzane wtyczki wymagają naprawy po udanej aktualizacji rdzenia, szczegóły awaryjnego użycia wersji wtyczki dla kanału beta, gdy wtyczka nie ma wydania beta, orazpostUpdate.plugins.integrityDrifts, gdy podczas synchronizacji wtyczek po aktualizacji wykryto rozbieżność artefaktu wtyczki npm.--timeout <seconds>: limit czasu na krok (domyślnie 1800 s).--yes: pomija monity o potwierdzenie (na przykład potwierdzenie obniżenia wersji).
openclaw update nie ma flagi --verbose. Użyj --dry-run, aby podejrzeć
planowane działania kanału/tagu/instalacji/ponownego uruchomienia, --json dla czytelnych maszynowo
wyników oraz openclaw update status --json, gdy potrzebujesz tylko szczegółów kanału i
dostępności. Jeśli debugujesz logi Gateway podczas aktualizacji,
szczegółowość konsoli i poziom logowania do pliku są oddzielne: --verbose dla Gateway wpływa na
wyjście terminala/WebSocket, natomiast logi plikowe wymagają logging.level: "debug" lub
"trace" w konfiguracji. Zobacz Logowanie Gateway.
W trybie Nix (
OPENCLAW_NIX_MODE=1) modyfikujące uruchomienia openclaw update są wyłączone. Zamiast tego zaktualizuj źródło Nix lub wejście flake dla tej instalacji; w przypadku nix-openclaw użyj agent-first Szybki start. openclaw update status i openclaw update --dry-run pozostają tylko do odczytu.update status
Pokazuje aktywny kanał aktualizacji + tag/gałąź/SHA git (dla checkoutów źródłowych) oraz dostępność aktualizacji.
--json: wypisuje czytelny maszynowo JSON statusu.--timeout <seconds>: limit czasu dla sprawdzeń (domyślnie 3 s).
update wizard
Interaktywny przepływ wyboru kanału aktualizacji i potwierdzenia, czy ponownie uruchomić Gateway
po aktualizacji (domyślnie ponowne uruchomienie). Jeśli wybierzesz dev bez checkoutu git,
zaproponuje jego utworzenie.
Opcje:
--timeout <seconds>: limit czasu dla każdego kroku aktualizacji (domyślnie1800)
Co robi
Gdy przełączasz kanały jawnie (--channel ...), OpenClaw utrzymuje także
zgodność metody instalacji:
dev→ zapewnia checkout git (domyślnie:~/openclaw, nadpisanie przezOPENCLAW_GIT_DIR), aktualizuje go i instaluje globalny CLI z tego checkoutu.stable→ instaluje z npm przy użyciulatest.beta→ preferuje dist-tag npmbeta, ale wraca dolatest, gdy beta jest brakująca lub starsza niż bieżące wydanie stable.
update.run
wymuszają nieodroczone ponowne uruchomienie aktualizacyjne bez cooldownu po podmianie pakietu,
ponieważ stary proces Gateway nadal może mieć w pamięci fragmenty wskazujące na
pliki usunięte przez nowy pakiet.
W przypadku instalacji przez menedżer pakietów openclaw update rozwiązuje docelową wersję pakietu
przed wywołaniem menedżera pakietów. Globalne instalacje npm używają instalacji etapowej:
OpenClaw instaluje nowy pakiet w tymczasowym prefiksie npm, weryfikuje
spis zapakowanego dist, a następnie podmienia to czyste drzewo pakietu na
rzeczywisty prefiks globalny. Jeśli weryfikacja się nie powiedzie, doctor po aktualizacji, synchronizacja wtyczek i
ponowne uruchomienie nie są wykonywane z podejrzanego drzewa. Nawet gdy zainstalowana wersja
już odpowiada celowi, polecenie odświeża globalną instalację pakietu,
a następnie uruchamia synchronizację wtyczek, odświeżenie uzupełnień poleceń rdzenia i ponowne uruchomienie. Dzięki temu
spakowane sidecary i rekordy wtyczek należące do kanału pozostają zgodne z
zainstalowaną kompilacją OpenClaw, a pełne przebudowy uzupełnień poleceń wtyczek pozostają
dla jawnych uruchomień openclaw completion --write-state.
Gdy zainstalowana jest lokalna zarządzana usługa Gateway i włączono ponowne uruchomienie,
aktualizacje menedżera pakietów zatrzymują działającą usługę przed zastąpieniem drzewa pakietu,
następnie odświeżają metadane usługi ze zaktualizowanej instalacji, ponownie uruchamiają
usługę i weryfikują, czy ponownie uruchomiony Gateway zgłasza oczekiwaną wersję przed
zgłoszeniem powodzenia. W systemie macOS sprawdzenie po aktualizacji weryfikuje także, czy LaunchAgent
jest załadowany/uruchomiony dla aktywnego profilu oraz czy skonfigurowany port loopback
jest zdrowy. Jeśli plist jest zainstalowany, ale launchd go nie nadzoruje, OpenClaw
automatycznie ponownie bootstrapuje LaunchAgent, a następnie ponownie uruchamia
sprawdzenia gotowości zdrowia/wersji/kanału. Świeży bootstrap ładuje zadanie RunAtLoad
bezpośrednio, więc odzyskiwanie aktualizacji nie wykonuje natychmiast kickstart -k na nowo
uruchomionym Gateway. Jeśli Gateway nadal nie stanie się zdrowy, polecenie kończy się
kodem różnym od zera i wypisuje ścieżkę logu ponownego uruchomienia oraz jawne instrukcje ponownego uruchomienia, ponownej instalacji i
wycofania pakietu. Z --no-restart
zastąpienie pakietu nadal jest wykonywane, ale zarządzana usługa nie jest zatrzymywana ani
ponownie uruchamiana, więc działający Gateway może zachować stary kod, dopóki nie uruchomisz go ponownie
ręcznie.
Przepływ checkoutu git
Wybór kanału
stable: wykonuje checkout najnowszego tagu nie-beta, a następnie build i doctor.beta: preferuje najnowszy tag-beta, ale wraca do najnowszego tagu stable, gdy beta jest brakująca lub starsza.dev: wykonuje checkoutmain, a następnie fetch i rebase.
Kroki aktualizacji
Build preflight (tylko dev)
Uruchamia build TypeScript w tymczasowym worktree. Jeśli tip się nie powiedzie, cofa się maksymalnie o 10 commitów, aby znaleźć najnowszy commit możliwy do zbudowania. Ustaw
OPENCLAW_UPDATE_PREFLIGHT_LINT=1, aby podczas tego preflight uruchomić także lint; lint działa w ograniczonym trybie szeregowym, ponieważ hosty aktualizacji użytkowników są często mniejsze niż runnerzy CI.Instalacja zależności
Używa menedżera pakietów repozytorium. Dla checkoutów pnpm aktualizator bootstrapuje
pnpm na żądanie (najpierw przez corepack, potem awaryjnie przez tymczasowe npm install pnpm@11) zamiast uruchamiać npm run build wewnątrz workspace pnpm.@beta. Jeśli wtyczka nie ma
wydania beta, OpenClaw wraca do zapisanej domyślnej/najnowszej specyfikacji i zgłasza
to jako ostrzeżenie. Dla wtyczek npm OpenClaw wraca także wtedy, gdy pakiet beta
istnieje, ale nie przejdzie walidacji instalacji. Te ostrzeżenia o awaryjnym wyborze wtyczek nie
powodują niepowodzenia aktualizacji rdzenia. Dokładne wersje i jawne tagi nie są
przepisywane.
Niepowodzenia synchronizacji wtyczek po aktualizacji, które są ograniczone do zarządzanej wtyczki i które ścieżka synchronizacji może obejść (np. niedostępny rejestr npm dla nieistotnej wtyczki), są zgłaszane jako ostrzeżenia po udanej aktualizacji rdzenia. Wynik JSON zachowuje najwyższy poziom aktualizacji
status: "ok" i zgłasza postUpdate.plugins.status: "warning" ze wskazówkami openclaw doctor --fix oraz openclaw plugins inspect <id> --runtime --json. Nieoczekiwane wyjątki aktualizatora lub synchronizacji nadal powodują niepowodzenie wyniku aktualizacji. Napraw instalację wtyczki lub błąd aktualizacji, a następnie uruchom ponownie openclaw doctor --fix albo openclaw update.Po kroku synchronizacji per wtyczka openclaw update uruchamia obowiązkowy przebieg konwergencji po rdzeniu przed ponownym uruchomieniem gateway: naprawia brakujące skonfigurowane payloady wtyczek, waliduje każdy aktywny śledzony rekord instalacji na dysku i statycznie weryfikuje, czy jego package.json jest parsowalny (oraz czy istnieje jawnie zadeklarowany main, jeśli podano). Niepowodzenia z tego przebiegu — oraz nieprawidłowy snapshot konfiguracji OpenClaw — zwracają postUpdate.plugins.status: "error" i przełączają najwyższy poziom aktualizacji status na "error", więc openclaw update kończy się kodem różnym od zera, a gateway nie jest ponownie uruchamiany z niezweryfikowanym zestawem wtyczek. Błąd zawiera strukturalne wiersze postUpdate.plugins.warnings[].guidance wskazujące na openclaw doctor --fix i openclaw plugins inspect <id> --runtime --json jako dalsze kroki. Wyłączone wpisy wtyczek oraz rekordy, które nie są oficjalnymi celami synchronizacji powiązanymi z zaufanym źródłem, są tutaj pomijane, odzwierciedlając zasadę skipDisabledPlugins używaną przez sprawdzanie brakujących payloadów, więc przestarzały wyłączony rekord wtyczki nie może zablokować poza tym prawidłowej aktualizacji.Gdy zaktualizowany Gateway startuje, ładowanie wtyczek jest tylko weryfikacyjne: start nie uruchamia menedżerów pakietów ani nie modyfikuje drzew zależności. Ponowne uruchomienia update.run menedżera pakietów omijają normalne odroczenie bezczynności i cooldown ponownego uruchomienia po podmianie drzewa pakietu, więc stary proces nie może dalej lazy-loadować usuniętych fragmentów.Jeśli bootstrap pnpm nadal się nie powiedzie, aktualizator zatrzymuje się wcześnie z błędem specyficznym dla menedżera pakietów zamiast próbować npm run build wewnątrz checkoutu.Skrót --update
openclaw --update przepisuje się na openclaw update (przydatne dla powłok i skryptów uruchamiających).
Powiązane
openclaw doctor(proponuje najpierw uruchomić aktualizację na checkoutach git)- Kanały deweloperskie
- Aktualizowanie
- Dokumentacja CLI