Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Ollama local model still hits ~5 minute "Headers Timeout Error" on 2026.4.15 despite increased OpenClaw timeouts [1 pull requests]

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…

When running OpenClaw against a slow local Ollama model, the request still appears to die at about 5 minutes with:

fetch failed | Headers Timeout Error

This happens even after increasing the OpenClaw timeout, and on a version that already includes the Ollama timeout fix (2026.4.15).

It looks like the failure happens before the first response token/chunk arrives, so this seems to be the HTTP/undici layer rather than the normal OpenClaw LLM idle timeout.

Environment

  • OpenClaw: 2026.4.15 (041266a)
  • Host: Oracle A1 VPS
  • CPU / RAM: 4 CPUs, 24 GB RAM
  • Model provider: local Ollama
  • Model: qwen3.5:9b
  • Use case: async/background agent tasks, so slow execution is acceptable

Error Message

fetch failed | Headers Timeout Error 5. Observe that the run still fails at about 5 minutes with Headers Timeout Error

  • The error is specifically Headers Timeout Error, which suggests the request may still be hitting an undici-level timeout before the first byte/chunk is returned 06:04:31+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end 06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end 06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":null,"provider":"ollama","model":"qwen3.5:9b","sourceProvider":"ollama","sourceModel":"qwen3.5:9b","profileId":"sha256:9c018ec112cf","fallbackConfigured":false,"timedOut":false,"aborted":false,"rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run failover decision

Root Cause

When running OpenClaw against a slow local Ollama model, the request still appears to die at about 5 minutes with:

fetch failed | Headers Timeout Error

This happens even after increasing the OpenClaw timeout, and on a version that already includes the Ollama timeout fix (2026.4.15).

It looks like the failure happens before the first response token/chunk arrives, so this seems to be the HTTP/undici layer rather than the normal OpenClaw LLM idle timeout.

Environment

  • OpenClaw: 2026.4.15 (041266a)
  • Host: Oracle A1 VPS
  • CPU / RAM: 4 CPUs, 24 GB RAM
  • Model provider: local Ollama
  • Model: qwen3.5:9b
  • Use case: async/background agent tasks, so slow execution is acceptable

Fix Action

Fixed

PR fix notes

PR #69433: fix(infra/net): propagate global stream timeout onto pinned http/1.1 dispatchers

Description (problem / solution / changelog)

Summary

Fixes #69390. On 2026.4.15, slow local Ollama runs still failed at ~5 minutes with Headers Timeout Error even after increasing OpenClaw timeouts. The Ollama chat stream path routes through fetchWithSsrFGuard, which builds per-request pinned undici Agent / EnvHttpProxyAgent dispatchers via createHttp1Agent / createHttp1EnvHttpProxyAgent. Those pinned dispatchers do not inherit the global dispatcher's headersTimeout / bodyTimeout, so they fell back to undici's default headersTimeout = 300_000 ms while waiting for the first token.

The 2026.4.15 fix (b4bbf06816) correctly wired the configured timeout onto the global dispatcher via ensureGlobalUndiciStreamTimeouts({ timeoutMs }), but SSRF-guarded flows bypass that global entirely.

Fix

  1. ensureGlobalUndiciStreamTimeouts now also records the last applied timeout in a module-level lastAppliedTimeoutMs, exposed via a new getter getEffectiveUndiciStreamTimeoutMs() (returns null when no explicit timeout has been configured yet).
  2. createHttp1Agent and createHttp1EnvHttpProxyAgent now call a withEffectiveStreamTimeouts(...) helper that mirrors that effective value onto pinned dispatcher options only when the caller has not already set headersTimeout/bodyTimeout (per-field, via hasOwnProperty).
  3. createHttp1ProxyAgent is intentionally not touched — explicit proxy routing keeps its existing semantics.

Net result: once the user configures a longer embedded-agent run timeout, slow Ollama first-token latency is honored end-to-end instead of silently capping at 5 minutes.

Test plan

  • Added src/infra/net/undici-runtime.test.ts (new) — 5 cases covering:
    • no injection when effective is null
    • mirrors effective timeout onto pinned Agent / EnvHttpProxyAgent
    • caller-provided timeouts win over effective
    • only the missing half of the pair is injected
    • allowH2: false is preserved throughout
  • Extended src/infra/net/undici-global-dispatcher.test.ts — getter exposes last applied value; leaves it null when dispatcher kind is unsupported.
  • FAST_COMMIT=1 pnpm test src/infra/net — 7 test files, 93 tests all pass.
  • Typecheck clean.

