OpenClaw Renames Its Agent Scheduler Tool to Automations

OpenClaw has completed the first main-branch phase of its scheduler terminology change: the model-facing agent tool is now automations, the CLI accepts openclaw automations, and visible UI, prompt and documentation language now calls scheduled work Automations.

The old word has not vanished. Cron schedule syntax, internal RPC methods, persisted state and existing configuration keys intentionally remain cron. The agent-tool name cron is retained as a compatibility alias.

That split is the whole operator story. This is a product-language and tool-identity migration—not a scheduler rewrite or state migration.

What changes and what does not

The distinction prevents a cosmetic rename from churning stable machine interfaces. It also means operators should not perform a global search-and-replace across configuration, scripts or databases.

The compatibility work is security-relevant

Renaming a tool is easy until its name appears in allowlists, denylists, transcripts, persisted jobs, MCP calls and default-deny boundaries. A naive rename can create two dangerous outcomes:

• an old deny rule stops matching, widening access; or
• an old allow rule stops matching, breaking scheduled work in ways that look like model failure.

PR #114841 describes a canonical identity migration with aliases across persisted configuration, transcript recovery, policy lists, inbound Gateway/MCP calls and security boundaries. The intended result is that cron and automations resolve to one scheduler authority rather than becoming two independently governable tools.

Interpretation: aliases at an authorization boundary must share policy identity. Backward compatibility is unsafe if an alias can bypass the canonical tool’s deny rule.

Operators should still test their own policy stack. Custom plugins, proxy layers and external audit tooling may compare raw strings without using OpenClaw’s canonical resolver.

Do not rename these by hand

This phase deliberately leaves machine-facing cron concepts in place. Do not manually rewrite:

• cron expressions such as 0 9 * * *;
• cron.* Gateway RPC names;
• SQLite tables or persisted scheduler records;
• configuration keys that the current schema still names cron; or
• external integrations that call the documented RPC surface.

A valid post-upgrade system can therefore show “Automations” in the Control UI while logs, RPC traces or config still contain cron. That is not evidence of a partial database migration.

The new CLI alias is a convenience and teaching surface. Existing scripts using openclaw cron do not need an emergency rewrite, and changing them before every deployed environment supports the alias would reduce compatibility.

Audit custom tool policies

For each policy layer that names scheduler tools:

1. identify whether it is interpreted by OpenClaw or by custom string-matching code;
2. verify that denying either cron or automations denies the canonical scheduler capability;
3. verify that an explicit allow does not accidentally create duplicate entries with different effective rules;
4. test an old persisted job and transcript reference after upgrade; and
5. preserve the effective-policy evidence without running a consequential schedule.

Be especially careful with external MCP allowlists, plugin-owned policy parsers and reporting systems that aggregate tool usage by raw name. They may require a deliberate alias mapping even though core OpenClaw remains compatible.

Model prompts and session labels also change

The second stack change, PR #114852, updates fallback guidance, heartbeat prose, session labels, delivery notices, default job names and failure messages. A model should now learn and repeat the canonical automations identity rather than being taught the old agent-tool name by system text.

That can affect tests and automations that assert exact human-readable output. Examples include parsers expecting a Cron: session label, screenshot tests, notification filters and support runbooks that tell users which tool name to request.

Do not parse presentation prose when a structured field is available. Where exact text is unavoidable, accept both generations during a mixed-version rollout.

Mixed-version rollout guidance

Because the compatibility alias is designed to be permanent, there is no need for a flag day. A safer rollout is:

1. upgrade a staging Gateway to a containing build;
2. confirm both CLI spellings list the same jobs;
3. invoke a harmless model-created schedule using the canonical tool name;
4. verify old policy and transcript references still resolve to the same authority;
5. update documentation and prompts to say Automations; then
6. update external string matchers only after every target environment understands the new name.

Keep “cron” where it describes syntax or the still-current machine contract. Replacing every occurrence makes runbooks less accurate, not more modern.

Release and evidence limits

The five implementation and documentation PRs in this terminology stack are merged on OpenClaw main. The official RFC defines the Phase 1 split between user-facing Automations language and intentionally stable cron internals. Current official documentation also presents Automations as the product surface while retaining cron scheduler and CLI concepts.

OpenClaw Academy reviewed the official merged records, commits, documentation-change signals and corroborating web-search results. We did not test a packaged mixed-version fleet or third-party policy plugin. Confirm the containing release before expecting openclaw automations or the canonical agent-tool name on an installed system.

Bottom line

Say Automations to users and models; keep cron where it remains the machine contract. The upstream alias work should prevent a breaking migration, but custom policy and reporting code deserves a two-name audit. This is precisely the kind of rename that looks cosmetic until an allowlist disagrees.