openclaw - 💡(How to fix) Fix Bug: Isolated cron run can stall in `runtime-plugins` phase, never starts agent execution

Summary

When a cron-triggered isolated session is being spawned, it can stall during the runtime-plugins initialization phase. The setup timer hits its 60s ceiling, the run is finished with status: error, no agent turn is ever executed, and failureNotificationDelivery.status stays unknown — so the operator gets no notification that their scheduled work failed.

Affects OpenClaw 2026.5.26 (commit 10ad3aa) on macOS 26.4.1 (Mac mini M4 Pro, native LaunchAgent install).

Reproduction (one observed instance)

Run record

{
  "ts": 1780120864997,
  "jobId": "0be92d3b-a47a-4ff0-a0cc-f5b8416d0a4b",
  "action": "finished",
  "status": "error",
  "error": "cron: isolated agent run stalled before execution start (last phase: runtime-plugins)",
  "diagnostics": {
    "summary": "cron: isolated agent run stalled before execution start (last phase: runtime-plugins)",
    "entries": [
      {
        "ts": 1780120860144,
        "source": "cron-setup",
        "severity": "error",
        "message": "cron: isolated agent run stalled before execution start (last phase: runtime-plugins)"
      }
    ]
  },
  "runAtMs": 1780120800018,
  "durationMs": 60126,
  "nextRunAtMs": 1780207200000,
  "deliveryStatus": "unknown",
  "failureNotificationDelivery": {
    "status": "unknown"
  }
}

Notable details:

• durationMs: 60126 — exactly the 60s setup timeout
• sessionId is null — the session was never created
• The next scheduled run (24h later) was unaffected and ran cleanly

Observed frequency

• Observed once on 2026-05-30 08:01 CEST for this specific cron (out of 6 historical runs since 2026-05-23)
• Subsequent scheduled runs (Sat 2026-05-30 manual retrigger, Sun 2026-05-31 08:00 scheduled) succeeded without issue
• So: looks transient / race condition during plugin discovery, not a persistent failure

Impact

1. Silent failure — failureNotificationDelivery.status: unknown means the operator gets no Telegram/Discord/webhook notification that the scheduled job failed
2. No diagnostic trail — the diagnostics.entries list contains only the timeout summary; no detail about which plugin or step actually hung
3. Operator has to manually re-trigger — openclaw cron run --id <id> worked, but only because the operator noticed the missing morning briefing

Expected behavior

Either:

• a) Plugin discovery completes within a reasonable budget (let's say 10s) so the 60s setup window has time to actually start the agent, OR
• b) On runtime-plugins-phase timeout, the runner emits a structured error to the failure-alert channel (currently goes nowhere), OR
• c) The runner exposes which plugin specifically hung so the operator can disable it

Ideally all three.

Workaround for affected users

Add --failure-alert --failure-alert-after 1 --failure-alert-channel telegram --failure-alert-to <chatid> so at least the empty-diagnostic notification reaches you, even if it doesn't tell you why it stalled.

Asks of maintainers

• Instrument the runtime-plugins phase with per-plugin timing logs (gateway.log or stderr is fine)
• Ensure failureNotificationDelivery is actually attempted when status is error, regardless of phase
• Consider a --plugins-timeout <ms> flag on cron jobs (or a global cap in ~/.openclaw/config.json) so users can tune the discovery budget

Environment

OpenClaw 2026.5.26 (10ad3aa)
macOS 26.4.1 Darwin 25.4.0 arm64
Node v26.0.0
Install: native LaunchAgent (~/.openclaw/, NOT Docker)

Happy to provide more gateway.log excerpts if useful — the run-record above is the only place where runtime-plugins appears in this setup's logs as far as I can tell.