OpenClaw Safe Change Flow

Safe OpenClaw config change workflow with backup, minimal edits, validation, health checks, and rollback. Single-instance first; secondary instance optional.

Security Scan

The skill's files and instructions are consistent with a safe change/rollback workflow for OpenClaw; it contains a helper script that makes backups, runs user-supplied edit scripts, validates, and rolls back on failure — nothing in the package appears disproportionate or unrelated to that purpose.

Purpose & Capability

The skill is aligned with its stated purpose (safe config changes and rollback). Minor inconsistency: the registry metadata lists no required binaries, but both SKILL.md and safe-change.sh assume an 'openclaw' CLI and standard UNIX tools (bash, cp, date, id, launchctl on macOS). This is expected for this task but the dependency on the OpenClaw CLI is implicit and should be confirmed before use.

Instruction Scope

SKILL.md and safe-change.sh stay within the stated scope: backup, run a provided edit script, validate (openclaw status/health), and rollback. The script intentionally executes user-provided scripts (bash "$MAIN_SCRIPT"), so those scripts can perform arbitrary actions — this is by design but means you must review the edit scripts before running. The script also restarts the gateway and optionally uses launchctl to kickstart a service (macOS-specific behavior).

Install Mechanism

Instruction-only skill with no install spec and a small included shell script. Nothing is downloaded or written to disk by an installer; the only file is safe-change.sh and it's executed locally — low install risk.

Credentials

No required credentials are declared. The script accepts optional environment overrides (SECONDARY_TOKEN, SECONDARY_URL, SECONDARY_HOME, MAIN_CFG) which are appropriate for the optional dual-instance flow. Requiring SECONDARY_TOKEN when using a secondary instance is reasonable and limited in scope.

Persistence & Privilege

The skill does not request persistent platform privileges (always:false). It does perform service restarts and writes/restores config backups under the user's home directory, which is appropriate for a config-change helper and limited to OpenClaw-related files.

Assessment

This skill is coherent and appears to do what it says, but take these precautions before installing/using it: (1) Verify you have the OpenClaw CLI on PATH (openclaw status/gateway commands) because the script assumes it. (2) Inspect any edit scripts (edit-main.sh / edit-secondary.sh / underlying python scripts) before running — safe-change.sh will execute them with bash, so they can run arbitrary commands. (3) If you enable secondary checks, provide SECONDARY_TOKEN only when needed and keep it secret. (4) Be aware the script will restart the OpenClaw gateway and may call launchctl on macOS; run this in a maintenance window if production impact is possible. (5) Confirm backups are created in the expected path and test the rollback path in a safe environment before using in production.

Goal: avoid outages, keep rollback ready, verify every change. Use single-instance mode by default. Secondary-instance checks are optional.

---

Scope

Default (recommended): single instance

• Main config: ~/.openclaw/openclaw.json

Optional (advanced): dual instance

• Secondary config: ~/.openclaw-secondary/openclaw.json (or your custom path)

If you do not need high-availability validation, single-instance flow is enough.

---

Required single-instance flow

1. Backup first
   • Create timestamped backup: *.bak.safe-YYYYmmdd-HHMMSS
2. Make minimal edits
   • Change only necessary keys
3. Validate immediately
   • Run: openclaw status --deep
4. Auto rollback on failure
   • Restore backup and restart gateway
5. Confirm availability
   • Verify channels/interfaces respond correctly

---

Agent execution convention (default behavior)

After this skill is installed, treat this as default policy for config changes:

• Default entrypoint: run config changes through safe-change.sh
• Avoid direct edits + bare restart
• If user explicitly asks to bypass: allow it, but warn about risk

Mental model:

• Before: edit config directly
• Now: create a small edit script and run safe-change.sh --main-script ./edit-main.sh

---

Optional dual-instance enhancement

On top of single-instance flow, you may also verify a secondary instance:

• OPENCLAW_HOME=<secondary-home> openclaw gateway health --url <secondary-url> --token "$SECONDARY_TOKEN"
• If either instance validation fails, rollback

Use this only when change risk is high or HA checks are required.

---

Automation script (v1.0.2+)

This skill includes safe-change.sh to enforce:

backup → change → validate → rollback on failure

Recommended: single-instance usage

cat > ./edit-main.sh <<'SH'
#!/usr/bin/env bash
python3 edit_main.py
SH
chmod +x ./edit-main.sh

./safe-change.sh --main-script ./edit-main.sh

Optional: dual-instance usage

cat > ./edit-main.sh <<'SH'
#!/usr/bin/env bash
python3 edit_main.py
SH
chmod +x ./edit-main.sh

cat > ./edit-secondary.sh <<'SH'
#!/usr/bin/env bash
python3 edit_secondary.py
SH
chmod +x ./edit-secondary.sh

export SECONDARY_TOKEN="<your-secondary-token>"
./safe-change.sh \
  --main-script ./edit-main.sh \
  --secondary-script ./edit-secondary.sh

When secondary checks are enabled, set SECONDARY_TOKEN as an environment variable.

---

Safety rules

• Never hardcode tokens or secrets
• Validate before announcing success
• Restore service first, investigate later
• Always keep a recent known-good backup in production

---

Manual quick template (single instance)

TS=$(date +%Y%m%d-%H%M%S)
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.safe-$TS

# ...apply minimal config edits...

openclaw status --deep

If validation fails:

cp ~/.openclaw/openclaw.json.bak.safe-$TS ~/.openclaw/openclaw.json
openclaw gateway restart