Notes

  • No behavior change for callers that already pass explicit headersTimeout/bodyTimeout (e.g. short SSRF-guard connect probes).
  • Default remains DEFAULT_UNDICI_STREAM_TIMEOUT_MS = 30 * 60 * 1000, so until ensureGlobalUndiciStreamTimeouts has been called the getter returns null and pinned dispatchers keep undici's defaults — zero regression risk for non-embedded paths.
  • Changelog entry added under Unreleased → Fixes, tagged [AI-assisted].

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/infra/net/undici-global-dispatcher.test.ts (modified, +25/-0)
  • src/infra/net/undici-global-dispatcher.ts (modified, +13/-0)
  • src/infra/net/undici-runtime.test.ts (added, +103/-0)
  • src/infra/net/undici-runtime.ts (modified, +43/-2)

Code Example

06:04:31+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end
06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end
06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":null,"provider":"ollama","model":"qwen3.5:9b","sourceProvider":"ollama","sourceModel":"qwen3.5:9b","profileId":"sha256:9c018ec112cf","fallbackConfigured":false,"timedOut":false,"aborted":false,"rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run failover decision

---
RAW_BUFFERClick to expand / collapse

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

When running OpenClaw against a slow local Ollama model, the request still appears to die at about 5 minutes with:

fetch failed | Headers Timeout Error

This happens even after increasing the OpenClaw timeout, and on a version that already includes the Ollama timeout fix (2026.4.15).

It looks like the failure happens before the first response token/chunk arrives, so this seems to be the HTTP/undici layer rather than the normal OpenClaw LLM idle timeout.

Environment

  • OpenClaw: 2026.4.15 (041266a)
  • Host: Oracle A1 VPS
  • CPU / RAM: 4 CPUs, 24 GB RAM
  • Model provider: local Ollama
  • Model: qwen3.5:9b
  • Use case: async/background agent tasks, so slow execution is acceptable

Steps to reproduce

  1. Run OpenClaw 2026.4.15
  2. Configure it to use local Ollama with qwen3.5:9b
  3. Trigger an embedded agent run with enough context that the model is very slow to produce its first output
  4. Increase OpenClaw timeout settings
  5. Observe that the run still fails at about 5 minutes with Headers Timeout Error

Notes

  • This is on 2026.4.15, so it seems to persist even after the recent Ollama timeout fix
  • The error is specifically Headers Timeout Error, which suggests the request may still be hitting an undici-level timeout before the first byte/chunk is returned
  • I am using a very slow CPU-only setup intentionally, so long first-token latency is expected in this environment
  • It would be helpful if either:
    • the Ollama request fully respected the configured OpenClaw timeout, or
    • there were a documented config knob for the underlying undici headers/body timeout

Expected behavior

If I increase the OpenClaw timeout, I expect slow local Ollama runs to keep waiting for the first token/chunk instead of failing after about 5 minutes.

Actual behavior

The run fails after about 5 minutes with a timeout that looks like an undici headers timeout:

06:04:31+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end
06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","isError":true,"error":"LLM request failed: network connection error.","failoverReason":"timeout","model":"qwen3.5:9b","provider":"ollama","rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run agent end
06:09:39+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"d8914715-5c17-43cb-b0e5-c4678399d6b1","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":null,"provider":"ollama","model":"qwen3.5:9b","sourceProvider":"ollama","sourceModel":"qwen3.5:9b","profileId":"sha256:9c018ec112cf","fallbackConfigured":false,"timedOut":false,"aborted":false,"rawErrorPreview":"fetch failed | Headers Timeout Error","rawErrorHash":"sha256:7aa8f0ebe2ea","providerRuntimeFailureKind":"timeout"} embedded run failover decision

OpenClaw version

2026.4.15 (041266a)

Operating system

Ubuntu 24.04

Install method

curl -fsSL https://openclaw.ai/install.sh | bash

Model

qwen3.5:9b

Provider / routing chain

ollama

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Increase the undici headers timeout to a value greater than the current 5-minute limit to prevent the Headers Timeout Error.

Guidance

  • Investigate the undici library configuration to find the headers timeout setting and increase its value to accommodate slow model responses.
  • Verify that the increased timeout is respected by the OpenClaw application and does not introduce other issues.
  • Consider adding a configurable option for the undici headers timeout in OpenClaw to make it easier to adjust this setting in the future.
  • Test the increased timeout with different model providers and scenarios to ensure it does not cause unintended consequences.

Example

No code snippet is provided as the issue is related to configuration and library settings rather than code.

Notes

The exact method to increase the undici headers timeout may vary depending on the OpenClaw and undici library versions. It is essential to consult the documentation for both libraries to find the correct configuration option.

Recommendation

Apply a workaround by increasing the undici headers timeout, as there is no clear indication that upgrading to a fixed version will resolve the issue. This workaround should help prevent the Headers Timeout Error and allow slow model responses to be processed correctly.

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…

FAQ

Expected behavior

If I increase the OpenClaw timeout, I expect slow local Ollama runs to keep waiting for the first token/chunk instead of failing after about 5 minutes.

#tool integration#LLM response#prompt template#agent execution#callback error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING