openclaw - 💡(How to fix) Fix TUI streaming watchdog (30s) fires false-positive on long tool-call turns; config knob already 80% wired but never plumbed

Summary

The TUI's "streaming watchdog" timeout fires after 30 seconds of no streamed output, displaying the system message:

This response is taking longer than expected. Send another message to continue.

…even when the assistant turn is genuinely still in progress on the backend (e.g. running an exec tool call that yields for 15s, then another, then a Supabase query). The run completes successfully; the warning is a false positive that misleads users into resending and creating duplicate turns.

The fix is already 80% wired in — the TUI reads context.streamingWatchdogMs and falls back to a 30s default — but the value is never plumbed through from config at the createEventHandlers() callsite, so no user-facing knob exists to extend it.

Evidence

From dist/tui-*.js (v2026.5.7 installed via Homebrew):

const DEFAULT_STREAMING_WATCHDOG_MS = 3e4;
const STREAMING_WATCHDOG_USER_MESSAGE =
  "This response is taking longer than expected. Send another message to continue.";

function createEventHandlers(context) {
  // ...
  const streamingWatchdogMs =
    typeof context.streamingWatchdogMs === "number" &&
    Number.isFinite(context.streamingWatchdogMs) &&
    context.streamingWatchdogMs >= 0
      ? Math.floor(context.streamingWatchdogMs)
      : DEFAULT_STREAMING_WATCHDOG_MS;
  // ...
}

Callsite (no streamingWatchdogMs passed in):

const { armStreamingWatchdog, reconnectStreamingWatchdog } = createEventHandlers({
  chatLog,
  btw,
  tui,
  state,
  localMode: isLocalMode,
  setActivityStatus,
  refreshSessionInfo,
  loadHistory,
  noteLocalRunId,
  isLocalRunId,
  forgetLocalRunId,
  clearLocalRunIds,
  isLocalBtwRunId,
  forgetLocalBtwRunId,
  clearLocalBtwRunIds,
});

Repro

In any TUI/webchat session, ask the assistant a task that requires multiple sequential exec calls each yielding 10–20s (e.g. nested data lookups, Supabase REST queries with yieldMs). After ~30s of no incremental stream output, the watchdog warning appears even though the run is alive — visible by waiting; the final assistant message lands a few seconds later.

Proposed fix

Wire the existing context flag through config:

1. Add agents.defaults.tui.streamingWatchdogMs (or tui.streamingWatchdogMs at top-level) to the config schema, default 30000, allow 0 to disable.
2. At the createEventHandlers() callsite, read the resolved config value and pass it as streamingWatchdogMs on the context object.
3. (Nice-to-have) Don't fire the watchdog message while the run is still emitting tool-call events even if no text tokens are streaming — that would solve the most common false-positive case (long sequential tool batches) without requiring users to tune the value.

Workaround

In the meantime, assistant agents can split long turns into multiple shorter messages with brief intermediate text between tool batches to keep the watchdog reset. Users can ignore the warning when they know a multi-step task is in flight.

Environment

• OpenClaw v2026.5.7 (Homebrew install)
• macOS 25.5.0 / arm64
• Channel: TUI / webchat