Summary

On [email protected], long agent loops (40+ messages, ~20+ tool_use/tool_result iterations) abort with surface_error reason=timeout / rawError=This operation was aborted at a consistent ~165–180s wall-clock duration, regardless of how high agents.defaults.timeoutSeconds and models.providers.<id>.timeoutSeconds are set. The error message in stderr explicitly suggests "increase agents.defaults.timeoutSeconds in your config" — but raising it from 300 → 600 has no effect on the abort timing.

This looks like the symptom described in the inline comment at src/agents/embedded-agent-runner/run/llm-idle-timeout.ts:158-160:

Without this, users hitting #77744 / #78361 set provider timeoutSeconds to e.g. 600s, observe the value is accepted and hot-reloaded, yet the idle watchdog still aborts at 120s.

… except the abort is hitting at ~180s in our case rather than 120s, even after the fix referenced in that comment was supposed to honor modelRequestTimeoutMs as a ceiling.

Environment

• OpenClaw 2026.6.2-beta.1 (f03f57a)
• Provider: custom-api-anthropic-com (base_url https://api.anthropic.com, model claude-sonnet-4-6, thinking=medium)
• Trigger: agent embedded ([agent/embedded] lane)
• Pod: long-lived (multi-day uptime), heavy session history, apply-cfg-managed config

Relevant config

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 600,
      "contextTokens": 130000,
      "thinkingDefault": "medium",
      "maxConcurrent": 4
    }
  },
  "models": {
    "providers": {
      "custom-api-anthropic-com": { "timeoutSeconds": 600 }
    }
  }
}

Reproduction / Observation

Outbound anthropic-payload log captured 11 post-config-bump runs in a ~1h window. Aggregated timing per run:

Pre-config-bump aborts (provider timeoutSeconds=300, agents timeoutSeconds=600) showed the same envelope:

→ All aborts land in ~165–180s, regardless of provider or agent timeoutSeconds. A run that takes 166s passes; a run that takes 169s aborts. The boundary is clearly between 167s (ok) and 169s (abort) in the post-edit window.

Server log at the moment of abort:

[agent/embedded] embedded run failover decision: runId=resp_… stage=assistant
  decision=surface_error reason=timeout from=custom-api-anthropic-com/claude-sonnet-4-6
  profile=- rawError=This operation was aborted
LLM request timed out.
Request timed out before a response was generated. Please try again, or
increase `agents.defaults.timeoutSeconds` in your config.

…but agents.defaults.timeoutSeconds is already at 600, well above the 180s wall-clock the run actually reaches.

Workload shape

Each affected run is an agent loop with ~20–30 sequential tool_use → tool_result pairs (each call ≈ 5–8s round-trip with thinking enabled). Cumulative duration grows linearly with tool calls; once it crosses ~165–180s the next stream fence triggers the abort. No oversized prompt, no overflow, no session takeover (after #89811 in 2026.6.2-beta.1 those went away).

Suspected sources

Skimming src/agents/embedded-agent-runner/, candidates I'm unable to rule out without more context:

• resolveLlmIdleTimeoutMs clamps fall back to DEFAULT_LLM_IDLE_TIMEOUT_MS = 120s when params.runTimeoutMs is treated as "no explicit timeout" and not derived from agents.defaults.timeoutSeconds. Could resolvedRunTimeoutMs be ending up undefined in attempt.ts:2764 because params.timeoutMs === configuredRunTimeoutMs, leading to a stricter clamp than expected?
• compaction-safety-timeout.ts / postCompactionAbortController in run.ts:1202 — unsure if these can fire mid-loop without a compaction having been triggered.
• CLI_RESUME_WATCHDOG_DEFAULTS.maxMs = 180_000 in cli-watchdog-defaults.ts — exact match for the boundary, but that's specifically the CLI runner watchdog (not embedded). Could the embedded runner be inheriting any "no-output" watchdog with these defaults?

Ask

1. Is there a hidden ~180s cap on [agent/embedded] runs that is not surfaced through agents.defaults.timeoutSeconds nor models.providers.<id>.timeoutSeconds?
2. Is the stderr suggestion "increase agents.defaults.timeoutSeconds" pointing to the right knob in this code path, or is there a different config key we should be using?
3. Is this a follow-up to LLM idle timeout cannot be configured for long local llama.cpp requests in 2026.5.3-1 #77744 / Expose model stream idle-timeout as user config (currently ~120s, hardcoded) #78361 — i.e., does the fix in 2026.6.2-beta.1 cover the chunk-level idle watchdog but not the run-level wall-clock abort?

Happy to share the redacted payload log entries and full server logs around an abort if helpful.