Summary

During long research-style turns (for example: web search + fetching docs + multi-step tool use), OpenClaw can appear completely unresponsive to the user even though the assistant has already done work and gathered partial results.

The specific failure mode is:

1. the assistant starts a long tool chain,
2. there is no visible progress / working indicator on the chat surface,
3. tool activity stops,
4. there is no automatic "still working", "paused", or "partial progress" message,
5. there is also no true background continuation,
6. from the user's perspective the session looks frozen.

This is especially confusing because the user cannot tell whether OpenClaw is:

• still actively working,
• waiting on tools,
• paused and waiting for the model,
• or simply stuck.

Problem to solve

A long-running turn may successfully perform several tool calls and gather partial results, but if the assistant does not emit a user-visible progress update before the next user message, the UX becomes "silent stall" / "looks dead".

This is different from a pure streaming issue:

• sometimes the system did real work,
• sometimes the tool chain has already stopped,
• but the chat surface still gives the user zero state signal.

The result is users sending ?, duplicate follow-ups, or assuming the system hung.

Reproduction pattern

Observed pattern in a real Telegram direct-chat session:

1. User asks for a research task ("investigate / research X")
2. Assistant starts web search / fetch / multi-step tool use
3. No immediate acknowledgement like "I'm checking"
4. A batch of tool calls completes and partial findings exist internally
5. No message is sent to the user yet
6. No background worker remains actively continuing the task
7. User sees silence and sends ?
8. Assistant only then explains what happened

Expected behavior

At least one of these should happen automatically for long-running turns:

1. Immediate acknowledgement

   • When a turn begins a long tool chain, the user gets a visible ACK such as:
     • "On it, checking now..."
     • "Researching this now..."

2. Progress / liveness updates

   • If the turn remains active beyond a threshold, the user gets periodic or event-based progress updates.

3. Paused-state signal

   • If tool execution has stopped but the assistant has not produced a final answer yet, surface a clear temporary state like:
     • "Paused while assembling results"
     • "Still working, partial results found"
     • "Waiting to continue"

4. Automatic partial-result fallback

   • If the system has already gathered meaningful partial results and has been silent for too long, emit a short progress summary automatically.

5. True background semantics (if claimed / implied by UX)

   • If the session is no longer actively running, the UI should not make it feel like background work is continuing invisibly.
   • Or, if background continuation does exist, it should have explicit status.

Actual behavior

• The assistant can perform several tool calls successfully.
• Then there is no visible user-facing update.
• The system does not clearly indicate whether the task is still running.
• There is no paused-state or partial-progress signal.
• The user experiences the session as frozen / dead.

Why this is distinct from existing issues

This overlaps with, but is not identical to:

• long-running no-progress heartbeat requests,
• TUI showing idle while work is active,
• session lane blocking,
• silent stalls after API errors.

This issue is specifically about the gap where:

• work already happened,
• the user got no visible signal,
• activity may already have stopped,
• and there is no explicit "paused / partial / no longer running" state.

Impact

• Users think OpenClaw froze
• Users send repeated ? / duplicate messages
• Hard to distinguish stuck vs active vs paused
• Particularly bad for mobile chat surfaces (Telegram/QQ/etc.) where there is no rich task UI
• Reduces trust in long-form research / multi-tool workflows

Suggested fixes

Possible fixes (any subset would help):

1. Auto-ACK for tool-heavy turns
2. Configurable progress heartbeat for long-running turns
3. Session state machine exposed to channel UX (thinking, running_tools, paused_with_partial_results, background_running, waiting_user)
4. Auto-emit a minimal progress message if N tool calls complete without any user-visible text
5. If a run becomes inactive after tool work but before final user text, emit a state transition / fallback message rather than leaving silence

Environment

• Channel: Telegram direct chat
• Runtime: main session
• Task type: web research / multi-step tool usage
• Symptom observed on chat surface UX, not just TUI

Additional context

This feels like a product / UX bug as much as an agent-behavior bug. The core issue is not only that the assistant "should be nicer"; the system currently gives insufficient visibility into whether a long turn is alive, paused, or finished doing tool work.