openclaw - 💡(How to fix) Fix Native cron agent-turn fire saturates the gateway event loop (chat transports unresponsive for minutes)

Severity: high — a single scheduled job can take the gateway (and all chat transports) unresponsive for minutes.

Version: 2026.5.18 (also reproduced on 2026.5.7).

Summary: Firing one isolated-session agentTurn cron job drives the gateway event loop to full saturation. During the run, chat transports (Telegram, Discord) stop responding; recovery takes minutes.

Reproduction:

1. Create an isolated-session cron job whose payload is kind: agentTurn with a model that spawns an ACP harness (e.g. openai-codex/...), lightContext: true.
2. Fire it: openclaw cron run <id> --wait.
3. Watch GET /readyz before and during the run.

Observed (a trivial local-script agent turn):

The cron run --wait call itself failed with gateway request timeout for connect / 1006 abnormal closure. 30s after the fire the loop was still degraded (utilization 0.998, delayP99 2864ms). Telegram and Discord were unresponsive for ~3 minutes.

Expected: a single scheduled agent turn should not block the event loop or take chat transports down. Cron work should be scheduled off the hot path or bounded so /readyz stays healthy.

Notes: 2026.5.18 shipped related fixes (#82764 prioritize manual turns over cron, #82811 before_agent_reply watchdog, #69121/#82433 restart drain) but none prevents this saturation.