Skillv1.1.0

ClawScan security

Openclaw Iflow Doctor · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousMar 1, 2026, 3:52 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's declared purpose (auto-repair of OpenClaw) matches most of what it does, but there are several mismatches and privilege-sensitive behaviors (systemd install, generating and running repair scripts, integration with an external iflow service) that warrant manual review before installing in production.
Guidance: Key things to check before installing or enabling auto-heal: 1) Review high-risk source files locally (openclaw_memory.py, watchdog.py, install-systemd.sh, install.py, and any code that composes/executes shell commands). Search for network calls (requests, urllib, sockets), hard-coded endpoints (iflow.cn or other URLs), and any use of subprocess/exec that constructs shell strings from user data. 2) Confirm what is sent externally: find functions that call iflow or POST logs/reports. Ensure uploads are to legitimate endpoints and inspect exactly what fields are transmitted (do not send API keys or full config files unless necessary). 3) Audit BAT/script generation: generated .bat/.sh files are executable payloads. Inspect the templates to ensure they contain only the repair steps you expect and do not exfiltrate data or run arbitrary remote code. Prefer manual review before executing generated repair scripts. 4) Avoid installing as root until reviewed: systemd/task-scheduler installation requires elevated privileges; run the skill first in a safe, non-production environment or inside a VM/container to observe behavior. 5) Protect credentials: if you enable iflow integration, use a dedicated least-privilege IFLOW_API_KEY and avoid reusing high-privilege keys. Prefer temporary/limited keys and do not store long-lived secrets in global shell profiles unless you understand the implications. 6) Test auto-heal in conservative mode: disable fully automatic destructive actions (set auto_heal=false) and run diagnosic/check commands manually to confirm suggested fixes before allowing the skill to autonomously run pkill, reinstall, chown, or other high-impact operations. 7) If you lack the ability to audit the omitted large files thoroughly (openclaw_memory.py, watchdog.py), treat this package as higher risk. Consider requesting the author publish the repository for review or provide a minimal-scope variant that only performs read-only diagnostics. If you want, I can help by listing specific grep patterns to search for (e.g., "requests.post", "subprocess.run", "open\(", "IFLOW_API_KEY", "http://", "https://", "pkill", "chown", "chmod", "cp ") and explain what to look for in each hit.

Review Dimensions

Purpose & Capability: noteName/description align with the provided code and docs: the package contains a repair engine, case library, diagnostics and watchdog components and explicitly integrates with an iflow helper. Required binaries (python3, openclaw) and optional dependency on iflow-helper are coherent with the stated goal. Note: the skill expects to operate on OpenClaw configuration, memory and logs (under ~/.openclaw and ~/.iflow), which is consistent with an auto-repair tool but expands its access to many user files.
Instruction Scope: concernRuntime instructions and included scripts direct the agent to read and modify local OpenClaw configuration and memory files, run system commands (pkill, openclaw gateway restart, cp, chmod/chown), generate executable BAT files, create diagnostic reports, and trigger iflow CLI flows. The SKILL.md and code indicate automatic triggering on errors and an 'auto_heal' mode that will take corrective actions without manual approval. These actions go beyond passive diagnostics and involve modifying system state and possibly restarting services — appropriate for a repair tool but high-impact. The instructions also recommend generating BAT files and 'double-clicking' them, which could execute arbitrary commands with the user's privileges. There is no explicit, fine-grained consent model in the instructions for potentially destructive operations (reinstall, chown, pkill).
Install Mechanism: noteThere is no formal install spec in the skill manifest (instruction-only), but the SKILL.md and docs instruct users to clone from a GitHub repo and run local install scripts (install-systemd.sh / install.py). The repo-based install is common and the URLs shown are ordinary GitHub links. The install scripts (systemd installer) will require sudo to place service files and enable services; they will run code on the host. This is expected for a daemon-style tool but increases the blast radius if the scripts are malicious or buggy. No arbitrary third-party binary download URLs or URL shorteners were observed in the provided texts.
Credentials: concernThe skill manifest declares no required environment variables, but the included docs (iflow-auth-guide.md and other docs/README) instruct users to set IFLOW_API_KEY, IFLOW_BASE_URL and similar env vars to enable iflow CLI integration. The skill integrates with an external service (iflow.cn) and may use user API keys. That is plausible for 'iflow-helper' functionality, but the SKILL.md/meta did not declare these env var requirements explicitly. The code and cases include commands that could include Authorization headers (curl examples) — if those commands are composed and executed programmatically they might leak keys if not handled carefully. Overall the number and sensitivity of resources the skill touches (local configs, logs, memory, optional external API keys) are high relative to a simple helper and should be explicitly documented and scoped.
Persistence & Privilege: noteThe skill does not set always:true and is user-invocable (normal). However, it includes an install-systemd.sh and instructions to register a systemd service (or use Windows Task Scheduler / macOS launchd), which if installed will persist across reboots and likely run with elevated permissions (the Linux instructions call sudo). That persistence is coherent with a watchdog/auto-heal service but materially increases risk because the skill will run continuously and can take actions autonomously. There is no evidence it attempts to modify other skills' configs, but installation as a system service should only be done after code review.