Cron Retry
Security checks across malware telemetry and agentic risk
Overview
The skill is transparent about retrying cron jobs, but it sets up recurring automatic reruns of broadly selected failed jobs with limited safeguards against duplicate or repeated side effects.
Review which cron jobs could be rerun before enabling this. It is safest if you restrict retries to an explicit allowlist of idempotent jobs, add retry limits and cooldowns, and avoid automatic retries for jobs that post publicly, send messages, spend money, or modify important data.
VirusTotal
66/66 vendors flagged this skill as clean.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A failed cron job could be rerun automatically and repeat side effects such as sending duplicate messages or making repeated external API calls.
The skill instructs the agent to automatically list and rerun cron jobs. The scope is all enabled jobs matching error text, with no explicit user approval, per-job allowlist, retry cap, or idempotency requirement.
1. On heartbeat, check all cron jobs via `cron list` ... 4. Re-run eligible jobs via `cron run`
Only enable this for jobs that are safe to rerun. Add an allowlist, cooldown, maximum retry count, and user confirmation for jobs with external or destructive effects.
The agent may keep retrying matching failed jobs in the background, including while the network problem persists or if a job repeatedly reports a retryable error.
Adding the instructions to HEARTBEAT.md creates recurring autonomous behavior that continues on each heartbeat rather than only when the user invokes the skill.
Add this to your `HEARTBEAT.md` ... That's it. On each heartbeat, failed network jobs get retried automatically.
Make the persistent heartbeat behavior explicit to users and include clear stopping rules, retry budgets, and a way to disable or audit the recovery loop.
Users may believe retry loops are fully prevented even though the documented algorithm does not clearly show how that protection works.
The safety claim mentions a lastRunAtMs check, but the implementation steps shown do not specify a concrete lastRunAtMs condition, cooldown, or retry limit.
Won't create retry loops (checks lastRunAtMs)
Document the exact loop-prevention logic, including how recently a job must have run and how many times it may be retried.