Summary

• Problem: The refresh chat data button was only disabled when chatLoading or disconnected, remaining clickable during active agent turns.
• Why it matters: Clicking refresh mid-turn stalls the live run, resets chat state, and can wedge the gateway session.
• What changed: Added chatSending, chatRunId, and chatStream guards to the refresh button's disabled condition.
• What did NOT change (scope boundary): No changes to refresh logic, gateway behavior, or other controls. Only the disabled guard on the refresh button.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Control UI: refreshing chat data during an active turn can stall the run and wedge the page/gateway openclaw/openclaw#65522
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: The refresh button's disabled binding was missing the busy-state guards (chatSending, chatRunId, chatStream) that are already used by the model select and thinking select controls in the same file.
• Missing detection / guardrail: No guard for the sending, running, or streaming phases of an agent turn on the refresh button specifically.
• Contributing context (if known): The model select (line ~490) and thinking select (line ~560) both use a busy variable combining these four flags. The refresh button only had two of them.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: ui/src/ui/app-render.helpers.ts
• Scenario the test should lock in: Refresh button disabled state includes chatSending, chatRunId, and chatStream
• Why this is the smallest reliable guardrail: The disabled binding is declarative (Lit ?disabled), so it's evaluated on every render cycle.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: The fix aligns a Lit template binding with the existing busy-state pattern. The guards are reactive properties that Lit re-evaluates on each render. A unit test for a template binding in Lit requires a full render harness and would test the framework, not the logic.

User-visible / Behavior Changes

Refresh button is now grayed out and non-clickable while the agent is sending, running, or streaming a response.

Diagram (if applicable)

Before:
[send message] -> [chatSending=true, chatRunId set, chatStream active] -> refresh button still enabled -> click -> stall/reset

After:
[send message] -> [chatSending=true, chatRunId set, chatStream active] -> refresh button disabled -> no click possible

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Windows 11 x64
• Runtime/container: Node v22.19.0, npm global install
• Model/provider: OpenRouter (openrouter/auto)
• Integration/channel (if any): Control UI WebChat
• Relevant config (redacted): Default config with OpenRouter provider

Steps

1. Open Control UI chat tab
2. Send a message that triggers an agent response
3. While the agent turn is active (sending/streaming), observe the refresh button

Expected

Refresh button should be disabled (grayed out) during the entire agent turn lifecycle.

Actual (before fix)

Refresh button remained clickable. Clicking it mid-turn reset the chat and stalled the run.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Before (refresh button clickable during active turn)

After (refresh button disabled during active turn)

Human Verification (required)

• Verified scenarios: Sent messages via Control UI WebChat, confirmed button is disabled during agent turn, confirmed button re-enables after turn completes.
• Edge cases checked: Button state on idle chat (enabled), button state during stream (disabled), button state after completion (re-enabled).
• What you did not verify: Behavior with WebSocket disconnection mid-turn, behavior on mobile Control UI layout.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Edge case where chatRunId or chatStream are set but the turn is actually stale, leaving the button permanently disabled.
  • Mitigation: The same guards are already used by model select and thinking select without reported issues. The existing lifecycle cleanup (resetChatStateForSessionSwitch) clears all three flags.