Autonomous Loop

Add self-sustaining autonomous loop capability to an OpenClaw agent. The agent keeps working after each reply until a stop file is placed. Use when: (1) crea...

Security Scan

The plugin's stated purpose (keep an agent looping) matches much of its behavior, but the code reads a local device identity (private key) to sign operator-level requests and accesses files under ~/.openclaw without declaring that need — this privilege and a few metadata/install mismatches are concerning and should be understood before installing.

Purpose & Capability

The skill claims only to add a follow-up-message loop, which is coherent with most of the code (watching a stop file, waiting delay, sending messages). However the plugin also attempts to load ~/.openclaw/identity/device.json and build a signed device block (operator.read, operator.write scopes). That is a higher-privilege operation (signing with a private key to impersonate a device for operator.write) that is not declared in the skill metadata or SKILL.md as a required capability. SKILL.md's metadata also lists an OS requirement (darwin) while the registry shows no OS restriction — another mismatch.

Instruction Scope

SKILL.md instructs the agent to run commands and read many workspace files (git log, init.sh, TASKS.md, PROGRESS.md, run E2E tests, take screenshots). Those instructions are within an autonomous agent's plausible remit, but they grant broad discretionary ability to run arbitrary shell commands and read/write project files. The plugin's runtime code watches and writes files under ~/.openclaw and logs to ~/.openclaw/logs; combined with the agent instructions this gives broad file-system and command execution scope.

Install Mechanism

There is no automated install spec (instruction-only install via copying the plugin into OpenClaw extensions). That lowers some remote-install risk because nothing is downloaded during install, but the package does include executable plugin code that the user must copy into their runtime — so the user will be executing included code manually. No external downloads or URL-based installs are present.

Credentials

The skill declares no required environment variables or credentials, yet the code reads ~/.openclaw/identity/device.json (privateKeyPem) to create signed device assertions for operator.read/operator.write. Access to a device private key and the ability to sign operator.write requests is a disproportionate and high-privilege capability for a plugin whose description focuses on message looping. The plugin also expects gateway config values (token/port) in OpenClaw config but does not declare or document explicit requirements for them in the registry metadata.

Persistence & Privilege

The skill is not marked always:true and does not request to modify other skills. However it is designed to run autonomously (plugin invoked on agent_end events) and — when device identity is available — can sign operator-scoped requests, which increases its potential impact while running. This combination (autonomous invocation + optional device auth) raises the blast radius if the plugin is compromised or misused.

What to consider before installing

Before installing: review the full plugin source code (index.ts) yourself and only install if you trust the author. Key specific checks: 1) Inspect ~/.openclaw/identity/device.json — the plugin will read privateKeyPem and, if present, use it to sign operator-scoped requests (operator.write). If you don't want the plugin to have that power, do NOT keep a device.json with a private key on the same host or restrict its permissions. 2) Understand the default/per-agent messages (defaultMessage / agents) — those messages tell the agent what shell commands and tests to run; malicious or buggy instructions could run arbitrary commands. 3) Test in an isolated environment (not production) first: run OpenClaw in a throwaway VM or container that does not have sensitive identity files or production data. 4) Note the metadata mismatch (SKILL.md says darwin) and that installation is manual (copying plugin into extensions) — confirm you are installing the intended version from a trusted source. 5) If you cannot audit the code, avoid installing or remove/lock the device identity so the plugin cannot perform device-authenticated operator actions.

Keeps an OpenClaw agent working continuously without human intervention. After each reply, the plugin waits N seconds and automatically sends the next task instruction — until you place a stop file.

Installation

# Copy the plugin into OpenClaw's extensions directory
cp -r ~/.openclaw/skills/local/autonomous-loop/plugin \
      ~/.openclaw/extensions/autonomous-loop

Verify it loaded:

openclaw plugins info autonomous-loop
openclaw gateway status

If not shown, restart the Gateway: openclaw gateway restart

How It Works

Agent finishes a reply
        │
        ▼
[agent_end event]  ← plugin listens here
        │
        ├─ stop file exists? → skip this round
        │
        ▼
Wait delayMs (default 30s)
        │
        ├─ check stop file again (double-check)
        │
        ▼
Send next task message to the same session via WebSocket
        │
        ▼
Agent starts next round of work ────────────────────────↑ loop

