#My dashboard

1 messages · Page 1 of 1 (latest)

ripe pine
#

My dashboard that was talking to the gateway just stop woring after the new update
i wonder what change

robust escarpBOT
ember mistBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

robust escarpBOT
solid narwhalBOT
#

Yeah, a few dashboard auth rules got stricter recently, so this is often not “the dashboard broke” so much as “the old access path no longer passes checks”.

Most common post-update causes:

  • opening the UI on http://<lan-ip>:18789 or http://<tailscale-ip>:18789 instead of http://127.0.0.1:18789/
  • missing/changed gateway token or password in Overview → Gateway Access
  • non-localhost access now needing explicit gateway.controlUi.allowedOrigins
  • remote plain HTTP hitting device-auth / secure-context checks

First, paste these:

pnpm openclaw --version
pnpm openclaw status
pnpm openclaw gateway status
pnpm openclaw doctor
ripe pine
#

not openclaw dashboard.. my own dashboard im talking it use to connect and stream it to my dashboard but after the new update it just stop showing what i was to get

solid narwhalBOT
#

Ah, got it, your custom dashboard, not the built-in one.

Then yes, there were gateway WS/protocol hardening changes that can break older dashboards. The big ones are:

  • Protocol v3 handshake

    • server sends connect.challenge
    • client must answer with connect
    • include minProtocol: 3 and maxProtocol: 3

  • Challenge signing is required now

    • clients must sign the nonce in connect.params.device
    • older clients that just sent a token can fail or get limited behavior

  • Event stream is scope-gated now

    • chat, agent, and tool-result style events require at least operator.read
    • if your dashboard connects as node, or as operator with no read scope, the socket may connect but the stream looks empty
#

So if your dashboard only reads data, it should usually connect as:

  • role: "operator"
  • scopes: ["operator.read"]

If it also sends commands/messages, add operator.write.

Can you paste these so I can tell which change hit you?

pnpm openclaw --version
pnpm openclaw gateway status

And from your dashboard side, tell me which one it is:

  1. socket never connects
ripe pine
#

The Diagnosis: The Dashboard is "Deaf" to Agents
Look closely at your logs. The server is receiving health events and tick events, but there are zero chat or agent events.

Normally, a healthy OpenClaw Gateway streams a constant flow of event:chat and event:agent frames. In your logs, we only see:

event: health (The Gateway saying "I'm alive").
event: tick (The heartbeat).
The problem is not the Dashboard server; the problem is the Gateway is not sending agent data to the server.

solid narwhalBOT
#

I don’t think that diagnosis is quite right.

If you’re getting only health and tick, that usually means:

  • the WebSocket is alive
  • but your client is not authorized or not subscribed for conversation events

A healthy gateway does not constantly emit chat/agent events when idle.

What changed recently is that broadcast events got tighter:

  • chat, agent, and tool-result events now require operator.read
  • pairing-only / node-only / low-scope clients will still see transport events like tick and health
  • transcript-style updates are session-scoped, so custom clients may also need:
    • sessions.subscribe
    • sessions.messages.subscribe
#

So for a custom dashboard, check these first:

  1. Your WS connect uses:

    • role: "operator"
    • scopes: ["operator.read"]
    • add operator.write too if the dashboard sends commands/messages

  2. After hello-ok, confirm the granted scopes actually include operator.read

  3. If you expect per-session updates, subscribe to the session explicitly with:

    • sessions.subscribe
    • sessions.messages.subscribe

If your dashboard is connecting as node, or as operator without operator.read, this exact “deaf dashboard” symptom is expected now.

If you want, paste a redacted version of:

  • your connect payload
ripe pine
#

i did all of that and notthing still not coming in

#

