Summary
OpenClaw dashboard intermittently shows a generic "Fetch failed" error when the browser has a stale/invalid gateway token. The gateway itself is healthy and responding, but the UI error does not clearly point to token mismatch/rate-limit lockout.
Environment
- OpenClaw: 2026.2.26
- OS: macOS (arm64)
- Gateway: local loopback (
127.0.0.1:18789), token auth enabled
What happened
After token/auth churn, the dashboard repeatedly displayed "Fetch failed".
At the same time:
openclaw gateway status showed runtime running and RPC probe ok.curl http://127.0.0.1:18789/ and curl http://127.0.0.1:18789/overview both returned 200.
Gateway logs showed repeated websocket auth failures:
unauthorized: gateway token mismatchunauthorized: too many failed authentication attempts (retry later)
Expected behavior
When auth is the root cause, dashboard should show a precise actionable error (for example):
- "Gateway token mismatch"
- "Temporarily rate-limited after failed auth attempts"
- and offer a clear recovery action (refresh token, wait/backoff, open dashboard with
#token=..., clear stale local storage/session token).
Actual behavior
UI often surfaced only a generic "Fetch failed", which made it look like gateway connectivity was broken.
Repro (probable)
- Open dashboard with stale/invalid token state in browser storage.
- Trigger repeated reconnect attempts.
- Observe websocket token mismatch -> temporary auth rate-limit.
- Dashboard displays generic "Fetch failed".
Workaround
- Open dashboard URL with explicit current token hash (
http://127.0.0.1:18789/#token=<token>), preferably in incognito.
- Hard reload / clear site storage for localhost.
- Wait briefly for auth backoff to expire.
Extra note
A friendlier auth-specific UI state here would save a lot of troubleshooting time.
Summary
OpenClaw dashboard intermittently shows a generic "Fetch failed" error when the browser has a stale/invalid gateway token. The gateway itself is healthy and responding, but the UI error does not clearly point to token mismatch/rate-limit lockout.
Environment
127.0.0.1:18789), token auth enabledWhat happened
After token/auth churn, the dashboard repeatedly displayed "Fetch failed".
At the same time:
openclaw gateway statusshowed runtime running and RPC probe ok.curl http://127.0.0.1:18789/andcurl http://127.0.0.1:18789/overviewboth returned 200.Gateway logs showed repeated websocket auth failures:
unauthorized: gateway token mismatchunauthorized: too many failed authentication attempts (retry later)Expected behavior
When auth is the root cause, dashboard should show a precise actionable error (for example):
#token=..., clear stale local storage/session token).Actual behavior
UI often surfaced only a generic "Fetch failed", which made it look like gateway connectivity was broken.
Repro (probable)
Workaround
http://127.0.0.1:18789/#token=<token>), preferably in incognito.Extra note
A friendlier auth-specific UI state here would save a lot of troubleshooting time.