openclaw update

OpenClaw を更新し、stable/extended-stable/beta/dev チャネルを切り替えます。

npm/pnpm/bun 経由でインストールした場合（グローバルインストールで、git メタデータなし）、 更新は更新で説明されているパッケージマネージャーのフローで行われます。

使用方法

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 に書き換えられます（シェルや ランチャースクリプトで便利です）。

オプション

--verbose フラグはありません。予定されている処理のプレビューには --dry-run、 機械可読な結果には --json、チャネル/可用性のみの確認には openclaw update status --json を使用します。Gateway コンソールの詳細度（--verbose）と ファイルログレベル（logging.level: "debug"/"trace"）は独立した設定です。 Gateway のログを参照してください。

update status

有効な更新チャネル、git タグ/ブランチ/SHA（ソースチェックアウトのみ）、 および更新の可用性を表示します。

openclaw update statusopenclaw update status --jsonopenclaw update status --timeout 10

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 による修復が 収束しなかった場合にサポートされる復旧手段です。

openclaw update repairopenclaw update repair --channel betaopenclaw update repair --acknowledge-clawhub-riskopenclaw update repair --json

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 を優先し、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 の遅延／ジッターの使用、beta のポーリング間隔の使用は一切行われません。明示的なフォアグラウンド更新、保存された update.channel: "extended-stable" を使用する引数なしのフォアグラウンド更新、オンデマンドのステータス確認、およびそれらの管理対象 Gateway ハンドオフは引き続きサポートされます。

ローカルの管理対象 Gateway サービスがインストールされ、再起動が有効な場合、パッケージマネージャーおよび git チェックアウトによる更新では、パッケージツリーの置換またはチェックアウト／ビルド出力の変更前に、実行中のサービスを停止します。その後、アップデーターはサービスのメタデータを更新し、サービスを再起動して、再起動後の Gateway を検証してから Gateway: restarted and verified. を報告します。 パッケージマネージャーによる更新では、再起動後の Gateway が想定されるパッケージバージョンを報告することも検証します。git チェックアウトによる更新では、再ビルド後の Gateway の正常性とサービスの準備完了状態を検証します。

パッケージマネージャーによる更新では通常、管理対象サービスに記録された Node バイナリを引き続き使用します。その Node で対象リリースを実行できないものの、現在の CLI の Node では実行でき、サービスが更新対象のパッケージに属することが確認されている場合、再起動が有効な更新では現在の Node を最終処理に使用し、サービスのメタデータをそのランタイムに書き換えます。--no-restart ではサービスのメタデータを修復できないため、同じランタイムの不一致がある場合、パッケージを変更する前に停止します。

macOS では、更新後のチェックで、アクティブなプロファイルの LaunchAgent が読み込まれて実行中であること、および設定されたループバックポートが正常であることも検証します。plist がインストールされているにもかかわらず launchd が監視していない場合、OpenClaw は LaunchAgent を自動的に再ブートストラップし、正常性／バージョン／チャンネルの準備完了チェックを再実行します（新規ブートストラップでは RunAtLoad ジョブを直接読み込むため、復旧処理が新たに起動した Gateway を直ちに kickstart -k することはありません）。それでも Gateway が正常にならない場合、コマンドはゼロ以外で終了し、再起動ログのパスに加えて、再起動、再インストール、パッケージのロールバック手順を出力します。

再起動を実行できない場合、コマンドは手動の openclaw gateway restart ヒントとともに Gateway: restart skipped (...) または Gateway: restart failed: ... を出力します。 --no-restart を使用すると、パッケージの置換または git の再ビルドは引き続き実行されますが、管理対象サービスは停止も再起動もされないため、手動で再起動するまで実行中の Gateway は古いコードを使用し続けます。

コントロールプレーンのレスポンス形式

パッケージマネージャーによるインストールまたは監視対象の git チェックアウトで、update.run が Gateway のコントロールプレーンを通じて実行される場合、ハンドラーは、Gateway の終了後も続行される CLI 更新とは別にハンドオフの開始を報告します。

