Skip to content

[Bug]: Isolated cron agentTurn fails with 'setup timed out before runner start' — all fallback models exhausted on 2026.5.12 #82662

Description

@Andy283

Bug type

Regression (worked before, now fails)

Summary

Isolated agentTurn cron job (auto-created by memory-core plugin) fails with "cron: isolated agent setup timed out before runner start". The failure occurs before the LLM is even invoked — all 6 fallback candidates hit the same setup-phase timeout. The gateway is healthy and interactive sessions work fine concurrently.

Environment

  • OpenClaw version: 2026.5.12 (f066dd2)
  • OS: macOS 15.7.5 (x64), Node 24.15.0
  • Gateway: LaunchAgent, pid 61734, loopback (127.0.0.1:18789)
  • Model config: primary deepseek/deepseek-v4-flash, fallback chain: xiaomi-coding/mimo-v2.5mimo-v2.5-promimo-v2-omnimimo-v2-prodeepseek/deepseek-v4-pro

Cron Job Details

Name:           Memory Dreaming Promotion
ID:             8633cd15-5bd6-48ab-9e8d-91d8e530741b
Schedule:       cron 0 */8 * * * (stagger 5m)
Session target: isolated
Payload kind:   agentTurn
Light context:  true
Managed by:     memory-core plugin (short-term-promotion)

Steps to Reproduce

  1. Allow a memory-core managed cron job with sessionTarget: "isolated" to fire on schedule
  2. Observe failure in openclaw cron list → status: error

Actual Behavior

The job runs for 71 seconds, then fails with:

cron: isolated agent setup timed out before runner start

The model fallback chain exhausts all 6 candidates — each fails with the same setup-phase timeout (not LLM timeout):

attempt 1/6: deepseek/deepseek-v4-flash       → timeout (status 408)
attempt 2/6: xiaomi-coding/mimo-v2.5          → timeout (status 408)
attempt 3/6: xiaomi-coding/mimo-v2.5-pro      → timeout (status 408)
attempt 4/6: xiaomi-coding/mimo-v2-omni       → timeout (status 408)
attempt 5/6: xiaomi-coding/mimo-v2-pro        → timeout (status 408)
attempt 6/6: deepseek/deepseek-v4-pro         → timeout (status 408)
→ chain_exhausted

Key observation: This is NOT an LLM request timeout. The error "setup timed out before runner start" indicates the isolated agent process itself fails to initialize — the runner never starts. The timeout is burned during agent setup, not during model inference.

What Works (concurrently)

  • Interactive sessions on the same gateway: ✅ instant response
  • openclaw gateway status: ✅ running, connectivity ok
  • openclaw doctor: ✅ 0 errors, 5 plugins loaded
  • openclaw channels status --probe: ✅ Feishu works

Consecutive Errors

consecutiveErrors: 1 — this was the first failure. Not a repeated pattern (yet). Will monitor next run.

Related Issues

Issue Version Symptom Relationship
#42464 2026.3.8+ isolated cron hangs, Profile X:default timed out Similar — but their error is at provider profile level, ours is at agent setup level
#42632 2026.3.8+ minimal prompt times out, LLM request timed out Similar — but their error is during LLM execution, ours is before runner starts
#43850 2026.3.8+ timeout budget burned in cron lane Related root cause area
#61118 2026.4.2+ 60-75s timeout on isolated cron Same pattern, different version
#64497 2026.4.9+ isolated agentTurn fails to spawn session Most similar — no session spawned

Hypothesis

The "setup timed out before runner start" error suggests the embedded runner fails during agent/session initialization — before any model call is made. Possible causes:

  1. Session spawn contention (main session active when cron fires)
  2. Agent workspace bootstrap timeout (large workspace with many files)
  3. Auth/credential loading stall during isolated agent setup

Logs

Structured log entry:

{
  "time": "2026-05-17T00:02:28.507+08:00",
  "level": "WARN",
  "module": "cron",
  "jobId": "8633cd15-5bd6-48ab-9e8d-91d8e530741b",
  "jobName": "Memory Dreaming Promotion",
  "error": "cron: isolated agent setup timed out before runner start",
  "lastDurationMs": 71365
}

Expected behavior

The isolated cron job should initialize the agent runner and execute within the timeout window, or at minimum provide a more actionable error (which phase of setup failed, what was blocking).

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions