#TypeError: Cannot read properties of undefined (reading 'trim')

74 messages · Page 1 of 1 (latest)

faint knot
#

help me please

bright coralBOT
#

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:

  1. Stuck bootstrapping

  2. Stale session store entry

    • a bad entry in the session metadata can keep breaking startup/bootstrap
#

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.

faint knot
#

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.'

|

bright coralBOT
#

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:

faint knot
#

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>

bright coralBOT
#

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:

  1. openclaw gateway status
  2. the log output when the error actually happens
faint knot
#

i was getting trim error after completing onboard

bright coralBOT
#

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.

faint knot
#

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>

bright coralBOT
#

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.json actually lives

Once we have that, I can give you the exact safe rename command.

faint knot
#

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": []
}

bright coralBOT
#

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:

  1. openclaw doctor
  2. the openclaw logs --follow output when it breaks
  3. whether this is native Windows or WSL2
faint knot
#

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.

bright coralBOT
#

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 run keeps 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 trim stack trace directly

So please paste:

  1. the full output of openclaw gateway status
#
  1. everything openclaw gateway run prints 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.

faint knot
#

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

bright coralBOT
#

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:

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.

faint knot
#

{
"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"
}
}
}

bright coralBOT
#

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: running
  • RPC 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.

faint knot
#

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

bright coralBOT
#

Nice, that looks healthy now.

The important lines are:

  • ready
  • heartbeat started
  • embedded 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 trim error still appears, paste the new error/log block from this running terminal.

A couple quick notes:

#
  • that DEP0190 warning is not the blocker here
  • once you confirm it works, you can stop this foreground run with Ctrl+C and 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.

faint knot
#

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?)

bright coralBOT
#

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: running
  • RPC 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?

faint knot
#

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>

bright coralBOT
#

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 run for now
  • if you want always-on/background, either try openclaw gateway install or switch to WSL2

Also, please rotate the gateway token you pasted earlier.

faint knot
#

how can i totally get rid of openclaw and delete all cache

bright coralBOT
#

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.

Docs: https://docs.openclaw.ai/install/uninstall

#

If you want, I can give you the exact PowerShell “wipe everything” block to paste.

faint knot
#

CLI still installed. Remove via npm/pnpm if desired.

bright coralBOT
#

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.

faint knot
#

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')

bright coralBOT
#

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>
faint knot
#

i dont have an openclaw.json

bright coralBOT
#

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:

faint knot
#

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

bright coralBOT
#

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.

faint knot
#

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).

bright coralBOT
#

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.

faint knot
#

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"
}
}

bright coralBOT
#

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.

faint knot
#

⚠️ 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

bright coralBOT
#

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
faint knot
#

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>

bright coralBOT
#

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.

faint knot
#

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

bright coralBOT
#

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

  1. Get the current gateway token:
openclaw config get gateway.auth.token
  1. Open the dashboard/control UI at:
http://127.0.0.1:18789/
#
  1. 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.

faint knot
#

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

bright coralBOT
#

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

  1. Close the old dashboard/control tab
  2. Run:
openclaw dashboard