v1.4.15: openclaw-update wrapper

Added

• openclaw-update wrapper — single-command update flow for OpenClaw 2026.5+. Runs openclaw update, then approves the post-restart self scope-upgrade pending via openclaw-pair-latest, then verifies via openclaw gateway status --deep. Trust model identical to the helper: only the CLI's own self scope-upgrade is approved; no external device is admitted automatically. Available at /usr/local/bin/openclaw-update. The user-visible payoff: the Gateway did not become healthy after restart + Capability: pairing-pending symptom that plagued openclaw update on freshly-installed 2026.5.x state (and on upgrades carrying legacy device tokens from earlier 2026.5 releases) now resolves automatically without the user having to know about pending.json or the chicken-and-egg Direct scope access failed; using local fallback. path.
• First-boot self scope-upgrade approval in entrypoint.sh. After the gateway settles, entrypoint runs openclaw-pair-latest once as the runtime user. Falls back silently when there's nothing pending (so re-runs and already-paired container restarts are safe). Surfaces a one-line status: Pairing : self scope-upgrade approved (gateway healthy) or Pairing : nothing pending (already healthy). The fresh container thus boots straight into a healthy Capability: read-only state instead of pairing-pending.

Changed

• openclaw-pair-latest extended to handle scope-upgrade case. Previously the helper only knew the first-time pairing log line (reason=pairing required ... (requestId: <uuid>)). The 2026.5.x scope-upgrade emit has a different shape (security audit: device access upgrade requested ... conn=<uuid>), and the helper was silently skipping it — leaving openclaw update users stuck in the post-restart pending-pending loop after every minor upgrade. The helper now reads ~/.openclaw/devices/pending.json directly (gateway's own source of truth, schema-stable across versions) and falls back to the log-grep path only when the state file doesn't exist (pre-2026.5 OpenClaw). One helper, two cases, same trust boundary. Investigation traced this gap by reproducing the user-visible symptom in a fresh v1.4.14 container and inspecting the gateway's ~/.openclaw/devices/ state directory directly — the actual stuck-state diagnostic surface that wasn't visible from the CLI's own status output.
• READMEs (EN/KO/JA/ZH) document the new wrapper as the standard update flow and add a "scope upgrade pending approval" troubleshooting entry for users who run openclaw update directly without the wrapper. DOCKERHUB_OVERVIEW.md Updating section rewritten to lead with the wrapper.

Fixed

• Remaining dashboard hints now use http://127.0.0.1:18789/. v1.4.14 aligned xdg-open and openclaw dashboard, but entrypoint startup output and the default openclaw.json comment still advertised localhost. Those hints could send users back into the stale localhost origin and recreate the double-pairing confusion. Updated runtime output, config comments, and README troubleshooting/config text to consistently point at the 127.0.0.1 origin.

Discussion

• Why a wrapper for what's essentially "run two commands in a row"? Because the second command's existence isn't obvious unless you've debugged the first one's Gateway did not become healthy after restart message — and the average user reads that as "update broken," not "now run the helper." The wrapper makes openclaw update mean what users expect it to mean on first read, while keeping the manual-approve trust boundary intact (the wrapper just invokes the same helper the user could run by hand). Same reasoning that motivated openclaw-pair-latest itself in v1.4.13.
• Did we consider patching upstream OpenClaw instead? Briefly. Upstream's self-scope-upgrade-needs-manual-approve is documented as intentional ("by design no path lets a device auto-approve its own scope upgrade"), and changing that would weaken the security posture for everyone. The wrapper sits squarely in container-image territory — a convenience layer that respects upstream policy.