web dashboard not correct working

[rose crow]

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

[runic citrus]

First thing: can you paste your version?

openclaw --version

Since console works, Gemini itself is probably okay — this sounds more like Control UI ↔ Gateway chat/event state, auth scope, or a frontend bug.

Please run these, then send one message in the Web UI while logs are open:

openclaw status --all
openclaw gateway status
openclaw logs --follow

Watch for errors like pairing required, scope-upgrade, unauthorized, chat.send, or Gemini/API errors.

Also try this quick browser-side check:

1. Hard refresh the Web UI
2. Try another browser/private window
3. If it asks for pairing or write access:

openclaw devices list
openclaw devices approve <requestId>

Docs for the relevant areas:
https://docs.openclaw.ai/start/faq
https://docs.openclaw.ai/web/control-ui
https://docs.openclaw.ai/gateway/troubleshooting

[summer mica]

OpenClaw 2026.4.23 (a979721)

[runic citrus]

Thanks — 2026.4.23 is useful info.

Because console works, I’d check the Web UI device/write permission path next.

Please try:

openclaw devices list

If you see a pending request or scope upgrade, approve it:

openclaw devices approve <requestId>

Then refresh the Web UI and try again.

If that doesn’t fix it, run this while sending one Web UI message:

openclaw logs --follow

Paste the error lines around the failed Web UI send — especially anything with chat.send, unauthorized, pairing required, scope-upgrade, Gemini, or Google.

Also worth trying once: private/incognito browser window, because stale Web UI browser state can cause weird disappearing-message behavior.

[summer mica]

operator │ │
│ 5d332cea459848 │ │ operator.read, │ │ │
│ a14907fa208ea6 │ │ operator.write, │ │ │
│ 9db876bd7687ad │ │ operator.approvals, │ │ │
│ 272c9237 │ │ operator.pairing │ │ │
│ e27401b4362b59 │ operator │ operator.read, │ operator │ │
│ c02db137e10f7f │ │ operator.admin, │ │ │
│ a438227fa0e64b │ │ operator.write, │ │ │
│ e4a55300297b0d │ │ operator.approvals, │ │ │
│ a7cf9337 │ │ operator.pairing, │ │ │
│ │ │ operator.talk. │ │ │
│ │ │ secrets │ │ │

[runic citrus]

That pasted table looks like you do have operator/write scopes, so pairing may already be okay. The important part is whether there’s a pending upgrade/request. You can preview that safely with:

openclaw devices approve --latest

If it shows a pending request, copy the exact requestId and run:

openclaw devices approve <requestId>

Docs note that --latest only previews; approval needs the exact request ID. (docs.openclaw.ai)

If no pending request appears, this is likely a Control UI rendering/state bug, not Gemini. There’s an open GitHub issue matching “messages disappear in Control UI while the run is happening”; the Gateway may still store the messages correctly. Try refresh / /new / another browser as a workaround. (github.com)

Next useful thing: run this, send one Web UI message, and paste the red/error lines:

openclaw logs --follow

That’ll tell us whether the run is actually failing or only the web dashboard is hiding it.

[summer mica]

there no pendings request or error messages with logs follow

[runic citrus]

Yep — if there are no pending device requests and no gateway log errors, I’d stop chasing pairing/auth.

This matches a known Control UI frontend/rendering bug: messages can disappear in the Web UI while the Gateway still has them stored correctly. Workarounds listed there are refresh, /new or /reset, or switching tabs. (github.com)

Try this next:

openclaw update --dry-run
openclaw update
openclaw health

openclaw update is the recommended updater and should also run doctor + restart the gateway. (docs.openclaw.ai)

If it still happens after updating, please check the browser console too — F12 → Console/Network — because frontend errors often won’t show in openclaw logs --follow.

For now, console/TUI is the safe workaround. If refresh makes the messages reappear, that confirms it’s Web UI rendering, not Gemini.

Bootstrap check done — I don’t see a resume file or today’s highlights, so I’m starting fresh on this thread.

Since console works and only the web UI chat fails, this is probably not Gemini itself. It sounds more like a Control UI / WebSocket / auth / origin problem.

Also: I don’t see the logs pasted yet.

Please send these first:

pnpm openclaw --version
pnpm openclaw status --all
pnpm openclaw gateway status
pnpm openclaw doctor

Then, while reproducing the issue in the web UI, run:

pnpm openclaw logs --follow

Two quick checks that matter a lot:

1. Open the UI via

   • http://127.0.0.1:18789/ or
   • http://localhost:18789/

   Not a LAN IP / reverse proxy / plain remote HTTP URL for now.

2. Tell me exactly what URL you’re using for the web UI right now.

If you’re opening it from a non-localhost URL, that can break the Control UI even while CLI still works.

If you want, also try this quick isolation test: