wheat nimbus
i used standard openclaw update
Gateway did not become healthy after restart.
Gateway version mismatch: expected 2026.4.26, running gateway reported unavailable.
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 3000ms
Discovery (this machine)
Found 1 gateway(s) via Bonjour (local.)
Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown
Running locally on my macbook pro 13' 2020 i5 16gb ram
neon bridgeBOT
trim notchBOT
This looks like the CLI updated to 2026.4.26, but the macOS launchd gateway service either didn’t restart or is still pointing at a stale install.
Can you paste these first?
openclaw --version
which openclaw
node -v
openclaw gateway status --deep
openclaw status --all
Then try the safe service refresh:
openclaw gateway stop
openclaw gateway install --force
openclaw gateway start
openclaw gateway status
If it still says unavailable, run it in the foreground so we can see the real crash:
openclaw gateway run --verbose
Paste the first error/stack trace from that.
On macOS especially, if you use nvm, the LaunchAgent can sometimes keep pointing at an older Node/global OpenClaw path after updates. which openclaw + openclaw gateway status --deep should reveal that.
Docs refs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting 🦐
wheat nimbus
Hey Krill, I ran the commands and tried the safe service refresh.
openclaw --version = OpenClaw 2026.4.26 (be8c246)
which openclaw = /usr/local/bin/openclaw
node -v = v25.5.0
gateway status --deep shows the LaunchAgent is installed/loaded and points to the current install:
Command: /usr/local/opt/node/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Config cli/service: ~/.openclaw/openclaw.json
Runtime: running
Gateway: loopback 127.0.0.1, port 18789
At one point it reported:
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
But openclaw status --all still says:
Gateway unreachable: unauthorized: gateway token mismatch (provide gateway auth token)
Relevant log line:
reason=unauthorized: gateway token mismatch
Then I ran:
openclaw gateway stop
openclaw gateway install --force
openclaw gateway start
openclaw gateway status
Stop said launchctl did not fully stop it and used bootout fallback. After reinstall/start, service got a new PID, but status said:
Runtime: running
Connectivity probe: failed
connect ECONNREFUSED 127.0.0.1:18789
Gateway port 18789 is not listening
Then I ran:
openclaw gateway run --verbose
It did not immediately crash. It reached:
[gateway] resolving authentication…
[gateway] starting HTTP server...
[canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
[health-monitor] started
[plugins] bonjour: advertised gateway on port 18789
So it doesn’t look like a stale binary path anymore. CLI and service both point to 2026.4.26. Main issue seems to be gateway auth/token mismatch, plus after service refresh it sometimes runs but doesn’t listen on 18789.
Is there a safe way to regenerate or sync the gateway auth token without wiping state/sessions?
trim notchBOT
Yes — safe, and it won’t wipe sessions/state. It only changes gateway auth.
First, check the common macOS cause: launchctl env overrides. These can beat your config and cause token mismatch:
launchctl getenv OPENCLAW_GATEWAY_TOKEN
launchctl getenv OPENCLAW_GATEWAY_PASSWORD
If either prints a value, clear them:
launchctl unsetenv OPENCLAW_GATEWAY_TOKEN
launchctl unsetenv OPENCLAW_GATEWAY_PASSWORD
openclaw gateway restart
If mismatch persists, rotate the shared gateway token explicitly:
TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status
openclaw status --all
Then reopen UI/TUI with the fresh token:
openclaw dashboard
Small note: openclaw doctor --generate-gateway-token is safe too, but it’s mainly for missing token setup. For a suspected drift/mismatch, manually setting gateway.auth.token as above is cleaner.
Also: you’re on Node v25.5.0. OpenClaw docs recommend Node 24, with Node 22.14+ supported. If the service keeps “running but not listening,” I’d switch Homebrew to Node 24 after the auth fix.
Docs: https://docs.openclaw.ai/cli/doctor, https://docs.openclaw.ai/cli/devices#token-drift-recovery-checklist, https://docs.openclaw.ai/start/getting-started 🦐
wheat nimbus
Hey Krill, quick update.
I checked launchctl env first:
launchctl getenv OPENCLAW_GATEWAY_TOKEN
launchctl getenv OPENCLAW_GATEWAY_PASSWORD
Both printed nothing.
Then I rotated the gateway token exactly as suggested:
TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status
openclaw status --all
openclaw dashboard
The token mismatch seems gone now. New status is different: gateway is listening, but health still times out.
Then I switched from Node 25.5.0 to Node 24.15.0 via Homebrew:
brew install node@24
brew unlink node
brew link --overwrite --force node@24
Now:
node -v = v24.15.0
which node = /usr/local/bin/node
After reinstall/restart, LaunchAgent now uses Node 24:
Command: /usr/local/opt/node@24/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Current state:
OpenClaw 2026.4.26
Node 24.15.0
Gateway service loaded/running, pid 8527
Port 18789 is in use by openclaw-gateway
Listening: 127.0.0.1:18789
But openclaw status --all still says:
Gateway local ws://127.0.0.1:18789 unreachable timeout
Gateway health: timeout
Dashboard opens and auto-auth seems to work. Logs show:
device pairing auto-approved
webchat connected
sessions.subscribe ok
agent.identity.get ok
But when I type in dashboard it still does not work.
There is one suspicious thing in stderr: old Node 25.5.0 still appears in dyld errors looking for missing libsimdjson.29.dylib:
Referenced from: /usr/local/Cellar/node/25.5.0/bin/node
Reason: /usr/local/opt/simdjson/lib/libsimdjson.29.dylib no such file
But the active service command now clearly points to node@24.
So we fixed token mismatch and downgraded to Node 24, but gateway health still times out and dashboard connects without actually working. What should I check next?
trim notchBOT
Nice progress — token + Node runtime are fixed. I’d treat this as two separate signals now:
Next checks:
curl -v --max-time 5 http://127.0.0.1:18789/healthz
curl -v --max-time 5 http://127.0.0.1:18789/readyz
openclaw health --verbose --timeout 30000
openclaw gateway status --require-rpc --timeout 30000
openclaw gateway stability --json
Then tail the raw file log while sending /status in Dashboard, then a plain hi:
tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | egrep -i 'webchat|web-inbound|agent|model|session|error|timeout|dyld|simdjson'
If /status works but hi doesn’t, WebChat is fine and the break is likely agent/model/session runtime. Then run:
openclaw models status
openclaw infer model run --prompt "Reply with exactly: ok" --json
For the Node 25 dyld thing: first confirm whether it’s new or just old stderr history. Check for stale references:
ps -axo pid,ppid,command | egrep 'openclaw|node/25|node@24|18789' | grep -v egrep
lsof -nP -iTCP:18789 -sTCP:LISTEN
grep -R "/usr/local/Cellar/node/25.5.0" ~/.openclaw ~/Library/LaunchAgents /usr/local/bin 2>/dev/null
If those dyld lines are still appearing after a fresh restart, something stale is still launching Node 25 despite the main gateway command looking correct.
Docs refs: https://docs.openclaw.ai/gateway/health and https://docs.openclaw.ai/gateway/troubleshooting 🦐
wheat nimbus
Update after running the checks:
healthz and readyz both connect to 127.0.0.1:18789 but return no bytes and time out after 5s.
openclaw health --verbose --timeout 30000 fails with:
gateway timeout after 30000ms
openclaw gateway status --require-rpc --timeout 30000 also fails:
Read probe failed, gateway timeout after 30000ms
openclaw gateway stability --json fails:
Gateway stability failed: gateway timeout after 10000ms
Gateway process is still running/listening:
LaunchAgent loaded
Command uses Node 24 now: /usr/local/opt/node@24/bin/node
port 18789 in use by openclaw-gateway
During log tail, Dashboard/WebChat does connect:
webchat connected
sessions.list ok
models.list ok
But I did not see useful inbound/agent processing from Dashboard messages in the filtered log.
Model runtime itself works locally:
openclaw models status shows openai-codex/gpt-5.4 as default and OAuth ok.
openclaw infer model run --prompt "Reply with exactly: ok" --json returned ok=true and output "ok" using local transport.
One important weird thing:
models status says OAuth ok, but then prints:
gateway connect failed: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
So I think gateway.auth.token was rotated, but gateway.remote.token may still be stale/mismatched.
Also saw:
session file repaired: rewrote 2529 assistant message(s)
And the agent actually started working on Discord now and sent a message by itself, so at least Discord/agent is partially alive.
Main remaining problem seems to be:
HTTP/RPC health probes time out, Dashboard connects but doesn’t process messages properly, and gateway.remote.token may still not match gateway.auth.token.
trim notchBOT
Good catch — yes, fix the gateway.remote.* drift next.
Since you’re running local on the Mac, I’d remove stale remote client creds rather than syncing them:
openclaw config set gateway.mode local
openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token
openclaw config unset gateway.remote.password
openclaw gateway install --force
openclaw gateway restart
Then close existing Dashboard tabs and reopen from a fresh URL:
openclaw dashboard
Don’t paste tokens here, but you can sanity-check non-secret bits:
openclaw config get gateway.mode
openclaw config get gateway.remote.url
openclaw config get gateway.auth.mode
openclaw gateway status --require-rpc --timeout 30000
openclaw health --verbose --timeout 30000
If healthz/readyz still accept TCP but return zero bytes after that, I’m worried this is a 2026.4.26 gateway HTTP/RPC hang/regression rather than config. The Discord agent partially working + models.list ok means the process isn’t totally dead, but health/stability/read probes timing out is not healthy.
If it persists, run:
openclaw gateway diagnostics export --output ~/Desktop/openclaw-diagnostics.zip --timeout 30000
Then file it here with the zip + your repro notes: https://github.com/openclaw/openclaw/issues
The session file repaired: rewrote 2529 assistant message(s) is probably a one-time repair. If it repeats every restart, mention that in the issue too.
wheat nimbus
Update after clearing gateway.remote.*:
I ran:
openclaw config set gateway.mode local
openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token
openclaw config unset gateway.remote.password
openclaw gateway install --force
openclaw gateway restart
The unset commands returned:
Config path not found: gateway.remote.url
Config path not found: gateway.remote.token
Config path not found: gateway.remote.password
So those remote fields were not present.
Then I reopened Dashboard with:
openclaw dashboard
Sanity checks:
openclaw config get gateway.mode = local
openclaw config get gateway.remote.url = Config path not found
openclaw config get gateway.auth.mode = token
Good news: require-rpc now improved:
openclaw gateway status --require-rpc --timeout 30000
Result:
Runtime: running pid 9375
Command uses Node 24: /usr/local/opt/node@24/bin/node
Read probe: ok
Capability: read-only
Listening: 127.0.0.1:18789
But health still fails:
openclaw health --verbose --timeout 30000
It prints:
gateway connect failed: unauthorized: gateway token mismatch (provide gateway auth token)
Then:
Failed to start CLI: Error: gateway timeout after 30000ms
So clearing remote.* helped RPC/read probe, but health still seems to use a mismatched or missing gateway token. What token/config path should I check next without pasting the token?
trim notchBOT
Yep — next suspect is env overriding config, not gateway.remote.*.
In local mode, token precedence is:
OPENCLAW_GATEWAY_TOKEN → gateway.auth.token → remote fallback only if auth token unset.
So check for a stale token in the current shell or .env files, without printing secrets:
for k in OPENCLAW_GATEWAY_URL OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD OPENCLAW_CONFIG_PATH OPENCLAW_STATE_DIR OPENCLAW_PROFILE; do
v="${!k-}"
[ -n "$v" ] && case "$k" in
*TOKEN*|*PASSWORD*) echo "$k=<set-redacted>" ;;
*) echo "$k=$v" ;;
esac
done
grep -nE 'OPENCLAW_GATEWAY_(URL|TOKEN|PASSWORD)|OPENCLAW_(CONFIG_PATH|STATE_DIR|PROFILE)' .env ~/.openclaw/.env 2>/dev/null \
| sed -E 's/(TOKEN|PASSWORD)=.*/\1=<set-redacted>/'
Then test health while forcing the config token into env:
TOKEN="$(openclaw config get gateway.auth.token --json | node -pe 'JSON.parse(require("fs").readFileSync(0,"utf8"))')"
OPENCLAW_GATEWAY_TOKEN="$TOKEN" openclaw health --verbose --timeout 30000
OPENCLAW_GATEWAY_TOKEN="$TOKEN" openclaw gateway status --require-rpc --timeout 30000
If that works, fix is: remove/update the stale OPENCLAW_GATEWAY_TOKEN from your shell, .env, or ~/.openclaw/.env.
Also check this:
openclaw config file
openclaw gateway status --deep
Make sure CLI + service are both using the same config path.
Docs: https://docs.openclaw.ai/gateway/remote#credential-precedence, https://docs.openclaw.ai/help/environment 🦐
wheat nimbus
I ran the env override check. It found this:
/Users/mac/.openclaw/.env:2:OPENCLAW_GATEWAY_TOKEN=<set-redacted>
So there is a stale token in ~/.openclaw/.env.
Then I tested with the config token forced into env:
TOKEN="$(openclaw config get gateway.auth.token --json | node -pe 'JSON.parse(require("fs").readFileSync(0,"utf8"))')"
OPENCLAW_GATEWAY_TOKEN="$TOKEN" openclaw health --verbose --timeout 30000
OPENCLAW_GATEWAY_TOKEN="$TOKEN" openclaw gateway status --require-rpc --timeout 30000
health still failed with:
gateway closed (1008): unauthorized: gateway token mismatch
But gateway status with the forced token worked:
Read probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Then:
openclaw config file = ~/.openclaw/openclaw.json
openclaw gateway status --deep shows:
Config cli/service: ~/.openclaw/openclaw.json
Runtime: running pid 9375
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
So CLI/service use the same config path, gateway is reachable/admin-capable now, but openclaw health still fails with token mismatch. Should I delete/update OPENCLAW_GATEWAY_TOKEN from ~/.openclaw/.env and restart?
trim notchBOT
Yes — remove/update that stale ~/.openclaw/.env token and restart. Even if the main read probe works, that stale env can still poison child/health/client paths.
I’d make openclaw.json the single source of truth and remove the env token:
cp ~/.openclaw/.env ~/.openclaw/.env.bak.$(date +%Y%m%d%H%M%S)
python3 - <<'PY'
from pathlib import Path
p = Path.home() / ".openclaw/.env"
drop = ("OPENCLAW_GATEWAY_TOKEN=", "OPENCLAW_GATEWAY_PASSWORD=", "OPENCLAW_GATEWAY_URL=")
lines = p.read_text().splitlines()
p.write_text("\n".join(l for l in lines if not l.startswith(drop)) + "\n")
PY
unset OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD OPENCLAW_GATEWAY_URL
openclaw gateway restart
openclaw gateway status --deep
openclaw health --verbose --timeout 30000
If you want to keep token auth in .env instead, update it to match gateway.auth.token; don’t leave both disagreeing.
If health still fails after this, the token-drift part is resolved and we’re likely down to a health-command regression/hang — but removing the stale .env is definitely the right next step.
wheat nimbus
Update: I removed the stale gateway env token from ~/.openclaw/.env, made a backup first, unset the current shell env vars, and restarted the gateway.
The grep check now returns nothing for:
OPENCLAW_GATEWAY_URL
OPENCLAW_GATEWAY_TOKEN
OPENCLAW_GATEWAY_PASSWORD
So the stale ~/.openclaw/.env token is gone.
After restart, gateway status initially still showed a timeout during warm-up:
Runtime running pid 9947
Listening 127.0.0.1:18789
Connectivity probe failed: timeout
But then I reran:
openclaw health --verbose --timeout 30000
And now it no longer shows token mismatch or CLI failure. It returns normal health info:
Gateway target ws://127.0.0.1:18789
Source local loopback
Config /Users/mac/.openclaw/openclaw.json
Discord configured
WhatsApp linked
Agents main default
Heartbeat interval 30m
Session store has 46 entries
So removing the stale ~/.openclaw/.env token seems to have fixed the auth mismatch. I’ll test Dashboard/Discord now to confirm behavior.
trim notchBOT
Hell yes, that’s the right shape now 🎉
Root cause looks like:
gateway.auth.token was rotated in openclaw.jsonOPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env kept winning in some pathsThe warm-up timeout right after restart is less worrying if openclaw health --verbose --timeout 30000 now returns normally.
Final quick checks:
openclaw gateway status --deep
openclaw status --all
openclaw channels status --probe
If Dashboard + Discord both work, you’re good. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future users. 🦐
wheat nimbus
Final checks now.
Root cause confirmed: stale OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env was overriding the rotated gateway.auth.token from openclaw.json in some paths.
After removing it and restarting, openclaw health --verbose --timeout 30000 returns normally.
I’ll run:
openclaw gateway status --deep
openclaw status --all
openclaw channels status --probe
Then I’ll test Dashboard and Discord. If both work, I’ll mark your solution so Answer Overflow indexes it.
trim notchBOT
Perfect — glad we pinned it down. 🙌
That root-cause summary is exactly what future folks need:
stale OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env overriding rotated gateway.auth.token in openclaw.json.
If those final checks pass, you’re back in business. Thanks for sticking through the debugging trail — that one was annoyingly subtle. 🦐
wheat nimbus
Final checks are mixed.
Good:
openclaw gateway status --deep now works:
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
openclaw status --all also shows:
Gateway reachable 138ms, auth token, app 2026.4.26
Node 24.15.0
Gateway service running
But channels/status still has a problem:
openclaw channels status --probe ends with:
Gateway not reachable: gateway timeout after 30000ms
Gateway not reachable; showing config-only status.
Dashboard still doesn’t really work. When I send a message it just spins; last actual response in Dashboard is from 11:47.
Discord and WhatsApp still don’t work properly from my side, although logs show partial activity:
discord logged in to CLAWDBOT
WhatsApp Listening for personal WhatsApp inbound messages
WhatsApp inbound message detected
Suspicious log lines:
draining 2 active task(s), 1 active embedded run(s), and 0 runtime deps install(s) before restart without a timeout
Also earlier:
stuck session ... state=processing
Dashboard/WebChat connects, but some RPC calls are very slow:
chat.history 29935ms
models.list 29943ms
node.list 19852ms
So auth/gateway reachability seems fixed, but agent/channel/runtime looks stuck or slow. What should I reset/clear next without wiping sessions/state?
trim notchBOT
Yep — auth is fixed; now this looks like stuck in-flight runtime work / session lane blockage, not config.
I’d do this, in order, without deleting sessions:
openclaw tasks list --status running
openclaw tasks audit
openclaw tasks flow list --status running
If anything obviously stale is running:
openclaw tasks cancel <task-id-or-run-id>
openclaw tasks flow cancel <flow-id>
openclaw tasks maintenance --apply
Then check this setting:
openclaw config get gateway.reload.deferralTimeoutMs
Your log says “before restart without a timeout” — if that value is 0, set a bounded drain so future restarts don’t wait forever:
openclaw config set gateway.reload.deferralTimeoutMs 30000 --strict-json
Then do stop/start, not restart, to clear in-memory active runs/lanes:
openclaw gateway stop
sleep 5
openclaw gateway start
openclaw gateway status --deep
openclaw health --verbose --timeout 30000
Once it’s back, in Dashboard/Discord try standalone:
/stop
/new
/status
Don’t use sessions cleanup for this — that’s pruning/maintenance, not stuck-run recovery. If stop/start still leaves chat.history/models.list taking ~30s, export diagnostics and file it: https://github.com/openclaw/openclaw/issues
wheat nimbus
I ran the stuck task/runtime recovery steps.
Tasks:
openclaw tasks list --status running = 0 running, 0 queued, 0 issues
openclaw tasks flow list --status running = 0 running flows
openclaw tasks audit = 14 warnings, all lost/backing session missing
openclaw tasks maintenance --apply did not change it:
0 reconcile, 0 recovered, 0 prune
still 14 audit warnings
gateway.reload.deferralTimeoutMs was not set:
Config path not found
I set it:
openclaw config set gateway.reload.deferralTimeoutMs 30000 --strict-json
Config updated OK.
Then I did stop/start, not restart:
openclaw gateway stop
sleep 5
openclaw gateway start
Stop was degraded again:
launchctl stop did not fully stop the service; used bootout fallback and left service unloaded
Start re-bootstrapped the LaunchAgent, but gateway status now says:
Runtime running pid 10898
Connectivity probe failed
connect ECONNREFUSED 127.0.0.1:18789
Gateway port 18789 is not listening
Most important log line:
stuck session: sessionId=main sessionKey=agent:main:whatsapp:direct:+48606332584 state=processing age=150s queueDepth=0
Then:
openclaw health --verbose --timeout 30000
fails with:
gateway closed 1006 abnormal closure, no close reason
So there are no running tasks/flows to cancel, maintenance did not clear anything, deferral timeout is now set, but after stop/start the gateway service appears running while not listening, and the last gateway error points to a stuck WhatsApp direct session.
What should I clear next without deleting all sessions/state?
trim notchBOT
Auth is fixed; this is now a specific stuck session lane. Since tasks/flows are clean, I’d do a targeted session reset for only that WhatsApp session — with a backup first.
First, safest thing: if you haven’t yet, a full Mac reboot may clear the in-memory lane. If it still comes back, do this targeted move-aside:
openclaw gateway stop
Then back up/remove only the stuck session entry:
export KEY='<the stuck sessionKey from the log>'
export STORE="$HOME/.openclaw/agents/main/sessions/sessions.json"
export BACKUP_DIR="$HOME/.openclaw/agents/main/sessions/stuck-session-backups/$(date +%Y%m%d%H%M%S)"
mkdir -p "$BACKUP_DIR"
node <<'NODE'
const fs = require("fs");
const path = require("path");
const key = process.env.KEY;
const storePath = process.env.STORE;
const backupDir = process.env.BACKUP_DIR;
const store = JSON.parse(fs.readFileSync(storePath, "utf8"));
const actual = Object.keys(store).find(k => k === key || k.toLowerCase() === key.toLowerCase());
if (!actual) {
console.error("session key not found");
process.exit(2);
}
const entry = store[actual];
fs.writeFileSync(path.join(backupDir, "entry.json"), JSON.stringify({ key: actual, entry }, null, 2));
if (entry.sessionFile) {
let f = entry.sessionFile;
if (!path.isAbsolute(f)) f = path.resolve(path.dirname(storePath), f);
if (fs.existsSync(f)) {
const dest = path.join(backupDir, path.basename(f));
fs.renameSync(f, dest);
console.log("moved transcript to", dest);
}
}
delete store[actual];
fs.writeFileSync(storePath, JSON.stringify(store, null, 2) + "\n");
console.log("removed session entry:", actual);
NODE
Then:
openclaw gateway start
openclaw gateway status --deep
openclaw health --verbose --timeout 30000
This does not wipe all sessions/state — it just forces that one WhatsApp direct chat to start a fresh session. The backup is under stuck-session-backups if needed.
The 14 tasks audit lost/backing-session warnings are probably separate stale task ledger records, not the current blocker.
wheat nimbus
Final update: looks fixed now.
Root cause seems to have been the stale OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.env overriding the rotated gateway.auth.token from openclaw.json in some paths.
Fixes applied:
Current behavior:
I’ll mark your solution now so Answer Overflow indexes it. Thanks a lot for walking me through this.
trim notchBOT
Awesome — really glad it’s back. 🎉
That final summary is perfect for indexing:
OPENCLAW_GATEWAY_TOKEN in ~/.openclaw/.envopenclaw.json had the rotated gateway.auth.tokenFor Dashboard, a fresh tab from openclaw dashboard should be enough; if it still spins, clear that tab/session storage or reopen the generated URL.
Thanks for marking the solution — this one will definitely help the next person. 🦐