Bug type

Regression (worked before, now fails)

Summary

Opening the Control UI/Dashboard often auto-navigates to the main session and the tab becomes unresponsive (freeze). Opening a different session directly (e.g. work) works normally. This looks like session-data-dependent UI crash combined with “auto restore last/default session” that forces users into the broken main session.；High — opening the dashboard/root URL often forces navigation into session=main, which freezes the entire UI tab, preventing access to session list/settings needed to repair/export the corrupted session. Workaround exists by manually navigating to /chat?session=work, but it is non-obvious and fragile.

Steps to reproduce

1. Start OpenClaw gateway normally (token mode).
2. Open Control UI/Dashboard at http://127.0.0.1:18789/ (or via openclaw dashboard).
3. UI auto-navigates to something like:
   http://127.0.0.1:18789/chat?view=home&session=main
4. The tab freezes / becomes unresponsive (sometimes DevTools can’t open).
5. Open another session directly:
   http://127.0.0.1:18789/chat?session=work → loads and works.

Expected behavior

• A single corrupted/problematic session should not be able to freeze the entire UI.
• If restoring last/default session fails to render, UI should fall back to a safe screen (home/sessions list) and allow the user to export/delete/repair the session.
• Provide a “safe mode” / “skip session restore” option (e.g. query param like ?safe=1) and/or always respect explicit ?session= in the URL without overriding it.

Actual behavior

Auto-opening session=main causes the UI to freeze/hang.
• Because the UI forces navigation to main, the Control UI can become effectively unusable.

OpenClaw version

OpenClaw: 2026.3.12 (6472949)

Operating system

OS: Windows 10 x64

Install method

Browser: Chrome 146.0.7680.76 (Official Build) (64-bit)

Model

gpt5.4

Provider / routing chain

Control UI/Dashboard access: http://127.0.0.1:18789/ (local loopback) • UI route that freezes: auto-navigates to /chat?view=home&session=main • Working route (bypass): /chat?session=work loads normally • Gateway transport: WebSocket over HTTP on localhost (ws://127.0.0.1:18789) • Browser: Chrome 146.0.7680.76 (Official Build) (64-bit) • OS: Windows 10 x64 • OpenClaw: 2026.3.12 (6472949)

Config file / key location

2. Config file / key location (redacted) • Gateway config file: C:\Users\Administrator.openclaw\openclaw.json • Auth mode: gateway.auth.mode = "token" • Token location: gateway.auth.token (value redacted, 64-hex, single-line) • Gateway bind/listen: gateway.bind = "lan"; Listening: 0.0.0.0:18789 (verified via openclaw gateway status) • Important: No tokens or secrets are included in this report.

Additional provider/model setup details

• This issue is Control UI session rendering / session restore behavior, not model/provider-specific.
• Reproduces regardless of agent model configuration.
• Gateway is healthy (RPC probe: ok) while the UI tab freezes, suggesting a frontend/session-data-dependent crash rather than gateway not running.

Logs, screenshots, and evidence

A) Evidence (most important)

• Screenshot A: Browser address bar shows it navigates to
http://127.0.0.1:18789/chat?view=home&session=main
then the tab becomes unresponsive/frozen.
• Screenshot B: Opening
http://127.0.0.1:18789/chat?session=work
works normally (UI responsive).

B) Gateway status (text evidence)

From openclaw gateway status (redacted, no token):

• RPC probe: ok
• Listening: 0.0.0.0:18789
• Probe target: ws://127.0.0.1:18789

C) Logs (minimal + relevant)

From %LOCALAPPDATA%\Temp\openclaw\openclaw-*.log (redacted):

• [ws] ws client ready
• [ws] reconnect (seen at least once)

(Other [ws] log lines about Feishu event subscription are present but not relevant.)

D) User intent / constraint

• I do not want to delete the main session to recover.
The UI should provide a safe fallback (e.g., sessions list / safe mode) when auto-restoring a corrupted session causes a freeze.

Impact and severity

Severity: High (UI becomes unusable)
• Impact:
• If the UI auto-restores a corrupted session (main), the entire Control UI tab can freeze and become unresponsive.
• Users may be unable to access session list / settings to repair or delete the problematic session.
• Workaround exists by directly opening another session URL (/chat?session=work), but this is non-obvious and fragile.

Additional information

Repro frequency: 100% when navigating to session=main (in this environment)
• Workaround:
• Directly open http://127.0.0.1:18789/chat?session=work (or any non-main session) → UI works.
• Clearing site data helps with auth/cache but does not prevent the main-session freeze once navigated.
• Suggestion:
• Implement safe fallback if a session fails to render (auto redirect to sessions list)
• Add a “safe mode” query param to disable session restore
• Provide session export/repair tooling when a session causes UI crash