Description

The timeoutSeconds field in cron job payload objects is not respected by the gateway. All isolated cron sessions use a hardcoded 600-second timeout regardless of the per-job setting.

Steps to Reproduce

1. Create a cron job with payload.timeoutSeconds: 120:

{
  "id": "example",
  "payload": {
    "kind": "agentTurn",
    "model": "ollama/qwen2.5:7b",
    "message": "Read ~/.openclaw/cron/jobs.json and summarize it",
    "timeoutSeconds": 120
  }
}

2. Force-run the job: openclaw cron run <id>

3. Observe in gateway.err.log:

[agent/embedded] embedded run timeout: runId=... timeoutMs=600000

The gateway always uses timeoutMs=600000 (600s) instead of the configured 120000 (120s).

Expected Behavior

The gateway should respect the per-job timeoutSeconds value, or at minimum document that it's ignored and that 600s is the fixed embedded timeout.

Actual Behavior

timeoutSeconds is silently ignored. All isolated cron sessions use 600s regardless of configuration.

Impact

• Jobs that should fail fast (120s) hang for 10 minutes before timing out
• Wastes Ollama/model compute on doomed runs
• Makes model watchdog unreliable (designed for quick checks, hangs for 10 min)
• No workaround available at the cron job level

Environment

• OpenClaw version: latest (installed via npm, as of 2026-02-16)
• Node.js: v25.6.0
• macOS Darwin 25.3.0
• Cron session target: isolated
• Payload kind: agentTurn

Suggested Fix

Either:

1. Read payload.timeoutSeconds and pass it as timeoutMs to the embedded agent runner
2. Add a top-level cron config for default timeout (e.g., cron.defaultTimeoutSeconds)
3. Document the 600s hardcoded limit if intentional