This is a comment left during a code review.
Path: ui/src/ui/app-tool-stream.ts
Line: 440-444

Comment:
**Mutating `@state` array without reassignment**

`chatStreamSegments.push(...)` mutates the array in-place without changing the reference. In Lit, `@state`-decorated properties only schedule re-renders when the property is **assigned** (the setter is called). The segment is only visible here because the immediately following `host.chatStream = null` assignment happens to trigger a re-render that reads the mutated array.

This is a silent coupling: if the `chatStream` nullification is ever moved, removed, or guarded separately, the pushed segment will be invisible until the next unrelated state change. The safe pattern for Lit is to replace the array:

```suggestion
    if (host.chatStream && host.chatStream.trim().length > 0) {
      host.chatStreamSegments = [...host.chatStreamSegments, { text: host.chatStream, ts: now }];
      host.chatStream = null;
      host.chatStreamStartedAt = null;
    }
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: ui/src/ui/app-gateway.ts
Line: 271-279

Comment:
**`hadToolEvents` reload guard skips the `refreshSessionsAfterChat` path**

The fix for "history not reloaded after tool runs" (fix #4) only applies when `!runId || !host.refreshSessionsAfterChat.has(runId)`. When a run's server `runId` IS in `refreshSessionsAfterChat` and tools were used, execution falls through to the `host.refreshSessionsAfterChat.delete(runId)` block, which calls `loadSessions` and returns `false`. Back in `handleChatGatewayEvent`, `shouldReloadHistoryForFinalEvent` returns `false` for a normal assistant reply (`role: "assistant"`), so `loadChatHistory` is never called for that path.

For the common case (`!refreshSessionsAfterChat.has(runId)`) this is fine because the mid-run `loadChatHistory` calls on each tool `result` keep history current, and `handleChatEvent` appends the final message directly. However, if `refreshSessionsAfterChat` ends up containing the run ID of a chat that also used tools, the cleared tool-stream state won't be backed by a fresh history fetch. Consider applying the same guard here:

```ts
host.refreshSessionsAfterChat.delete(runId);
if (state === "final") {
  void loadSessions(host as unknown as OpenClawApp, {
    activeMinutes: CHAT_SESSIONS_ACTIVE_MINUTES,
  });
  // Also reload history if tools were seen, just like the untracked-run path.
  if (hadToolEvents) {
    void loadChatHistory(host as unknown as OpenClawApp);
    return true;
  }
}
return false;
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: ui/src/ui/controllers/chat.ts
Line: 74-90

Comment:
**Duplicated streaming-state cleanup across `loadChatHistory` and `resetToolStream`**

`loadChatHistory` now manually replicates the internals of `resetToolStream` (clear `toolStreamById`, `toolStreamOrder`, `chatToolMessages`, `chatStreamSegments`, cancel timer) plus two extra fields (`chatStream`, `chatStreamStartedAt`). `resetToolStream` was explicitly designed to own this cleanup, so future changes to either location can easily fall out of sync.

Consider exposing a single helper that clears all streaming state — or simply call `resetToolStream` here and then separately null out the chat stream fields:

```ts
// After successfully receiving history:
resetToolStream(state as unknown as Parameters<typeof resetToolStream>[0]);
state.chatStream = null;
state.chatStreamStartedAt = null;
```

This removes the duplicated `as unknown as` cast and keeps the cleanup in one place.

How can I resolve this? If you propose a fix, please make it concise.