• 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 は安全なハンドオフに必要な 監視サービス境界と永続的なサービス ID を検出できませんでした （たとえば、systemd のハンドオフには、単に周囲の systemd プロセスマーカーではなく、 OPENCLAW_SYSTEMD_UNIT ユニット ID が必要です）。レスポンスには、 Gateway の外部から実行するシェルコマンドである handoff.command が含まれます。
• ok: false、result.reason: "managed-service-handoff-failed"：Gateway は ハンドオフの作成を試みましたが、デタッチされたヘルパーを起動できませんでした。

sentinel ペイロードは Gateway の終了前に書き込まれ、CLI のハンドオフは、管理対象サービスの再起動後の正常性チェックが完了すると、同じ再起動センチネルを更新します。ハンドオフ中、センチネルには成功時の継続処理なしで stats.reason: "restart-health-pending" が含まれる場合があります。再起動した Gateway はこれをポーリングし、CLI がサービスの正常性を検証し、最終的な ok の結果でセンチネルを書き換えた後にのみ継続処理を実行します。 openclaw status と openclaw status --all は、そのセンチネルが保留中または失敗している間、Update restart 行を表示します。update.status は更新を行い、最新のセンチネルを返します。

Git チェックアウトのフロー

チャンネルの選択

• stable：最新の beta 以外のタグをチェックアウトし、ビルドと doctor を実行します。
• beta：最新の -beta タグを優先し、beta が存在しないか古い場合は最新の stable タグにフォールバックします。
• dev：main をチェックアウトし、その後 fetch と rebase を実行します。
• extended-stable：Git チェックアウトではサポートされておらず、チェックアウトの変更は行われません。

更新手順

Plugin 同期の詳細

beta チャンネルでは、default/latest 系列に従う追跡対象の npm および ClawHub plugin インストールは、最初に plugin の @beta リリースを試行します。plugin に beta リリースがない場合、OpenClaw は記録済みの default/latest 指定にフォールバックし、警告を報告します。npm plugins では、beta パッケージが存在してもインストール検証に失敗した場合も OpenClaw はフォールバックします。これらのフォールバック警告によってコア更新が失敗することはありません。正確なバージョンと明示的なタグが書き換えられることはありません。

extended-stable のコア更新が成功すると、コア更新後の plugin の整合性確認と収束処理では、対象となる公式 npm plugins に、インストール済みコアと完全に同じバージョンを適用します。default/latest の指定では、OpenClaw は plugin の @extended-stable を照会せず、npm の latest にフォールバックもしません。パッケージバージョンはインストール済みコアから導出します。明示的なバージョン固定、明示的な latest 以外のタグ、サードパーティ製パッケージ、npm 以外のソースでは、既存の指定が維持されます。

パッケージマネージャーによるインストールでは、openclaw update はパッケージマネージャーを呼び出す前に対象パッケージのバージョンを解決します。npm のグローバルインストールでは、段階的インストールを使用します。OpenClaw は新しいパッケージを一時的な npm prefix にインストールし、候補パッケージが preinstall 中にホストの Node バージョンを検証できるようにして、そこでパッケージ化された dist インベントリを検証します。パッケージ化完了ガードは preinstall が成功するまでそのインベントリの外部に置かれるため、ライフサイクルスクリプトをスキップするパッケージマネージャーも有効化前に停止します。npm 12 以降では、アップデーターは候補の OpenClaw ライフサイクルのみを許可し、推移的依存関係のスクリプトは引き続きブロックされます。その後、OpenClaw はクリーンなパッケージツリーを実際のグローバル prefix に入れ替えます。検証に失敗した場合、更新後の doctor、plugin の同期、再起動処理は、疑わしいツリーから実行されません。インストール済みバージョンがすでに対象と一致している場合でも、コマンドはグローバルパッケージのインストールを更新し、その後 plugin の同期、コアコマンドの補完情報の更新、再起動処理を実行します。これにより、パッケージ化されたサイドカーとチャンネルが所有する plugin 記録が、インストール済みの OpenClaw ビルドと整合した状態に保たれます。一方、plugin コマンドの補完情報の完全な再ビルドは、明示的な openclaw completion --write-state の実行時にのみ行われます。

関連項目

• openclaw doctor（git チェックアウトで最初に更新を実行するよう提案します）
• 開発チャンネル
• 更新
• CLI リファレンス