unauthorized: gateway token mismatch | Friends of the Crustacean 🦞🤝 | Page 1

worldly geyser Mar 9, 2026, 6:48 PM

#

This used to work, but now I am following errors when trying to run 'openclaw tui'

openclaw tui

🦞 OpenClaw 2026.3.7 (unknown) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

openclaw tui - ws://127.0.0.1:18789 - agent manager - session main
connecting | idle
gateway disconnected: unauthorized: gateway token mismatch (provide gateway auth token) | idle
gateway disconnected: unauthorized: gateway token mismatch (provide gateway auth token) | press ctrl+c again to exit
gateway disconnected: unauthorized: gateway token mismatch (provide gateway auth token) | idle
gateway connect failed: Error: unauthorized: gateway token mismatch (provide gateway auth token)─────────────────────────────────────────────────────────────────────────────────────────────────────────
gateway connect failed: Error: unauthorized: gateway token mismatch (provide gateway auth token)

visual robinBOT Mar 9, 2026, 6:51 PM

#

That error means the Gateway is reachable, but the TUI is authenticating with a different token than the Gateway is expecting (very common after reinstalling the gateway service / changing config / having an old OPENCLAW_GATEWAY_TOKEN lying around).

1) Check what auth mode you’re using (don’t paste the token)

Run these and paste the output with the token/password redacted:

openclaw gateway status --deep
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw config get gateway.auth.password

2) Quick fix paths

A) If you explicitly pass --url anywhere: you must also pass creds (no fallback):

openclaw tui --url ws://127.0.0.1:18789 --token <gateway-token>
# or:

#

openclaw tui --url ws://127.0.0.1:18789 --password <gateway-password>

(From docs: https://docs.openclaw.ai/web/tui)

B) If the Gateway runs as a background service (launchd/systemd): the service may still be using the old token even if your CLI config changed.
After you set the correct token in config, re-sync the service metadata:

openclaw gateway install --force
openclaw gateway restart

C) If you rotated/changed the token recently: make sure you changed the right key:

✅ gateway.auth.token
❌ old keys like gateway.token won’t work anymore (they’re ignored)

Troubleshooting ref: https://docs.openclaw.ai/gateway/troubleshooting

#

If you paste openclaw gateway status --deep (with secrets redacted), I can tell you exactly where the mismatch is coming from (CLI vs service env vs remote-mode).

worldly geyser Mar 9, 2026, 6:57 PM

#

I am running gateway in docker container.

openclaw gateway status --deep

🦞 OpenClaw 2026.3.7 (unknown) — I don't sleep, I just enter low-power mode and dream of clean diffs.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://10.10.0.12:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

openclaw config get gateway.auth.mode

🦞 OpenClaw 2026.3.7 (unknown) — I'm like tmux: confusing at first, then suddenly you can't live without me.

token

visual robinBOT Mar 9, 2026, 6:59 PM

#

Got it — Docker changes the “where is the token coming from?” story a lot.

What’s happening

Your CLI config says gateway.auth.mode = token, so the Gateway requires a token. But when the Gateway is inside a container, the token it’s enforcing is usually coming from inside the container (env var or the container’s own ~/.openclaw/openclaw.json). Your host-side openclaw tui is likely using a different token (or none), so you get gateway token mismatch.

Also: the systemd user services unavailable… stuff in gateway status --deep is basically noise here — you’re not using systemd; you’re using Docker.

Verify the token the container Gateway is actually using (don’t paste it here)

On the host, run:

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker exec -it <gateway-container> sh -lc 'echo "OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}"; echo "CLAWDBOT_GATEWAY_TOKEN=${CLAWDBOT_GATEWAY_TOKEN}"; openclaw config get gateway.auth.token; openclaw config get gateway.auth.mode'

(Just use that to inspect locally — please don’t post the token in Discord.)

#

Quick fix: pass the correct token to the TUI explicitly

Once you know the token the container is using:

openclaw tui --url ws://127.0.0.1:18789 --token <that-token>

Make it permanent (recommended)

Pick one token and make both sides use it:

In Docker Compose / docker run: set OPENCLAW_GATEWAY_TOKEN=... for the container (so it doesn’t change across restarts)
On the host: either export OPENCLAW_GATEWAY_TOKEN=... when running the TUI, or set it in host config:
```
openclaw config set gateway.auth.token "<same-token>"
```

Common “used to work, now broken” Docker gotcha

#

