What happened?

An isolated cron job using payload.kind = "agentTurn" appears to get stuck in a stale/running state and often times out, even for a lightweight task.

The task is intentionally simple:

1. Run clawhub explore --limit 10 --json
2. Read the first 10 items
3. Rewrite them into 10 short lines
4. Deliver to Telegram via normal cron announce

The underlying clawhub command is fast when run directly, and direct Telegram sends also work. But the same logic inside OpenClaw cron repeatedly hangs or times out.

Environment

• OpenClaw: 2026.3.8
• Node: v22.22.0
• Session target: isolated
• Payload kind: agentTurn
• Delivery: announce to Telegram
• Timeout: 900s
• lightContext: true

Repro config

Cron job payload:

{
  "kind": "agentTurn",
  "message": "使用 clawhub skill，并且只做下面这件事：\n\n1. 执行一次 clawhub explore --limit 10 --json\n2. 只读取返回 JSON 里的 items 前 10 条\n3. 基于每条的 slug 和 summary，整理成 10 行中文摘要\n4. 每行格式固定为：序号. slug - 简短中文描述\n5. 不要读取其他文件，不要运行其他 clawhub 命令，不要搜索，不要展开分析\n6. 不要输出思考、步骤、工具调用、JSON 原文、标题或结尾说明\n7. 只输出最终这 10 行文本，系统会自动投递到 Telegram",
  "timeoutSeconds": 900,
  "lightContext": true
}

Repro steps

1. Configure an isolated cron job with the payload above
2. Trigger it manually with openclaw cron run <job-id>
3. Observe cron state, run history, and logs

Expected behavior

• The job should finish within a few minutes
• It should produce 10 short lines
• It should be delivered through cron announce

Actual behavior

Observed repeatedly:

• cron list sometimes shows the job as running even after the previous run already finished with error
• manual runs can get queued behind a stale slot:
  • cron: queued manual run waiting for an execution slot
• old stale running markers seem to survive until gateway restart
• after restart, state may clear, but the next run can still get stuck again
• many runs end as:
  • Error: cron: job execution timed out
• logs show:
  • FailoverError: LLM request timed out.

Evidence

Timed-out runs:

• runAtMs: 1773365921979, durationMs: 900004, status: error
• runAtMs: 1773326195890, durationMs: 900003, status: error
• runAtMs: 1773324907261, durationMs: 900004, status: error

Example log lines:

cron: queued manual run waiting for an execution slot

FailoverError: LLM request timed out.

lane=session:agent:main:cron:<job-id> durationMs=900028 error="FailoverError: LLM request timed out."

Also observed earlier:

cron: clearing stale running marker on startup

Why this seems like an OpenClaw bug

The same underlying operations succeed outside cron:

• clawhub explore --limit 10 --json returns quickly when run directly
• direct Telegram send via openclaw message send succeeds

So this does not look like:

• ClawHub CLI slowness
• Telegram delivery failure
• large output size

It looks more like a cron / isolated agentTurn state-machine or execution-slot bug.

Additional note

A much simpler 3-line version of the same ClawHub task did succeed once, which suggests the cron lane is sensitive in a way that direct command execution is not.