Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The bundled openai npm package has a hardcoded DEFAULT_TIMEOUT = 600000 (10 minutes). OpenClaw does not override this when constructing the client for local/custom providers. This causes the HTTP connection to be aborted after exactly 10 minutes, killing any in-flight inference request — even when agents.defaults.timeoutSeconds and llm.idleTimeoutSeconds are configured to allow longer runs.

Steps to reproduce

1. Configure a local provider with a large model where total request time can exceed 10 minutes
2. Set generous timeouts in openclaw.json:

   {
     "agents": {
       "defaults": {
         "timeoutSeconds": 3600,
         "llm": {
           "idleTimeoutSeconds": 0
         }
       }
     }
   }

3. Send a message. The model begins inference and streams tokens normally.
4. At exactly 10 minutes, the connection is killed — even while tokens are actively streaming

Expected behavior

The OpenAI SDK client timeout should respect the user-configured agents.defaults.timeoutSeconds, or at minimum be configurable separately. When timeoutSeconds: 3600 is set, no layer should abort the request before 3600 seconds.

Suggested fix

When constructing the OpenAI client instance, pass timeout derived from the agent's configured timeoutSeconds:

const client = new OpenAI({
  baseURL: provider.baseURL,
  apiKey: provider.apiKey,
  timeout: resolvedTimeoutSeconds * 1000, // propagate to SDK
});

Alternatively, add a dedicated config key (e.g., llm.httpTimeoutSeconds) that is forwarded to the SDK constructor, with a default that matches timeoutSeconds or is sufficiently large for local inference workloads.

Actual behavior

The inference backend receives a TCP disconnection at exactly 10 minutes after inference begins, regardless of configured timeouts. On exo, this surfaces as:

[ 2026-04-09 00:12:28.727 | INFO | exo.worker.main:plan_step:167 ] Worker plan: CancelTask

Timestamps confirm the 600-second boundary from the first inference step:

[ 23:44:53.694 | DEBUG ] step overhead: 0.10ms (next=80.86ms total=80.96ms)
[ 23:54:55.430 | INFO  ] Worker plan: CancelTask

Delta: 10 minutes 2 seconds (600,000ms + minor overhead). The timer starts when inference begins — meaning the SDK imposes a hard 10-minute wall clock on the entire request, regardless of whether tokens are actively streaming back.

Root cause

In the bundled OpenAI SDK at anthropic-vertex-stream-BySayhWO.js, three call sites fall back to 6e5 when no explicit timeout is provided:

// Line 3019
timeout: timeout ?? 6e5,

// Line 3282
timeout: this._client._options.timeout ?? 6e5,

// Line 3987
timeout: timeout ?? 6e5,

This originates from node_modules/openai/src/client.ts:

static DEFAULT_TIMEOUT = 600000; // 10 minutes

OpenClaw never passes a timeout option to the OpenAI client constructor for local providers, so the SDK default wins. The user-configured timeoutSeconds and llm.idleTimeoutSeconds operate at higher abstraction layers (run orchestration and SSE chunk monitoring respectively) and do not propagate down to the SDK's HTTP request timeout.

OpenClaw version

v2026.4.5

Operating system

macOS 26.4

Install method

npm global

Model

Kimi-K2.5 (1T parameters, 200k context window)

Provider / routing chain

Local OpenAI-compatible endpoint (exo/MLX, also reproducible with llama-server)

Additional provider/model setup details

2× Mac Studio M3 Ultra (512GB unified memory each), tensor-parallel via exo

Logs, screenshots, and evidence

[ 2026-04-08 23:44:53.694 | DEBUG | exo.worker.engines.mlx.generator.batch_generate:step:365 ] step overhead: 0.10ms (next=80.86ms total=80.96ms)
[ 2026-04-08 23:54:55.430 | INFO  | exo.worker.main:plan_step:167 ] Worker plan: CancelTask

Impact and severity

This affects all users running local inference backends where total request time can exceed 10 minutes. Common scenarios include large models on consumer hardware (1T+ parameter models across multiple machines), large context windows (100k+ tokens), and multi-modal requests with vision models. The existing timeout configuration (timeoutSeconds, llm.idleTimeoutSeconds) gives users the impression they have control, but the SDK's hidden 10-minute ceiling overrides everything silently.

Additional information

Second related bug: tools.exec.timeoutSeconds config is silently ignored

The exec tool (bash/shell) has a separate 30-minute default timeout at line 3108 of pi-embedded-DWASRjxE.js:

const defaultTimeoutSec = typeof defaults?.timeoutSec === "number" && defaults.timeoutSec > 0 ? defaults.timeoutSec : 1800;

The code reads defaults.timeoutSec, but the zod schema validates timeoutSeconds:

timeoutSeconds: z.number().int().positive().optional(),

There is no rename mapping between the two. Setting tools.exec.timeoutSeconds in openclaw.json passes validation but never reaches createExecTool() — the 1800s default always wins. This kills long-running tool calls (coding tasks with multiple exec rounds) at exactly 30 minutes.

Workaround for the exec timeout:

sed -i 's/defaults.timeoutSec > 0 ? defaults.timeoutSec : 1800/defaults.timeoutSec > 0 ? defaults.timeoutSec : 7200/' \
  "$(npm root -g)/openclaw/dist/pi-embedded-DWASRjxE.js"

The fix is either rename the schema field to timeoutSec or rename the code to read timeoutSeconds.

Workaround for the SDK timeout

Patch the bundled SDK directly:

sed -i 's/timeout ?? 6e5/timeout ?? 36e5/g' \
  "$(npm root -g)/openclaw/dist/anthropic-vertex-stream-BySayhWO.js"

This changes the fallback from 10 minutes to 1 hour. Both patches must be reapplied after every update.