Bug type

Behavior bug (incorrect output/state without crash)

Summary

After a clean installation and onboarding, visiting http://127.0.0.1:18789/ immediately redirects to /chat?session=main and shows unauthorized: gateway token missing. The gateway logs confirm token_missing. However, manual WebSocket test with websocat using the same token succeeds, proving the gateway and token are functional.

Steps to reproduce

1. Install OpenClaw on a fresh Ubuntu 24.04 server using the official script:
   curl -fsSL https://openclaw.ai/install.sh | bash

2. Run openclaw onboard --install-daemon and choose QuickStart (skip model config if desired).

3. On the server, confirm the gateway is listening:
   sudo systemctl status openclaw-gateway → active, and curl http://127.0.0.1:18789 returns HTML.

4. Get the token from ~/.openclaw/openclaw.json.

5. From a Mac, establish an SSH tunnel:
   ssh -L 18789:127.0.0.1:18789 ubuntu@<server-ip>

6. In a Chrome/Chromium incognito window, visit http://127.0.0.1:18789/.

Expected behavior

The browser should display a login page (likely at /login) where the user can paste the token. After entering a valid token, the WebSocket connection should succeed and the chat interface should load.

Actual behavior

The page immediately redirects to http://127.0.0.1:18789/chat?session=main and shows:

• unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings) -

The gateway logs repeatedly show reason=token_missing for WebSocket connections from 127.0.0.1. Browser Developer Tools → Network tab confirms the WebSocket upgrade request to ws://127.0.0.1:18789/ does not include the ?access_token= parameter.

OpenClaw version

2026.3.2 (85377a2) – confirmed via openclaw --version

Operating system

Server: Ubuntu 24.04.4 LTS (x86_64) Client: macOS (tested on Sonoma) with Chrome 145 and Safari 26

Install method

Official installer script: curl -fsSL https://openclaw.ai/install.sh | bash

Logs, screenshots, and evidence

- Server-side WebSocket test (succeeds):
 "ws://127.0.0.1:18789/?access_token=abc123def456"
→ Returns
{"type":"event","event":"connect.challenge","payload":{"nonce":"...","ts":...}}
- Browser Network tab evidence:
The WebSocket connection request (type `websocket`) shows no query parameters.
- Gateway logs:

[ws] closed before connect ... reason=unauthorized: gateway token missing

Impact and severity

Affected users: Any user trying to access the Web UI via SSH tunnel (or presumably any localhost access).

Severity: Blocks workflow – users cannot log in to the Web UI at all, despite a functioning backend.

Frequency: Always – reproducible on every fresh install.

Consequence: Users are forced to use the TUI (openclaw tui) exclusively; the Web UI is unusable.

Additional information

The token is valid (proven by websocat).

Clearing all browser storage (LocalStorage, SessionStorage, IndexedDB, Cookies, Cache) in incognito mode does not resolve the issue.

Directly visiting /login still redirects to /chat.

The same behavior occurs in Safari (private window) and Chrome (incognito).

This happens on a completely fresh Ubuntu 24.04 installation with no prior OpenClaw config.

Suspect: Frontend routing bug – the login page is skipped because the app believes the user is already authenticated (perhaps reading an empty token from storage or an incorrect state).