#error gateway connect failed: Error: unauthorized: gateway token mismatch (provide gateway auth toke

1 messages · Page 1 of 1 (latest)

supple ledge
#

trying to debug using openclaw logs --follow, but all i'm seeing is "error gateway connect failed: Error: unauthorized: gateway token mismatch (provide gateway auth token)" even when i'm entering things through the openclaw tui

vernal plumeBOT
pure garnetBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

vernal plumeBOT
harsh summitBOT
#

That usually means openclaw logs is connecting with the wrong auth, even if the TUI happens to be working.

A subtle gotcha: the TUI and logs are separate Gateway clients. The TUI can survive on cached device auth, while openclaw logs may still be using a mismatched shared token.

Can you paste these first?

openclaw --version
openclaw status --all
openclaw doctor

Please redact any secret values.

A few high-probability checks:

  • If you passed --url to openclaw logs or openclaw tui, you must also pass --token or --password explicitly. With --url, they do not fall back to config/env auth.
#
  • gateway.remote.token is only for the client side in remote mode, it does not set the gateway’s own auth.
  • Wrong URL/port can also show up as gateway connect failed, so openclaw status --all is useful here.
  • If the shared token is correct but it still loops on unauthorized, a stale paired device token can be the next thing to fix with openclaw devices list.

Docs:

If you send the --version + status --all output, I can narrow it down pretty quickly.

supple ledge
#

OpenClaw 2026.4.6 (18ff7d7)

harsh summitBOT
#

Nice, thanks, 2026.4.6 is recent enough.

That makes one thing more interesting: if you’re running plain openclaw logs --follow locally, it should fall back to the local log file when loopback auth gets in the way. So seeing gateway token mismatch usually means one of these:

  • you’re actually targeting a remote URL/profile
  • a stale OPENCLAW_GATEWAY_TOKEN is overriding config
  • you passed --url somewhere without the matching --token

Can you paste these next?

openclaw status --all
openclaw config get gateway.mode
openclaw config get gateway.remote.url
bash -lc 'printenv OPENCLAW_GATEWAY_TOKEN >/dev/null && echo OPENCLAW_GATEWAY_TOKEN=set || echo OPENCLAW_GATEWAY_TOKEN=unset'
#

Also, are you running exactly:

openclaw logs --follow

or are you adding --url / using a non-default profile?

If you are using --url, logs does not auto-apply auth, so you need the matching token too:
https://docs.openclaw.ai/cli/logs

Relevant auth docs too:
https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting-what-now
https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity

Don’t paste the actual token value here, just the command outputs.

supple ledge
#

iagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/me/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/me/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 1114351 openclaw: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    ✓ Skills: 16 eligible · 0 missing · /home/me/.openclaw/workspace
    ✓ Plugin compatibility (none)
    ! Channel issues (1)
  • telegram[default] config: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. · fix: In BotFather run /setprivacy → Disable for this bot (then restart the gateway).
#

openclaw config get gateway.mode gives "local"

#

i'm just using openclaw logs --follow with no other params

harsh summitBOT
#

This is helpful. The port warning is not the problem here, it just means your local gateway is already running. The Telegram warning is unrelated too.

What this points to instead is token drift between the CLI client and the running gateway. In practice, the usual causes are:

  • a stale OPENCLAW_GATEWAY_TOKEN in your shell or service env
  • you changed gateway.auth.token, but the already-running gateway still has the old one loaded

Try these locally:

bash -lc 'printenv OPENCLAW_GATEWAY_TOKEN >/dev/null && echo OPENCLAW_GATEWAY_TOKEN=set || echo OPENCLAW_GATEWAY_TOKEN=unset'
openclaw config get gateway.auth.mode

If that env var is set, and you are not intentionally using it, clear it for this shell and retry:

# 
unset OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD
openclaw logs --follow

If you recently changed gateway auth in config, restart so the running gateway reloads the same token the CLI is using:

openclaw gateway restart
openclaw logs --follow

If it still fails after that, run this next:

openclaw gateway status --deep
#

Yep, that rules out remote mode. In gateway.mode=local, gateway.remote.* is not the culprit.

So the shortlist is now basically:

  1. OPENCLAW_GATEWAY_TOKEN is set and overriding what the CLI uses
  2. the running gateway still has an older token loaded than the one in config

Next check:

bash -lc 'printenv OPENCLAW_GATEWAY_TOKEN >/dev/null && echo OPENCLAW_GATEWAY_TOKEN=set || echo OPENCLAW_GATEWAY_TOKEN=unset'

If it says set, and you are not intentionally using that env var:

#

If you send the set / unset result, I can tell you which branch to take next.

#

Got it, then this is not a logs usage problem.

With:

  • gateway.mode = local
  • local loopback target
  • plain openclaw logs --follow

…the likely issue is almost certainly auth drift:

  • stale OPENCLAW_GATEWAY_TOKEN in your shell, or
  • the gateway process is still running with an older token than the config now has

I’d do exactly this next:

# 
bash -lc 'printenv OPENCLAW_GATEWAY_TOKEN >/dev/null && echo OPENCLAW_GATEWAY_TOKEN=set || echo OPENCLAW_GATEWAY_TOKEN=unset'

If it says set:

unset OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD
openclaw logs --follow

If it says unset:

openclaw gateway restart
openclaw logs --follow
supple ledge
#

ok the restart fixed it. but why?

harsh summitBOT
#

Because the running gateway and the fresh CLI call were out of sync on auth.

Most likely, the gateway had a stale auth snapshot in memory, and openclaw logs --follow was using the current token source. Restarting made the gateway reload its auth state, so both sides agreed again.

Why the TUI could still seem okay:

  • an already-connected client can keep working longer than a fresh RPC call
  • the TUI may also have had cached device auth, while logs was doing a new shared-token auth check

So the issue probably was not logs itself, it was auth drift.

Typical causes:

  • token changed in config after the gateway was already running
  • env override changed
  • service env and CLI env/config were not matching