Problem

The gateway run timeout (agents.defaults.timeoutSeconds, default 600s) is a flat wall-clock timer. It kills runs that exceed the limit regardless of whether they are actively making progress.

Observed behavior: Sessions running complex multi-tool chains (image analysis, diagram generation, research with 10+ sequential tool calls) get killed at 600s with embedded run timeout. The user sees silence — tool calls completed but no assistant response is generated.

Expected behavior: Active runs making steady progress (tool calls completing, LLM generating responses) should not be killed by a wall-clock timeout.

5 Whys Root Cause

1. Sessions stalled with no response → Gateway killed the embedded run at 600s
2. Runs exceeded 10 min → Complex multi-tool chains with LLM inference between steps
3. 10-min flat timeout triggered → Default safety net for stuck runs
4. Timeout doesn't distinguish active vs stuck → Wall-clock timer, not activity-aware
5. No activity-based timeout exists → Gateway timeout doesn't reset on tool call completion

Current Workaround

Bump agents.defaults.timeoutSeconds to a higher value (e.g. 1200). This is a band-aid — long research sessions can still hit it.

Proposed Solutions (any of these would help)

1. Activity-aware timeout — reset the timeout counter when a tool call completes or LLM produces output. Kill only when idle for timeoutSeconds.
2. Separate idle vs wall-clock timeout — e.g. idleTimeoutSeconds (time since last activity) + maxTimeoutSeconds (absolute cap)
3. Allow timeoutSeconds: 0 — the JSON Schema currently has exclusiveMinimum: 0, preventing "no timeout". Allow 0 to mean unlimited.
4. Progressive timeout — extend timeout dynamically based on number of tool calls in the run

Environment

• OpenClaw version: 2026.3.2
• Config: agents.defaults.timeoutSeconds (default 600)
• Trigger: multi-tool agent workflows with 10+ sequential tool calls

Labels

enhancement, gateway