openclaw/docs/cli/update.md

summary	read_when	title
CLI reference for `openclaw update` (updates, repair, and recovery cleanup)	You want to update a source checkout safely You are debugging `openclaw update` output or options You want to inspect or retire migration recovery originals after an update You need to understand `--update` shorthand behavior	Update

openclaw update

Update OpenClaw and switch between stable/extended-stable/beta/dev channels.

If you installed via npm/pnpm/bun (global install, no git metadata), updates go through the package-manager flow described in Updating.

Custom npm prefixes such as ~/.npm-global are recognized from npm's configured prefix and the installed OpenClaw launcher. A prefix configured in ~/.npmrc does not need a matching NPM_CONFIG_PREFIX environment variable. If no owner can be identified, the CLI includes the inspected package, prefix, and launcher paths and the package-manager probe results in its guidance.

An older updater that stops before staging cannot use this repair. For a known npm installation, supply its configured prefix explicitly for that update: NPM_CONFIG_PREFIX="$(npm prefix -g)" openclaw update.

An installation without a detected package-manager owner records a skipped update, exits successfully, and leaves the Gateway running. For Docker/container images, pull or build the new image and recreate the container with the same state/config mounts. For a standalone or extracted tarball installation, reinstall using the original method; Yarn global installations must be updated with Yarn. The CLI displays this next action. Existing profiles also record it in update history and include it in JSON as run.origin.nextAction. With --json, a fresh profile emits the guidance to stderr and does not create a state database for a skipped update. These non-outcomes do not run rollback verification or offer an update failure report.

Usage

openclaw update
openclaw update status
openclaw update repair
openclaw update cleanup --dry-run
openclaw update wizard
openclaw update --channel extended-stable
openclaw update --channel beta
openclaw update --channel dev
openclaw update --tag beta
openclaw update --dry-run
openclaw update --no-restart
openclaw update --yes
openclaw update --accept-capabilities
openclaw update --json
openclaw --update

openclaw --update rewrites to openclaw update (useful for shells and launcher scripts).

Update admission recognizes orphan task_delivery_state rows whose parent tasks are missing as repairable. When it can acquire Doctor's ownership fences, it runs the same preservation-first recovery before creating update history. Recovery and its ledger entry commit together; the entry records the row count and recovery directory. A live Gateway owner, read-only store, or failed preservation prevents repair and reports openclaw doctor --fix as the next action. Other foreign-key violations and structural damage still refuse admission. --dry-run reports the repairable condition without recovering rows or creating an update ledger entry for that refused preview.

The installed 2026.9.4 updater cannot use this recovery before updating itself. If it refuses with a database integrity error, install the corrective release manually and run openclaw doctor --fix.

Failed update and repair attempts enter recovery triage after service recovery and cleanup finish. A verified rollback does not automatically start triage: the previous generation is running again, and the report keeps the failing check as the reason. An interactive update offers the diagnose/report menu with Exit selected by default. Declining or cancelling preserves the failed update's nonzero exit status. JSON, non-interactive, --yes, and managed-service handoff invocations do not prompt after rollback.

After a final interactive update failure, Diagnose update failure and Report update failure are separate choices. Reporting first shows the exact sanitized issue body and defaults confirmation to No. After confirmation, OpenClaw checks the GitHub CLI's active github.com account with a silent, read-only request before issue creation. Fallback and pending outcomes retain the sanitized report locally; a confirmed issue keeps only its durable issue URL. If the CLI is missing or that check cannot confirm authentication, OpenClaw provides a prefilled issue link without starting issue creation. If the exact report exceeds the browser URL limit, OpenClaw keeps the sanitized body locally and returns to the action menu, where reporting can be chosen and confirmed again. A report preparation or submission error also returns to that menu; Diagnose runs only when selected explicitly. In the Control UI, an interrupted pre-create preparation becomes retryable after its local reservation expires. After an uncertain creation result, OpenClaw checks for an issue matching the exact report. If neither a verified issue URL nor a definitive rejection is available, the report stays pending with no replay link because an issue may already exist. --yes, --json, non-interactive runs, and managed-service handoffs never submit a report.

Automation and SSH

