Cron Worker Guardrails

v1.0.5

Use when: hardening OpenClaw cron/background workers (POSIX shells: bash/sh) against brittle quoting, cwd/env drift, and false pipeline failures (SIGPIPE, pi...

0· 877·2 current·2 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The name/description (cron hardening) matches the SKILL.md and reference files. No unexpected binaries, environment variables, or external services are required; all guidance is about execution patterns and scripts, which is appropriate for the stated goal.
Instruction Scope
Runtime instructions are scoped to making cron jobs deterministic and low-noise (scripts-first, cd to repo, NO_REPLY, avoid complex shell constructs). Examples show running local scripts (python3 tools/*.py) and short shell wrappers. The docs explicitly warn about secret leakage and advise redaction; there are no instructions to collect or transmit data to external endpoints or to read unrelated system files.
Install Mechanism
No install spec and no code files beyond static documentation — nothing is written to disk or downloaded. This is the lowest-risk pattern and is proportional to an advisory/checklist skill.
Credentials
The skill declares no required env vars or credentials. It even cautions against printing secrets in logs and recommends documenting any env vars a job needs. There are no disproportionate credential requests.
Persistence & Privilege
The skill is not always-enabled, does not request system-level persistence, and does not attempt to modify other skills or global agent configuration. Autonomous invocation is allowed by platform default but the skill content does not exploit that.
Assessment
This is a documentation-only skill that provides sensible, POSIX-specific cron hardening guidance. Before adopting: (1) confirm your runtime actually treats the sentinel NO_REPLY as described (or decide on an equivalent silent-success behavior); (2) test suggested patterns in a staging environment (ensure scripts are executable, chdir behavior works, and alerts on failure are actionable); (3) adapt examples if you run non-POSIX shells (Windows/PowerShell); and (4) follow the skill's own advice about not printing secrets — ensure your cron scripts redact or never log sensitive values. Overall it's coherent and low-risk, but treat it as best-practice guidance rather than a replacement for application-level fixes.

Like a lobster shell, security has layers — review code before you run it.

latestvk977j98jh59qxf39n83ww9rz55822xpn

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Runtime requirements

🧯 Clawdis

Comments