Update Approval Guard
This skill turns automatic updating into a safer two-step workflow:
- Scheduled check: inspect for OpenClaw and installed skill updates, save a pending plan, and ask the user for approval.
- Approved apply: only after the user explicitly confirms, execute the update commands and report the result.
Never apply updates automatically during the scheduled check.
When to use
Use this skill when the user asks to:
- schedule update checks for OpenClaw or installed skills
- review available updates before applying them
- require human approval before running update commands
- keep production instances stable while still checking daily for updates
Hard rules
- Never execute real update commands during the scheduled check.
- Never apply updates without explicit user confirmation.
- If there is no valid pending update plan, do not run updates.
- If the plan is expired, do not run updates. Ask the user to run a fresh check.
- Keep all state under the workspace data directory.
- Prefer dry-run or inspection commands for checks.
- After approved updates, always run a health check.
- Be transparent. Summarize what will change before asking for approval.
- If a command fails, stop and report clearly.
State directory
Store data under:
<workspace>/data/update-approval-guard/
Use these files:
pending-update.jsonhistory.json
Pending plan shape
Use this structure for pending-update.json:
{
"createdAt": "2026-03-13T00:00:00+08:00",
"expiresAt": "2026-03-14T00:00:00+08:00",
"status": "pending_confirmation",
"summary": "Detected 1 OpenClaw update and 2 skill updates.",
"openclaw": {
"current": "2026.3.8",
"latest": "2026.3.9",
"hasUpdate": true
},
"skills": [
{
"name": "some-skill",
"current": "1.0.0",
"latest": "1.0.1",
"hasUpdate": true
}
],
"approved": false,
"approvedAt": null,
"approvedBy": null
}
Scheduled check behavior
When the user asks to enable the daily scheduled check, create an isolated cron job that runs every day at 00:00 Asia/Shanghai.
The scheduled job must do the following:
- Ensure
<workspace>/data/update-approval-guard/ exists.
- Check whether a non-expired pending plan already exists.
- If a non-expired pending plan already exists, do not overwrite it. Inform the user that approval is still pending.
- Inspect whether OpenClaw has an available update.
- Inspect whether installed skills have available updates.
- If there are no updates, report that everything is current and do not create a pending plan.
- If updates are found, create
pending-update.json with a 24-hour expiry.
- Mark the plan as
pending_confirmation.
- Send a concise summary and ask the user to confirm.
- Do not run any real update command in this phase.
Recommended scheduled cron message
Use wording equivalent to:
Check for updates to OpenClaw and all installed skills.
Rules:
1. Run check-only commands. Do not apply updates automatically.
2. Create <workspace>/data/update-approval-guard/pending-update.json only when updates are found.
3. Include current version, latest version, and whether each item has an update.
4. Set status to pending_confirmation and expiry to 24 hours after creation.
5. If a non-expired pending plan already exists, keep it and report that approval is still pending.
6. If there are no updates, report that everything is current.
7. Ask the user to confirm before any update can be executed.
8. Never run the actual update command during this scheduled check.
User approval behavior
When the user sends an approval message such as:
确认执行更新确认更新批准更新approve updatesapply pending updates
perform this workflow:
- Read
<workspace>/data/update-approval-guard/pending-update.json.
- Verify the file exists.
- Verify status is
pending_confirmation.
- Verify the plan has not expired.
- Verify there is at least one update to apply.
- Record approval metadata.
- Execute the real update commands.
- Run
openclaw doctor after updates.
- Append a result entry to
history.json.
- Mark the pending plan as
completed or failed.
- Return a clear summary of what changed.
If there is no pending plan, say there is nothing to approve.
If the plan is expired, say it expired and a fresh check is required.
Command strategy
The local command available on this machine is openclaw.
Use the following command policy.
Check phase
Use safe inspection commands only.
For skills:
clawhub update --all --dry-run
For OpenClaw:
- Prefer a non-mutating version or update-check command if available in the local installation.
- If there is no dedicated check-only command, inspect the locally installed version and compare it using the safest available non-mutating mechanism.
- Do not upgrade OpenClaw during the scheduled phase.
Apply phase
Only after explicit approval, use the real update commands.
For skills:
clawhub update --all
For OpenClaw:
- Use the real update command that matches the local installation method.
- If
openclaw update is available in the environment, use it.
- If the installation uses npm or another package manager, use the correct local update procedure.
Post-update health check
After approved updates:
openclaw doctor
If a safe fix mode is explicitly requested and supported, you may use it. Otherwise prefer the plain health check.
Cron defaults
When the user asks to set up the schedule and does not specify otherwise, use:
- time:
00:00
- timezone:
Asia/Shanghai
- session target:
isolated
- delivery:
announce
- light context:
true for routine checks unless the job clearly needs full bootstrap context
Suggested cron configuration
Use the Cron Jobs capability with settings equivalent to:
- name:
Daily Update Approval Check
- schedule:
0 0 * * *
- timezone:
Asia/Shanghai
- sessionTarget:
isolated
- payload.kind:
agentTurn
- delivery.mode:
announce
- payload.lightContext:
true
Human-facing summaries
Updates found
Use wording like:
检测到 OpenClaw 本体和已安装 skills 的可用更新，已生成待更新计划，默认不会自动执行。若需执行，请回复：确认执行更新
No updates
Use wording like:
当前 OpenClaw 与已安装 skills 均为最新版本，无需更新。
Approval success
Use wording like:
已根据你的确认执行更新。OpenClaw 更新状态：成功。Skill 更新状态：成功。健康检查已完成。
Plan expired
Use wording like:
待更新计划已过期，未执行任何更新。请先重新检查更新。
Failure handling
If any step fails:
- Stop immediately.
- Record the failure in
history.json.
- Report the exact failing step.
- Never claim success when updates were not fully applied.
Common failure causes:
- no network
- permission denied
- clawhub missing
- update command unavailable
- pending plan missing
- pending plan expired
- doctor failed
Design intent
This skill is intentionally conservative. It is meant for operators who want the visibility of automatic update checks but want to keep change approval in human hands.
