Back to skill
Skillv1.0.0
ClawScan security
Gateway Self-Heal Watchdog · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
ReviewMar 6, 2026, 2:12 PM
- Verdict
- Review
- Confidence
- high
- Model
- gpt-5-mini
- Summary
- The skill mostly does what it claims (watch a gateway process, backup/rollback configs), but there are several implementation and scope issues that could be destructive or unexpected (cron manipulation that can wipe existing jobs, an undeclared env var, and privileged/run-as-root suggestions in reference files).
- Guidance
- What to check before installing or running this skill: - Inspect the scripts yourself. The setup script writes and runs ~/.openclaw/watchdog.sh and registers a cron job — review the watchdog.sh contents (they are included) to ensure the restart/rollback logic matches your expectations. - Backup your existing crontab before running setup, because the removal step (crontab -l | grep -v "watchdog.sh" | crontab -) can clear other jobs if crontab -l returns nothing. Run: crontab -l > ~/crontab.before.install - Confirm openclaw binary is installed and in the PATH for the same user that will run the cron job; otherwise the script will fail to restart the service. - Be aware of the undeclared environment variable OPENCLAW_HEALTH_PORT used by the watchdog; if your gateway uses a different port, export OPENCLAW_HEALTH_PORT before installing or edit the script. - The included references (systemd/launchd/docker) assume different locations and privileges: systemd example runs as root with /root/.openclaw — prefer running under the least privilege user and adjust paths accordingly. - If you operate critical systems, test the watchdog in a non-production environment first to confirm it doesn't accidentally overwrite valid configs or remove needed cron jobs. - If you want safer behavior, modify setup-watchdog.sh to (a) prompt before altering crontab, (b) preserve/merge existing crontab more robustly, and (c) avoid running any privileged commands or root paths unless intentionally chosen.
Review Dimensions
- Purpose & Capability
- noteName/description align with the files and scripts: scripts check gateway process, perform health-checks, backup openclaw.json, and perform rollback. The files included (setup and watchdog scripts plus systemd/launchd/docker references) are consistent with a watchdog purpose.
- Instruction Scope
- concernThe runtime instructions and setup script perform system-level actions: create ~/.openclaw/watchdog.sh, write logs, and register a cron job that runs every minute. The setup script will modify the user's crontab and run the watchdog immediately. The scripts access and overwrite configuration files under ~/.openclaw, call openclaw start/stop, and curl the local health endpoint. The crontab manipulation pattern used can erase unrelated existing cron entries (see details below). A watchdog script that restarts services and overwrites configs is expected, but the crontab/sysadmin actions are potentially destructive and should be highlighted to users before install.
- Install Mechanism
- okThis is an instruction-only skill with no install spec; it writes scripts into the user's home directory and registers a cron job. No external downloads or package installs are performed by the skill itself. That reduces supply-chain risk, but the script's behavior still modifies system state.
- Credentials
- concernNo credentials are requested (good). However, the watchdog script references an environment variable OPENCLAW_HEALTH_PORT (defaulting to 3377) but this env var is not declared anywhere in the skill metadata or SKILL.md. The systemd and docker reference files also assume root paths (/root/.openclaw) and global npm-installed openclaw in Docker, which are not declared requirements. These undeclared environment/path assumptions could cause surprises or require elevated privileges.
- Persistence & Privilege
- concernThe setup script registers a cron job to run every minute (persistent/automated invocation). While the skill is not marked always:true, the cron job is permanent until removed. The included systemd reference file runs the watchdog as root (User=root) and uses /root paths — that suggests a privileged deployment option which elevates impact if used. The cron-registration approach in the script can unintentionally wipe other cron entries (risk of losing unrelated scheduled jobs).