Summary

The TUI can get stuck in "streaming" status after a response finishes. The status indicator never returns to "idle".

Version

openclaw 2026.4.14

Steps to Reproduce

1. Open the TUI (openclaw tui)
2. Send a message and wait for a response
3. After the assistant finishes generating, observe the status bar

The status bar continues to show "streaming" instead of returning to "idle".

Root Cause

Race condition in tui-CcmuLL4-.js between the chat stream's final event and the lifecycle stream's end event.

The problem (lines ~2694–2742):

// On every delta:
if (evt.state === "delta") {
  setActivityStatus("streaming");  // ← sets streaming on every chunk
}

// On final:
if (evt.state === "final") {
  const wasActiveRun = state.activeChatRunId === evt.runId;  // ← computed here
  // ...
  finalizeRun({ runId: evt.runId, wasActiveRun, status: "idle" });
}

And in finalizeRun:

const finalizeRun = (params) => {
  noteFinalizedRun(params.runId);
  clearActiveRunIfMatch(params.runId);     // ← clears activeChatRunId
  if (params.wasActiveRun) setActivityStatus(params.status);  // ← only clears if wasActiveRun=true
};

The race: If the lifecycle stream's end event fires and calls clearActiveRunIfMatch before the chat stream's final event is processed, state.activeChatRunId is already null when wasActiveRun is evaluated at line 2702. This makes wasActiveRun = false, so setActivityStatus("idle") is never called by finalizeRun. The status stays "streaming" permanently.

The same guard exists in the lifecycle handler (if (!isActiveRun) return at line 2793), meaning the lifecycle path also won't reset the status if activeChatRunId was already cleared.

Fix

Compute wasActiveRun before calling clearActiveRunIfMatch, or better: always call setActivityStatus("idle") when a final event arrives for any run that was displaying as streaming, regardless of whether it's still the "active" run:

// Option A: capture wasActiveRun before clearActiveRunIfMatch clears it
const finalizeRun = (params) => {
  noteFinalizedRun(params.runId);
  // wasActiveRun is already captured by caller before this call — no change needed here

  clearActiveRunIfMatch(params.runId);
  flushPendingHistoryRefreshIfIdle();
  if (params.wasActiveRun) setActivityStatus(params.status);
  refreshSessionInfo?.();
};

Wait — wasActiveRun IS captured by the caller before finalizeRun is called (line 2702 captures it, then passes it to finalizeRun at line 2739). So the issue must be upstream: state.activeChatRunId gets cleared between when the delta sets "streaming" and when the final event fires.

Most likely culprit: The lifecycle end event arrives first, calls setActivityStatus("idle"), then the chat delta events arrive late (reordering over SSE/WS), set status back to "streaming", and then no further final ever clears it because activeChatRunId was already nulled.

Robust fix: Track streaming state by runId in the UI (similar to how streamingRuns map works for the chat log), and only clear "streaming" status when all tracked streaming runs have finalized — not based solely on wasActiveRun.

Alternatively, the simplest fix: in handleChatEvent, when evt.state === "final", always call setActivityStatus("idle") if streamingRuns has no remaining entries after finalization, rather than gating on wasActiveRun.

Workaround

Send another message — the next message's sending → waiting transition resets the status correctly.