Backup and restore all OpenClaw configuration, agent memory, skills, and workspace data. Part of the MyClaw.ai (https://myclaw.ai) open skills ecosystem — th...
Security Analysis
high confidenceThe skill does what it says — backs up and restores ~/.openclaw and provides an optional local HTTP UI — and the required binaries, paths, and scripts align with that purpose; no unrelated credentials or suspicious install sources are requested.
Name/description, declared binaries (node, rsync, tar, python3, openclaw), and declared read/write permissions for ~/.openclaw match the implemented behavior. The scripts explicitly read and write OpenClaw state (workspace, openclaw.json, credentials, channels, agents, etc.), which is the stated goal.
SKILL.md and the included scripts are explicit about reading/writing ~/.openclaw and about scheduling and serving a web UI. That is in-scope for backup/restore. There are security-sensitive operations (restore overwrites files, schedule.sh edits crontab) and a built-in HTTP server that accepts uploads and serves downloads. The documentation and code implement safeguards (mandatory token to start server, POST /backup and POST /restore restricted to localhost in code). However: the server binds 0.0.0.0 (serve logs and listen on all interfaces), token is commonly passed in query parameters (appears in URLs/console output/UI), /health is unauthenticated, and the web UI can upload arbitrary .tar.gz files into the backup directory — so if the token or host exposure is misconfigured, an attacker with the token or an exposed port could download backups (containing bot tokens/API keys) or upload archives (which would not auto-restore remotely but could be a staging vector). These are security design notes rather than functional incoherence; the skill documents the risks and gives explicit warnings.
No external install downloader or remote code fetch; this is an instruction + script package that relies on local binaries. The included Node server uses child_process.execSync to run the shipped scripts (expected for this tool). No high-risk install steps (no arbitrary URL downloads or extract operations) are present.
The skill requests no external credentials or unrelated environment variables. It legitimately reads and writes ~/.openclaw (which contains secrets) for backup/restore. The only operational secret is the server token used to protect the HTTP UI; the skill does not request other unrelated keys. Note: token handling (appearing in query params and printed URLs) is less secure than header-only auth and increases risk of token leakage via logs or referers.
The skill does not set always:true and is user-invocable only. It does persist changes when invoked: schedule.sh modifies the user's crontab to add a recurring job, and serve.sh writes a pid file and logs in /tmp. These behaviors are expected for backup scheduling and a long-running UI but are persistent effects that require explicit user consent (crontab modification in particular).
Guidance
This skill is functionally coherent with its stated purpose, but it handles highly sensitive data (bot tokens, API keys, conversation history). Before installing: (1) Review and understand that backups contain all credentials and must be stored securely; do not commit them to VCS. (2) Prefer running the HTTP server only on localhost or behind a reverse proxy with TLS; avoid exposing the port publicly. (3) Avoid passing the token in URLs in public contexts (query-string tokens can be logged or leaked via referer); where possible use Authorization headers and a secure transport. (4) Inspect any uploaded backup archive before running a restore (always run restore.sh --dry-run first). (5) Be aware schedule.sh modifies your crontab — verify the cron entry before accepting. (6) If you start the server, rotate tokens/keys after a migration if you have any suspicion they were exposed. If you want stronger guarantees, run only the shell scripts for backups/restores (skip the HTTP server) and keep backups on secure storage (scp/sftp, encrypted storage).
Latest Release
v1.7.0
Post-restore report: after restore.sh completes, writes .restore-complete.json flag. On next heartbeat Agent detects it, sends restore report to user in their own language (read from USER.md), then deletes the flag (one-shot). Report includes backup name, agent name, restore time, and contents list.
More by @LeoYeAI
Published by @LeoYeAI on ClawHub
