Docker: Token mismatch: autogenerated token: macOS 26.2

[slate oracle]

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

[steep silo]

Token mismatches in the Docker flow almost always come from “there are 2 (or 3) places a token can be set, and different parts are reading different ones.” In OpenClaw that’s typically:

1. Docker/Compose env var: OPENCLAW_GATEWAY_TOKEN (often coming from the repo’s .env, or your shell env)
2. Config file: gateway.auth.token in the config JSON
3. Control UI localStorage (cached gatewayUrl + token from a previous install)

On macOS especially, (1) is the usual culprit because Compose will prefer your shell environment over the generated .env file.

1) First: confirm what token the running gateway container is actually using

Run these and paste the output (no secrets):

# from the repo root (important)
docker compose exec openclaw-gateway sh -lc 'echo "OPENCLAW_CONFIG_PATH=${OPENCLAW_CONFIG_PATH:-<unset>}"; echo -n "OPENCLAW_GATEWAY_TOKEN="; [ -n "$OPENCLAW_GATEWAY_TOKEN" ] && echo "SET" || echo "UNSET"'
docker compose exec openclaw-cli     sh -lc 'echo "OPENCLAW_CONFIG_PATH=${OPENCLAW_CONFIG_PATH:-<unset>}"; echo -n "OPENCLAW_GATEWAY_TOKEN="; [ -n "$OPENCLAW_GATEWAY_TOKEN" ] && echo "SET" || echo "UNSET"'

Key idea: you already compared “token in file A equals token in file B”, but if OPENCLAW_GATEWAY_TOKEN is SET in the gateway container, the gateway may be using that (depending on build/config), not what you saw in the JSON file you checked.

2) Check if your host shell is injecting an old token into Compose

In the same terminal where you run docker compose up:

env | grep OPENCLAW_GATEWAY_TOKEN || true

If that prints anything, that value can override the .env that docker-setup.sh generated in the repo root.

Fix: unset OPENCLAW_GATEWAY_TOKEN (and remove it from your shell rc files if you set it there previously).

3) Make sure you’re editing the config file the containers actually mount/use

Inside the container, check which file exists (paths have changed across versions and some folks end up editing the wrong one):

docker compose exec openclaw-gateway sh -lc 'ls -la /home/node/.openclaw 2>/dev/null || true; ls -la /home/node | grep openclaw || true'

You mentioned /home/node/.openclaw.json — but current docs/examples often use /home/node/.openclaw/openclaw.json. If the gateway is reading a different config path than the one you’re editing on the host, you’ll get “looks identical” comparisons that don’t reflect runtime.

4) Control UI “keys mismatch”: clear cached browser state + use tokenized URL

If you previously had a native install, your browser may have cached old gateway settings/credentials.

Do this once:

• Open the dashboard in an incognito/private window, and/or clear site data for http://localhost:18789.
• Get a fresh tokenized URL from the CLI container (it avoids “did I paste the right token” problems):

docker compose run --rm openclaw-cli dashboard --no-open

(Then open the printed URL; it includes ?token=....)

If you then see “pairing required”, that’s expected for non-loopback-ish connections; approve the device:

docker compose run --rm openclaw-cli devices list
docker compose run --rm openclaw-cli devices approve <requestId>

5) Two quick context questions (so we don’t chase version-specific ghosts)

Please paste:

docker compose run --rm openclaw-cli --version

and confirm: are you running docker compose up from the repo root (same directory where docker-setup.sh wrote the .env)?