Autonomous Task Runner

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:28 PM UTC
• Version: 2.1.0

Overview

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.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T06 · System Persistence

Error

• Location: SKILL.md:110
• Finding: Automatic Installation of Cross-Session Heartbeat and Cron Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:110-148` and `SKILL.md:396-425` **Vulnerability Type**: Automatic scheduled-task and heartbeat persistence **Risk Level**: High ### Vulnerable Code ```text Step 0 — First Run Setup (auto-configure on first use) [3] Register heartbeat entry: READ HEARTBEAT.md (create it if missing) IF "Task Runner Dispatcher" is NOT already in the file: APPEND the following block: ## Task Runner Dispatcher Every heartbeat: check ${TASK_RUNNER_DIR}/task-queue.json - If pending or running tasks exist → run DISPATCHER mode (task-runner skill) - If nothing pending → HEARTBEAT_OK (skip) WRITE the updated HEARTBEAT.md [4] Register backup cron job: CALL cron tool with: action: "add" job: name: "Task Runner Dispatcher" schedule: { kind: "every", everyMs: 900000 } payload: { kind: "systemEvent", text: "TASK_RUNNER_DISPATCH: check queue and run pending tasks" } sessionTarget: "main" enabled: true ``` The persistence behavior is also explicitly enabled in `skill.yml:158-164`: ```yaml heartbeat_integration: register_in_heartbeat_md: true heartbeat_check: "Read ${TASK_RUNNER_DIR}/task-queue.json; if pending/running tasks exist, run DISPATCHER mode; else HEARTBEAT_OK" cron_backup: schedule: "every 15 minutes" system_event: "TASK_RUNNER_DISPATCH: check queue and run pending tasks" ``` ### Technical Analysis On the first broadly matching intake request, the Skill modifies `HEARTBEAT.md` and creates a recurring cron job targeting the main agent session. Both mechanisms survive the original Skill invocation and repeatedly reactivate the dispatcher. A persistent queue reasonably requires some form of later execution, so scheduling is related to the declared functionality. However, the implementation exceeds minimum privilege because: - Two independent persistence mechanisms are installed automatically. - Installat ...[truncated 1868 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Require explicit, informed user approval before modifying `HEARTBEAT.md` or registering a cron job. 2. Present the schedule, target session, capabilities, and retention behavior before installation. 3. Use only one persistence mechanism by default. Make the backup mechanism separately opt-in. 4. Run scheduled dispatch in a dedicated restricted session rather than the main session. 5. Add commands such as `disable task runner` and `uninstall task runner` that: - Disable and remove the cron job. - Remove only the Skill-owned block from `HEARTBEAT.md`. - Stop or revoke active subagent sessions where supported. - Optionally purge the queue and archives after confirmation. 6. Store and validate the scheduler's unique job identifier instead of relying only on queue-file existence. 7. Prevent queue deletion from implicitly reinstalling persistence. 8. Add tests verifying explicit consent, reliable removal, duplicate prevention, and disabled-state enforcement. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: skill.yml:167
• Finding: Declared Least-Privilege Boundary Does Not Match Effective Shell and Network Capabilities<![CDATA[ ## Vulnerability Details **File Location**: `skill.yml:167-181`, with effective strategies in `references/task-types.md:91-116` and `references/task-types.md:181-193` **Vulnerability Type**: Undeclared arbitrary command execution, possible elevation, and raw outbound API access **Risk Level**: High ### Vulnerable Code The manifest describes `exec` as limited to directory creation: ```yaml permissions: filesystem: - "create ${TASK_RUNNER_DIR}/ directory on first run" - "read/write ${TASK_RUNNER_DIR}/task-queue.json (persistent queue)" - "read/write/create HEARTBEAT.md (injects dispatcher entry on first run)" - "write ${TASK_RUNNER_DIR}/archive/YYYY-MM.json (archiving old tasks)" cron: - "register one recurring cron job on first run (every 15 min dispatcher)" - "no cron jobs are registered after first-run setup" subagents: - "spawn subagent per pending task (up to maxConcurrent simultaneously)" - "subagents execute tasks and report results back to queue" exec: - "mkdir -p ${TASK_RUNNER_DIR} (directory creation only)" ``` However, `references/task-types.md:91-116` authorizes general shell execution: ```text Type: code-execution | Priority | Strategy | Tool | When to Use | | 1 | Direct exec | exec tool | Standard shell commands | | 2 | Exec with error handling | exec with || true | Recoverable errors expected | | 3 | Exec in PTY mode | exec with pty=true | Interactive commands or TTY-required programs | | 4 | Write script then exec | write + exec | Complex multi-line script | Common failure modes: - Command not found → check if tool is installed - Permission denied → try with elevated flag if appropriate; otherwise block - Timeout → increase timeout or break into smaller commands ``` The messaging strategy additionally permits raw API requests: ```text | 1 | Message tool | message | Configured channels | | 2 | Channel-specific fallback | channel's API via exec curl | If message tool unavailable for that ...[truncated 2673 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make the manifest accurately declare arbitrary command execution, external file access, outbound network access, and task-specific cron creation. 2. Prefer deny-by-default per-task capability grants: - Lookup tasks: web access only. - File tasks: access only to explicitly approved paths. - Messaging tasks: structured messaging API only. - Command tasks: restricted sandbox with a command allowlist. 3. Require fresh confirmation before: - Destructive file operations. - Package installation. - Service or configuration changes. - Privileged execution. - Credential use. - External messaging or data transmission. 4. Remove the instruction to try an elevated flag automatically. Elevation should require explicit user approval and platform policy authorization. 5. Remove raw `exec curl` as an automatic messaging fallback. Use structured APIs with destination validation and scoped credentials. 6. Sanitize command arguments and avoid constructing shell commands from untrusted task text. 7. Run subagents in isolated working directories with restricted environment variables, network policy, filesystem permissions, and execution time limits. 8. Add destination and path allowlists, plus explicit denial of credential files and sensitive system directories. 9. Add security tests for shell metacharacters, path traversal, destructive commands, privilege requests, and unauthorized outbound destinations. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/queue-schema.md:5
• Finding: Indefinite Plaintext Retention of User Tasks, Results, Paths, and Session Metadata<![CDATA[ ## Vulnerability Details **File Location**: `references/queue-schema.md:5-9`, `references/queue-schema.md:44-81`, and `references/queue-schema.md:266-275` **Vulnerability Type**: Sensitive-data retention without redaction, access-control, or secure deletion requirements **Risk Level**: Medium ### Vulnerable Code The schema defines a persistent file that accumulates user data: ```text File path: ${TASK_RUNNER_DIR}/task-queue.json (default: ~/.openclaw/tasks/task-queue.json) This is a single file that accumulates all tasks over time. It is never reset — only tasks older than archiveDays days with terminal statuses are moved to the archive directory. ``` Task records preserve the original request and operational metadata: ```json { "id": "T-01", "description": "original user text for this task", "goal": "parsed objective in one sentence", "type": "info-lookup", "status": "pending", "retries": 0, "maxRetries": 3, "subagent_session": null, "strategies_tried": [], "deliverable": null, "deliverable_path": null, "blocked_reason": null, "user_action_required": null, "added_at": "2026-02-17T09:00:00Z", "started_at": null, "completed_at": null } ``` The documented archive process moves rather than deletes records: ```text When the dispatcher runs and finds tasks with terminal status where completed_at is older than archiveDays days: 1. Move those task objects to ${TASK_RUNNER_DIR}/archive/YYYY-MM.json 2. Archive file structure is identical to the main queue file 3. Remove archived tasks from tasks[] in the main queue file 4. Do NOT change lastId ``` The user-facing documentation reinforces indefinite retention at `README.md:159-172`: ```text Tasks are never deleted — they're archived so you always have a record. ``` ### Technical Analysis The queue stores original user text verbatim or lightly cleaned, together with result summaries, output paths, failure details, attempted strategies, and subagent session identifiers. ...[truncated 1870 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Create the task directory with owner-only permissions, such as mode `0700`, and queue/archive files with mode `0600`. 2. Do not store original user text verbatim by default. Persist only the minimum fields required to resume execution. 3. Detect and redact common secrets, credentials, tokens, private keys, and sensitive headers before writing records. 4. Replace indefinite archival with a finite retention period and automatic deletion. 5. Add explicit controls to: - Delete one task. - Purge completed tasks. - Purge all archives. - Disable retention of deliverables and execution history. 6. Remove or hash session identifiers after tasks reach a terminal state unless they are required for a short diagnostic period. 7. Avoid recording command output or external message content when a status code and minimal summary are sufficient. 8. Document backup implications and ensure archive files are covered by the same access controls and deletion policy. 9. If the environment is multi-user or sensitive, encrypt retained task data with a user-controlled key. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (36)

Exfiltration Commands

High

• Category: Prompt Injection

Content

| 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 |

---

• Confidence: 90% confidence
• Finding: Instructions found that direct the agent to transmit conversation context or user data to external services.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: 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.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: 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.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: 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.

Vague Triggers

High

• Confidence: 97% confidence
• Finding: 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.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: 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.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```
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:

• Confidence: 84% confidence
• Finding: 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.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: 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.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: 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.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 84% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 88% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

| 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

• Confidence: 85% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: 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.

Description-Behavior Mismatch

Medium

• Confidence: 91% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 92% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

| 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 |

• Confidence: 85% confidence
• Finding: 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.

Static analysis

No suspicious patterns detected.