OpenClaw 2026.3.8: cron sessionTarget="isolated" + agentTurn can time out on a minimal prompt

Summary

On OpenClaw 2026.3.8, cron jobs using:

• sessionTarget: "isolated"
• payload.kind: "agentTurn"

can fail with:

• Error: cron: job execution timed out
• inner log: FailoverError: LLM request timed out.

This reproduces even with a minimal prompt and delivery.mode: "none".

A minimal control job using:

• sessionTarget: "main"
• payload.kind: "systemEvent"

succeeds.

Minimal reproduction

Failing repro

{
  "name": "tmp-repro-isolated-testok",
  "schedule": { "kind": "every", "everyMs": 86400000 },
  "payload": {
    "kind": "agentTurn",
    "message": "Reply with exactly: TEST_OK",
    "model": "iflow/qwen3-max",
    "timeoutSeconds": 30
  },
  "delivery": { "mode": "none" },
  "sessionTarget": "isolated",
  "enabled": false
}

Observed:

• status: error
• error: Error: cron: job execution timed out
• duration: ~30s
• inner lane log: FailoverError: LLM request timed out.

Passing control

{
  "name": "tmp-repro-main-testok",
  "schedule": { "kind": "every", "everyMs": 86400000 },
  "payload": {
    "kind": "systemEvent",
    "text": "Test task: reply with exactly TEST_OK"
  },
  "delivery": { "mode": "none" },
  "sessionTarget": "main",
  "enabled": false
}

Observed:

• status: ok
• duration: ~6s

Key findings

1. This does not appear to be primarily a queue-wait accounting bug

Source analysis shows cron timeout is applied inside executeJobCoreWithTimeout(...) around executeJobCore(...), not during the earlier manual-run queue wait.

2. The isolated run actually starts and runs for the full timeout budget

Logs show isolated session-lane tasks themselves running for roughly the full configured timeout before failing, e.g.:

• lane=session:agent:cron-min:cron:... durationMs=29969 error="FailoverError: LLM request timed out."
• lane=session:agent:main:cron:... durationMs=30020/60023/120004/... error="FailoverError: LLM request timed out."

So this does not look like a case where execution never began.

3. The timeout is generated inside the embedded runner

Source analysis shows this chain:

1. cron resolves timeoutMs from payload.timeoutSeconds via resolveAgentTimeoutMs(...)
2. cron passes that into runEmbeddedPiAgent({ ..., timeoutMs, ... })
3. runEmbeddedPiAgent(...) creates an internal abort timer
4. when it fires, it calls abortRun(true)
5. the run is marked timed out and later surfaced as:
   • LLM request timed out.
   • wrapped in FailoverError

So the timeout is not just an outer cron wrapper decision; it is the embedded path's own timeout machinery firing.

4. The prompt path is actually invoked

Source analysis confirms embedded runs do call:

• await abortable(activeSession.prompt(effectivePrompt))

So this is not explained by the prompt never being submitted.

5. Most likely failing window

Given the above, the most likely failing window is:

• after activeSession.prompt(...) begins
• before the first assistant output/token is produced

In other words, the isolated cron embedded path appears able to stall or run too slowly between prompt dispatch and first output, until the embedded runner's own timeoutMs abort timer fires.

Possibly related

• bug(cron): job timeout includes cron-lane queue wait time #41783 / PR fix(cron): start isolated job timeout after queue wait #41796 — isolated cron timeout after queue wait

  • Related, but this report suggests queue wait is not the primary remaining cause in this repro.

• [Bug]: Isolated cron agentTurn jobs hang until timeout — providers reachable, interactive sessions unaffected #42464 / PR fix(cron): per-attempt AbortControllers and deferred execution timeout #42482 — per-attempt AbortControllers and deferred execution timeout

  • Highly related.
  • This report adds a minimal repro plus source/log evidence showing the timeout fires inside the embedded runner after activeSession.prompt(...) is invoked.

• Cron agentTurn jobs: timeouts + context truncation despite sessionTarget=isolated / maxMessages caps #22125 — isolated cron agentTurn timeouts despite isolation / maxMessages caps

  • Related, but this report narrows further by removing delivery, long prompts, and context size as likely causes.

• openclaw models status --probe returns LLM request timed out on 2026.3.8 #41874 — LLM request timed out. on 2026.3.8 model probe

  • Possibly only related at the lower timeout/error surface.

Expected

The isolated minimal job should complete successfully and return TEST_OK within 30s.

Actual

The isolated minimal job times out and fails with LLM request timed out. / cron: job execution timed out.

Environment

• OpenClaw: 2026.3.8
• OS: Linux 6.8.12-19-pve
• Node: 22.22.0

Workaround observed

A production failing isolated cron job was changed to:

• sessionTarget: "main"
• payload.kind: "systemEvent"

That workaround succeeded.