Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
The connection between the gateway and the OpenClaw Control page drops during long tasks and prevents stopping the model, even when using /stop
Steps to reproduce
start a long coding task in OpenCLaw
let it run (often happens more when verification tasks are also running)
observe that the connection drops between the gateway and the control page in the browser
reload the page
notice the stop button is gone, and the task is still running
try using /stop and see that it does not stop the process
Expected behavior
the connection should remain stable even during long tasks and the stop button should always be available to stop the model properly, including via /stop command
Actual behavior
The connection drops without warning, forcing a page reload, then the stop button disappears
even when using /stop, it does not stop the process at all
the model keeps generating code anyway, sometimes going completely off track with no way to regain control, which is really problematic
OpenClaw version
OpenClaw 2026.4.22 (00bd2cf)
Operating system
Windows 11
Install method
default windows
Model
kimi 2.6
Provider / routing chain
kimi 2.6
Additional provider/model setup details
No response
Logs, screenshots, and evidence
no logs available right now but the issue is easily reproducible during normal usage with long tasks
Impact and severity
affects normal usage during long-running tasks
severity is quite high since it becomes impossible to stop execution, even when explicitly sending /stop
happens fairly often with longer runs
consequence: complete loss of control over the model, wasted time, and generation of irrelevant or incorrect code that cannot be interrupted
Additional information
This is pretty frustrating in practice, especially when the model starts going in the wrong direction and there’s no way to stop it after the connection drops. the fact that even /stop does nothing makes it much worse, because there is literally no fallback to interrupt the process. it really feels unstable under longer workloads
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
The connection between the gateway and the OpenClaw Control page drops during long tasks and prevents stopping the model, even when using /stop
Steps to reproduce
start a long coding task in OpenCLaw
let it run (often happens more when verification tasks are also running)
observe that the connection drops between the gateway and the control page in the browser
reload the page
notice the stop button is gone, and the task is still running
try using /stop and see that it does not stop the process
Expected behavior
the connection should remain stable even during long tasks and the stop button should always be available to stop the model properly, including via /stop command
Actual behavior
The connection drops without warning, forcing a page reload, then the stop button disappears
even when using /stop, it does not stop the process at all
the model keeps generating code anyway, sometimes going completely off track with no way to regain control, which is really problematic
OpenClaw version
OpenClaw 2026.4.22 (00bd2cf)
Operating system
Windows 11
Install method
default windows
Model
kimi 2.6
Provider / routing chain
kimi 2.6
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
affects normal usage during long-running tasks
severity is quite high since it becomes impossible to stop execution, even when explicitly sending /stop
happens fairly often with longer runs
consequence: complete loss of control over the model, wasted time, and generation of irrelevant or incorrect code that cannot be interrupted
Additional information
This is pretty frustrating in practice, especially when the model starts going in the wrong direction and there’s no way to stop it after the connection drops. the fact that even /stop does nothing makes it much worse, because there is literally no fallback to interrupt the process. it really feels unstable under longer workloads