If you don’t mount/persist the container’s ~/.openclaw directory, the gateway may have regenerated state (including auth) on a recreate — so the host keeps trying the old token.

If you tell me whether you’re using docker run or docker compose (and whether you mount ~/.openclaw as a volume), I can point to the exact place to wire this up cleanly.

worldly geyser Mar 9, 2026, 7:02 PM

#

ok 'openclaw tui --token $OPENCLAW_GATEWAY_TOKEN' worked. Why am I having to state it manually now?

visual robinBOT Mar 9, 2026, 7:03 PM

#

Because openclaw tui only auto-picks up creds from (a) exported environment variables or (b) your config — but --token $OPENCLAW_GATEWAY_TOKEN works even if $OPENCLAW_GATEWAY_TOKEN is only a shell variable (not exported), because the shell expands it before openclaw even starts.

Two common causes:

1) The token isn’t actually in the process environment

Check what openclaw can see:

printenv OPENCLAW_GATEWAY_TOKEN

If that prints nothing, you probably set it like OPENCLAW_GATEWAY_TOKEN=... (not exported).
Fix:

export OPENCLAW_GATEWAY_TOKEN=...
# (or put `export OPENCLAW_GATEWAY_TOKEN=...` in your shell rc)

#

2) A stale `gateway.remote.token` is overriding it (remote-mode precedence)

In remote mode, gateway.remote.token wins over OPENCLAW_GATEWAY_TOKEN. So if it’s set to an old value, you’ll get “token mismatch” until you override with --token.

Check:

openclaw config get gateway.mode
openclaw config get gateway.remote.token

If you see a gateway.remote.token you don’t want, either update it or remove it:

openclaw config unset gateway.remote.token

Docs for the precedence rules: https://docs.openclaw.ai/gateway/remote (see “Credential precedence”).

If you paste the output of openclaw config get gateway.mode + whether printenv OPENCLAW_GATEWAY_TOKEN prints a value (no token itself), I can tell you which of the two it is.

worldly geyser Mar 9, 2026, 7:05 PM

#

openclaw config get gateway.mode

🦞 OpenClaw 2026.3.7 (unknown) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

local

And printenv did show my token correctly.

visual robinBOT Mar 9, 2026, 7:06 PM

#

If printenv OPENCLAW_GATEWAY_TOKEN shows the right token, but plain openclaw tui still fails, it almost always means:

openclaw tui is pulling a different token from your config file (~/.openclaw/openclaw.json) and using that instead of the env var.
Then --token … wins (explicit CLI arg always overrides), so it works.

Confirm (locally) which token source is being used

Run these (don’t paste the token back here):

openclaw config get gateway.auth.token
openclaw config get gateway.remote.token

If either of those is set to an old token, that’s the culprit.

Fix options

Option A (keep using env var, stop config from overriding):

#

openclaw config unset gateway.auth.token
openclaw config unset gateway.remote.token

Option B (make config match your env token so openclaw tui “just works”):

openclaw config set gateway.auth.token "$OPENCLAW_GATEWAY_TOKEN"

After that, openclaw tui should connect without needing --token.

If Option A/B fixes it, please mark the solution (right-click the solution message → Apps → ✅ Mark Solution) so Answer Overflow indexes it for the next person.

worldly geyser Mar 9, 2026, 7:08 PM

#

openclaw config get gateway.auth.token returns OPENCLAW_REDACTED

visual robinBOT Mar 9, 2026, 7:10 PM

#

Yep — that __OPENCLAW_REDACTED__ is the clue.

openclaw config get gateway.auth.token is redacted because you do have a token stored in ~/.openclaw/openclaw.json, and openclaw tui will use that configured token by default. In your case it’s just stale / different from the token your Docker gateway is using (the one in OPENCLAW_GATEWAY_TOKEN), so you get the mismatch.

Fix (pick one)

A) Prefer your env var going forward (don’t store token in config):

openclaw config unset gateway.auth.token
openclaw tui

Since printenv OPENCLAW_GATEWAY_TOKEN is set, TUI should now connect without --token.

B) Make the config token match your env token (store it in config):

openclaw config set gateway.auth.token "$OPENCLAW_GATEWAY_TOKEN"

#

openclaw tui

If A works, it’s the cleanest setup for Docker (compose/.env owns the token; your shell env owns the token; config doesn’t fight you).

If this fixes it, please mark the solution (right-click → Apps → ✅ Mark Solution) so it gets indexed.

#unauthorized: gateway token mismatch