OpenClaw Guard

配置文件修改守护脚本 - 危险操作前自动备份，一键回滚

What to check before installing/running: 1) Inspect and edit scripts/config/settings.yaml (the script loads this file by default). Immediately set feishu_enabled: false or replace feishu_open_id with your own trusted recipient. The provided file enables Feishu notifications to a specific Open ID by default — that will cause the script to send backup/incident info via the local 'openclaw' messaging integration. 2) Confirm you trust and have the 'openclaw' CLI and its message-sending behaviour; the script uses 'openclaw message send' rather than a local-only log, so it can transmit messages out of your environment. 3) Verify required tooling: systemctl (or systemctl --user), bash, and optionally curl/nc. The metadata did not list these; make sure these commands exist and that you understand the privileges they require (service restart). 4) Update backup paths: change hard-coded /home/ljj paths and BACKUP_DIR to directories you control so backups don't go to unexpected locations. 5) Run tests first: use ./scripts/guard.sh test and ./scripts/guard.sh start with a short timeout in a non-production environment to confirm behavior. Inspect the backup contents and incident_log.txt to ensure no sensitive secrets are included before enabling notifications. 6) Consider limiting scope: review and, if needed, trim BACKUP_FILES so only necessary files are backed up. The examples and README mention 'any system config file' which could be overly broad. 7) If you cannot audit the script or do not want any external notifications, do not install/run it or remove the notification/send code paths. If you want to proceed, mark the skill suspicious and change the defaults described above.

Type: OpenClaw Skill Name: openclaw-guard-v2 Version: 1.1.0 The skill bundle provides a backup and auto-rollback utility for OpenClaw configuration files. It is classified as suspicious due to a hardcoded Feishu Open ID (ou_0b05bbfa08fd31bb887ba0fc4dcf6854) in 'scripts/config/settings.yaml', which causes system status notifications and incident logs to be sent to an external third party by default. While the script logic in 'scripts/guard.sh' (performing file backups and service restarts via systemctl) aligns with the stated purpose, the inclusion of a specific, non-placeholder ID for remote notifications poses a significant privacy and security risk.