Summary

• The cron setup watchdog that aborts an isolated agent job which has not reached runner started is a hardcoded 60_000 ms (CRON_AGENT_SETUP_WATCHDOG_MS in src/cron/service/timer.ts). It is not overridable via config.
• When several heavy isolated agent jobs come due in the same window, their setup (runtime init, plugin load, CLI handshake) contends on the single gateway event loop. A healthy agent can then exceed 60s during setup and is aborted with isolated agent setup timed out before runner start — even on idle, high-spec hosts where nothing is actually stuck.
• This change adds an optional cron.agentSetupWatchdogMs override (default 60000), clamped to a 1000 ms minimum so the safety timer can never be disabled. It mirrors the existing resolveRunConcurrency() config pattern already in the same module (state.deps.cronConfig?.maxConcurrentRuns).

Why now: operators running many isolated cron jobs on capable hardware hit false setup timeouts with no supported way to tune the budget; the only current mitigation is manually spreading job schedules.

Out of scope: the pre-execution watchdog and per-job execution timeoutSeconds are unchanged. Default behaviour is unchanged when the new field is unset.

What success looks like: with cron.agentSetupWatchdogMs set above 60s, concurrently-starting isolated jobs that previously failed setup now reach the runner; unset config behaves exactly as before.

Reviewers may want to focus on: the clamp/fallback semantics in resolveCronAgentSetupWatchdogMs (min 1000 ms; non-finite → default) — the watchdog can never be disabled.

Real behavior proof

Behavior addressed: cron.agentSetupWatchdogMs is accepted by the cron config schema and the cron timer resolver uses the configured setup watchdog budget while preserving the 60s default and 1s safety floor.

Real environment tested: Local OpenClaw contributor checkout on macOS, branch feat/configurable-cron-setup-watchdog at 3fb689ac0d, with repository dependencies already installed.

Exact steps or command run after this patch: node_modules/.bin/vitest run src/cron/service/timer.setup-watchdog.test.ts --reporter=verbose 2>&1 | grep -E '✓|Tests ' and node_modules/.bin/vitest run src/cron/service src/config/zod-schema.cron-setup-watchdog.test.ts 2>&1 | tail -8.

Evidence after fix: Terminal capture from this branch after the patch:

✓ |cron| ../../src/cron/service/timer.setup-watchdog.test.ts > resolveCronAgentSetupWatchdogMs > defaults to 60s when no override is provided 10ms
✓ |cron| ../../src/cron/service/timer.setup-watchdog.test.ts > resolveCronAgentSetupWatchdogMs > honours a valid override 0ms
✓ |cron| ../../src/cron/service/timer.setup-watchdog.test.ts > resolveCronAgentSetupWatchdogMs > floors fractional overrides 0ms
✓ |cron| ../../src/cron/service/timer.setup-watchdog.test.ts > resolveCronAgentSetupWatchdogMs > clamps overrides below the safety minimum (1s) so the watchdog cannot be disabled 0ms
✓ |cron| ../../src/cron/service/timer.setup-watchdog.test.ts > resolveCronAgentSetupWatchdogMs > falls back to the default for non-finite values 0ms
      Tests  5 passed (5)

Test Files  13 passed (13)
      Tests  123 passed (123)

Observed result after fix: The resolver proof shows default, valid override, fractional floor, minimum clamp, and non-finite fallback all passing; the broader cron service plus schema run completed with Test Files 13 passed (13) and Tests 123 passed (123).

What was not tested: No live production cron jobs were started; this PR only changes local config parsing and timer budget resolution, and the default runtime behaviour remains unchanged when the new option is unset.

Testing

• New unit test src/cron/service/timer.setup-watchdog.test.ts (5 cases: default, valid override, fractional floor, sub-minimum clamp, non-finite fallback) — passing.
• Full src/cron/service plus src/config/zod-schema.cron-setup-watchdog.test.ts run passes with no regressions.

Linked context

Closes #

Related #