Summary

Isolated cron jobs that run longer than 600 seconds are always logged as
status: "error" with "cron: job execution timed out", even when the
orchestrator session continues running, receives all sub-agent Push results,
and completes its work successfully.

Additionally, agents.defaults.timeoutSeconds and CLI --timeout flags
appear to have no effect on this 600s threshold.

Steps to reproduce

• OpenClaw 2026.2.23 (6c441ea)
• macOS arm64 (Mac Studio)
• Model: anthropic/claude-sonnet-4-6

1. Register a one-shot isolated cron job that spawns multiple sub-agents
   via sessions_spawn with varying sleep durations (e.g., 1min, 10min, 15min)
2. Orchestrator waits for all sub-agent Push results before sending a Slack DM
3. Job runs longer than 600 seconds
4. Check openclaw cron runs --id <jobId>

Expected behavior

openclaw cron runs --id <jobId> returns:

{
"status": "error",
"error": "cron: job execution timed out",
"durationMs": 600018,
"deliveryStatus": "unknown"
}

• status is always "error" when job duration exceeds 600s
• durationMs is always exactly ~600000ms regardless of actual runtime
• summary field is absent
• deliveryStatus is "unknown"

Despite this, the orchestrator session was NOT actually dead:

• Slack DM arrived at exactly start_time + 15min (correct completion time)
• DM content matched the orchestrator's completion message exactly
• All sub-agent Push results were received and processed correctly

Actual behavior

• agents.defaults.timeoutSeconds: 1200 should be respected by isolated
  cron sessions — jobs should not be marked as timed out at 600s
• status should reflect actual outcome: "ok" if job completed successfully
• durationMs should reflect actual wall-clock duration, not the timeout
  threshold
• summary should contain the orchestrator's final output text
• deliveryStatus should reflect actual delivery result

OpenClaw version

2026.2.23 (6c441ea)

Operating system

macOS arm64 (Mac Studio) -

Install method

• macOS app (OpenClaw.app) via official installer

Logs, screenshots, and evidence

| Test | Timers        | Timeout Config                       | Log Status | durationMs | DM Received |
|------|---------------|--------------------------------------|------------|------------|-------------|
| 1    | 1min x3       | default                              | ok         | 79s        | ✅          |
| 2    | 1, 3, 5min    | CLI --timeout 600                    | ok         | 326s       | ✅          |
| 3    | 1, 5, 10min   | CLI --timeout 1800                   | error      | 599s       | ✅          |
| 4    | 1, 10, 15min  | agents.defaults.timeoutSeconds: 1200 | error      | 600s       | ✅          |

Pattern: Jobs under 600s → `status: ok`. Jobs over 600s → `status: error`.
600s threshold appears hardcoded regardless of timeout configuration.
CLI `--timeout` and `agents.defaults.timeoutSeconds` both appear ineffective.

## Additional Issue: Cron Session History Inaccessible

Debugging via `sessions_history` on the cron session key returns:

{
  "status": "forbidden",
  "error": "Session history visibility is restricted to the current session
            tree (tools.sessions.visibility=tree)."
}

This makes post-mortem debugging of cron jobs impossible from within the
agent itself.

Impact and severity

• Long-running cron jobs (>10min) cannot be reliably monitored via logs
• status: error in logs does not reflect actual job outcome
• No way to distinguish real failures from successful long-running jobs
• Timeout configuration options (--timeout CLI flag,
agents.defaults.timeoutSeconds, payload.timeoutSeconds) need
clarification — it's unclear which one actually controls cron session timeout

Additional information

No response