Bug type

Behavior bug (model call hangs indefinitely in cron agentTurn path)

Summary

On OpenClaw 2026.6.9 (c645ec4), isolated agentTurn cron jobs consistently fail with cron: job execution timed out (last phase: model-call-started) at the configured timeout boundary. Chat sessions (main session) using the same models have zero failures over months of daily use.

Environment

• OpenClaw 2026.6.9 (c645ec4)
• macOS 26 (Darwin 25.3.0 arm64)
• Models tested: deepseek/deepseek-v4-flash, dmxapi-cn/deepseek-v4-flash, dmxapi-cn/qwen3.5-flash
• Gateway restarted multiple times during testing window

Steps to reproduce

1. Create an isolated cron job with sessionTarget: "isolated" and kind: "agentTurn"
2. Use deepseek/deepseek-v4-flash as model, timeoutSeconds: 360
3. Set a moderately long prompt (1000+ tokens)
4. Trigger via cron run --force
5. Observe: job times out at exactly timeoutSeconds with model-call-started phase

Observed behavior — 10 consecutive failures across all variables

* Test #10 used a minimal prompt ("just call sessions_spawn") — even a trivial single-action model call hangs.

Key findings:

• Changing provider (deepseek direct → dmxapi-cn proxy) → no effect
• Changing thinking level (off → low) → no effect
• Disabling lightContext → no effect
• Changing sessionTarget (isolated → persistent named session) → no effect
• Reducing task to single sessions_spawn call → no effect
• Gateway restart → no effect

Contrast: chat sessions work perfectly

The same model (deepseek-v4-flash) has been used in daily chat with 100% success rate over months. Not a single model-call-started timeout in chat.

Fallback mechanism also broken in this path

When the primary model hangs at model-call-started, configured fallback models never trigger. The cron-level timeout kills the entire run before the model-call layer can engage fallback logic.

Why this matters

• Cron is completely unusable for any agentTurn work on this version
• Users have no way to differentiate between "API is slow" vs "cron is broken"
• Raising timeoutSeconds is a red herring — the model call never actually starts
• The diagnostic message model-call-started is misleading; it suggests the call was initiated when it may not have been dispatched at all