{"configured":true,"running":false,"lastStartAt":null,"lastStopAt":null,"lastError":null,"tokenSource":"none","probe":{"ok":true,"status":null,"error":null,"elapsedMs":407,"bot":{"id":8540965352,"username":"AllpreeBot","canJoinGroups":true,"canReadAllGroupMessages":true,"supportsInlineQueries":false},"webhook":{"url":"","hasCustomCert":false}},"lastProbeAt":1777000362113,"mode":null,
[Gateway] EVENT: health | session= | keys=['ok', 'ts', 'durationMs', 'channels', 'channelOrder', 'channelLabels', 'heartbeatSeconds', 'defaultAgentId', 'agents', 'sessions']
[Gateway] EVENT: tick | session= | keys=['ts']
[Gateway] UNKNOWN EVENT: tick | payload_preview={'ts': 1777000389502}
[Gateway] EVENT: presence | session= | keys=['presence']
[Gateway] UNKNOWN EVENT: presence | payload_preview={'presence': [{'host': 'gateway:chat.history', 'version': '2026.4.22', 'platform': 'win32', 'mode': 'backend', 'deviceId': '7d4cf729b909f642c8e1d8658db5a65c7aa8f1666c9c51e0956278a438c7d6a5', 'roles':
[Gateway] RAW USER-RELATED FRAME: {"type":"event","event":"health","payload":{"ok":true,"ts":1777000389813,"durationMs":1018,"channels":{"telegram":{"configured":true,"running":false,"lastStartAt":null,"lastStopAt":null,"lastError":null,"tokenSource":"none","probe":{"ok":true,"status":null,"error":null,"elapsedMs":312,"bot":{"id":8540965352,"username":"AllpreeBot","canJoinGroups":true,"canReadAllGroupMessages":true,"supportsInlineQueries":false},"webhook":{"url":"","hasCustomCert":false}},"lastProbeAt":1777000389813,"mode":null,
[Gateway] EVENT: health | session= | keys=['ok', 'ts', 'durationMs', 'channels', 'channelOrder', 'channelLabels', 'heartbeatSeconds', 'defaultAgentId', 'agents', 'sessions']

solid narwhalBOT
#

Then I think the next likely issue is not auth anymore, it’s the event model your dashboard is listening to.

A custom dashboard that used to passively watch event:agent / event:chat can break after the hardening changes. The safer path now is usually:

  1. connect as operator with operator.read
  2. call sessions.subscribe
  3. call sessions.list
  4. for each real session key, call:
    {"method":"sessions.messages.subscribe","params":{"key":"agent:main:main"}}
  5. listen for:
    • session.message
    • session.tool
    • sessions.changed

If your dashboard is only waiting for agent or chat, it may stay mostly quiet.

#

Minimal wire test

After connect, do this exact flow:

{"type":"req","id":"1","method":"sessions.subscribe","params":{}}
{"type":"req","id":"2","method":"sessions.list","params":{}}
{"type":"req","id":"3","method":"sessions.messages.subscribe","params":{"key":"<one key from sessions.list>"}}

Then trigger one message in that session.

What you should see:

  • event: sessions.changed
  • event: session.message
  • maybe event: session.tool

If you still get only tick and health, I need the raw redacted frames for:

#
  • connect request
  • hello-ok response
  • sessions.list response
  • sessions.messages.subscribe request/response
  • one attempted run after subscribing

Also, before we go deeper, paste:

pnpm openclaw --version

My honest guess: your dashboard is still wired for the older broad event flow, and now it needs per-session subscriptions plus session.message/session.tool handling.

Docs:
https://docs.openclaw.ai/gateway/protocol

#

Nice, this helps.

A couple important things from that dump:

  • that running:false blob is from the Telegram channel probe inside the health payload, not the gateway itself
  • tick and presence arriving means the socket is alive
  • UNKNOWN EVENT: tick/presence just means your dashboard parser doesn’t know those newer event names yet

What’s still missing in your logs is the real clue:

  • no logged hello-ok.auth
  • no sessions.list
  • no sessions.subscribe
  • no sessions.messages.subscribe

So I still think the dashboard is connected, but not subscribed to transcript/session events on that connection.

What to do on every reconnect

#

After WS connect succeeds:

{"type":"req","id":"1","method":"sessions.subscribe","params":{}}
{"type":"req","id":"2","method":"sessions.list","params":{}}
{"type":"req","id":"3","method":"sessions.messages.subscribe","params":{"key":"agent:main:main"}}

Then for every session key from sessions.list, subscribe it.

Also:

  • when you get sessions.changed, re-run sessions.list or subscribe any new key
  • subscriptions are per connection, so reconnect = re-subscribe everything

One more check

Log the hello-ok payload and confirm it grants:

# 
"role": "operator",
"scopes": ["operator.read"]

If you want, paste these 4 redacted frames next:

  1. connect
  2. hello-ok
  3. sessions.list response
  4. one sessions.messages.subscribe request/response

And please paste:

pnpm openclaw --version
ripe pine
#

it look like im going to stop these updates because it keep breaking my own setup kmt

solid narwhalBOT
#

That’s honestly fair. If you have a custom dashboard/integration, freezing updates for a bit is a sane move, not overreacting.

My recommendation:

  1. Get off beta/dev if you’re on it

    pnpm openclaw update --channel stable

  2. If you need maximum stability, pin a known-good version

    pnpm add -g openclaw@<working-version>
pnpm openclaw doctor
pnpm openclaw gateway restart

  3. Treat gateway updates like API upgrades for your dashboard

#
  • test first
    • then roll forward
    • don’t auto-update production blindly

If you want, the safest workflow is:

  • one machine/version for your real setup
  • one test install for trying updates first

If you paste:

pnpm openclaw update status
pnpm openclaw --version

I can tell you the cleanest “freeze here” path for your install type.

ripe pine
#

i dont know what you talking about..

solid narwhalBOT
#

Yeah, that’s on me, I overcomplicated it.

Simple version:

  • Your custom dashboard used to work
  • The update changed the gateway connection behavior
  • so now your dashboard likely needs a small code update, or you go back to the last version that worked

Easiest next step

Send me just these 2 things:

pnpm openclaw --version

and tell me:

#
  • what language your dashboard is written in (node, python, etc.)

If you want the fastest fix

Tell me:

  • the last OpenClaw version that worked
  • whether you want to rollback or fix the dashboard code

If you want, paste the part of your dashboard that connects to the gateway WebSocket, with any token removed, and I’ll tell you exactly what changed.

Background docs, if needed later: https://docs.openclaw.ai/gateway/protocol

ripe pine
#

im speanding all night a try fix this.. just let me how i can go back the older vs

solid narwhalBOT
#

Yeah, I’d stop fighting it too. Let’s just roll it back.

If you installed with pnpm/npm

Run this:

pnpm add -g openclaw@<last-working-version>
pnpm openclaw doctor
pnpm openclaw gateway restart
pnpm openclaw health

Replace <last-working-version> with the version that worked before.

If you installed from a git checkout

Run this in your OpenClaw repo:

# 
git fetch origin --tags
git checkout v<last-working-version>
pnpm install
pnpm build
pnpm openclaw gateway restart

If you do not know which install type you have

Paste these 2 commands and I’ll tell you the exact rollback command:

pnpm openclaw --version
pnpm openclaw update status

After rollback, just stay pinned there for now and don’t update again until you want to test your dashboard.

ripe pine
solid narwhalBOT
#

Yep, that installer usually does a package install, so rollback is pretty simple.

Easiest rollback on Windows PowerShell

openclaw --version
openclaw update --tag <OLD_VERSION> --yes
openclaw gateway restart

Example:

openclaw update --tag 2026.4.20 --yes
openclaw gateway restart
#

If openclaw update gives you trouble, use the installer again with a pinned version

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.20 -NoOnboard
openclaw gateway restart

If you don’t know what old version to use

Paste this:

openclaw --version
openclaw update status

and I’ll tell you the exact rollback command.