PR #60210: fix(agents): disable default cron idle timeout for isolated runs

• Repository: openclaw/openclaw
• Author: skainguyen1412
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60210

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: isolated cron runs inherited the embedded runner's generic 60-second LLM idle timeout even when the cron job's payload.timeoutSeconds was much higher.
• Why it matters: scheduled background jobs can legitimately stay quiet for longer than 60 seconds, so they were aborting early and looked like cron was ignoring payload.timeoutSeconds.
• What changed: cron-triggered embedded runs now disable the default idle watchdog unless agents.defaults.llm.idleTimeoutSeconds is explicitly configured; added regression coverage for the trigger-aware policy.
• What did NOT change (scope boundary): cron's outer timeout logic did not change, manual/scheduled cron execution plumbing did not change, and explicit agents.defaults.llm.idleTimeoutSeconds still wins when set.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #60175
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: the embedded runner's default LLM idle timeout (60_000ms) was applied to all triggers, including cron, even though scheduled background runs can be intentionally quiet for longer than that.
• Missing detection / guardrail: there was no test asserting that cron-triggered runs should not inherit the generic default idle timeout.
• Prior context (git blame, prior PR, issue, or refactor if known): the idle-timeout behavior came from feat: add LLM idle timeout for streaming responses (84b72e66b91); cron already had separate outer timeout coverage and logic.
• Why this regressed now: once the idle-timeout feature shipped in 2026.4.1, cron-triggered embedded runs started picking up the same default 60-second watchdog as interactive runs.
• If unknown, what was ruled out: ruled out cron scheduler timeout ignoring payload.timeoutSeconds; the cron outer timeout path still honors job timeouts and already has regression coverage.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

• Coverage level that should have caught this:
• Unit test
• Seam / integration test
• End-to-end test
• Existing coverage already sufficient
• Target test or file: src/agents/pi-embedded-runner/run/llm-idle-timeout.test.ts
• Scenario the test should lock in: cron-triggered runs default to no LLM idle timeout unless agents.defaults.llm.idleTimeoutSeconds is explicitly configured; explicit config still applies to cron.
• Why this is the smallest reliable guardrail: the regression lives in trigger-aware timeout resolution, so a focused unit test on that resolver catches the behavior without needing a live cron/provider setup.
• Existing test that already covers this (if any): src/cron/service.issue-regressions.test.ts already covers cron honoring payload.timeoutSeconds on the outer timeout path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Isolated cron runs no longer abort at the default 60-second LLM idle timeout just because the model stays quiet for a while.
• If users explicitly set agents.defaults.llm.idleTimeoutSeconds, cron runs still use that configured value.
• No config migration is required.

Diagram (if applicable)

Before:
[cron isolated run] -> [default LLM idle watchdog = 60s] -> [abort around 60s]

After:
[cron isolated run] -> [default idle watchdog disabled for cron] -> [cron outer timeout / explicit llm idle timeout decides outcome]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node v22.22.1
• Model/provider: N/A for verification; targeted repo tests only
• Integration/channel (if any): cron isolated runner
• Relevant config (redacted): payload.timeoutSeconds > 60, agents.defaults.llm.idleTimeoutSeconds unset

Steps

1. Create an isolated cron job with a long payload.timeoutSeconds.
2. Let the embedded run stay quiet long enough to cross the generic LLM idle watchdog window.
3. Observe the run abort around 60 seconds even though the cron job timeout is higher.

Expected

• Cron-triggered isolated runs should not inherit the generic 60-second idle timeout by default.

Actual

• They inherited the generic default idle timeout and could abort around 60 seconds.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • Ran ./node_modules/.bin/vitest run src/agents/pi-embedded-runner/run/llm-idle-timeout.test.ts
  • Ran ./node_modules/.bin/vitest run src/cron/service.issue-regressions.test.ts -t "applies timeoutSeconds to manual cron.run isolated executions"
  • Ran pnpm build
• Edge cases checked:
  • explicit idleTimeoutSeconds: 0 still disables the watchdog
  • explicit cron idle timeout still applies when configured
  • non-cron default behavior remains unchanged
• What you did not verify:
  • no live end-to-end scheduled cron run against a real provider/channel
  • no manual vs scheduled real-world repro on a running gateway instance

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: users who implicitly relied on the default 60-second idle watchdog for cron-triggered runs will now see those runs continue until the cron outer timeout or an explicit idle-timeout config applies.
• Mitigation: explicit agents.defaults.llm.idleTimeoutSeconds is still honored, and the new regression test locks in the cron-only default behavior change.

Changed files

• src/agents/pi-embedded-runner/run/attempt.ts (modified, +4/-1)
• src/agents/pi-embedded-runner/run/llm-idle-timeout.test.ts (modified, +20/-8)
• src/agents/pi-embedded-runner/run/llm-idle-timeout.ts (modified, +12/-3)