T06 · System Persistence
- Location
SKILL.md:110- Finding
Automatic Installation of Cross-Session Heartbeat and Cron Persistence
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed task runner, but it can automatically install persistent background dispatch, run broad user tasks, and use powerful tools without enough scoping or consent.
Review before installing. This skill should only be used in an environment where you intentionally want persistent background task execution, and it should be tightened to require explicit setup approval, explicit confirmation for shell commands, file writes, cron jobs, and outbound messages, narrower triggers, accurate permission declarations, and clear controls to pause, uninstall, and purge stored task data.
SKILL.md:110Automatic Installation of Cross-Session Heartbeat and Cron Persistence
skill.yml:167Declared Least-Privilege Boundary Does Not Match Effective Shell and Network Capabilities
references/queue-schema.md:5Indefinite Plaintext Retention of User Tasks, Results, Paths, and Session Metadata
Instructions found that direct the agent to transmit conversation context or user data to external services.
| code-execution | "run this script", "install X", "check if Y is running" | `exec` tool |
| agent-delegation | "have a sub-agent research X", "delegate Y" | subagent spawn |
| reminder-scheduling | "remind me at 3pm", "set a weekly check" | cron tool |
| messaging | "send message to X", "post to #channel" | `message` tool |
| unknown | Ambiguous tasks | `web_search` → re-classify → ask |
---
The file authorizes direct shell command and script execution, PTY execution, and writing scripts before running them. In an always-on asynchronous dispatcher, this is a high-risk remote execution surface: natural-language tasks could trigger arbitrary commands, filesystem changes, package installation, or lateral actions with minimal safety boundaries.
The markdown describes shell/code execution as a routine strategy but omits any warning that commands will run on the underlying system. Users may not understand that natural-language requests can translate into real command execution with side effects, making accidental destructive actions or abuse materially more likely.
The messaging section permits sending content through configured channels or direct API calls but provides no privacy warning about transmitting user data externally. This is dangerous because queued tasks may include sensitive text, recipient mistakes are easy, and asynchronous dispatch reduces real-time user oversight before data leaves the system.
The trigger list includes broad natural-language phrases such as 'I need you to', 'help me with', and 'can you do', which are common in ordinary chat and can cause the persistent task-runner to activate when the user did not intend to enqueue asynchronous work. In this skill, accidental activation is especially risky because first-run behavior creates persistent files, modifies HEARTBEAT.md, may register cron automation, and stores requests for later execution, turning a conversational misunderstanding into durable system changes.
The changelog shows a material behavioral shift from deferred asynchronous execution to immediate same-turn execution on intake. For a task-queue skill, this removes the safety boundary implied by queued/heartbeat-based processing and can cause unreviewed user-supplied tasks to execute instantly, increasing the chance of prompt-injection-driven actions, unsafe tool use, or unexpected side effects in the current session.
Triggering privileged setup on the vague condition of a 'first INTAKE invocation' is overly broad and under-constrained. Without precise activation rules, ordinary user interaction can unexpectedly cause initialization steps such as filesystem changes or scheduler registration, expanding the attack surface and making accidental or adversarial triggering easier.
The changelog describes automatic file and system modifications during first run without indicating a user-facing warning or consent step. Silent creation of directories, queue files, scheduler entries, or heartbeat hooks undermines transparency and can lead to unauthorized persistence or environment changes that users did not expect.
The README advertises persistent background execution, file creation, code execution, messaging, and cron-triggered automation, but does not prominently warn users that the skill can continue acting after the initiating conversation and may perform side-effecting actions automatically. In an agent setting, that omission increases the risk of users authorizing capabilities without understanding ongoing execution, external communications, or writes to local state.
The skill is explicitly designed for session persistence: tasks are stored in a long-lived queue file and can execute later across multiple days. That persistence is functional, but it becomes a security concern because queued instructions, generated artifacts, and deferred execution can outlive the original user context and may be triggered without re-validation or fresh consent.
I need you to:
1. Research the top 5 open-source LLM frameworks and summarize pros/cons
2. Create a markdown comparison table at ~/reports/llm-frameworks.md
Agent responds:
The INTAKE trigger list includes very broad natural-language phrases such as 'I need you to' and 'I want you to', which can match ordinary conversational requests rather than explicit queue-management intent. In this skill, a false match does more than misclassify a message: it can persist data, create files, modify HEARTBEAT.md, register cron jobs, and immediately launch subagents with the full tool suite.
The rule 'Any message with 2+ distinct action items' is highly ambiguous and will commonly match normal multi-step user requests. In this skill, that ambiguity is amplified because matching INTAKE automatically enqueues persistent tasks and immediately invokes the dispatcher, potentially causing unintended autonomous actions from a routine chat request.
On first run, the skill silently creates directories and files, edits HEARTBEAT.md, and registers a recurring cron-triggered system event before obtaining explicit informed consent. That is dangerous because it establishes persistence and automatic re-entry behavior, turning a one-time ambiguous trigger into ongoing background execution with privileged tooling access.
The notes authorize automatic first-run setup on any undefined 'INTAKE invocation' and couple it to persistent system-affecting actions like creating directories and registering heartbeat and backup cron behavior. In a persistent task-runner skill, ambiguous activation scope is dangerous because benign user interaction or incidental invocation could trigger durable background execution and scheduling without clear boundaries or consent.
The document defines a single persistent queue file and archive behavior that retain task descriptions, goals, deliverables, and other user-derived data on disk indefinitely or for extended periods, but it does not warn about privacy, retention, or sensitive-data handling. Because this skill is designed to accumulate tasks over time and never fully reset, it increases the chance that secrets, personal data, or sensitive operational requests will be stored in plaintext and later exposed through local compromise, backup leakage, or unintended reuse.
The schema explicitly supports a messaging task type that can send content to channels or people, but it provides no guardrails about validating recipients, confirming consent, or warning that user-derived content may be transmitted externally. In a persistent asynchronous task system, this is more dangerous because queued tasks may be executed later by subagents without immediate user review, increasing the risk of unintended disclosure or spam.
Web search, URL fetch, and browser navigation expand the skill from queue management into general network access. While information lookup may be useful for some queued tasks, the documented capability is broad and can be abused to retrieve external content, follow attacker-controlled URLs, or gather data unrelated to the queue's core purpose.
The instructions normalize direct file writes, edits, and directory creation without warning the user that the filesystem may be modified. In an asynchronous task runner, silent file changes can overwrite important data, create unauthorized artifacts, or be used as a staging step for persistence or later execution.
The documentation permits registering cron jobs and inspecting crontab state, creating persistence beyond the immediate task lifecycle. In a skill designed to remain continuously ready, adding OS-level scheduled execution increases the risk of unauthorized recurring actions, stealthy persistence, and difficult-to-audit background behavior.
The scheduling guidance discusses cron registration and reminder-file creation without warning that these actions may create persistent background behavior. That omission is significant because recurring jobs can continue acting long after the original user interaction, increasing the chance of unnoticed or abusive persistence.
The reference to verifying jobs with crontab inspection reflects use of OS-level persistence mechanisms rather than purely in-skill state. Although crontab -l itself is read-oriented, it signals a design that relies on persistent scheduled execution, which broadens attack surface and may expose or normalize unrelated scheduled tasks in the environment.
| 2 | Write reminder file | `write` to `~/reminders/` | Cron not available; user can check later |
| 3 | Notify user to schedule manually | (message) | Neither cron nor file write available |
**Verification:** Cron job registered (confirm with `crontab -l`); OR reminder file exists with correct content
**Common failure modes:**
- Cron not available in environment → write to reminder file and notify user
The skill documentation explicitly authorizes outbound messaging to people, channels, and third-party services, including fallback API calls via exec/curl. In a persistent task queue that accepts natural-language tasks and runs asynchronously, this creates a strong capability for exfiltration, spam, impersonation, or unintended disclosure without requiring sufficiently narrow scope or consent controls.
The verification guide expands the skill from a persistent task queue/dispatcher into operational domains like reminder scheduling and outbound messaging that are not justified by the declared scope. In a task-runner that accepts natural-language tasks and executes them asynchronously, these undocumented capabilities widen the action surface and enable execution of higher-risk side effects without clear scope boundaries or user-confirmation requirements.
The guide explicitly validates cron-based reminder scheduling via direct crontab inspection, which normalizes persistent background execution. In the context of a never-finished dispatcher, this creates a durable execution mechanism that can be abused for persistence, repeated task execution, or stealthy scheduling beyond the queue's stated purpose.
Referencing crontab -l as a normal verification mechanism indicates the skill is expected to interact with persistent OS-level scheduling state. In this context, that materially increases risk because the task-runner is already designed for continuous operation, making long-lived persistence and recurring execution more dangerous than in a one-shot utility.
| Check | How to Verify | Pass Condition |
|-------|--------------|----------------|
| Cron job registered (if cron used) | `exec: crontab -l` | New cron entry appears with correct schedule |
| Reminder file exists (if file fallback) | `ls <reminder_path>` | File found |
| Schedule is correct | Compare cron entry or file content to task | Time/recurrence matches task description |
| No duplicate entries | Scan crontab for duplicates | Only one matching entry |
No suspicious patterns detected.