Logs are written to: ~/.openclaw/logs/autonomous-loop-{agentId}.log

Configuration

Add to ~/.openclaw/openclaw.json under the plugins key:

{
  "plugins": {
    "autonomous-loop": {
      "delayMs": 30000,
      "defaultMessage": "Read TASKS.md and PROGRESS.md. Pick the highest-priority Pending task and execute it. Update both files when done.",
      "agents": {
        "david": "Read TASKS.md and PROGRESS.md to understand the current project state, then:\n\n1. If there is an in-progress task, continue it\n2. Otherwise pick the highest-priority Pending task (skip tasks requiring user input)\n3. Execute the task, verify with end-to-end browser testing, take a screenshot as proof\n4. Update TASKS.md and PROGRESS.md",
        "allen": "Read Todo.md. Pick the highest-priority incomplete task and execute it. Update Todo.md when done."
      }
    }
  }
}

Parameter	Type	Description
delayMs	number	Milliseconds to wait before sending the next message (default: 30000)
defaultMessage	string	Fallback message used when no per-agent message is configured
agents	object	Per-agent messages. Key = agentId, value = message string

Stop & Resume

# Pause a specific agent's loop
touch ~/.openclaw/autonomous-loop.{agentId}.stop

# Resume the loop
rm ~/.openclaw/autonomous-loop.{agentId}.stop

# Watch the loop log live
tail -f ~/.openclaw/logs/autonomous-loop-{agentId}.log

Log Reference

Log entry	Meaning
countdown-started	Normal — reply finished, countdown running
message-sent	Normal — message delivered, next round started
stop-file-detected	Stop file found by watcher, loop paused
skipped-stop-flag	Stop file present at trigger time, skipped
send-error	Message delivery failed — check if gateway is running
skipped-no-assistant-text	Agent reply had no text content, skipped
skipped-no-gateway-config	Gateway port or token missing from config
skipped-stop-token	Agent replied with DONE or HEARTBEAT_OK — loop idle until next user message

Agent Workspace Structure

A workspace for an autonomous agent needs these files:

workspace-{agentId}/
├── AGENTS.md       # Startup sequence, memory system, behavior rules
├── SOUL.md         # Identity and core values
├── WORK.md         # Execution loop (pick task → execute → verify → wrap up)
├── TASKS.md        # Task queue (Pending / In Progress / Done)
├── PROGRESS.md     # Project state — must be updated at end of every session
├── HEARTBEAT.md    # Heartbeat checklist (empty file = skip)
└── ARTIFACTS/      # Work outputs (screenshots, code, analysis)

Session startup sequence (defined in WORK.md):

1. git log --oneline -20     understand what was done recently
2. read PROGRESS.md          current project state
3. read TASKS.md             find the next task
4. run init.sh (if present)  start the dev server
5. basic E2E test            catch leftover bugs from last session
6. pick one task, do one task

Two-Phase Workflow for New Projects

Long-running agents restart fresh every session. Structure work in two phases:

Phase 1 — Init session (first session only)

1. Create init.sh — one command to start the dev server
2. Create FEATURES.json — full feature list, every item "status": "failing"
3. First git commit
4. Write each feature as a sub-task in TASKS.md

Phase 2 — Coding sessions (every subsequent session)

• Read git log + PROGRESS.md to restore context
• Do one feature per session
• Only mark "status": "passing" after E2E verification
• Never delete or modify tests to make them pass

FEATURES.json Pattern (Large Projects)

For projects with 10+ independent features, track verification state in a structured JSON file instead of a plain checklist:

[
  { "id": "user-login",   "description": "User login",    "status": "passing", "verified": "2026-03-20" },
  { "id": "video-upload", "description": "Video upload",  "status": "failing", "verified": null }
]

Each session picks one "failing" item, implements and verifies it, then updates status to "passing".

Difference from agent-reply-trigger

If you already have the agent-reply-trigger plugin installed, this skill provides equivalent functionality with external configuration instead of hardcoded values.

	agent-reply-trigger	autonomous-loop (this skill)
Message config	Hardcoded in index.ts	Configured in config.json
Log prefix	agent-reply-trigger-	autonomous-loop-
Stop file	agent-reply-trigger.{id}.stop	autonomous-loop.{id}.stop

Do not enable both plugins for the same agentId — the loop will fire twice per reply.