Summary

A legacy cron job shape in ~/.openclaw/cron/jobs.json (schedule as string + top-level command) can trigger scheduler errors (Cannot read properties of undefined (reading 'trim')) and may be partially hidden from normal openclaw cron list --json output.

This creates a failure mode where cron appears mostly healthy, but the scheduler keeps emitting tick failures and auto-disables the affected job.

Environment

• OpenClaw: 2026.2.15 baseline in production audit
• Host: macOS (Nimbus), but this appears store-shape/runtime parsing related (likely platform-agnostic)

Reproduction

1. Ensure cron store contains a legacy entry like:
   • schedule: "0 */2 * * *" (string)
   • command: "bash /path/to/script.sh" (top-level)
2. Start/keep gateway running with cron enabled.
3. Check logs and cron list:
   • tail -f ~/.openclaw/logs/openclaw.log
   • openclaw cron list --json

Expected

• Legacy entries are either migrated on load or rejected with a clear validation error.
• Scheduler does not emit recurring tick failures due to one malformed legacy entry.
• CLI listing and runtime store state are consistent.

Actual

• Repeated scheduler errors observed:
  • cron: timer tick failed
  • TypeError: Cannot read properties of undefined (reading 'trim')
  • cron: failed to compute next run for job (skipping)
  • cron: auto-disabled job after repeated schedule errors
• Legacy job can be absent from openclaw cron list --json while still present in store.

Evidence (from frozen audit bundle)

• Legacy store entry before migration:

{"id":"imessage-refresh","name":"iMessage Refresh","schedule":"0 */2 * * *","command":"bash /Users/Nimbus/clawd/scripts/imessage-refresh.sh","timeout":120,"enabled":false,"state":{"scheduleErrorCount":3,"lastError":"schedule error: TypeError: Cannot read properties of undefined (reading 'trim')"}}

• Log signatures:
  • cron: timer tick failed
  • TypeError: Cannot read properties of undefined (reading 'trim')
  • cron: failed to compute next run for job (skipping)
  • cron: auto-disabled job after repeated schedule errors

Impact

• Cron reliability degradation and noisy error loops.
• Hidden/misaligned operator view between store and CLI list.
• Increased operational risk during migrations/upgrades from older cron store formats.

Related (not duplicate as far as I can tell)

• Rapid cron create/delete cycles can freeze the scheduler timer #18121
• Cron runningAtMs flag never auto-clears after session timeout, permanently blocking cron execution #18120