For an authorized update on another host, use the target installation's owning account and a non-interactive SSH command:

ssh -T user@gateway-host 'openclaw update --yes' </dev/null

Ensure openclaw resolves to the intended installation in that account's SSH environment. Add the existing global --profile <name> before update when targeting a named profile.

An active chat session alone does not prevent an explicit update. --yes skips confirmation and optional shell-completion prompts. Without it, ordinary upgrades can still run with piped input, but an operation requiring confirmation, such as a downgrade, fails promptly. Failure-report menus and triage consent prompts do not wait for input when stdin is not a terminal. --yes does not grant exec approval or accept changed plugin capabilities.

An agent updating the Gateway that hosts its own session should use the gateway tool's update.run action when available. The SSH recipe is for another host; verify that the destination is not that same Gateway. Normal execution approvals and deployment ownership still apply.

Native service commands during updates

Native service install, restart, and stop commands launched by the updater through the target CLI retain the original update owner while their child processes settle. A command whose owner exits or loses its lease cannot start another native mutation or commit its pending config changes. A new update remains excluded while a registered child or its process group is still alive.

The target runtime must support this ownership handoff. Candidate validation checks that support before stopping the Gateway or activating its replacement. A missing target CLI or an older target without support is refused; the updater does not invoke the old runtime installer as a substitute. Authorized installation-root changes bind the destination CLI separately while retaining the original update owner. Update-owned commands also refuse unmanaged restart/stop and detached restart or Windows Startup-folder fallbacks that cannot retain this ownership. Ordinary user-invoked openclaw gateway commands keep their existing behavior.

This target-CLI protection does not cover every Doctor or plugin child, the in-process service preparation before package mutation, or the separate deferred-install activation checks.

Options

Updater-managed openclaw update finalize runs repair Doctor without a separate per-Doctor deadline, including post-plugin repair. The enclosing activation deadline still applies. An explicit --timeout <seconds> limits each finalization phase and its child commands. Admission and config phases scale with shared SQLite state. Post-plugin config validation and readiness checks use the measured shared and agent database sizes after Doctor finishes, including WAL files. Serial plugin operations retain individual deadlines within the enclosing activation budget. That budget uses the measured database sizes, observed candidate startup, plugin count, and the caller's step allowance. Migrated finalization receives the same allowance; it does not choose a separate default. Expiry reports update-activation-timeout and retains ownership until writers settle; it does not authorize rollback or restart. Use openclaw update status and Doctor for recovery guidance.

Flag	Description
--no-restart	Skip restarting the Gateway service after a successful update. Package-manager updates that do restart verify the restarted service reports the expected version before the command succeeds.
--channel <stable|extended-stable|beta|dev>	Set the update channel and persist it after core update success. Extended-stable is package-only.
--tag <dist-tag|version|spec>	Override the package target for this update only. It cannot be combined with an effective extended-stable channel, whose verified exact target is mandatory. Package installs reject the main shorthand; use --channel dev for the supported checkout and build flow. Other explicit package specs keep their package-manager behavior.
--dry-run	Preview planned actions (channel/tag/target/restart flow) without writing config, installing, syncing plugins, or restarting.
--json	Print machine-readable UpdateRunResult JSON. Includes postUpdate.plugins.warnings when a managed plugin needs repair, beta-channel plugin fallback details, and postUpdate.plugins.integrityDrifts when npm plugin artifact drift is detected during post-update sync.
--timeout <seconds>	Per-step timeout. Default 1800.
--yes	Skip confirmation prompts (for example downgrade confirmation).
--reapply-local-overrides	Replay trusted local packaged dist edits when the new package has the same baseline. Otherwise preserve them for manual recovery.
--accept-capabilities	Accept each plugin's reviewed capability changes during post-update sync. This acknowledges the exact staged capability surface; it does not disable capability checks or establish future trust.

There is no --verbose flag. Use --dry-run to preview planned actions, --json for machine-readable results, and openclaw update status --json for channel, availability, and the latest durable update report. Gateway console verbosity (--verbose) and file log level (logging.level: "debug"/"trace") are independent knobs; see Gateway logging.

