openclaw - 💡(How to fix) Fix [Bug] WebChat / Control UI repeatedly dispatches agent:main:main, causing repeated provider initialization and very slow replies [2 comments, 2 participants]

Summary

After upgrading to OpenClaw 2026.4.29, WebChat / Control UI can repeatedly dispatch agent:main:main, causing repeated provider initialization (loaded 49 plugin(s)), very slow replies, and sometimes the impression of an infinite loop.

This is not just one slow response:

• the same agent:main:main session keeps getting source=dispatch
• providers/plugins are re-initialized over and over
• even a trivial message like ? can trigger a heavy run
• disabling some hooks / memory-wiki reduces some symptoms but does not stop the repeated dispatch behavior

Environment

• OpenClaw version: 2026.4.29
• Surface: WebChat / Control UI
• Session key: agent:main:main
• Main model observed in logs: xiaomi-coding / mimo-v2.5
• OS: Windows
• Runtime path examples show:
  • C:\Users\pc\.openclaw\...
  • C:\Users\pc\AppData\Roaming\npm\node_modules\openclaw\...

Observed behavior

A simple WebChat message (for example ?) triggers:

1. message queued ... source=dispatch
2. session enters processing
3. OpenClaw loads 49 providers/plugins again
4. embedded run starts with xiaomi-coding
5. agent may call tools like:
   • session_status
   • memory_search
6. memory embeddings may start via OpenAI
7. reply eventually completes, but the system may soon dispatch again

This makes the system feel like it is “re-initializing providers/plugins forever”.

Key evidence from logs

Repeated dispatch of the same main session

message queued: sessionId=unknown sessionKey=agent:main:main source=dispatch queueDepth=1 sessionState=idle
session state: sessionId=unknown sessionKey=agent:main:main prev=idle new=processing reason="message_start" queueDepth=1

These lines appear repeatedly.

Repeated provider/plugin initialization

[plugins] loaded 49 plugin(s) (49 attempted) in 32024.9ms
[plugins] loaded 49 plugin(s) (49 attempted) in 34174.5ms
[plugins] loaded 49 plugin(s) (49 attempted) in 34892.3ms

This happens again and again across runs.

Embedded run starts after provider loading

embedded run prompt start: runId=72e4f117-6e09-4999-b4d6-857dcc914401 sessionId=f8bb37ba-f2b8-467c-ac45-4b046da713cf provider=xiaomi-coding api=openai-completions endpoint=custom route=proxy-like policy=none

Even trivial input triggers heavy tool use

From the session transcript, a simple user message ? led to:

tool=session_status
tool=memory_search

And logs also show:

memory embeddings: query start
provider: openai

So a trivial message can trigger both:

• main model execution
• memory embeddings / extra provider work

WebChat / Control UI origin

Session transcript shows the sender as:

{
  "label": "openclaw-control-ui",
  "id": "openclaw-control-ui"
}

What I already tried

I disabled these settings:

• hooks.internal.enabled = false
• hooks.internal.entries.session-memory.enabled = false
• messages.tts.auto = off
• plugins.entries.memory-wiki.enabled = false

This changed the behavior somewhat, but did not solve the repeated dispatch / repeated provider initialization problem.

So this does not appear to be only:

• a before_agent_reply hook problem
• a memory-wiki problem
• a TTS problem

Current suspicion

This looks like a WebChat / Control UI dispatch/session-state problem, possibly related to:

• repeated source=dispatch for agent:main:main
• Control UI / WebChat session resume or reconnection behavior
• duplicate or repeated dispatch into the same session
• overly heavy provider discovery / initialization on each run
• trivial user messages causing aggressive default tool use

Why this seems wrong

A trivial message like ? should not require:

• repeated loading of 49 providers
• repeated dispatch cycles on agent:main:main
• memory embeddings calls just to answer a simple ping

Expected behavior:

• one dispatch
• one lightweight reply
• no repeated provider re-initialization loop pattern

Actual behavior:

• repeated dispatches
• repeated provider initialization
• very slow response path

Related issues I found

These seem related but not identical:

• #75239 WebChat assistant replies still duplicate after #66875 fix
• #73956 Control UI duplicates assistant replies via assistant-media delivery path
• #72892 Control UI duplicates inbound messages in webchat sessions
• #70472 compaction can orphan agent:main:main
• #68162 Control UI creates new session on WebSocket reconnection instead of resuming

My case may be another variant in the same area.

Request

Could maintainers help confirm:

1. why agent:main:main keeps getting source=dispatch
2. why provider/plugin initialization happens on so many consecutive runs
3. whether WebChat / Control UI is re-dispatching or duplicating session work
4. whether trivial messages should really invoke memory_search / embeddings by default