Summary
Cron jobs scheduled to run in the main session (sessionTarget: "main", payload.kind: "systemEvent") are being marked skipped with error:

timeout waiting for main lane to become idle

This makes cron unusable for reliable automation (e.g., “check every 5 minutes”) in an active deployment.

Environment

• OpenClaw: 2026.2.3-1 (stable)
• Host: Ubuntu 24.04.3 LTS on WSL2
• Node: 24.13.0
• Gateway mode: local / bind loopback (ws://127.0.0.1:18789)
• Cron enabled: cron.enabled = true

What I expected
A scheduled cron job targeting the main session should:

• enqueue the system event and run on the main lane as soon as possible, even if the lane is busy (queue), or
• at least not silently “skip” recurring jobs due to the lane being active.

In other words, a recurring “every 5 minutes” job should not become unreliable just because the main session is busy.

What happened
The job runs were recorded as status: "skipped" with the error timeout waiting for main lane to become idle.

Reproduction steps

1. Enable cron:
   • cron.enabled: true in ~/.openclaw/openclaw.json
2. Create a main-session cron job (every 5 minutes) with wakeMode now:

{
  "name": "cdc:check-practical-slots-5min",
  "schedule": { "kind": "cron", "expr": "*/5 * * * *", "tz": "Asia/Singapore" },
  "sessionTarget": "main",
  "wakeMode": "now",
  "payload": {
    "kind": "systemEvent",
    "text": "CDC auto-check (every 5 min): …"
  }
}

3. Keep the main session active/busy (normal use: chatting, browser relay automation, tool calls).
4. Observe cron run history showing skipped runs.

Evidence
Cron run JSONL file:

• ~/.openclaw/cron/runs/bb43ab8c-df55-44bc-ac83-b6ad482a5ff1.jsonl

Example entry:

{"ts":1770394267036,"jobId":"bb43ab8c-df55-44bc-ac83-b6ad482a5ff1","action":"finished","status":"skipped","error":"timeout waiting for main lane to become idle","summary":"Reminder: check CDC Booking Portal Practical Lesson (Class 3 Motorcar) now. Book/reserve only slots whose start time is between 08:00–18:00 SGT. Target total bookings: 10 slots max, 1 per day. If a verification code/captcha is required, ask the user to enter it in the portal. Ask before any irreversible payment/confirmation step.","runAtMs":1770394146856,"durationMs":120177,"nextRunAtMs":1770394320000}

Also confirmed:

• openclaw cron run <jobId> --force can execute jobs and write run history, so the cron engine itself works; the problem is scheduler execution for main-session jobs under load.

Impact
Any “polling” automation that must run in main session (e.g., controlling a Chrome Relay tab) becomes unreliable and effectively non-automatable.

Suggested fix / questions

• Should main-session cron jobs queue instead of skip when the main lane is busy?
• If skipping is intended, can we configure a much longer wait/backoff, or a guaranteed eventual enqueue?
• Can the cron job be re-tried rather than marked skipped?