T06 · System Persistence
Error
- Location
- HEARTBEAT-CONFIG.md:27
- Finding
- Persistent Autonomous Agent Execution Through Scheduled Cron Jobs<![CDATA[ ## Vulnerability Details **File Location**: `HEARTBEAT-CONFIG.md:27-30`, `HEARTBEAT-CONFIG.md:84-94`, `HEARTBEAT-CONFIG.md:106-114`, `HEARTBEAT-CONFIG.md:234-240`, and `SKILL.md:294-301` **Vulnerability Type**: T06: System Persistence **Risk Level**: High ### Vulnerable Code Snippets ```bash # HEARTBEAT-CONFIG.md:27-30 1. **Create cron job** (fires every 30 minutes): ```bash */30 * * * * /path/to/send-heartbeat.sh ``` ``` ```bash # HEARTBEAT-CONFIG.md:84-94 ### Pattern 1: Isolated agentTurn (Background Subprocess) **When:** Weekly velocity reports, auto-cleanup, metadata updates **How:** Run agent in isolated subprocess, no main session context ```bash # /etc/cron.d/proactive-velocity-weekly 0 9 * * MON /path/to/openclaw-runner \ --mode isolated \ --agent proactive-tasks-velocity \ --task "Calculate weekly velocity and log to memory/velocity-YYYY-W##.md" ``` ``` ```bash # HEARTBEAT-CONFIG.md:106-114 ### Pattern 2: Scheduled systemEvent (Exact Time Critical) **When:** Daily reminders at specific time ("9:00 AM sharp") **How:** Send systemEvent to main session at precise time ```bash # /etc/cron.d/proactive-daily-reminder 0 9 * * * /path/to/send-system-event \ --target "main:main:main" \ --message "Daily reminder: Check important deadlines" ``` ``` ```bash # HEARTBEAT-CONFIG.md:234-240 ## Testing Your Setup 1. **Verify heartbeat fires:** ```bash crontab -l # Should show your heartbeat job ``` ``` ### Technical Analysis The documentation instructs users to register recurring cron jobs that activate an agent, send events to an agent session, or run isolated agent tasks after the original interaction has ended. Cron entries survive individual Skill invocations and commonly survive system reboots, making this a cross-session persistence mechanism. Periodic execution is related to the declared autonomous task-management functionality, and the repository does not silently install these jobs itself. Nevertheless, a recurring ...[truncated 2424 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make scheduling an explicitly optional feature rather than part of the default quick setup. 2. Require clear user confirmation immediately before creating any recurring job. 3. Prefer an application-scoped scheduler with narrowly restricted permissions instead of `/etc/cron.d`. 4. Run scheduled work under a dedicated, unprivileged account with access only to the required task-data directory. 5. Add a finite lifetime or maximum execution count to every schedule. 6. Require approval before an autonomous run performs external communication, executes commands, modifies files outside the task-data directory, or starts substantive work. 7. Restrict scheduled tasks to a documented allowlist of read-only or narrowly scoped operations. 8. Provide complete removal instructions, such as: ```bash crontab -e # Remove the proactive-tasks entry ``` For system entries, document the exact `/etc/cron.d` file to remove and the administrative implications. 9. Add a command that lists, disables, and removes all schedules created for the Skill. 10. Record each scheduled activation, selected task, resulting action, and file modification in an audit log. 11. Validate ownership and permissions of every script referenced by a cron entry, and reject scripts writable by less-trusted users. 12. Do not recommend privileged installation unless a concrete feature requires it and no lower-privilege alternative exists. ]]>