myclaw-backup

This skill appears to do exactly what it claims (full OpenClaw backup/restore) but it operates on highly sensitive files and offers a built-in HTTP server and cron scheduling — review these points before installing: - Trust boundary: backups contain bot tokens, API keys, session history and channel credentials. Only install/run on a trusted machine and protect the resulting .tar.gz files. - HTTP server defaults: serve.sh starts the Node server and binds to 0.0.0.0; although docs warn not to expose it, the default listen address makes it reachable on all interfaces. If you only want local access, modify the server to bind to 127.0.0.1 or run it behind a firewall/reverse proxy with TLS. - Token handling: serve.sh passes the token on the node command line and environment; command-line arguments can be visible to other local users via ps. Prefer passing the token via a protected environment or modify server.js/serve.sh to read the token from a secured file or prompt. - Exposure via URL: the UI embeds the token in links (query string). Query strings and logs may leak tokens (reverse proxies, access logs). Avoid sharing these URLs publicly; prefer scp/ssh when migrating between machines. - Cron changes: schedule.sh modifies the system crontab. Review the cron entry before enabling; use --disable to remove. If you lack admin consent, do not enable scheduling. - Restore safety: follow the skill advice — always run restores with --dry-run first. The restore scripts prompt for confirmation when not dry-run but the server can auto-confirm (echo 'yes' | restore) when invoked via the local restore endpoint; ensure only trusted local users can invoke that endpoint. - Audit and harden: inspect server.js, backup.sh, restore.sh yourself before using. Consider hardening: restrict server.listen to localhost, drop token from argv, enable TLS or run behind SSH tunnel, and ensure backup files have strict permissions and are transferred using scp/sftp. If you want to proceed: run backups locally first, inspect archives, test restore with --dry-run, and avoid starting the HTTP server on a machine exposed to untrusted networks. If you cannot review/modify code yourself, treat this as a high-trust skill and consider alternative migration methods (scp of archive) instead of enabling the built-in HTTP server.