OpenClaw merged a high-priority cron hardening change this morning that tightens how recurring jobs inherit tool access from the agent that created them. The fix landed in PR #104430, titled fix(cron): cap trigger script tool access, after maintainers found a path where a restricted agent could create a cron job whose trigger script later ran with more tools than the creator was allowed to use.
That matters because cron is one of OpenClaw's most powerful automation surfaces. A scheduled job can wake an agent without a human in the loop, run at predictable intervals, and carry enough context to perform real work. If a trigger script escapes the creator's policy, the schedule becomes a delayed privilege boundary bug rather than a convenience feature.
What Changed
The PR says the issue involved "a restricted agent" creating a recurring cron job with a trigger script and a systemEvent payload. Main-session cron jobs require systemEvent, so this path could bypass the creator's tool policy whenever cron triggers were enabled.
The fix applies the creator's tool cap whenever a cron job has a trigger script. That cap is retained across cron payload shapes, persisted through the cron SQLite store, and passed into the headless trigger evaluator after gateway restarts.
In practical terms, the job should not get a larger tool surface just because it runs later or runs headlessly. The original agent's allowed tools remain the upper bound.
Why It Is Significant
This is a score-four Tier 1 story because it touches a security boundary in an official OpenClaw workflow. The PR carries a P0 label, a compatibility merge-risk label, and proof-sufficient status, which puts it above ordinary reliability work for operators who rely on scheduled agents.
Cron jobs are commonly used for:
- Scheduled summaries and daily reports
- Inbox, calendar, and notification checks
- Maintenance scripts
- Background monitoring
- Agent-to-agent handoff workflows
Those jobs often run when nobody is watching. A clear and durable cap on trigger script tools is exactly the kind of policy guarantee that automation-heavy installations need.
Operator Takeaway
If you run OpenClaw cron jobs created by restricted agents, this is a meaningful hardening update. Existing scheduled workflows should continue to work, but the headless trigger side now carries the creator's tool policy more explicitly.
The broader pattern is also worth noticing: OpenClaw is treating scheduled automation as a first-class security boundary, not just a background convenience. That is the right direction for a system where recurring jobs can touch files, channels, APIs, and long-running agent sessions.