assistant: Both errors are coming from the Gateway websocket handshake, and they have two different root causes:

On your host, the gateway saw a browser coming through the Tailscale Serve proxy, then the socket died without a close frame (code 1006). The most common cause here is the client trying to connect to the wrong URL shape (redirect / trailing slash) or the proxy closing the upgraded connection.

Make sure you’re using:

/gateway/ often triggers a redirect, and redirects break WS upgrades in a way that shows up as 1006.

This one is definitive: the dashboard chat page was sending:

…but the Gateway only accepts an allowlisted set of client ids (e.g. openclaw-control-ui, webchat, cli, etc.). So it closed the connection with 1008 and that schema error.

I updated openclaw-dashboard to use an allowlisted id (openclaw-control-ui) for the connect handshake, then deployed it:

If it still drops, tell me whether it drops immediately (handshake) or after ~N seconds, and I’ll pull the corresponding gateway log lines around the disconnect. user: System: [2026-04-12 13:34:30 UTC] Exec completed (nova-val, code 0) :: 31-21-143 node[3820]: Already on 'main' Apr 12 09:15:05 ip-172-31-21-143 node[3820]: fatal: Cannot fast-forward to multiple branches. Apr 12 09:15:05 ip-172-31-21-143 node[3820]: Command exited with code 128 Apr 12 13:32:37 ip-172-31-21-143 node[3820]: 2026-04-12T13:32:37.418Z [ws] webchat connected conn=2829b51d-9808-4608-aac5-9721e889d863 remote=127.0.0.1 client=openclaw-control-ui webchat vdev System: [2026-04-12 13:36:03 UTC] Exec failed (ember-em, signal SIGKILL) System: [2026-04-12 13:36:44 UTC] Exec failed (swift-at, signal SIGKILL) System: [2026-04-12 13:37:08 UTC] Exec failed (faint-fo, signal 9)

control ui requires HTTPS or localhost (secure context) [message_id: 21ba2ddf-3fc5-4981-9101-c34b436b8650] assistant: That message is coming from the Gateway Control UI code path (it checks window.isSecureContext) and it only runs when the page is not considered a secure context by the browser.

A page is a secure context only if it’s loaded from:

So this error almost always means you’re actually loading the Control UI over plain HTTP (or via an origin the browser treats as insecure), even if you think you’re on the Tailnet URL.

What’s the full URL you’re visiting when you see “control ui requires HTTPS or localhost”? (Copy/paste the address bar.) user: https://openclaw.tail18850e.ts.net/chat. also yes i'd like 3 [message_id: a9237f73-e03a-4e77-9500-0d5f9531d868] assistant: Done. I added a dedicated Control UI path in Tailscale Serve:

Your Serve map is now:

Try opening /control in the browser. If you still see the “requires HTTPS or localhost” warning on that URL, tell me what browser/OS you’re using and whether any extension is forcing an http downgrade. assistant: Don’t give up — we just hit an annoying but known class of problems: path-prefix proxying an SPA that assumes it lives at /.

What you’re seeing lines up with that:

Use localhost port-forwarding for interactive UI stuff:

This satisfies the “localhost / secure context” requirement and avoids all the path-prefix proxy weirdness.

Let’s stop trying to expose the Control UI under /control (it’s not worth it), and keep Tailscale Serve for:

If you want, I can remove the /control mapping right now so it stops interfering. user: System: [2026-04-12 13:45:11 UTC] Cron: Dashboard Activity Sync complete.

i don't want to use local port forwarding. since my own dashboard is working, i'm assuming the gateway dashboard can work too . plus docs says you can access remotely https://docs.openclaw.ai/gateway/remote. also regardless the chat is not working, and chat is on my own dashboard, so i'm assumign it's different issue? [message_id: 773c2bfa-4e48-410e-9983-68618c22c7ff] assistant: No, we shouldn’t give up — this is fixable, and you’re right: your dashboard (/chat) is a different app and should work remotely.

What happened is we introduced a path-prefix hosting problem when we added /control:

I removed /control entirely and set up the Gateway Control UI on its own HTTPS port, at root, so it behaves exactly as designed:

If /chat still shows “control ui requires HTTPS or localhost”, paste a screenshot of the page + the DevTools Console first 20 lines. At this point that message should not even be present in the dashboard bundle unless the browser is still using a cached/bad asset path. user: https://openclaw.tail18850e.ts.net:444/ - also doens't work, disconnected (1008): unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control UI settings) [message_id: 20457c2b-8a35-4593-a914-2a01f4f365c2] assistant: That :444 result is actually progress: the Gateway is reachable and speaking WS, it’s just rejecting the Control UI because it isn’t receiving a token in its own settings yet.

More importantly: your /chat error was not “secure context” in your browser — it was the Gateway closing the connection with reason:

control ui requires HTTPS or localhost (secure context)

…and that happened because we identified your dashboard chat client as openclaw-control-ui, which triggers Control-UI-specific constraints inside the Gateway.

I changed the dashboard chat handshake to identify as webchat-ui with mode webchat (instead of pretending to be the Control UI). This avoids the Gateway’s Control-UI-only secure-context/device-signing rules.

Deployed:

If it still fails, the next thing I’ll check is the Gateway log line for the new connection and adjust accordingly, but this change should eliminate the “secure context” closure.

This is expected until you set the token inside the Control UI:

(That error is specifically token_missing, which matches the gateway logs.)

If you try /chat after the new deploy and it still errors, paste the exact red error text it shows now (it should no longer be the secure-context string). user: System: [2026-04-12 13:53:21 UTC] Exec failed (marine-b, signal SIGKILL) :: [main 44ebc61] fix(chat): identify as webchat-ui for gateway connect 1 file changed, 4 insertions(+), 4 deletions(-) To https://github.com/elite-flacco/openclaw-dashboard.git c2bcbea..44ebc61 main -> main System: [2026-04-12 13:53:46 UTC] Exec failed (ember-bi, signal SIGKILL)

its showing no data at all. i feel like it's not set up correctly [message_id: 42515707-958e-47f4-a835-f275e856300d] assistant: It is set up correctly — the screenshots show the Gateway UI loading fine, it’s just not authenticated, so it can’t fetch anything (hence all the n/a, “Health Offline”, and “Schema unavailable”).

The red banner in your screenshot is the whole story:

unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control UI settings)

On https://openclaw.tail18850e.ts.net:444/

As soon as the Control UI has the token, Health should flip to online and the Cron/Config/Sessions panes will populate.

Without a token, the Gateway intentionally refuses:

If you paste the token into the Control UI settings and it still doesn’t populate, tell me what it shows in the top-right pill (the Health status text), and I’ll pull the gateway log line for that connection. assistant: I didn't receive any text in your message. Please resend or add a caption. user: there's no place to set the token [message_id: 277ab183-3f61-464a-8723-483a7bd533d8] assistant: That banner is coming from the Control UI, not the Config editor. The token field doesn’t live on the “Config” page.

Here’s where it is:

If you truly don’t see that menu (some builds hide it when disconnected), you can also do it by opening the dashboard with a tokenized URL (same idea the banner mentions), e.g.:

A couple notes:

If you tell me which dashboard build/repo you’re using (or the URL path you’re on, e.g. /config), I can tell you the exact menu label/route it uses in that version.