Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]:Control UI feels significantly laggier in 2026.4.12 during normal chat use [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#66564•Fetched 2026-04-15 06:25:37
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
jarvisaeyejarvisaeye
Participants
jarvisaeyejarvisaeye
Timeline (top)
cross-referenced ×1labeled ×1

After updating to 2026.4.12, the Control UI became noticeably laggier during normal chat use, including sticky initial load and delayed visual settling after pressing Enter.

Root Cause

After updating to 2026.4.12, the Control UI became noticeably laggier during normal chat use, including sticky initial load and delayed visual settling after pressing Enter.

Fix Action

Fix / Workaround

Local mitigation attempts:

  • increased polling intervals
  • disabled several eager connect-time loads in the shipped bundle

Those mitigations reduced some churn but did not fully remove the lag, especially post-send visual settling.

PR fix notes

PR #66596: fix(control-ui): reduce polling intervals to improve chat responsiveness

Description (problem / solution / changelog)

Summary

Increase Control UI polling intervals to reduce gateway load during normal chat use, addressing the lag regression reported in #66564.

Changes

  • node.list polling: 5s to 30s (nodes change infrequently, not needed for chat tab)
  • logs polling: 2s to 15s (logs tab only polls when active, reduce gateway load)
  • debug polling: 3s to 15s (debug tab only polls when active, reduce gateway load)

Root Cause

The Control UI was polling node.list every 5 seconds unconditionally (even when the user was on the chat tab), and polling logs/debug every 2-3 seconds when those tabs were active. These 300-800ms RPC calls competed with chat message rendering for gateway resources, causing the noticeable lag during normal chat use.

Testing

  • All existing UI unit tests pass
  • Polling functions are already mocked in app-lifecycle-connect tests, so no test changes needed for the interval values themselves

Impact

These reduced polling intervals significantly cut gateway load while still providing reasonably fresh data for the nodes/logs/debug tabs. For chat tab users (the majority), the background gateway load is reduced by eliminating the 5-second node.list polling burst.

Changed files

  • src/daemon/launchd-plist.ts (modified, +1/-1)
  • src/gateway/server-plugins.ts (modified, +1/-1)
  • ui/src/ui/app-polling.ts (modified, +3/-3)

Code Example

Observed local gateway timings during investigation:

- loopback HTTP to `http://127.0.0.1:18789/` was about `6ms`
- many websocket `chat.history` calls were about `55–100ms`

Observed slower Control UI websocket calls:
- `commands.list` ~ `344ms`
- `chat.history` ~ `480ms`
- `device.pair.list` ~ `511ms`
- `node.list` ~ `513ms`, later ~ `829ms`
- `health` ~ `847ms`

Bundle audit of the shipped `dist/control-ui/assets/index-*.js` in `2026.4.12` showed:
- `node.list` polling every `5s`
- logs polling every `2s` when logs tab is active
- debug polling every `3s` when debug tab is active
- eager connect-time loading of `health`, `node.list`, `device.pair.list`, and `commands.list`

Local mitigation attempts:
- increased polling intervals
- disabled several eager connect-time loads in the shipped bundle

Those mitigations reduced some churn but did not fully remove the lag, especially post-send visual settling.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating to 2026.4.12, the Control UI became noticeably laggier during normal chat use, including sticky initial load and delayed visual settling after pressing Enter.

Steps to reproduce

  1. Start OpenClaw 2026.4.12 on a local macOS machine with Control UI enabled.
  2. Open the local Control UI and use normal chat flow.
  3. Observe sticky initial load and delayed visual settling after pressing Enter.
  4. If a paired node exists but is disconnected, the lag is still reproducible.

Expected behavior

The Control UI should remain responsive during normal chat use, with messages appearing promptly after pressing Enter and without noticeable sticky initial hydration.

Actual behavior

After updating to 2026.4.12, the Control UI feels noticeably laggier during normal chat use. Initial load is sticky, and after pressing Enter the message can take a few seconds to visibly settle into chat.

OpenClaw version

2026.4.12

Operating system

macOS 13.7.8

Install method

pnpm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

Primary configured model was openai-codex/gpt-5.4 with OpenAI Codex OAuth auth.

A separate stale session-model corruption issue was found earlier and fixed, but the lag described in this report remained afterward. This report is specifically about the remaining Control UI responsiveness regression, not the earlier model-routing issue.

Logs, screenshots, and evidence

Observed local gateway timings during investigation:

- loopback HTTP to `http://127.0.0.1:18789/` was about `6ms`
- many websocket `chat.history` calls were about `55–100ms`

Observed slower Control UI websocket calls:
- `commands.list` ~ `344ms`
- `chat.history` ~ `480ms`
- `device.pair.list` ~ `511ms`
- `node.list` ~ `513ms`, later ~ `829ms`
- `health` ~ `847ms`

Bundle audit of the shipped `dist/control-ui/assets/index-*.js` in `2026.4.12` showed:
- `node.list` polling every `5s`
- logs polling every `2s` when logs tab is active
- debug polling every `3s` when debug tab is active
- eager connect-time loading of `health`, `node.list`, `device.pair.list`, and `commands.list`

Local mitigation attempts:
- increased polling intervals
- disabled several eager connect-time loads in the shipped bundle

Those mitigations reduced some churn but did not fully remove the lag, especially post-send visual settling.

Impact and severity

Affected: local users of the Control UI during normal chat use Severity: moderate to high annoyance; degrades chat responsiveness Frequency: consistently observed after update to 2026.4.12 Consequence: slower-feeling chat UX, sticky initial load, and delayed visible settling after sending messages

Additional information

This appears distinct from an earlier session/model routing issue that was separately diagnosed and fixed. After that fix, the remaining lag still reproduced.

Likely regression shape:

  • eager connect-time loading of Control UI metadata/state
  • recurring polling for node/log/debug surfaces
  • post-send UI/render/update path still feeling round-trip-coupled

Last known good: NOT_ENOUGH_INFO First known bad: 2026.4.12

extent analysis

TL;DR

The most likely fix for the Control UI lag issue is to optimize the eager connect-time loading and recurring polling of metadata and state.

Guidance

  • Review the polling intervals for node.list, logs, and debug to ensure they are not too frequent, as they may be contributing to the lag.
  • Investigate the eager connect-time loading of health, node.list, device.pair.list, and commands.list to see if it can be optimized or deferred.
  • Consider implementing a caching mechanism for frequently accessed data to reduce the number of requests made to the server.
  • Analyze the post-send UI/render/update path to identify any potential bottlenecks or round-trip coupling that may be causing the delayed visual settling.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The issue appears to be related to the changes introduced in version 2026.4.12, and the provided mitigation attempts suggest that optimizing the polling intervals and eager loading may help alleviate the issue. However, further investigation is needed to fully resolve the problem.

Recommendation

Apply workaround: Optimize eager connect-time loading and recurring polling, as this is likely to have the most significant impact on reducing the lag.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The Control UI should remain responsive during normal chat use, with messages appearing promptly after pressing Enter and without noticeable sticky initial hydration.

#runtime error#dependency conflict#environment setup#docker error#permission error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING