Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: /status command returns state via chat.history instead of WebSocket event push [1 comments, 2 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#48817•Fetched 2026-04-08 00:52:10
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
dropteadroptea
Participants
dropteadropteaRyceRyce
Timeline (top)
labeled ×2commented ×1subscribed ×1

In the current implementation of Openclaw, sending the /status command does not trigger a direct state update via the established WebSocket connection. Instead, the system seems to rely on a subsequent chat.history request to retrieve the status message.

This behavior is inefficient as it introduces unnecessary latency and deviates from the expected real-time event-driven architecture of the project.

Root Cause

In the current implementation of Openclaw, sending the /status command does not trigger a direct state update via the established WebSocket connection. Instead, the system seems to rely on a subsequent chat.history request to retrieve the status message.

This behavior is inefficient as it introduces unnecessary latency and deviates from the expected real-time event-driven architecture of the project.

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

In the current implementation of Openclaw, sending the /status command does not trigger a direct state update via the established WebSocket connection. Instead, the system seems to rely on a subsequent chat.history request to retrieve the status message.

This behavior is inefficient as it introduces unnecessary latency and deviates from the expected real-time event-driven architecture of the project.

Steps to reproduce

  1. Open the console/client connected via WebSocket.
  2. Send the /status command using chat.send.
  3. Observe the message flow:
  4. The client receives a chat.send response with status: started.
  5. An event of type chat is received with state: final.
  6. The actual status content is missing from the events.
  7. The client is then forced to call chat.history to see the actual output of the command. According to the console logs, the current flow is: // 1. Send command { "type": "req", "id": "b5bac90f-576c-4dc2-919f-e354f8b5ede9", "method": "chat.send", "params": { "sessionKey": "agent:main:main", "message": "/status", "deliver": false, "idempotencyKey": "d9104f3b-b6f2-441f-a29e-672fa99927cb" } }

// 2. Receive ack { "type": "res", "id": "b5bac90f-576c-4dc2-919f-e354f8b5ede9", "ok": true, "payload": { "runId": "...", "status": "started" } }

// 3. Receive final state event (but no payload content) { "type": "event", "event": "chat", "payload": { "runId": "d9104f3b-b6f2-441f-a29e-672fa99927cb", "sessionKey": "agent:main:main", "seq": 1, "state": "final" }, "seq": 92594 }

// 4. Forced to pull history to see the result (Inefficient) { "type": "req", "id": "2ab8e785-da6b-4255-b308-a4d25c8bb14d", "method": "chat.history", "params": { "sessionKey": "agent:main:main", "limit": 200 } }

Expected behavior

The results of the /status command (and other similar internal commands) should be pushed directly as a chat event payload or a specific status event via the WebSocket, eliminating the need for an extra chat.history roundtrip.

Actual behavior

After sending the /status command, the WebSocket only emits a status: started response and a state: final event notification. However, the event payload contains no actual message content regarding the system status.

To display the status info, the client is forced to manually invoke chat.history to fetch the message list and extract the result. This results in unnecessary network overhead and breaks the real-time event-driven flow.

OpenClaw version

v2026.3.2

Operating system

Ubuntu24.04

Install method

npm global

Model

qwen3.5-plus

Provider / routing chain

Aliyun (DashScope)

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To address the issue of the /status command not triggering a direct state update via the WebSocket connection, we need to modify the server-side logic to push the status results as a chat event payload. Here are the steps:

  • Modify the chat.send handler to capture the command output and push it as a chat event:
// In chat.send handler
if (message.startsWith('/status')) {
  const statusOutput = await getStatus(); // Assume getStatus() fetches the status
  const event = {
    type: 'event',
    event: 'chat',
    payload: {
      runId: runId,
      sessionKey: sessionKey,
      seq: seq,
      state: 'final',
      message: statusOutput, // Include the status output in the event payload
    },
    seq: seq,
  };
  // Emit the event via the WebSocket connection
  ws.emit('event', event);
}
  • Update the client-side logic to handle the new event payload:
// In client-side event handler
ws.on('event', (event) => {
  if (event.event === 'chat' && event.payload.state === 'final') {
    const statusOutput = event.payload.message;
    // Update the UI with the status output
    console.log(statusOutput);
  }
});

Verification

To verify that the fix worked, send the /status command and observe the WebSocket events. The event payload should now include the status output, eliminating the need for an extra chat.history roundtrip.

Extra Tips

  • Ensure that the getStatus() function is properly implemented to fetch the status output.
  • Consider adding error handling for cases where the status output is not available or fails to fetch.
  • Review the event payload structure to ensure it aligns with the expected format and includes all necessary information.

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 results of the /status command (and other similar internal commands) should be pushed directly as a chat event payload or a specific status event via the WebSocket, eliminating the need for an extra chat.history roundtrip.

#api#ssr#installation#tensor shape#autograd error#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: /status command returns state via chat.history instead of WebSocket event push [1 comments, 2 participants]