openclaw - 💡(How to fix) Fix Update to 2026.4.1 breaks cron jobs: API timeout not respecting agents.defaults.timeoutSeconds [8 comments, 7 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59678Fetched 2026-04-08 02:41:47
View on GitHub
Comments
8
Participants
7
Timeline
8
Reactions
4

After updating from 2026.3.31 to 2026.4.1, cron jobs that previously worked are now failing with:

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

Error Message

The error message tells users to increase agents.defaults.timeoutSeconds, but that setting is being ignored.

Root Cause

Root Cause (suspected)

Code Example

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

---

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 1800,
      "model": {
        "primary": "anthropic/claude-opus-4-5"
      }
    }
  }
}

---

/usr/local/lib/node_modules/openclaw/dist/io-CHHRUM9X.js:
  llm: z.object({ idleTimeoutSeconds: z.number()...
  "Idle timeout for LLM streaming responses in seconds. If no token is received within this time, the request is aborted. Set to 0 to disable. Default: 60 seconds."
RAW_BUFFERClick to expand / collapse

Summary

After updating from 2026.3.31 to 2026.4.1, cron jobs that previously worked are now failing with:

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

Problem

The timeout is happening at ~66 seconds despite:

  • agents.defaults.timeoutSeconds set to 1800 (30 min)
  • Individual job timeoutSeconds set to 1800

The error message tells users to increase agents.defaults.timeoutSeconds, but that setting is being ignored.

Evidence

JobExplicit TimeoutActual DurationStatus
twitter-replies-unified1800s68s❌ timeout
defiprime-twitter-replies1800s66s❌ timeout
defiprime-respond-to-replies300s65s❌ timeout

These same jobs worked fine on 2026.3.31 (25-27 min execution time).

Config

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 1800,
      "model": {
        "primary": "anthropic/claude-opus-4-5"
      }
    }
  }
}

Root Cause (suspected)

Looking at the source:

/usr/local/lib/node_modules/openclaw/dist/io-CHHRUM9X.js:
  llm: z.object({ idleTimeoutSeconds: z.number()...
  "Idle timeout for LLM streaming responses in seconds. If no token is received within this time, the request is aborted. Set to 0 to disable. Default: 60 seconds."

There's an llm.idleTimeoutSeconds that defaults to 60s, but:

  1. It's not documented
  2. It's not exposed in the config schema (I tried to set it, got "Unrecognized key")
  3. It overrides the user-facing timeoutSeconds setting

Expected Behavior

  • agents.defaults.timeoutSeconds should control the overall timeout
  • If there's an internal idle timeout, it should be configurable
  • Updates should not break existing working workflows

Environment

  • OpenClaw: 2026.4.1 (da64a97)
  • Previous version: 2026.3.31 (worked fine)
  • OS: macOS Darwin 24.6.0
  • Node: v25.5.0
  • Model: anthropic/claude-opus-4-5

extent analysis

TL;DR

  • The likely fix involves configuring or exposing the llm.idleTimeoutSeconds setting to override its default 60-second timeout, which is currently overriding the user-set timeoutSeconds.

Guidance

  • Investigate the source code of openclaw to find a way to configure llm.idleTimeoutSeconds, possibly through an environment variable or an undocumented configuration option.
  • Consider reaching out to the maintainers of openclaw to report the issue and request that llm.idleTimeoutSeconds be exposed in the configuration schema.
  • Verify that the timeoutSeconds setting is being correctly applied to the individual jobs by checking the job configuration and logs.
  • Test setting llm.idleTimeoutSeconds to a higher value (e.g., 1800) if a configuration method is found, to see if it resolves the timeout issue.

Example

  • No code snippet can be provided without knowing the exact configuration method for llm.idleTimeoutSeconds, but an example might look like adding a new configuration option: "llm": { "idleTimeoutSeconds": 1800 } if such an option were exposed.

Notes

  • The fix may require changes to the openclaw library itself, rather than just the user's configuration.
  • The llm.idleTimeoutSeconds setting is not currently documented, so its behavior and potential side effects are unknown.

Recommendation

  • Apply workaround: Try to find an undocumented way to configure llm.idleTimeoutSeconds or wait for an update to openclaw that exposes this setting, as upgrading to a fixed version is not currently an option.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Update to 2026.4.1 breaks cron jobs: API timeout not respecting agents.defaults.timeoutSeconds [8 comments, 7 participants]