openclaw - 💡(How to fix) Fix Cron runs can be recorded as ok when the agent ends gracefully after reporting a real blocker and producing no expected outputs

Summary

A cron run can be recorded as ok even when the agent reports a real blocker, stops early as instructed, and produces none of the expected outputs. This appears to happen when graceful turn completion is treated as job success.

Actual behavior

Observed failure cases include runs where the agent reports a concrete execution blocker such as:

• sandbox permission denial
• network access denial
• required command failure before the main work begins

The agent then exits cleanly with a human-readable explanation, but the cron ledger records the run as ok even though expected artifacts were not produced.

Expected behavior

A run should not be recorded as ok merely because the agent finished its turn cleanly. If the skill reports a blocking failure or fails to produce required outputs, the job outcome should be non-success.

Why this matters

This creates false positives in cron status. Operators have to manually inspect output artifacts or read the full summary to determine whether the job actually succeeded.

Minimal repro

1. Run a cron skill whose instructions tell the agent to stop and report the blocker if an early required step fails
2. Make that required step fail with a real runtime blocker
3. Let the agent end gracefully with an explanatory summary
4. Observe the cron run being recorded as ok even though no expected outputs were written

Expected fix direction

• separate agent turn completed from job succeeded
• use explicit structured outcome reporting from the skill or runtime
• optionally validate expected output state before recording ok

Environment

• OpenClaw 2026.5.19
• Linux