Cron & Scheduling

PassAudited by ClawScan on May 1, 2026.

Overview

This is a coherent cron/systemd scheduling guide, but users should notice that it includes commands for persistent and privileged scheduled tasks.

This skill appears safe as a scheduling reference, but treat cron and systemd changes as persistent system changes: review commands before running them, back up existing crontabs, confirm the user/service account, and disable timers or jobs you no longer want.

Findings (3)

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.

Note

ASI02: Tool Misuse and Exploitation

What this means

A user or agent following the example incorrectly could delete existing scheduled jobs.

Why it was flagged

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.

Skill content

# Remove all cron jobs (be careful!)
crontab -r

Recommendation

Confirm the target crontab and make a backup with `crontab -l > backup.txt` before removing or replacing scheduled jobs.

Note

ASI03: Identity and Privilege Abuse

What this means

Using these commands can modify jobs that run as another system user, which may affect services or production workloads.

Why it was flagged

The skill includes privileged administration of another user's crontab. This is purpose-aligned for scheduling administration, but it crosses user/account boundaries.

Skill content

# Edit another user's crontab (root)
sudo crontab -u www-data -e

Recommendation

Use privileged cron or systemd commands only when the user explicitly requests that scope and understands which account or service will run the job.

Note

ASI10: Rogue Agents

What this means

Scheduled tasks may run later, at startup, or after a reboot, potentially causing unexpected changes if forgotten.

Why it was flagged

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.

Skill content

@reboot    /path/to/script.sh   # Run once at startup
...
Persistent=true
...
nohup bash -c "sleep 7200 && /opt/scripts/task.sh" &

Recommendation

Track installed cron entries, systemd timers, and queued at/nohup jobs, and remove or disable them when they are no longer needed.