Cron & Scheduling
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
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 user or agent following the example incorrectly could delete existing scheduled jobs.
The guide documents a command that can remove all cron jobs for a user. It is clearly labeled with a caution and is relevant to crontab management, but misuse could disrupt scheduled tasks.
# Remove all cron jobs (be careful!) crontab -r
Confirm the target crontab and make a backup with `crontab -l > backup.txt` before removing or replacing scheduled jobs.
Using these commands can modify jobs that run as another system user, which may affect services or production workloads.
The skill includes privileged administration of another user's crontab. This is purpose-aligned for scheduling administration, but it crosses user/account boundaries.
# Edit another user's crontab (root) sudo crontab -u www-data -e
Use privileged cron or systemd commands only when the user explicitly requests that scope and understands which account or service will run the job.
Scheduled tasks may run later, at startup, or after a reboot, potentially causing unexpected changes if forgotten.
The guide covers mechanisms that continue or resume execution after reboot or logout. Persistence is central to scheduling, but users should be aware that jobs may keep running after the initial setup.
@reboot /path/to/script.sh # Run once at startup ... Persistent=true ... nohup bash -c "sleep 7200 && /opt/scripts/task.sh" &
Track installed cron entries, systemd timers, and queued at/nohup jobs, and remove or disable them when they are no longer needed.