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.
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
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.