Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Web UI blank screen after login on 2026.4.30-beta.1 [4 comments, 4 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#76170•Fetched 2026-05-03 04:41:24
View on GitHub
Comments
4
Participants
4
Timeline
7
Reactions
3
Author
Vianne-droidVianne-droid
Participants
BunsDevBunsDevclawsweeper[bot]clawsweeper[bot]suretargetsuretargetVianne-droidVianne-droid
Timeline (top)
commented ×4closed ×1subscribed ×1unsubscribed ×1

After upgrading from 2026.4.29 to 2026.4.30-beta.1, the web dashboard shows a blank screen immediately after entering the password. Hard refresh and incognito window both reproduce the issue.

Root Cause

After upgrading from 2026.4.29 to 2026.4.30-beta.1, the web dashboard shows a blank screen immediately after entering the password. Hard refresh and incognito window both reproduce the issue.

Fix Action

Workaround

None found. Rolling back to 2026.4.29 resolves the issue but is undesirable.

Code Example

← connect client=openclaw-control-ui version=dev mode=webchat auth=token
→ hello-ok methods=152 events=25 presence=17 stateVersion=36
⇄ res ✓ sessions.list
→ close code=1005 durationMs=267 handshake=connected lastFrameType=req lastFrameMethod=connect
RAW_BUFFERClick to expand / collapse

Description

After upgrading from 2026.4.29 to 2026.4.30-beta.1, the web dashboard shows a blank screen immediately after entering the password. Hard refresh and incognito window both reproduce the issue.

Environment

  • Version: 2026.4.30-beta.1
  • Deployment: Railway (Docker, node:24-bookworm-slim)
  • Browser: Tested in Chrome (regular + incognito)

Behaviour

  1. Navigate to /openclaw/ → password prompt appears ✅
  2. Enter correct password → blank screen ❌
  3. No UI renders at all

What the logs show

The webchat client connects, authenticates, requests sessions.list, then immediately disconnects (code 1005, normal closure) in under 300ms — before the UI has a chance to render anything.

← connect client=openclaw-control-ui version=dev mode=webchat auth=token
→ hello-ok methods=152 events=25 presence=17 stateVersion=36
⇄ res ✓ sessions.list
→ close code=1005 durationMs=267 handshake=connected lastFrameType=req lastFrameMethod=connect

This cycle repeats every ~30 seconds (reconnect attempts), but the UI never renders.

Additional context

  • Gateway API is fully healthy (/health returns {"ok":true})
  • HTML and JS assets load fine (both 200)
  • All other channels (Telegram, WhatsApp) are working normally
  • The issue did not exist on 2026.4.29
  • Gateway logs also show a liveness warning: eventLoopDelayMaxMs=3059.7 — possible contributor

Workaround

None found. Rolling back to 2026.4.29 resolves the issue but is undesirable.

extent analysis

TL;DR

The issue can likely be resolved by investigating and addressing the eventLoopDelayMaxMs warning in the gateway logs, which may be causing the premature disconnection of the webchat client.

Guidance

  • Investigate the cause of the eventLoopDelayMaxMs=3059.7 warning in the gateway logs, as it may be contributing to the premature disconnection of the webchat client.
  • Verify that the sessions.list request is being processed correctly and that the response is being sent back to the client before the disconnection occurs.
  • Check for any changes in the 2026.4.30-beta.1 version that may be causing the webchat client to disconnect immediately after authentication.
  • Consider increasing the timeout for the webchat client to allow for more time to render the UI before disconnecting.

Example

No code snippet is provided as the issue seems to be related to the interaction between the webchat client and the gateway API, and more information is needed to provide a specific code example.

Notes

The issue seems to be specific to the 2026.4.30-beta.1 version, and rolling back to 2026.4.29 resolves the issue. However, this is not a desirable solution, and further investigation is needed to identify the root cause.

Recommendation

Apply workaround: Investigate and address the eventLoopDelayMaxMs warning, as it is likely contributing to the issue. This may involve optimizing the gateway API to reduce the event loop delay or increasing the timeout for the webchat client.

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…
#api#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING