Skillv1.0.3

ClawScan security

Cost Control · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

BenignMar 10, 2026, 7:41 AM

Verdict: benign
Confidence: medium
Model: gpt-5-mini
Summary: The skill's code, instructions, and required artifacts are coherent with its stated purpose (a local cost-tracking system with a watchdog and kill switch), but it relies on file-based state and an external watchdog that can kill processes — so review deployment and file/perms configuration before use.
Guidance: This package appears to implement exactly what it claims: a local cost tracker, an external watchdog that can kill a process, and a manual kill switch. Before installing or deploying: - Run code review and test in staging; verify record_call() is invoked reliably by your app. - Ensure the state directory (default ./state) is writable only by the intended user and not writable by untrusted users to prevent tampering (someone creating cost_emergency.flag or KILL_SWITCH will block API calls). - If using the watchdog, make sure your application writes state/app.pid with its own PID and that the PID path in cost_watchdog.py points to that file. Be careful: pointing the watchdog to the wrong PID file can kill other processes. - Prefer running the watchdog under a dedicated, unprivileged cron/systemd service and restrict who can edit its config or state files. - Consider adding safeguards: validate PID ownership (compare uid), check process command line/name before killing, enforce file permissions, and test kill/restart procedures. - Understand limitations in LIMITATIONS.md: file-based state is single-process, clock skew and delayed billing can cause false positives/negatives, and emergency recovery is manual. If you cannot enforce these deployment constraints or secure the state files, exercise caution — the feature that kills processes is necessary for the purpose but can be disruptive if misconfigured.

Review Dimensions

Purpose & Capability: okName/description (cost control for expensive APIs) matches the provided code and SKILL.md. All included files (CostTracker, watchdog, kill switch, config examples) are directly relevant to implementing a 3‑tier cost control system. There are no unrelated credentials, network endpoints, or binaries requested.
Instruction Scope: noteRuntime instructions focus on integration (call is_call_allowed() before calls, record_call() after, deploy watchdog via cron). The docs explicitly instruct creating a PID file and state directory and writing/reading flag files. This is expected for the design, but the SKILL.md/code instruct the agent/operator to create or rely on on-disk artifacts (state/, state/app.pid, cost_emergency.flag, KILL_SWITCH). Those files are central to behavior and can be misused or misconfigured if not secured.
Install Mechanism: okNo install spec is present (instruction-only). Code is provided as Python files that the user places in their project or pip can install; no external downloads from untrusted URLs or package installs are embedded in the skill metadata.
Credentials: okThe skill requests no environment variables or credentials. It uses only local filesystem and process signaling, which is proportionate to a local kill-switch/watchdog design. There are no unexplained secret or network access requirements.
Persistence & Privilege: noteThe skill does not request 'always:true' and allows normal opt-in/autonomous invocation. However, the external watchdog will (if configured) send SIGTERM/SIGKILL to the PID read from state/app.pid and write an emergency flag file that prevents restart until manual clearing. This behavior is coherent with the purpose but is high-impact: misconfigured PID paths or tampered state files could cause unintended process termination or denial of service. The implementation does not validate PID ownership, process identity, or require elevated permissions — responsibility for safe deployment falls to the operator.