Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw cron edit <id> --cron <invalid> rejects invalid cron expressions for enabled jobs, but accepts and persists the same invalid expression when the target job is disabled; a later openclaw cron enable <id> returns an error while leaving the invalid job enabled in live state.

Steps to reproduce

1. Start OpenClaw from current main (204ef7f1c4) with a reachable gateway.
2. Create a disabled valid cron job:

   openclaw cron add --name probe --every 10m --session main --system-event "probe" --disabled

3. Edit it to an invalid cron expression:

   openclaw cron edit <job-id> --cron "* * * 13 *"

4. Run:

   openclaw cron show <job-id> --json

5. Run:

   openclaw cron enable <job-id>

6. Run:

   openclaw cron show <job-id> --json

Expected behavior

Invalid --cron expressions should be rejected before mutating cron state, regardless of whether the target job is enabled or disabled. The job should keep its previous valid schedule.

Actual behavior

cron edit exits 0 for a disabled job and persists:

"schedule": { "kind": "cron", "expr": "* * * 13 *" },
"enabled": false

Then cron enable exits 1 with:

GatewayClientRequestError: invalid cron.update params: CronPattern: Invalid value for month: 12

But cron show reports the job as enabled with the invalid schedule and schedule-error state.

OpenClaw version

2026.4.27 (204ef7f)

Operating system

Ubuntu 24.04.4 LTS

Install method

pnpm dev

Model

N/A

Provider / routing chain

N/A

Additional provider/model setup details

No response

Logs, screenshots, and evidence

$ openclaw cron add --name probe --every 10m --session main --system-event "probe" --disabled
{
  "id": "70f4b9b8-d501-4315-98cf-f645b49b6386",
  "enabled": false,
  "schedule": { "kind": "every", "everyMs": 600000, "anchorMs": 1777475041128 }
}

$ openclaw cron edit 70f4b9b8-d501-4315-98cf-f645b49b6386 --cron "* * * 13 *"
{
  "id": "70f4b9b8-d501-4315-98cf-f645b49b6386",
  "enabled": false,
  "schedule": { "kind": "cron", "expr": "* * * 13 *" }
}

$ openclaw cron enable 70f4b9b8-d501-4315-98cf-f645b49b6386
GatewayClientRequestError: invalid cron.update params: CronPattern: Invalid value for month: 12

$ openclaw cron show 70f4b9b8-d501-4315-98cf-f645b49b6386 --json
{
  "id": "70f4b9b8-d501-4315-98cf-f645b49b6386",
  "schedule": { "kind": "cron", "expr": "* * * 13 *" },
  "enabled": true,
  "state": {
    "scheduleErrorCount": 1,
    "lastError": "schedule error: RangeError: CronPattern: Invalid value for month: 12"
  }
}

Impact and severity

Affected users/systems/channels: users editing disabled cron jobs with --cron.

Severity: reliability / state consistency bug. A rejected invalid schedule should not be accepted into cron state.

Frequency: deterministic for disabled jobs edited to an invalid cron expression.

Consequence: cron state can contain an invalid enabled job after a failed enable path, creating confusing CLI behavior and schedule-error state that should have been rejected upfront.

Additional information

Root cause appears to be that src/cron/service/ops.ts applies the patch in-place before schedule computation, while src/gateway/server-methods/cron.ts does not validate cron expressions before calling context.cron.update. Invalid schedules can therefore mutate live state before the error response is returned.