Heartbeat Cron
ReviewAudited by ClawScan on May 10, 2026.
Overview
This skill is coherently about scheduled automation, but it can create recurring Claude jobs that run commands, use credentials or browser sessions, and keep acting after setup.
Install only if you want scheduled autonomous Claude workflows. Review each generated HEARTBEAT.md before registering it, avoid `permissions: skip` and broad sandboxes unless necessary, use scoped credentials or dedicated accounts, keep state in a dedicated workspace, and make sure you know how to pause or remove each scheduled heartbeat.
Findings (8)
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.
A heartbeat can keep running on a schedule and take actions without the user present.
The core workflow creates recurring autonomous agent runs. This is disclosed and purpose-aligned, but it is persistent behavior that can continue after setup.
Create and refine HEARTBEAT.md files for murmur — a CLI daemon that runs scheduled Claude prompts on a cron or interval schedule... tests it, and registers it with murmur's scheduler.
Before enabling a heartbeat, confirm the schedule, working directory, exact prompt, stop/disable procedure, and whether any action will occur without review.
A generated heartbeat could automatically modify GitHub issues or PRs, send public/team messages, or delete Docker resources.
The examples include recurring jobs that mutate third-party accounts and local system resources. These examples fit the automation purpose, but they are high-impact if enabled without tight scoping and review.
Use `gh issue edit {number} --add-label {label}` ... `gh pr comment {number} --body "Friendly nudge..."` ... `docker system prune -f`Use read-only or reporting-only heartbeats by default; require explicit confirmation for mutations, public posts, destructive cleanup, or force flags.
A recurring heartbeat may act as the logged-in user on websites or services if browser sessions or CLI credentials are available.
Reusing a browser session can involve authenticated account state. The artifacts do not clearly bound which accounts or session data may be used by scheduled jobs.
session: my-session # pi-specific: reuse a named browser session
Use dedicated low-privilege accounts or scoped tokens for heartbeats, and avoid reusing personal browser sessions unless the exact site, action, and data flow are clear.
Webhook URLs and bot tokens can send messages as the user or bot if exposed or misused.
The examples use expected service credentials for notification delivery. There is no evidence of credential logging or exfiltration, but users should treat these as sensitive.
Slack webhook: `curl -X POST ... $SLACK_WEBHOOK_URL` ... Telegram bot: `curl -s "https://api.telegram.org/bot$TELEGRAM_TOKEN/sendMessage"`
Store tokens outside the prompt where possible, use least-privilege credentials, and avoid embedding secrets directly in HEARTBEAT.md.
If enabled, a scheduled heartbeat may run tool actions with fewer interactive safety prompts.
The skill documents a mode that skips permission checks for scheduled agent runs. It is commented as an option, not shown as default, but it materially increases risk for unattended automation.
# permissions: skip # skip permission checks (only "skip" supported in frontmatter)
Do not use `permissions: skip` for jobs that can modify files, accounts, infrastructure, or send messages unless the task is tightly scoped and separately monitored.
Incorrect or manipulated state files could affect future automated decisions.
The skill encourages persistent state files for recurring jobs. This is appropriate for the purpose, but later runs may trust or reuse those files.
For workflows that need to track changes over time ... use files in the workspace as simple state stores (e.g., `last-price.txt`, `tracking-state.json`).
Keep state files in a dedicated workspace, avoid storing secrets in them, and design heartbeats to validate state before acting.
Installing from a moving external source can change what code is installed over time.
The installation commands are user-directed and central to the skill's purpose, but they fetch and build external code without pinning a specific commit in the instructions.
brew install t0dorakis/murmur/murmur ... git clone https://github.com/t0dorakis/murmur.git ... bun install && bun run build
Install murmur from a trusted source, review the repository, and pin a known version or release when possible.
Running the test helper executes local Node/Jest commands.
The static scanner found shell execution in a test coverage helper. The provided artifacts do not show it being executed automatically during install or normal skill use.
execSync('node --experimental-vm-modules node_modules/jest/bin/jest.js --coverage --coverageDirectory=coverage --coverageReporters=json-summary --silent', {Do not run bundled test scripts unless you intend to execute development tooling and have reviewed the test dependencies.