openclaw - 💡(How to fix) Fix [Bug]: TUI stream watchdog marks quiet active runs idle in 2026.5.4 [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In OpenClaw TUI 2026.5.4, a long-running chat run can be shown as idle or can emit repeated This response is taking longer than expected. Send another message to continue. prompts while the run is still active and later continues streaming/finalizes normally.

Steps to reproduce

1. Start openclaw tui using OpenClaw 2026.5.4.
2. Send a prompt that causes the agent to do multi-minute real work with sparse assistant text output / sparse stream deltas.
3. Wait while the run is still executing.
4. Observe the TUI status and watchdog messages before the eventual later stream/final output arrives.

Observed concrete case: after a user message, the TUI showed no visible working/thinking activity for about 2.5 minutes, then began streaming chunks. During the same overall run it later showed repeated This response is taking longer than expected. Send another message to continue. messages and at one point returned to connected | idle, even though more text later arrived and the run finished normally.

Expected behavior

A quiet stream should stay visibly streaming / working until authoritative session or run state says the run is terminal. Lack of recent text deltas alone should not clear the active run, set the TUI to idle, or prompt the user to send another message if the backend/session is still active.

Actual behavior

The TUI can treat a quiet but still-active run as stale: it may clear the active/busy indication, show idle, or emit repeated This response is taking longer than expected. Send another message to continue. prompts. The same run can later resume visible streaming and produce a normal final answer, so the earlier idle/taking-longer state is misleading.

OpenClaw version

2026.5.4

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global (npm install -g openclaw / global install path under ~/.npm-global/lib/node_modules/openclaw)

Model

venice/openai-gpt-55 in the observed run; similar quiet-working behavior has also been noticed on heart/Opus-style long-running work.

Provider / routing chain

OpenClaw TUI -> local OpenClaw gateway/session -> configured provider route (observed TUI footer: venice/openai-gpt-55).

Additional provider/model setup details

Mind/heart streaming is enabled in the admin settings. The issue appears tied to TUI stream/watchdog state rather than model-specific final output, because the final text eventually arrived after the TUI had already shown idle/taking-longer states.

Logs, screenshots, and evidence

Observed TUI footer during the issue:
connected | idle
agent eva-dm | session main (webchat:g-agent-eva-dm-main) | venice/openai-gpt-55 | tokens 102k/1.0m (10%)

Repeated watchdog prompt while the run later continued:
This response is taking longer than expected. Send another message to continue.
This response is taking longer than expected. Send another message to continue.
This response is taking longer than expected. Send another message to continue.

Observed progression from the same run:
- Initial visible assistant text: "Let me look at the exact pipeline that produced the good grateful, then batch-apply to the rest."
- Later chunks arrived after quiet/idle/taking-longer states, including:
  "All 16 expressions now match idle: h=443, baseline=479. Now sync to godot/assets as webp:"
  "WebP conversion done. Now build Windows and copy to share:"
  "Build done and copied. Now commit:"
- Final answer arrived normally after the misleading idle/taking-longer state.

Impact and severity

Affected: TUI users running long/sparse-output agent tasks.

Severity: Medium workflow/UX bug. It makes the user think the run is done or stuck when it is still working, which can lead to duplicate messages/runs or premature manual intervention.

Frequency: Intermittent; observed on sparse-output multi-minute work, not every response.

Consequence: Busy/streaming indicators become unreliable during exactly the cases where users most need them.

Additional information

This looks related to previously closed issue #69081, but it is still observable on 2026.5.4. A local workaround that improved behavior was to make the TUI watchdog keep quiet streams active, refresh session info, and re-arm the watchdog instead of clearing activeChatRunId, setting idle, or emitting the taking-longer prompt purely due to missing recent text deltas.