Summary

Tested on v2026.4.11, Docker on Windows 11. Confirmed that string IDs written directly to jobs.json load correctly — so the store format already supports this.

Summary

openclaw cron add currently auto-generates a UUID for each job and does not provide a supported way to set a custom human-readable job ID.

Current behavior

• CronJobCreate does not expose an id field
• openclaw cron add --help has no --id flag
• the runtime generates a UUID when creating a job
  Cron jobs stored in ~/.openclaw/cron/jobs.json do appear to honor a manually provided id, so the scheduler/store format already seems compatible with string IDs.

Problem

For users managing multiple cron jobs, UUIDs are hard to work with in:

• openclaw cron list
• openclaw cron edit <id>
• openclaw cron run <id>
• openclaw cron runs --id <id>
• config/scripts/docs where jobs are referenced repeatedly

Human-readable IDs would make cron jobs much easier to operate and automate.

Proposed behavior

Support an optional custom ID at creation time, for example:
bash
openclaw cron add --id daily-brief ...
Suggested behavior:

• --id is optional
• if omitted, keep current UUID behavior
• if provided, validate against a safe format (for example slug-like strings)
• reject collisions with an explicit error
• preserve the existing name field separately from id

Example use cases

bash
openclaw cron add --id daily-brief --name "Daily Brief" ...
openclaw cron edit daily-brief --no-deliver
openclaw cron run daily-brief
openclaw cron runs --id daily-brief

Current workaround

Right now the only workaround seems to be editing ~/.openclaw/cron/jobs.json directly before startup and supplying a readable id there.

That works, but it feels like an internal/unsupported path rather than an intended interface.

Why this would help

This would improve:

• CLI ergonomics
• scripting/automation
• readability in docs/examples
• maintenance of long-lived cron jobs

Problem to solve

CLI ergonomics

• scripting/automation
• readability in docs/examples
• maintenance of long-lived cron jobs

Proposed solution

Support an optional custom ID at creation time, for example:
bash
openclaw cron add --id daily-brief ...
Suggested behavior:

• --id is optional
• if omitted, keep current UUID behavior
• if provided, validate against a safe format (for example slug-like strings)
• reject collisions with an explicit error
• preserve the existing name field separately from id

Example use cases

bash
openclaw cron add --id daily-brief --name "Daily Brief" ...
openclaw cron edit daily-brief --no-deliver
openclaw cron run daily-brief
openclaw cron runs --id daily-brief

Current workaround

Alternatives considered

Right now the only workaround seems to be editing ~/.openclaw/cron/jobs.json directly before startup and supplying a readable id there.

That works, but it feels like an internal/unsupported path rather than an intended interface.

Why this would help

Impact

Anyone managing more than a handful of cron jobs. UUID-based IDs make routine operations like cron edit, cron run, and cron runs --id unnecessarily painful since you have to look up the ID every time instead of just typing a meaningful name.

• Severity: Annoying but workable — the workaround (editing jobs.json directly before startup) functions correctly but is unsupported and fragile
• Frequency: Every time a new cron job is created or an existing one needs to be referenced by ID in the CLI
• Consequence: Extra manual work to maintain a UUID→name mapping, and direct file edits that could break if the internal format changes

Evidence/examples

No response

Additional information

No response