OpenClaw Main Replaces Surprise Auto-Updates with Scheduled Campaigns

OpenClaw has merged a substantial rewrite of automatic-update timing into main. Instead of applying an update as soon as it becomes due, the Gateway will create an update campaign, wait for idle work, show a countdown and expose a one-shot hold.

This is a meaningful availability-policy change, not merely a new settings screen. It is merged source work, not evidence that your installed release already behaves this way. Check the exact package notes before relying on it.

The new timing contract

PR #120506 defines the campaign sequence:

• while active work exists, the campaign reports waiting-for-idle;
• once the Gateway is idle, a one-minute countdown begins;
• a 15-minute hard deadline eventually forces the update, using the existing drain and session-recovery path;
• an administrator can use a one-shot Hold 1 h action, which moves the forced deadline behind the hold;
• Update now adopts the same campaign rather than starting a competing apply;
• a failed apply clears its campaign instead of leaving the UI stuck on “Updating…”.

The design is process-local. Durable recovery still depends on the restart sentinel and the existing session-recovery machinery. In plain English: the countdown is coordination, not a transactional guarantee that every workload reached a perfect checkpoint.

Source checkouts join automatic updating

The change also adds hourly upstream checks for git installations configured on update.channel: "dev". The campaign freezes the selected upstream commit and can show up to five pending commit subjects before applying it. External-supervisor mode continues to refuse automatic application.

That is useful for managed development Gateways, but it changes the risk profile. A dev checkout is no longer necessarily a manually advanced environment. If automatic updates are enabled, a source install can move after the same idle/countdown process as packaged installations.

Interpretation: dev auto-update is suitable for disposable or tightly observed environments, not an excuse to let an unreviewed production checkout follow main blindly. A short list of commit subjects is a change preview, not a dependency, migration or behavioural audit.

The control surface is finally explicit

A new Updates page is designed to show build facts, release channel, automatic-update policy, campaign timing and pending git commits. Stable, beta and dev are normal choices; extended-stable appears when already configured. Non-admin users receive a read-only view.

The corresponding protocol additions are additive: schedule state is included in update status and availability events, while the hold operation requires admin scope. Detailed update metadata is restricted to read-capable clients rather than being exposed to pairing-only or node clients.

What operators should decide now

Before adopting a release containing this change, answer four questions:

1. Can any run exceed the forced window? If important turns routinely last more than 15 minutes, prove drain and recovery with that workload rather than assuming “active” means indefinitely protected.
2. Who may hold or accelerate an update? The actions are administrative. Confirm that role assignment matches your operating model.
3. Should dev checkouts move automatically? Disable that path where commit review or maintenance windows are mandatory.
4. Who owns the supervisor? An external process manager and OpenClaw’s own campaign must not both believe they control replacement timing.

A practical test plan

Use a non-production Gateway when the feature reaches your channel:

• begin a synthetic long-running turn, announce an available update and confirm the campaign waits;
• let the Gateway become idle and verify the countdown appears;
• use the one-hour hold once and confirm a second hold is refused;
• force a harmless failed apply and verify the campaign clears visibly;
• on a git fixture, verify the applied commit equals the campaign’s frozen target;
• restart during a synthetic turn and confirm recovery is visible rather than silently losing the run.

Do not perform the first test with a consequential automation. The hard deadline exists specifically so busy work cannot postpone updates forever.

Bottom line

Scheduled campaigns are a better default than surprise restarts, but the 15-minute deadline is still a policy decision. Treat the release that ships it as an availability change: review admin ownership, dev-channel consent, supervisor boundaries and your longest real run before enabling automatic movement.