Summary

When an isolated agentTurn cron job completes its work and exits cleanly, the cron scheduler still logs status: error with error: "cron: job execution timed out". The session itself exits with stopReason: "stop" and all work is delivered — the timeout error is false.

Environment

• OpenClaw: v2026.4.15
• Cron job: sessionTarget: "isolated", payload.kind: "agentTurn", timeoutSeconds: 600

Steps to Reproduce

1. Create an isolated agentTurn cron job that does meaningful work (e.g., system status report, Discord delivery)
2. Set timeoutSeconds: 600
3. Job completes in ~10-12 minutes
4. Check openclaw cron runs --id <job-id> — shows status: error, error: "cron: job execution timed out", durationMs: 600XXX
5. But the session transcript shows the agent exited with stopReason: "stop" and posted all content to Discord before the timeout fired

Expected Behavior

When the embedded isolated session exits cleanly with stopReason: "stop" and the agent has delivered all expected output, the cron run should be recorded as status: ok — not status: error.

Actual Behavior

• Session transcript shows: agent completed all work, posted to Discord, exited with stopReason: "stop"
• Cron run log shows: status: "error", error: "cron: job execution timed out", durationMs: 600XXX
• Discord: report was delivered successfully
• deliveryStatus: unknown (announce delivery not recorded, but agent-side delivery via exec/curl worked)

Evidence

Session transcript shows:

• Session started normally, ran checks
• Agent composed and posted full report to Discord via exec curl calls (two parts posted successfully)
• Agent exited with stopReason: "stop" and HEARTBEAT_OK message
• Total session time: ~11 minutes

But cron run history shows:

status: error
error: "cron: job execution timed out"  
durationMs: 600065

Hypothesis

The job-level setTimeout in executeJobCoreWithTimeout fires at exactly 600,000ms and races against the embedded runner's clean completion. When the embedded runner finishes first and exits cleanly, the job-level timeout has already been scheduled and fires afterward — incorrectly marking the job as timed out.

OR: The job runner's completion signal and timeout signal race, with the timeout error overwriting the clean completion status.

Impact

• Cron run history shows false errors
• consecutiveErrors counter increments incorrectly
• Monitoring/alerting based on lastRunStatus produces false positives
• The actual work is not lost (agent delivers via exec/curl), but the scheduler's record is wrong

Related

• Issue #63805 (300s job-level timeout) — same root cause area
• Issue #61913 (Cron Announce Delivery Reports False Success) — opposite pattern
• Issue #64005 (Cron lastError persists when later retry delivers successfully) — related false-state pattern