#TypeError: Cannot read properties of undefined (reading 'trim')
74 messages · Page 1 of 1 (latest)
Yep, let’s narrow it down.
First, paste these:
openclaw --version
openclaw status
If this is the bootstrap error Cannot read properties of undefined (reading 'trim'), the two most likely causes I’ve seen are:
-
Stuck bootstrapping
BOOTSTRAP.mdis still sitting in the workspace, so the agent keeps trying first-run bootstrap- docs: https://docs.openclaw.ai/start/bootstrapping
-
Stale session store entry
- a bad entry in the session metadata can keep breaking startup/bootstrap
- session store path is usually:
~/.openclaw/agents/<agentId>/sessions/sessions.json- legacy:
~/.openclaw/sessions/sessions.json - docs: https://docs.openclaw.ai/concepts/session
If you’re using a remote gateway, check those paths on the gateway host, not your laptop.
Also worth linking the FAQ since it covers state/layout paths:
https://docs.openclaw.ai/help/faq
Send the version + status output and I’ll tell you the safest next step.
C:\Users\ultra>openclaw --version
OpenClaw 2026.4.14 (323493f)
C:\Users\ultra>openclaw status
🦞 OpenClaw 2026.4.14 (323493f) — You had me at 'openclaw gateway start.'
|
Nice, that version is recent, so this probably isn’t just an old fixed bug.
openclaw status by itself is a bit too short here. Please paste these next:
openclaw status --all
openclaw gateway status
openclaw doctor
And tell me when the trim error appears:
- on
openclaw gateway start - on first chat/bootstrap
- in the dashboard/control UI
- or on every message
If this is bootstrap-related, also check whether this file still exists:
C:\Users\ultra\.openclaw\workspace\BOOTSTRAP.md
It should be removed after first-run bootstrap. If it’s still there, that’s a strong clue.
Troubleshooting ref: https://docs.openclaw.ai/help/troubleshooting
C:\Users\ultra>openclaw gateway start
🦞 OpenClaw 2026.4.14 (323493f) — I don't sleep, I just enter low-power mode and dream of clean diffs.
Restarted Windows login item: OpenClaw Gateway
C:\Users\ultra>
Got it, so the gateway starts cleanly. That’s actually helpful.
That means the trim error is probably happening after startup, not during gateway start.
Next step:
openclaw gateway status
openclaw logs --follow
Then, while openclaw logs --follow is running, do the thing that triggers the error and paste the first error block/stack trace here.
Also, quick check:
dir C:\Users\ultra\.openclaw\workspace\BOOTSTRAP.md
If that file exists, say so. It should normally be gone after bootstrap.
So right now I need 2 things:
openclaw gateway status- the log output when the error actually happens
i was getting trim error after completing onboard
Ah, that helps a lot. That matches a known post-onboard bootstrap/session-state issue.
I’d try these in order, safest first:
1) Check for a stuck bootstrap file
If this exists after onboarding finished, it can keep the agent in bootstrap mode:
dir C:\Users\ultra\.openclaw\workspace\BOOTSTRAP.md
If it exists, rename it, then restart the gateway:
ren C:\Users\ultra\.openclaw\workspace\BOOTSTRAP.md BOOTSTRAP.md.bak
openclaw gateway start
2) If that doesn’t fix it, back up the session store
A stale session entry can also cause the trim error after onboard.
Default path is usually:
C:\Users\ultra\.openclaw\agents\main\sessions\sessions.json
Rename it instead of deleting it:
ren C:\Users\ultra\.openclaw\agents\main\sessions\sessions.json sessions.json.bak
openclaw gateway start
Then start a fresh session and test again.
Docs:
- bootstrapping: https://docs.openclaw.ai/start/bootstrapping
- sessions: https://docs.openclaw.ai/concepts/session
If you want, paste the result of:
dir C:\Users\ultra\.openclaw\workspace\BOOTSTRAP.md
dir C:\Users\ultra\.openclaw\agents\main\sessions
and I’ll tell you exactly which of the two you should touch first.
C:\Users\ultra>dir C:\Users\ultra.openclaw\workspace\BOOTSTRAP.md
The system cannot find the file specified.
C:\Users\ultra>C:\Users\ultra.openclaw\agents\main\sessions\sessions.json
The system cannot find the path specified.
C:\Users\ultra>
Perfect, that rules out the stuck BOOTSTRAP.md case.
And yep, that second line tried to run the path instead of listing it. No worries.
Let’s have OpenClaw tell us the real session-store path instead of guessing:
openclaw sessions --all-agents --json
If that errors, also paste:
dir C:\Users\ultra\.openclaw
dir C:\Users\ultra\.openclaw\agents
What I’m looking for is:
- whether your state dir is actually the default
C:\Users\ultra\.openclaw - what the real agent id is
- where
sessions.jsonactually lives
Once we have that, I can give you the exact safe rename command.
C:\Users\ultra>openclaw sessions --all-agents --json
{
"path": null,
"stores": [
{
"agentId": "main",
"path": "C:\Users\ultra\.openclaw\agents\main\sessions\sessions.json"
}
],
"allAgents": true,
"count": 0,
"activeMinutes": null,
"sessions": []
}
That’s useful. The session store resolves correctly, and it’s empty, so I don’t think this is the stale sessions.json case after all.
So next I want the real stack trace, because the earlier guesses are getting ruled out.
Please run:
openclaw doctor
openclaw logs --follow
Then reproduce the trim error once and paste the first error block.
One more question: are you on native Windows or WSL2?
Reason I’m asking: native Windows is supported, but WSL2 is the more stable/recommended path in the docs, and onboarding/runtime edge cases are more common on native Windows:
https://docs.openclaw.ai/platforms/windows
At this point I need:
openclaw doctor- the
openclaw logs --followoutput when it breaks - whether this is native Windows or WSL2
im on windows. o Start gateway service now?
| Yes
Restarted Windows login item: OpenClaw Gateway
Updated ~.openclaw\openclaw.json
|
— Doctor complete.
C:\Users\ultra>OpenClaw Gateway
error: unknown command 'Gateway'
(Did you mean gateway?)
C:\Users\ultra>openclaw doctor
C:\Users\ultra>openclaw logs --follow
C:\Users\ultra>openclaw logs --follow
🦞 OpenClaw 2026.4.14 (323493f) — I read logs so you can keep pretending you don't have to.
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\ultra.openclaw\openclaw.json
Bind: loopback
Hint: run openclaw doctor.
Okay, we found the immediate problem: the gateway is not actually running, so logs --follow has nothing to attach to.
Let’s force the real error to show in the foreground.
Run these next:
openclaw gateway status
openclaw gateway run
A couple notes:
openclaw gateway runkeeps the gateway in the current terminal instead of the Windows background/login-item path- if there’s a real crash, this is the command most likely to print the actual
trimstack trace directly
So please paste:
- the full output of
openclaw gateway status
- everything
openclaw gateway runprints before it exits or hangs
And yep, since you’re on native Windows, that matches the rougher path in the docs. WSL2 is still the recommended setup long-term, but first I want to catch the real crash in gateway run.
17:44:18 [gateway] resolving authentication…
17:44:18 Gateway start blocked: existing config is missing gateway.mode. Treat this as suspicious or clobbered config. Re-run openclaw onboard --mode local or openclaw setup, set gateway.mode=local manually, or pass --allow-unconfigured.
17:44:18 Config write audit: C:\Users\ultra.openclaw\logs\config-audit.jsonl
Nice, we finally have the real blocker.
Your config is missing:
gateway: { mode: "local" }
So the gateway is refusing to start.
Best fix
Since you already onboarded, the quickest/safest repair is:
openclaw setup
openclaw gateway run
If that works, then you can go back to:
openclaw gateway start
Important
I would not use --allow-unconfigured as the real fix here. That only bypasses the guard, it does not repair the config.
Docs:
- setup: https://docs.openclaw.ai/cli/setup
- gateway troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting
If openclaw setup still doesn’t stamp it correctly, paste C:\Users\ultra\.openclaw\openclaw.json here and I’ll tell you the exact JSON5 edit.
{
"gateway": {
"auth": {
"mode": "token",
"token": "98f2771fe74ac98e62eac1b3c00f3197b6c44bfce7dcb056"
},
"mode": "local"
},
"wizard": {
"lastRunAt": "2026-04-14T22:00:38.687Z",
"lastRunVersion": "2026.4.14",
"lastRunCommand": "doctor",
"lastRunMode": "local"
},
"meta": {
"lastTouchedVersion": "2026.4.14",
"lastTouchedAt": "2026-04-14T22:46:35.428Z"
},
"agents": {
"defaults": {
"workspace": "C:\Users\ultra\.openclaw\workspace"
}
}
}
That config looks correct now. gateway.mode: "local" is present, so the earlier startup block should be fixed.
Next step:
openclaw gateway run
If that stays up, in another terminal run:
openclaw gateway status
What we want to see is:
Runtime: runningRPC probe: ok
Then retry the thing that was giving the trim error.
One important security note: you pasted your gateway token in a public thread. Please delete/edit that message and rotate the token after we get you running again. If you want, I can walk you through that next.
C:\Users\ultra>openclaw gateway run
🦞 OpenClaw 2026.4.14 (323493f) — I've survived more breaking changes than your last three relationships.
|
o
17:47:00 [gateway] loading configuration…
17:47:00 [gateway] resolving authentication…
17:47:00 [gateway] starting...
17:47:27 [gateway] starting HTTP server...
17:47:27 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\ultra.openclaw\canvas)
17:47:27 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
17:47:28 [gateway] agent model: openai/gpt-5.4
17:47:28 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 27.3s)
17:47:28 [gateway] log file: \tmp\openclaw\openclaw-2026-04-14.log
17:47:28 [gateway] starting channels and sidecars...
17:47:28 [hooks] loaded 4 internal hook handlers
17:47:28 [plugins] embedded acpx runtime backend registered (cwd: C:\Users\ultra.openclaw\workspace)
17:47:28 (node:36384) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use node --trace-deprecation ... to show where the warning was created)
17:47:28 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
17:47:31 [heartbeat] started
17:47:31 [plugins] embedded acpx runtime backend ready
Nice, that looks healthy now.
The important lines are:
readyheartbeat startedembedded acpx runtime backend ready
So the gateway is up. I think the real issue was the broken config/startup state, not a persistent live trim crash.
Next
Retry the thing you were doing right after onboard.
- If it now works, you’re basically unblocked.
- If the
trimerror still appears, paste the new error/log block from this running terminal.
A couple quick notes:
- that
DEP0190warning is not the blocker here - once you confirm it works, you can stop this foreground run with
Ctrl+Cand use:
openclaw gateway start
to put it back in the background again
Also, please delete/edit the message with the exposed gateway token and rotate it after this.
Microsoft Windows [Version 10.0.26200.8037]
(c) Microsoft Corporation. All rights reserved.
C:\Users\ultra>openclaw gateway start
🦞 OpenClaw 2026.4.14 (323493f) — Your AI assistant, now without the $3,499 headset.
Restarted Windows login item: OpenClaw Gateway
C:\Users\ultra>
C:\Users\ultra> OpenClaw Gateway
error: unknown command 'Gateway'
(Did you mean gateway?)
Yep, that last error is just from running the wrong command.
OpenClaw Gateway is not a command.
Use only:
openclaw gateway status
openclaw gateway start
openclaw gateway run
So right now, do this:
openclaw gateway status
If it says:
Runtime: runningRPC probe: ok
then the gateway/service side is fixed, and the next thing is just to retry the original post-onboard flow.
So the important question now is: is the original trim error gone?
C:\Users\ultra>openclaw gateway status
🦞 OpenClaw 2026.4.14 (323493f) — If it works, it's automation; if it breaks, it's a "learning opportunity."
|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-14.log
Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: unknown (Startup-folder login item installed; gateway port unknown.)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
C:\Users\ultra>
Yep, this is a different problem now.
The original trim blocker looks gone.
What’s failing now is the native Windows background/startup path:
- foreground:
openclaw gateway runâś… works - background/login item:
gateway start→Runtime: unknown,RPC probe: failed❌
So OpenClaw itself is okay. The flaky part is the native Windows service wrapper.
Best options
1) Fastest, reliable right now, recommended for tonight
openclaw gateway run
Just keep it running in that terminal.
2) If you want native Windows auto-start, try a fresh service install
openclaw gateway install
openclaw gateway status --json
3) Best long-term fix
Move to WSL2, which is the recommended Windows setup and much more stable:
https://docs.openclaw.ai/platforms/windows
So my recommendation is:
- use
openclaw gateway runfor now - if you want always-on/background, either try
openclaw gateway installor switch to WSL2
Also, please rotate the gateway token you pasted earlier.
how can i totally get rid of openclaw and delete all cache
Yep, if you want to fully nuke it on Windows, the easiest path is:
openclaw uninstall --all --yes --non-interactive
That’s the built-in full uninstall.
If you want to do it manually, or if uninstall fails:
openclaw gateway stop
openclaw gateway uninstall
schtasks /Delete /F /TN "OpenClaw Gateway"
Remove-Item -Recurse -Force "$env:USERPROFILE\.openclaw"
npm rm -g openclaw
If you installed with pnpm or bun, use that instead of npm:
pnpm remove -g openclaw
bun remove -g openclaw
If a task/script still lingers, also remove:
Remove-Item -Force "$env:USERPROFILE\.openclaw\gateway.cmd"
That wipes the usual config, logs, sessions, auth, workspace, and cache.
If you used profiles, also delete any ~\.openclaw-<profile> dirs.
If you want, I can give you the exact PowerShell “wipe everything” block to paste.
CLI still installed. Remove via npm/pnpm if desired.
Yep, that means the service/state cleanup ran, and the only thing left is the global CLI package.
Finish with whichever one you used:
npm rm -g openclaw
or
pnpm remove -g openclaw
or
bun remove -g openclaw
If you want to double-check after that:
where openclaw
If it’s fully gone, that should stop finding the CLI.
If this solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.
o How do you want to provide this Telegram bot token?
| Enter Telegram bot token
|
o Enter Telegram bot token
| 8624412885:AAELoVrcaXbB96eEASwdosNSSS3k8X01e38
|
o Telegram DM access warning --------------------------------------------------+
| |
| Your bot is using DM policy: pairing. |
| Any Telegram user who discovers the bot can send pairing requests. |
| For private use, configure an allowlist with your Telegram user id: |
| openclaw config set channels.telegram.dmPolicy "allowlist" |
| openclaw config set channels.telegram.allowFrom '["YOUR_USER_ID"]' |
| Docs: channels/pairing |
| |
+-------------------------------------------------------------------------------+
TypeError: Cannot read properties of undefined (reading 'trim')
Ah, that’s the real repro. This looks like a bug in the Telegram onboarding flow on 2026.4.14, right after the DM-policy warning.
First, important: you pasted a Telegram bot token in public. Please revoke it in BotFather and generate a new one.
Workaround
Skip the Telegram wizard step and add it manually to ~/.openclaw/openclaw.json:
{
channels: {
telegram: {
enabled: true,
botToken: "NEW_TOKEN_FROM_BOTFATHER",
dmPolicy: "pairing",
},
},
}
Then run:
openclaw gateway run
DM the bot, then approve the pairing:
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
If you want a private-only bot instead of pairing, use:
dmPolicy: "allowlist",
allowFrom: ["YOUR_NUMERIC_TELEGRAM_USER_ID"]
Docs: https://docs.openclaw.ai/channels/telegram
This is also worth filing as a bug here, with the exact repro you pasted:
https://github.com/openclaw/openclaw/issues
i dont have an openclaw.json
Yep, that makes sense if you just wiped it.
Do this instead of onboard:
openclaw setup
That creates the base config at:
C:\Users\ultra\.openclaw\openclaw.json
Then add your Telegram block to that file, for example:
{
gateway: {
mode: "local",
},
channels: {
telegram: {
enabled: true,
botToken: "NEW_TOKEN_FROM_BOTFATHER",
dmPolicy: "pairing",
},
},
}
Then run:
openclaw gateway run
So the flow is:
openclaw setup- edit
C:\Users\ultra\.openclaw\openclaw.json openclaw gateway run
Also, please use a new Telegram token since the old one got pasted in public.
Docs: https://docs.openclaw.ai/cli/setup and https://docs.openclaw.ai/channels/telegram
18:21:49 [gateway] loading configuration…
18:21:49 [gateway] resolving authentication…
18:21:49 [gateway] starting...
18:22:18 Config overwrite: C:\Users\ultra.openclaw\openclaw.json (sha256 f3f005604313545325b3fd185ecdcc001fd304b1c85ffd6ffdba38ed45128632 -> 842b38794314799ecc36d8bb5b559fe567129d2d7ae22224e8b7a3834c67dc01, backup=C:\Users\ultra.openclaw\openclaw.json.bak)
18:22:18 [gateway] auth token was missing. Generated a new token and saved it to config (gateway.auth.token).
18:22:21 [gateway] starting HTTP server...
18:22:21 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\ultra.openclaw\canvas)
18:22:21 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:22:21 [gateway] agent model: openai/gpt-5.4
18:22:21 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 31.9s)
18:22:21 [gateway] log file: \tmp\openclaw\openclaw-2026-04-14.log
18:22:21 [gateway] starting channels and sidecars...
18:22:22 [hooks] loaded 4 internal hook handlers
18:22:22 [plugins] embedded acpx runtime backend registered (cwd: C:\Users\ultra.openclaw\workspace)
18:22:22 (node:38648) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use node --trace-deprecation ... to show where the warning was created)
18:22:22 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
18:22:24 [heartbeat] started
18:22:24 [plugins] embedded acpx runtime backend ready
Nice, that looks healthy. The gateway is up, and I don’t see the old trim crash here.
So we’ve likely fixed the original blocker. 🎉
Next check
I don’t see Telegram startup lines in that log, so let’s verify whether the Telegram config actually loaded.
Run:
openclaw channels status --probe
and paste the Telegram section.
If Telegram still doesn’t show up there, then the next thing I want is your openclaw.json with the bot token redacted.
Also, that DEP0190 warning is not the issue.
C:\Users\ultra>openclaw channels status --probe
🦞 OpenClaw 2026.4.14 (323493f) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.
|
o
Gateway reachable.
Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
Yep, that means Telegram is not loaded from config yet.
If Telegram were configured, channels status --probe would show a Telegram section. Since it doesn’t, add this to C:\Users\ultra\.openclaw\openclaw.json and keep your existing gateway / agents parts:
{
// keep your existing gateway/agents config above
channels: {
telegram: {
enabled: true,
botToken: "NEW_TELEGRAM_BOT_TOKEN",
dmPolicy: "pairing",
},
},
}
Then restart:
openclaw gateway run
After that, openclaw channels status --probe should actually show Telegram.
Two important notes:
- use a new Telegram token, not the one pasted in the thread
- config is JSON5, so trailing commas are okay
Docs: https://docs.openclaw.ai/channels/telegram
If you want, paste your current openclaw.json with secrets redacted and I’ll tell you exactly where to insert the Telegram block.
fix this {
"agents": {
"defaults": {
"workspace": "C:\Users\ultra\.openclaw\workspace"
}
},
gateway: {
mode: "local",
},
channels: {
telegram: {
enabled: true,
botToken: "NEW_TOKEN_FROM_BOTFATHER",
dmPolicy: "pairing"
}
},
"meta": {
"lastTouchedVersion": "2026.4.14",
"lastTouchedAt": "2026-04-14T23:22:18.123Z"
}
}
Yep, here’s the fixed JSON5 version.
Important: if your file already has gateway.auth, keep it. Don’t delete that block.
{
agents: {
defaults: {
workspace: "C:\\Users\\ultra\\.openclaw\\workspace",
},
},
gateway: {
mode: "local",
// keep your existing auth block here if you already have one
},
channels: {
telegram: {
enabled: true,
botToken: "NEW_TOKEN_FROM_BOTFATHER",
dmPolicy: "pairing",
},
},
meta: {
lastTouchedVersion: "2026.4.14",
lastTouchedAt: "2026-04-14T23:22:18.123Z",
},
}
Then run:
openclaw gateway run
If you want, paste the full current file with secrets redacted and I’ll merge it cleanly so you don’t accidentally drop gateway.auth.
⚠️ Agent failed before reply: All models failed (2): opencode/kimi-k2.5: No API key found for provider "opencode". Auth store: C:\Users\ultra.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\ultra.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | openai/gpt-5.4: No API key found for provider "openai". Auth store: C:\Users\ultra.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\ultra.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | No API key found for provider "openai". Auth store: C:\Users\ultra.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\ultra.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. | No API key found for provider "openai". Auth store: C:\Users\ultra.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\ultra.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: openclaw logs --follow
Nice, this is a different error now, and it’s much more straightforward.
OpenClaw is running, but it has no model credentials yet.
That’s why the agent fails before replying.
Fix
Run:
openclaw configure --section model
That will walk you through adding a provider API key for the agent.
Then check:
openclaw models status
You want it to stop showing Missing auth for the provider/model you’re using.
Then restart and test again:
openclaw gateway run
What this means
- Telegram setup is no longer the blocker
- the gateway is up
- now you just need model auth for the agent
Docs:
If you want, paste the output of openclaw models status next and I’ll tell you exactly what’s still missing.
o
18:34:40 [gateway] loading configuration…
18:34:40 [gateway] resolving authentication…
18:34:40 Gateway start blocked: set gateway.mode=local (current: remote) or pass --allow-unconfigured.
18:34:40 Config write audit: C:\Users\ultra.openclaw\logs\config-audit.jsonl
C:\Users\ultra>
That just means your config got flipped back to remote mode.
Quick fix:
openclaw config set gateway.mode local
openclaw config get gateway.mode
openclaw gateway run
You want the second command to print:
local
Then the gateway should start normally again.
If it keeps getting flipped back, run:
openclaw configure --section gateway
and choose local.
Docs: https://docs.openclaw.ai/cli/config and https://docs.openclaw.ai/cli/configure
18:37:19 [telegram] [default] starting provider
18:37:19 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=DESKTOP-43NBC0E (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
18:37:23 [ws] unauthorized conn=cafdb2dd-40fa-4977-a1bb-466047c4d97c peer=127.0.0.1:53274->127.0.0.1:18789 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.14 role=operator scopes=5 auth=token device=yes platform=Win32 instance=43518196-2473-4db5-b481-d7e9f34a11b5 host=127.0.0.1:18789 origin=http://127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 reason=token_mismatch
18:37:23 [ws] closed before connect conn=cafdb2dd-40fa-4977-a1bb-466047c4d97c peer=127.0.0.1:53274->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 code=1008 reason=unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)
18:37:23 [ws] unauthorized conn=ea275e2f-1f81-48bf-afb2-9228aa6b7cd9 peer=127.0.0.1:65353->127.0.0.1:18789 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.14 role=operator scopes=5 auth=token device=yes platform=Win32 instance=43518196-2473-4db5-b481-d7e9f34a11b5 host=127.0.0.1:18789 origin=http://127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 reason=token_mismatch
18:37:23 [ws] closed before connect conn=ea275e2f-1f81-48bf-afb2-9228aa6b7cd9 peer=127.0.0.1:65353->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789
Nice, this is actually good news.
[telegram] [default] starting provider means Telegram is loading now.
The remaining problem is just the Control UI using an old gateway token.
Fix the UI token mismatch
- Get the current gateway token:
openclaw config get gateway.auth.token
- Open the dashboard/control UI at:
http://127.0.0.1:18789/
- In Control → Overview → Gateway Access, paste that value into the Gateway Token field, then click Connect.
If it still keeps failing, close/reopen the page or do a hard refresh, because the browser is probably caching the old token.
Do not paste the token here in Discord.
Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/help/faq
You’re very close now, the gateway and Telegram parts look alive.
C:\Users\ultra>openclaw config get gateway.auth.token
🦞 OpenClaw 2026.4.14 (323493f) — Your .zshrc wishes it could do what I do.
OPENCLAW_REDACTED
Yep, that’s expected, config get redacts secrets on purpose.
Use this instead:
openclaw dashboard
That command is the easy path here, it opens the Control UI using the current gateway token bootstrap.
I’d do this
- Close the old dashboard/control tab
- Run:
openclaw dashboard