Interactive updates show phase transitions, the current step, and elapsed time. The phases match the Control UI: requested, staging, validating, optional repairing, activating, restarting, verifying, and finished. When output is piped or captured in a log, progress prints without animation. repairing can follow failed candidate validation or failed post-activation verification when rollback is unsafe or has failed; successful repair returns to validation or verification. The Control UI shows this optional phase only after it starts. Failed steps include the final diagnostics from both output streams; timeouts are labeled explicitly. The final report includes the outcome, recorded phase durations, failed steps, verification facts, and recovery guidance. --json keeps stdout machine-readable and does not print progress steps.

When switching from a dev checkout to a package, the updater replaces npm's install link and leaves the external checkout untouched. If activation fails, restoring that link and its launchers does not verify the mutable checkout's runtime. Recovery stays unverified and does not authorize an automatic restart; inspect the checkout and recovery report before restarting it.

For a profile without a runtime database, an older npm target initializes its compatible state before the updater records history. The selected release's Doctor runs before activation, including when npm's install hooks already created the database. Existing databases retain their downgrade protections.

Explicit package specs on a fresh profile first stage with a temporary OpenClaw profile. The updater inspects the staged runtime's declared schema and Node requirements before admitting changes to the selected profile. Artifacts without declared schema support are refused without creating the profile's runtime database. Preparation uses the original package spec and owning package manager.

A fresh-profile --dry-run leaves the database absent and does not record a run. If package metadata cannot be resolved, retry with an exact published --tag; failed target selection does not initialize the profile with the updater's schema.

--yes also skips the optional shell-completion setup prompt. Existing completion profiles and caches are still repaired when needed; installing completion in a new shell profile remains an interactive choice.

--tag changes only this package update. A saved update.channel continues to govern later foreground and automatic updates, even after a one-off beta install. Use --channel to change that policy.

For explicit package artifacts, configured plugin availability is checked against the privately staged package version before rehearsal or activation. --dry-run does not stage the artifact and reports that this check remains pending.

Managed update handoffs preserve the selected artifact, including already-current repeats, so target checks use that artifact's database schema and runtime requirements.

For source checkouts, --dry-run previews the update flow without fetching Git refs or checking working-tree changes. The real update checks for uncommitted changes before modifying the checkout. Use openclaw update status to inspect the current branch, version, and update availability.

In Nix mode (`OPENCLAW_NIX_MODE=1`), mutating `openclaw update` runs are disabled. Update the Nix source or flake input for this install instead; for nix-openclaw, use the agent-first [Quick Start](https://github.com/openclaw/nix-openclaw#quick-start). `openclaw update status` remains read-only. `openclaw update --dry-run` previews the flow without changing the installation. It records a skipped run only when the profile already has a runtime database. Downgrades require confirmation because older versions can break configuration. If the install has already migrated sessions to SQLite, restore archived legacy transcript artifacts before starting an older file-backed version. See [Doctor: Downgrading after session SQLite migration](/cli/doctor#downgrading-after-session-sqlite-migration).

update wizard

Interactive flow to pick an update channel and confirm whether to restart the Gateway afterward (defaults to restart). Selecting dev without a git checkout offers to create one.

The channel picker reads the local install identity without checking Git freshness or dependencies. Those checks run when you apply the update; use openclaw update status to inspect availability first.

Flag	Default	Description
--timeout <seconds>	1800	Timeout for each update step.
--accept-capabilities	false	Accept reviewed plugin capability changes during the update.

Detailed topics

`update status`, the durable run ledger, and the reports each run writes. Triage after a failed update, `update repair`, and `update cleanup`. Channel switching, validation, restart handoff, and the Git checkout flow.

• Recover a failed update
• update status
• Run history and reports
• update repair
• update cleanup
• What it does
• Validation and activation
• Recovery limits
• Compatibility-checked package rollback
• Restart handoff
• Control-plane response shape
• Git checkout flow
• Channel selection
• Update steps
  • Verify clean worktree
  • Resolve the target
  • Build a candidate
  • Validate the candidate
  • Activate and verify
  • Sync plugins
• Plugin sync details

Related

• openclaw doctor (offers to run update first on git checkouts)
• Development channels
• Updating
• CLI reference