openclaw - 💡(How to fix) Fix [Bug]: Control UI/Gateway responsiveness regression during active runs: UI reconnect stalls, Telegram typing gaps, heartbeat poll noise, and media mirror UX issues [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to v2026.4.26, OpenClaw becomes partially unresponsive while an agent run is active. The model eventually responds and Telegram delivery works, but the Control UI can fail to load/reconnect during the run, Telegram typing stops for ~11-12 seconds mid-processing, heartbeat polls appear inside the visible chat transcript, and outbound media sent successfully to Telegram is mirrored in Control UI only as a filename instead of an image preview.

Steps to reproduce

Run OpenClaw v2026.4.26 in Docker on Windows + WSL2. Open Control UI at http://127.0.0.1:18789. Use Telegram or Control UI to send a normal message to the assistant. While the assistant is processing, refresh Control UI or open 127.0.0.1:18789 in another browser. Watch Telegram typing indicator during the same run. Optionally trigger image generation from Telegram and inspect the Control UI transcript. Wait for heartbeat poll and inspect the visible session transcript.

Expected behavior

Control UI should remain responsive and reconnectable during active agent runs. Telegram typing/presence should stay consistent while processing is active. Heartbeat should be out-of-band or silent, not injected into the visible chat transcript. Outbound media delivered to Telegram should be mirrored in Control UI as a media attachment/preview, not just a filename.

Actual behavior

During active runs, Control UI may stay on loading/connect screen or fail to reconnect until the assistant response is nearly complete. Opening a second browser session can also hang during the same window. Telegram typing appears for a few seconds, disappears for about 11-12 seconds, then appears again before the response. Heartbeat appears as [OpenClaw heartbeat poll], causes HEARTBEAT.md to be read, and adds visible transcript noise. Generated images are successfully sent to Telegram, but Control UI delivery_mirror shows only the PNG filename rather than a preview.

OpenClaw version

v2026.4.26

Operating system

Windows host + Docker Desktop + WSL2 Ubuntu. Gateway bound locally to 127.0.0.1:18789

Install method

Docker

Model

Primary: openai-codex/gpt-5.4 Image generation: openai/gpt-image-2 Configured fallbacks include Ollama cloud/local models.

Provider / routing chain

Primary: openai-codex/gpt-5.4 Fallbacks/configured: Ollama cloud/local models, openai/gpt-image-2 for image generation.

Additional provider/model setup details

Telegram enabled, browser plugin enabled with remote CDP attach-only, memory-core/memory-wiki enabled, sandbox enabled Telegram enabled, browser plugin enabled with remote CDP attach-only, memory-core/memory-wiki enabled, sandbox enabled with Docker socket access. The issue is not that Telegram/image delivery fails: image generation and Telegram media send can succeed. The problem is responsiveness/state sync/mirroring while runs are active.with Docker socket.

Logs, screenshots, and evidence

[ws] handshake timeout ...
[ws] closed before connect ...
[ws] ⇄ res ✓ models.list 39086ms
[sessions.resolve] No session found: current
[system-presence] missing operator.read
[OpenClaw heartbeat poll]
read /home/node/.openclaw/workspace/HEARTBEAT.md
HEARTBEAT_OK
image_generate -> generated PNG
message tool -> ok: true, media: /home/node/.openclaw/media/tool-image-generation/...
delivery_mirror -> shows only filename

Impact and severity

High severity for daily use. The assistant technically works, but the UX feels unreliable: the UI appears down or stuck while the assistant is working, Telegram gives a long silent gap, and transcript noise makes it harder to understand what is happening. This makes OpenClaw feel unstable even when the model eventually responds and tools succeed.

Additional information: This appears to be a combined gateway/control-ui/session-state responsiveness problem rather than a pure model latency issue. /healthz can be fast while Control UI reconnect/bootstrap still stalls during active runs. The media issue is lower priority but confirms that delivery mirror state in Control UI does not faithfully represent what was sent through Telegram.

Additional information

The stack is not a vanilla desktop/macOS install. It runs as a custom Docker-based local assistant stack on Windows + WSL2 with persistent mounted config/data/workspace. Host OS: Windows Runtime: Docker Desktop + WSL2 Ubuntu Gateway bind: 127.0.0.1:18789 Install method: Docker Containerized gateway: yes Persistent config/data/workspace mounts: yes Telegram enabled: yes Browser plugin enabled: yes, remote CDP attach-only Memory/wiki enabled: yes Sandbox enabled: yes Docker socket mounted for sandbox/debug workflows: yes Primary model: openai-codex/gpt-5.4 Image generation model: openai/gpt-image-2 The issue is reproducible during active assistant runs, not only during startup. Idle health checks can be fast, but Control UI reconnect/bootstrap can still stall while the agent is processing. Telegram image delivery itself works; the generated image is delivered successfully, but Control UI mirrors it only as a filename under delivery_mirror. Heartbeat also appears in the visible chat transcript and triggers HEARTBEAT.md reads, adding extra visible session noise.