upgraded to the latest 8-apr version of openclaw, the gateway doesn't stay open now | Friends of the Crustacean 🦞🤝 | Page 1

charred nymphBOT Apr 8, 2026, 8:32 AM

#

thick boughBOT Apr 8, 2026, 8:32 AM

#

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

charred nymphBOT Apr 8, 2026, 8:32 AM

#

glossy bayBOT Apr 8, 2026, 8:33 AM

#

Got you — and quick correction first: the flag is --fix, not --fixed.

Let’s grab the exact crash reason in one pass. Please run these and paste output:

openclaw --version
openclaw status
openclaw gateway status --deep
openclaw doctor --fix --deep
openclaw gateway restart
openclaw logs --follow

If openclaw logs --follow doesn’t show anything useful, also paste:

#

tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Most common causes after upgrade are:

service/config mismatch (CLI config vs service config)
port conflict (EADDRINUSE)
missing/invalid local gateway mode/auth config

Once you paste those logs/status blocks, I’ll give you the exact fix (not generic guesses).

Docs for reference: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

gray steeple Apr 8, 2026, 8:35 AM

#

PS C:\Windows\system32> tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
head : The term 'head' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try again.
At line:1 char:53

tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
```
                                                ~~~~
```
- CategoryInfo : ObjectNotFound: (head:String) [], CommandNotFoundException
- FullyQualifiedErrorId : CommandNotFoundException

gray steeple Apr 8, 2026, 9:39 AM

#

@glossy bay

gray steeple Apr 9, 2026, 4:04 AM

#

gray steeple PS C:\Windows\system32> tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head...

any idea?

glossy bayBOT Apr 9, 2026, 4:04 AM

#

⚠️ Missing API key for provider "openai". Configure the gateway auth for that provider, then try again.

gray steeple Apr 9, 2026, 3:23 PM

#

i still can't get it to work.
i have uninstalled it and reinstalled again just now, but now it is saying that it doesn't recognize the openclaw command from powershell.. why?

glossy bayBOT Apr 9, 2026, 3:24 PM

#

That part is usually a PATH issue, not the gateway itself.

On Windows, when PowerShell says openclaw isn’t recognized, it usually means the npm global install directory isn’t on your PATH.

Try this in PowerShell:

npm config get prefix

Then add that exact directory to your User PATH in Windows Environment Variables.

Important:

on Windows, add the prefix itself, not \bin
on many setups it’s %AppData%\npm
then close every PowerShell window and reopen it

#

After that, run:

openclaw --version
openclaw gateway status
openclaw status --all

Paste those outputs here and I’ll help you debug the gateway crash next.

Docs I checked:

Also, if you’re on native Windows, docs still recommend WSL2 for the smoothest setup.

gray steeple Apr 9, 2026, 3:25 PM

#

PS F:\openclaw-state> openclaw --version
openclaw : The term 'openclaw' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

openclaw --version

  + CategoryInfo          : ObjectNotFound: (openclaw:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

PS F:\openclaw-state> openclaw gateway status
openclaw : The term 'openclaw' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

openclaw gateway status

  + CategoryInfo          : ObjectNotFound: (openclaw:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

glossy bayBOT Apr 9, 2026, 3:25 PM

#

Yep, this confirms the problem is before the gateway now, PowerShell just can’t see the OpenClaw CLI.

Please run these three and paste the output:

npm config get prefix
npm list -g openclaw --depth=0
$env:Path

What I’m checking:

if openclaw is actually installed globally
what npm’s global install directory is
whether that directory is in your PATH

On Windows, if it is installed, the fix is usually:

#

take the output of npm config get prefix
add that exact folder to your User PATH
fully close PowerShell
open a new PowerShell window
run:

openclaw --version

Important: on Windows, add the prefix itself, not \bin.

Once openclaw --version works, we can go straight back to the gateway issue with:

openclaw gateway status

#

openclaw status --all

Docs:

gray steeple Apr 9, 2026, 3:30 PM

#

PS F:\openclaw-state> npm config get prefix
F:\npm-global

It is already in my "User Path" variable

glossy bayBOT Apr 9, 2026, 3:31 PM

#

Good, that prefix looks sane.

So now we need to separate two cases:

OpenClaw did not actually install there
it installed, but this terminal still isn’t seeing that PATH

Please run these:

dir F:\npm-global\openclaw*
npm list -g openclaw --depth=0
where.exe openclaw
$env:Path -split ';' | Select-String 'F:\\npm-global'

One important Windows gotcha: if you’re using Windows Terminal or VS Code terminal, closing just the tab is often not enough. Fully quit the whole app, then reopen it, because new tabs can inherit the old PATH from the already-running parent process.

#

So the likely quick fix is:

completely close Windows Terminal / VS Code
open a fresh one
run:

openclaw --version

If that still fails, paste the four outputs above and I’ll pin down which side is broken.

gray steeple Apr 9, 2026, 4:45 PM

#

PS C:\Windows\system32> dir F:\npm-global\openclaw*

npm list -g openclaw --depth=0
where.exe openclaw
$env:Path -split ';' | Select-String 'F:\npm-global'
F:\npm-global
`-- (empty)

INFO: Could not find files for the given pattern(s).

F:\npm-global

PS C:\Windows\system32> openclaw --version
openclaw : The term 'openclaw' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

openclaw --version

  + CategoryInfo          : ObjectNotFound: (openclaw:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

glossy bayBOT Apr 9, 2026, 4:46 PM

#

Nice, this tells us exactly what’s wrong.

Your PATH is fine, but OpenClaw is not actually installed right now:

F:\npm-global is on PATH
where.exe openclaw found nothing
dir F:\npm-global\openclaw* found nothing
npm list -g openclaw --depth=0 is empty

So the uninstall worked, but the reinstall apparently didn’t complete.

Please run these next and paste the full output:

node -v
npm -v

#

npm install -g openclaw@latest

Then, if install succeeds:

dir F:\npm-global\openclaw*
openclaw --version

If npm install -g openclaw@latest throws an error, paste the whole error, that’s the real blocker now.

Docs I checked:

#

Once the CLI is back, we can go straight after the gateway crash again.

gray steeple Apr 9, 2026, 4:55 PM

#

PS C:\Windows\system32> node -v

npm -v
v24.13.1
11.8.0
PS C:\Windows\system32> npm install -g openclaw@latest
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated npmlog@5.0.1: This package is no longer supported.
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated glob@7.2.3: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated are-we-there-yet@2.0.0: This package is no longer supported.
npm warn deprecated gauge@3.0.2: This package is no longer supported.
npm warn deprecated tar@6.2.1: Old versions of tar are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

added 667 packages in 6m

99 packages are looking for funding
run npm fund for details

should i still run the 'dir F:\npm-global\openclaw*
openclaw --version' command in this case?

glossy bayBOT Apr 9, 2026, 4:55 PM

#

Yep, please do. That install looks like it completed. Those deprecation warnings are ugly, but they’re not the immediate blocker.

Run this next:

dir F:\npm-global\openclaw*
where.exe openclaw
openclaw --version
openclaw gateway status
openclaw status --all

If openclaw is still not recognized after the install, fully close PowerShell/Windows Terminal and open a fresh one first, then rerun those commands.

Once you paste that, we should finally be back on the actual gateway problem.

gray steeple Apr 9, 2026, 5:01 PM

#

PS C:\Windows\system32> dir F:\npm-global\openclaw*

where.exe openclaw
openclaw --version
openclaw gateway status
openclaw status --all

Directory: F:\npm-global

Mode LastWriteTime Length Name

-a---- 4/10/2026 12:53 AM 411 openclaw
-a---- 4/10/2026 12:53 AM 336 openclaw.cmd
-a---- 4/10/2026 12:53 AM 849 openclaw.ps1
F:\npm-global\openclaw
F:\npm-global\openclaw.cmd
OpenClaw 2026.4.9 (0512059)

🦞 OpenClaw 2026.4.9 (0512059) — I can't fix your code taste, but I can fix your build and your backlog.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-10.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: stopped (state Ready, last run 1, last run time 4/9/2026 1:13:10 AM, Task Last Run Result=1; treating as not running.)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006)

glossy bayBOT Apr 9, 2026, 5:01 PM

#

Nice, we’re finally past the PATH mess.

This is now a real gateway startup failure:

CLI works
service is registered
CLI config and service config match
Task Last Run Result=1 means the scheduled task starts, then exits with an error

So the next step is the log.

Please run:

openclaw gateway restart
openclaw gateway status --deep

#

openclaw logs --follow

If openclaw logs --follow keeps streaming, let it run just long enough to show the failure, then Ctrl+C and paste the first error / stack trace.

If that’s easier, you can also paste the tail of the log file directly:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-10.log" -Tail 200

The docs path I’m following here is:

https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

Once we see that error block, we should be able to pin the actual cause pretty fast.

gray steeple Apr 9, 2026, 5:11 PM

#

01:06:34+08:00 [gateway] loading configuration…
01:06:39+08:00 [gateway] resolving authentication…
01:06:40+08:00 [gateway] starting...
01:06:52+08:00 [gateway] starting HTTP server...
01:06:52+08:00 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root F:\openclaw-state\canvas)
01:06:52+08:00 [gateway] MCP loopback server listening on http://127.0.0.1:52616/mcp
01:06:52+08:00 [heartbeat] started
01:06:52+08:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
01:06:53+08:00 [gateway] agent model: minimax-portal/MiniMax-M2.7
01:06:53+08:00 [gateway] ready (6 plugins, 13.3s)
01:06:53+08:00 [gateway] log file: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
01:06:54+08:00 [gateway] starting channels and sidecars...
01:06:58+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
01:06:58+08:00 [hooks] loaded 4 internal hook handlers
01:08:52+08:00 [bonjour] restarting advertiser (service stuck in announcing for 114611ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
01:08:53+08:00 [ws] closed before connect conn=042bfd85-9e00-4be7-9abf-09d5e4dfd163 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
01:08:53+08:00 [ws] webchat connected conn=50d197c5-a532-40a6-bb9c-1bad0e9eb4bc remote=::1 client=openclaw-control-ui webchat v2026.3.28
01:09:48+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
01:09:49+08:00 [ws] ⇄ res ✓ config.get 56335ms conn=50d197c5…b4bc id=a420b38c…77b6
01:09:49+08:00 [ws] ⇄ res ✓ node.list 9622ms conn=50d197c5…b4bc id=d159e1b9…6a20
01:09:53+08:00 [plugins] embedded acpx runtime backend registered

glossy bayBOT Apr 9, 2026, 5:12 PM

#

Honestly, this log looks healthy so far.

Important lines:

gateway ready
webchat connected
config.get and node.list returned successfully

So I do not see a crash in what you pasted.

The noisy bits are probably not the blocker:

bonjour ... re-advertise = discovery annoyance, not a fatal startup error
ws closed before connect ... code=1006 = usually one failed client/probe connection, not the gateway dying

So next question is: is it actually still down right now, or did the reinstall/restart fix it?

Please run right now:

#

openclaw gateway status
openclaw status --deep

And tell me:

does http://127.0.0.1:18789/ open?
does the dashboard stay connected?

If it still dies, leave openclaw logs --follow running a bit longer and paste the lines after gateway ready, especially anything about:

error
exception
shutting down
closed
failed

I think we’re close now.

gray steeple Apr 9, 2026, 6:04 PM

#

🦞 OpenClaw 2026.4.9 (0512059) — I don't have opinions about tabs vs spaces. I have opinions about everything else.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-10.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: running (last run 267009, last run time 4/10/2026 1:04:59 AM)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
timeout

Port 18789 is already in use.

pid 2680: "C:\Program Files\nodejs\node.exe" F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.9 (0512059) — Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

|
o
|
o
|
o
[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\glysh.openclaw\openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///F:/npm-global/node_modules/openclaw/dist/call-Iw4xDZUX.js:460:9)
at listOnTimeout (node:internal/timers:605:17)
at process.processTimers (node:internal/timers:541:7)

glossy bayBOT Apr 9, 2026, 6:05 PM

#

Aha, this is more specific now.

This does not look like “gateway won’t stay open” anymore.

It looks like:

the gateway process is running
port 18789 is bound
but the RPC layer is timing out

That also matches your earlier log, where config.get took 56 seconds. So the process is alive, but it’s getting wedged / extremely slow after startup.

Best next step: bypass the Scheduled Task and run it in the foreground so we can see what it’s doing.

openclaw gateway stop

#

openclaw gateway run

Leave that running.

Then in a second PowerShell window, run:

openclaw gateway status

What I want next is one of these:

the foreground output from openclaw gateway run, especially anything after ready
or the exact error if openclaw gateway run fails immediately

#

The key detail here is: it’s probably hanging, not crashing. That’s why status says running but the RPC probe times out.

Docs:

gray steeple Apr 9, 2026, 6:06 PM

#

wait, the config should be under F:\openclaw-state' and not 'C:\Users'

glossy bayBOT Apr 9, 2026, 6:07 PM

#

Yes, that could absolutely be the real issue.

By default, OpenClaw uses:

OPENCLAW_STATE_DIR → ~\.openclaw
OPENCLAW_CONFIG_PATH → ~\.openclaw\openclaw.json

And your status output shows both CLI and service are currently using that default C: path.

So if your real setup is supposed to live under F:\openclaw-state, then after the reinstall you’re probably booting the wrong state/config.

First, verify the F: config actually exists:

dir F:\openclaw-state
Test-Path F:\openclaw-state\openclaw.json

#

If that file exists, then in the same PowerShell window run:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

That should restamp the Windows Scheduled Task to use the F: state/config instead of the default C:\Users\glysh\.openclaw.

Paste the output after that.

Docs I checked:

gray steeple Apr 9, 2026, 6:15 PM

#

PS C:\Windows\system32> $env:OPENCLAW_STATE_DIR='F:\openclaw-state'

$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — The only open-source project where the mascot could eat the competition.

Installed Scheduled Task: OpenClaw Gateway
Task script: F:\openclaw-state\gateway.cmd

🦞 OpenClaw 2026.4.9 (0512059) — Hot reload for config, cold sweat for deploys.

Restarted Scheduled Task: OpenClaw Gateway

🦞 OpenClaw 2026.4.9 (0512059) — I don't have opinions about tabs vs spaces. I have opinions about everything else.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
Command: C:\Program Files\nodejs\node.exe F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: F:\openclaw-state\gateway.cmd
Service env: OPENCLAW_STATE_DIR=F:\openclaw-state OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): F:\openclaw-state\openclaw.json
Config (service): F:\openclaw-state\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (last run 267009, last run time 4/10/2026 2:11:01 AM)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
timeout

Port 18789 is already in use.

pid 9492: "C:\Program Files\nodejs\node.exe" F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status

glossy bayBOT Apr 9, 2026, 6:15 PM

#

Much better. We fixed one real bug already:

service file is now F:\openclaw-state\gateway.cmd
service env points to F:\openclaw-state
CLI config and service config now match

So the wrong C: config issue is resolved. Nice catch.

What’s left might just be the fact that you checked immediately after restart. The status output is even telling you that:

Warm-up: launch agents can take a few seconds. Try again shortly.

So next, do this from the same PowerShell where those OPENCLAW_* vars are set:

Start-Sleep -Seconds 30

#

openclaw gateway status

Also check whether this opens and stays connected:

http://127.0.0.1:18789/

If it still says RPC probe: failed ... timeout after waiting, then do the clean foreground test from the same F: env:

openclaw gateway stop
openclaw gateway run

That will tell us whether it’s still hanging after startup, but at least now we know it’s hanging on the right config/state.

gray steeple Apr 9, 2026, 6:20 PM

#

PS C:\Windows\system32> openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — Your terminal just grew claws—type something and let the bot pinch the busywork.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
Command: C:\Program Files\nodejs\node.exe F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: F:\openclaw-state\gateway.cmd
Service env: OPENCLAW_STATE_DIR=F:\openclaw-state OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): F:\openclaw-state\openclaw.json
Config (service): F:\openclaw-state\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (last run 267009, last run time 4/10/2026 2:11:01 AM)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
timeout

Port 18789 is already in use.

pid 9492: "C:\Program Files\nodejs\node.exe" F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status

glossy bayBOT Apr 9, 2026, 6:20 PM

#

Yep, at this point it’s not just warming up. If it still times out now, it’s hung.

Next step is the foreground run, using the F: env we fixed.

In the same PowerShell window where you already set:

OPENCLAW_STATE_DIR=F:\openclaw-state
OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json

run:

openclaw gateway stop
openclaw gateway run

Leave that running and paste what it prints.

#

What I care about most is:

whether it reaches ready
whether it stalls after ready
any error/exception lines after that

If you want to test from a second window, re-set the same env vars there first, then run:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
openclaw gateway status

I think the Scheduled Task is hiding the real failure, and gateway run should expose it.

gray steeple Apr 9, 2026, 6:28 PM

#

i have ran 'gateway run' and result as follow:

02:23:39+08:00 [gateway] removed stale session lock: F:\openclaw-state\agents\healthcheck\sessions\c187327f-fb4f-4a3e-b7f3-ce3d5073f4a3.jsonl.lock (dead-pid)
02:23:39+08:00 [gateway] removed stale session lock: F:\openclaw-state\agents\main\sessions\21173ef1-f708-42e3-904e-5f7fe6e4002b.jsonl.lock (dead-pid)
02:23:39+08:00 [hooks] loaded 4 internal hook handlers
02:25:24+08:00 [bonjour] restarting advertiser (service stuck in announcing for 39408ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
02:25:27+08:00 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
02:25:27+08:00 (node:4244) [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)
02:25:27+08:00 [browser] control listening on http://127.0.0.1:18791/ (auth=token)
02:25:31+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
02:25:31+08:00 [telegram] [default] starting provider (@glyclawdbot)
02:25:59+08:00 [plugins] embedded acpx runtime backend ready
02:26:02+08:00 [bonjour] restarting advertiser (service stuck in announcing for 30248ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
02:26:02+08:00 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
02:26:02+08:00 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.29s.
02:26:14+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=unannounced)

glossy bayBOT Apr 9, 2026, 6:29 PM

#

That log is actually pretty helpful.

The core gateway does not look like it’s crashing. The next suspect is channel startup, especially Telegram:

starting provider (@glyclawdbot)
deleteWebhook failed
webhook cleanup failed

So let’s do one temporary diagnostic run with channels skipped. That avoids writing config and tells us immediately whether the hang is in channel startup.

In PowerShell:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
$env:OPENCLAW_SKIP_CHANNELS='1'

#

openclaw gateway stop
openclaw gateway run

Then in a second PowerShell, set the same env vars and run:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
$env:OPENCLAW_SKIP_CHANNELS='1'
openclaw gateway status

If status suddenly works with OPENCLAW_SKIP_CHANNELS=1, then we’ve basically proven the hang is in channel startup, and Telegram is the first thing I’d blame from that log.

After the test, you can clear it with:

#

Remove-Item Env:OPENCLAW_SKIP_CHANNELS

Paste the result of that skipped-channels test.

gray steeple Apr 9, 2026, 6:56 PM

#

when i run 'openclaw gateway stop
openclaw gateway run', why is it looking at my old config again and not under F drive?

PS C:\Windows\system32> openclaw gateway stop

openclaw gateway run

🦞 OpenClaw 2026.4.9 (0512059) — No $999 stand required.

Stopped Scheduled Task: OpenClaw Gateway

🦞 OpenClaw 2026.4.9 (0512059) — I'm not AI-powered, I'm AI-possessed. Big difference.

|
o
02:55:37+08:00 [gateway] loading configuration…
02:55:37+08:00 [gateway] resolving authentication…
02:55:37+08:00 [gateway] starting...
02:55:41+08:00 Config overwrite: C:\Users\glysh.openclaw\openclaw.json (sha256 bd49621d9961bd7edaba2d3e177549782960c44e0e4f414ef69dc37c926435ac -> c22f02548cd304cd65802b16c435bcd53cb92411f07247401c11aad0668bef02, backup=C:\Users\glysh.openclaw\openclaw.json.bak)
02:55:41+08:00 [gateway] auto-enabled plugins:

minimax-portal auth configured, enabled automatically.

glossy bayBOT Apr 9, 2026, 6:57 PM

#

Yep, exactly, and this explains it.

openclaw gateway run uses the current shell’s environment, not the Scheduled Task’s saved environment.

So you now have two different cases:

Scheduled Task was correctly restamped to use F:\openclaw-state
manual gateway run falls back to C:\Users\glysh\.openclaw unless you set the env vars in that shell first

That’s why it jumped back to the old config.

Use this exact block in one PowerShell window:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'

#

$env:OPENCLAW_SKIP_CHANNELS='1'
openclaw gateway stop
openclaw gateway run

Then, if you open a second PowerShell window, you must set the same vars there too before running openclaw gateway status.

So the short answer is: the service is using F:, but your manual shell was still using the default C: because those env vars were not set in that shell session.

If you want, after we finish debugging, I can show you how to make the F: path permanent so you don’t have to keep setting those vars manually.

gray steeple Apr 9, 2026, 7:01 PM

#

03:00:57+08:00 [gateway] loading configuration…
03:00:57+08:00 [gateway] resolving authentication…
03:00:57+08:00 [gateway] starting...
03:01:05+08:00 [gateway] starting HTTP server...
03:01:05+08:00 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root F:\openclaw-state\canvas)
03:01:05+08:00 [gateway] MCP loopback server listening on http://127.0.0.1:53174/mcp
03:01:05+08:00 [heartbeat] started
03:01:05+08:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
03:01:05+08:00 [gateway] agent model: minimax-portal/MiniMax-M2.7
03:01:05+08:00 [gateway] ready (5 plugins, 8.0s)
03:01:05+08:00 [gateway] log file: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
03:01:06+08:00 [gateway] starting channels and sidecars...
03:01:06+08:00 [gateway] removed stale session lock: F:\openclaw-state\agents\healthcheck\sessions\c868fd77-b148-41c9-83a6-450afd76440d.jsonl.lock (dead-pid)
03:01:06+08:00 [hooks] loaded 4 internal hook handlers
03:01:06+08:00 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
03:01:06+08:00 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
03:01:06+08:00 (node:11096) [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)
03:01:06+08:00 [browser] control listening on http://127.0.0.1:18791/ (auth=token)
03:01:11+08:00 [plugins] telegram missing register/activate export
03:01:11+08:00 [plugins] 1 plugin(s) failed to initialize (validation: telegram). Run 'openclaw plugins list' for details.
03:01:11+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)

glossy bayBOT Apr 9, 2026, 7:02 PM

#

Aha, that’s the smoking gun.

[plugins] telegram missing register/activate export

That usually means OpenClaw found a stale/broken Telegram plugin entry instead of the proper bundled one, often after an upgrade when an old plugin path is still shadowing the bundled plugin.

So now I’d do this, in the same PowerShell with the F: env set:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
openclaw doctor --fix
openclaw plugins inspect telegram
openclaw plugins list --verbose

Two important notes:

#

use --fix, not --fixed
make sure those OPENCLAW_* vars are set first, so doctor repairs the F: config, not the old C:\Users\... one

If I’m right, doctor --fix may repair a legacy bundled-plugin path, and plugins inspect telegram should show where that bad Telegram plugin is being loaded from.

Paste those outputs and I think we’ll have the exact culprit.

gray steeple Apr 9, 2026, 7:04 PM

#

i can't write anything into the same powershell because it's still running the gateway

glossy bayBOT Apr 9, 2026, 7:05 PM

#

Yep, that’s normal, openclaw gateway run takes over that terminal.

Easiest path now:

press Ctrl+C in that PowerShell to stop the foreground gateway
then run this in a fresh PowerShell:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
openclaw doctor --fix
openclaw plugins inspect telegram
openclaw plugins list --verbose

If you’d rather keep the gateway running, open a second PowerShell window and run the same block there, but you must set those two OPENCLAW_* vars again in the new window first.

#

So yes, the fix is just: stop the foreground run, or use a second shell.

gray steeple Apr 9, 2026, 7:13 PM

#

i ran the command, but the result is too long, which part should i paste to show you?

glossy bayBOT Apr 9, 2026, 7:13 PM

#

Just the Telegram-related bits and any repair/warning lines. 👍

Please paste these parts only:

From openclaw doctor --fix
- any lines mentioning:
- telegram
- plugins.load.paths
- bundled plugin
- rewrote
- warning
- error
From openclaw plugins inspect telegram
- the section that shows:
- id
- source / origin

#

path
- status
- error / validation message

From openclaw plugins list --verbose
- just the telegram entry/block

If it’s easier, you can rerun and filter it down like this:

openclaw doctor --fix | Select-String 'telegram|plugins.load.paths|bundled|rewrite|warning|error'
openclaw plugins inspect telegram | Select-String 'id|source|origin|path|status|error|validation'
openclaw plugins list --verbose | Select-String 'telegram'

That should give me the useful bits without the giant wall of text.

gray steeple Apr 9, 2026, 7:17 PM

#

o Legacy config keys detected ----------| - channels.telegram: channels.telegram.streamMode, channels.telegram.streaming (scalar), |
| chunkMode, blockStreaming, draftChunk, and blockStreamingCoalesce are legacy; use |
| channels.telegram.streaming.{mode,chunkMode,preview.chunk,block.enabled,block.coalesce |
| } |
| instead. Run "openclaw doctor --fix". |
| - channels.telegram: channels.telegram.streamMode, channels.telegram.streaming (scalar), |
| chunkMode, blockStreaming, draftChunk, and blockStreamingCoalesce are legacy; use |
| channels.telegram.streaming.{mode,chunkMode,preview.chunk,block.enabled,block.coalesce |
| }. |
| - channels.telegram: channels.telegram.streamMode, channels.telegram.streaming (scalar), |
| chunkMode, blockStreaming, draftChunk, and blockStreamingCoalesce are legacy; use |
| channels.telegram.streaming.{mode,chunkMode,preview.chunk,block.enabled,block.coalesce |
o Doctor changes ------------------------| |
| Moved channels.telegram.streaming (scalar) → channels.telegram.streaming.mode (partial). |
| |
+--------------------------------------------------------------------------------------------+
|
o Bundled plugins ---------------------------------+
| |
| Bundled plugin runtime deps are missing. |
| - @discordjs/opus@^0.10.0 (used by discord) |
| Fix: run openclaw doctor --fix to install them. |
Failed to install bundled plugin runtime deps: Error: npm install failed

glossy bayBOT Apr 9, 2026, 7:17 PM

#

Good, that helps a bit.

Two things there are probably not the main blocker:

the channels.telegram.streaming... legacy key warning
the missing @discordjs/opus package, that’s mainly for Discord voice, not Telegram startup

What I still need is the Telegram plugin source/path, because the real smoking gun was:

telegram missing register/activate export

So please paste just this next:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'

#

openclaw plugins inspect telegram

If that output is long, only paste the lines showing:

source / origin
path
status
error
validation

If you want, you can filter it down like this:

openclaw plugins inspect telegram | Select-String 'source|origin|path|status|error|validation|telegram'

#

That’s the part most likely to tell us why the wrong Telegram plugin is loading.

gray steeple Apr 9, 2026, 7:22 PM

#

Telegram
id: telegram
Telegram channel plugin
Status: loaded
Source: F:\npm-global\node_modules\openclaw\dist\extensions\telegram\index.js
Origin: bundled
channel: telegram

glossy bayBOT Apr 9, 2026, 7:23 PM

#

Perfect, that’s actually useful.

This says the Telegram plugin itself is:

bundled
loaded
coming from the normal packaged path

So the earlier missing register/activate export line is probably not the main issue after all.

The decisive test is still this:

while the gateway is running with OPENCLAW_SKIP_CHANNELS=1, does openclaw gateway status work or still timeout?

Please run this in a second PowerShell window:

#

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
$env:OPENCLAW_SKIP_CHANNELS='1'
openclaw gateway status

Then paste just that output.

That will tell us:

if status works → channel startup is the culprit, and Telegram network/webhook cleanup is the likely offender
if status still times out → the problem is somewhere deeper than channels

This is the cleanest fork in the road now.

gray steeple Apr 9, 2026, 7:25 PM

#

PS C:\Windows\system32> $env:OPENCLAW_STATE_DIR='F:\openclaw-state'

$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
$env:OPENCLAW_SKIP_CHANNELS='1'
openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — I've survived more breaking changes than your last three relationships.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
Command: C:\Program Files\nodejs\node.exe F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: F:\openclaw-state\gateway.cmd
Service env: OPENCLAW_STATE_DIR=F:\openclaw-state OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): F:\openclaw-state\openclaw.json
Config (service): F:\openclaw-state\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (last run 267009, last run time 4/10/2026 3:08:04 AM)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
timeout

Port 18789 is already in use.

pid 6612: "C:\Program Files\nodejs\node.exe" F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status

glossy bayBOT Apr 9, 2026, 7:26 PM

#

That’s actually a really important result.

Since OPENCLAW_SKIP_CHANNELS=1 still times out, Telegram is not the root cause.

So the picture now is:

gateway reaches ready
port 18789 is listening
but the CLI status RPC is timing out, even with channels skipped

That makes me think this may be a status-probe / gateway-RPC issue, not “the gateway won’t stay open”.

Quickest next check, and my recommendation:

open http://127.0.0.1:18789/
tell me whether the dashboard:
- loads at all

#

stays connected
- can show normal UI data

If you can also send a test message to your Telegram bot and it responds, that’s even better evidence the gateway itself is alive.

If the dashboard doesn’t work either, then I’ll give you one last ultra-minimal startup test with extra skip flags for browser/canvas/cron/providers. But since channels were already skipped, I’d first check whether the gateway is actually usable despite gateway status timing out.

gray steeple Apr 9, 2026, 7:29 PM

#

the dashboard works now, and the telegram is replying to my message (but very slow, and i am guessing there are some stucked session or messages).
but more importantly, i thought there are some old configs that needs to be cleared?

glossy bayBOT Apr 9, 2026, 7:29 PM

#

That’s actually great news, it means the gateway is basically alive again 🎉

And yes, I do think you have old config/state leftovers to clean up, but I’d do it safely, not by hard-deleting stuff.

What I’d recommend

Make F: the permanent OpenClaw home for your CLI too
Set these as User Environment Variables in Windows:
- OPENCLAW_STATE_DIR = F:\openclaw-state
- OPENCLAW_CONFIG_PATH = F:\openclaw-state\openclaw.json
That stops openclaw from falling back to C:\Users\glysh\.openclaw whenever you open a fresh shell.
Archive the old default state dir instead of deleting it
If you no longer want the old config used, rename:
- C:\Users\glysh\.openclaw
  to something like:

#

C:\Users\glysh\.openclaw-old

I’d rename, not delete, until you’re sure everything is stable.

Then restart and re-run doctor on the F: config
In a fresh PowerShell after setting the env vars:
```
openclaw doctor --fix
openclaw gateway restart
```

About the “stuck sessions/messages”

The stale lock files are already being auto-cleaned by startup, so I would not manually wipe sessions yet.

Since Telegram is replying, I’d first:

clean up the old C: fallback

#

let doctor --fix finish migrations on the real F: config
restart once cleanly

If Telegram is still very slow after that, then we can look specifically at backlog / session state next.

If you want, I can give you the safest exact Windows steps for making those two env vars permanent and archiving the old C:\Users\glysh\.openclaw folder.

gray steeple Apr 9, 2026, 7:32 PM

#

ok, give me the safest exact Windows steps for making those two env vars permanent

glossy bayBOT Apr 9, 2026, 7:32 PM

#

Safest way is the Windows UI, using User environment variables, not System ones.

Do this

Press Start
Search for environment variables
Open “Edit the system environment variables”
Click Environment Variables…

Under User variables for your account

If these already exist, select them and click Edit…
If not, click New…

Add:

Variable name

#

OPENCLAW_STATE_DIR

Variable value

F:\openclaw-state

Then add:

Variable name

OPENCLAW_CONFIG_PATH

Variable value

#

F:\openclaw-state\openclaw.json

Click OK on every dialog until they all close

Important after that

Fully close:

PowerShell
Windows Terminal
VS Code terminal windows, if you use them

Then open a fresh PowerShell and verify:

#

echo $env:OPENCLAW_STATE_DIR
echo $env:OPENCLAW_CONFIG_PATH

You should see:

F:\openclaw-state
F:\openclaw-state\openclaw.json

Then run:

openclaw gateway status

#

That should stop new shells from silently falling back to C:\Users\glysh\.openclaw.

Docs for the env vars themselves:

https://docs.openclaw.ai/help/environment

If you want, next I can give you the safest exact steps to archive C:\Users\glysh\.openclaw without deleting it.

gray steeple Apr 9, 2026, 7:37 PM

#

i don't need to archive what's under C drive because majority of my openclaw stuff are under F drive. i then ran openclaw doctor --fix and saw the below:

| Bundled plugin runtime deps are missing. |
| - @discordjs/opus@^0.10.0 (used by discord) |
| Fix: run openclaw doctor --fix to install them. |

Failed to install bundled plugin runtime deps: Error: npm install failed

Multiple state directories detected. This can split session history. |
| - ~.openclaw |
| Active state dir: F:\openclaw-state
Found 1 session lock file. |
| - F:\openclaw-state\agents\headhunter\sessions\ee28929c-46e1-41be-a623-900aa8c812c9.jsonl.lock |
| pid=6612 (alive) age=3m4s stale=no

glossy bayBOT Apr 9, 2026, 7:37 PM

#

Yep, that output is mostly telling us three separate things:

@discordjs/opus missing
- this is mainly for Discord voice
- if you are not using Discord voice, you can ignore it for now
- it is probably not the reason Telegram/OpenClaw was acting weird
Multiple state directories detected
- this just means C:\Users\glysh\.openclaw still exists
- your active state dir is correctly F:\openclaw-state
- now that you made the env vars permanent, this is much less dangerous
- if you truly do not care about the old C: folder, you can just leave it for now, but doctor will keep warning about it
The .lock file
- that one is normal
- pid=6612 (alive) and stale=no means the gateway is actively using it
- do not delete it while OpenClaw is running

#

My recommendation now

From a fresh PowerShell, run:

openclaw gateway restart
openclaw gateway status

If the dashboard still works and Telegram still replies, then I think you’re basically back in business.

The only remaining cleanup item is the old ~\.openclaw folder warning. That is optional unless you want doctor to stop complaining.

If Telegram is still unusually slow after this clean restart, we can debug the “stuck sessions/messages” part next.

Glad we got you this far, this was a messy one 😅

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

gray steeple Apr 9, 2026, 7:42 PM

#

still unusually slow after this clean restart, we can debug the “stuck sessions/messages” part

glossy bayBOT Apr 9, 2026, 7:43 PM

#

Yep, let’s debug that part now.

First I want to separate:

session-store / transcript bloat
Telegram transport slowness

Please run these from a fresh PowerShell:

openclaw sessions --all-agents --active 1440
openclaw sessions cleanup --all-agents --dry-run --json

What I’m looking for:

a surprisingly large number of active/recent sessions

#

one agent store being much bigger than the others
cleanup wanting to prune a lot of old entries/transcripts

If the output is long, paste just:

the store paths / agent ids
the counts
the beforeCount / afterCount / pruned parts

If those look normal, the next thing I’ll check is Telegram log lines for stuck getUpdates / send delays.

gray steeple Apr 9, 2026, 7:50 PM

#

not responding on telegram again.
and i am seeing these repetitive messages in gateway log:
03:48:02+08:00 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=189s queueDepth=1

session stores: 6
sessions listed: 22
filtered to last 1440 minute(s)

"stores": [
{
"agentId": "main",
"storePath": "F:\openclaw-state\agents\main\sessions\sessions.json",
"mode": "warn",
"dryRun": true,
"beforeCount": 28,
"afterCount": 14,
"missing": 0,
"pruned": 14,
"capped": 0,
"diskBudget": null,
"wouldMutate": true
},
{
"agentId": "healthcheck",
"storePath": "F:\openclaw-state\agents\healthcheck\sessions\sessions.json",
"mode": "warn",
"dryRun": true,
"beforeCount": 12,
"afterCount": 12,
"missing": 0,
"pruned": 0,
"capped": 0,
"diskBudget": null,
"wouldMutate": false
},
{
"agentId": "fintech",
"storePath": "F:\openclaw-state\agents\fintech\sessions\sessions.json",
"mode": "warn",
"dryRun": true,
"beforeCount": 8,
"afterCount": 8,
"missing": 0,
"pruned": 0,
"capped": 0,
"diskBudget": null,
"wouldMutate": false
},

{
  "agentId": "headhunter",
  "storePath": "F:\\openclaw-state\\agents\\headhunter\\sessions\\sessions.json",
  "mode": "warn",
  "dryRun": true,
  "beforeCount": 12,
  "afterCount": 12,
  "missing": 0,
  "pruned": 0,
  "capped": 0,
  "diskBudget": null,
  "wouldMutate": false
},
{
  "agentId": "email-scout",
  "storePath": "F:\\openclaw-state\\agents\\email-scout\\sessions\\sessions.json",
  "mode": "warn",
  "dryRun": true,
  "beforeCount": 12,
  "afterCount": 12,
  "missing": 0,
  "pruned": 0,
  "capped": 0,
  "diskBudget": null,
  "wouldMutate": false

glossy bayBOT Apr 9, 2026, 7:50 PM

#

Yep, that gives us something real to act on.

The key line is this:

[diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=189s queueDepth=1

That means a main session is wedged in processing, and the queue behind it is backing up.

I’d do these two recovery steps now

From a fresh PowerShell:

openclaw sessions cleanup --all-agents --enforce

#

openclaw gateway restart

Then in Telegram, send this as a standalone message to the bot:

/new

(/reset is also fine, but I’d use /new.)

Why

sessions cleanup --enforce will prune the old session entries that your dry-run already flagged in main
/new forces a fresh session id, so the stuck agent:main:main conversation doesn’t keep poisoning the queue

#

Important

Do not delete the live .lock file manually while the gateway is running.

If Telegram is still slow after cleanup + restart + /new, paste:

the new stuck session lines, if any
and whether /new itself got a response

I’m pretty optimistic this is the right next move.

gray steeple Apr 9, 2026, 8:00 PM

#

i have enforced the sessions clean up and /new in telegram
upon restarting the gateway, i am still seeing the below in gateway log:

03:58:01+08:00 [gateway] ready (6 plugins, 12.9s)
03:58:01+08:00 [gateway] log file: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-10.log
03:58:02+08:00 [gateway] starting channels and sidecars...
03:58:03+08:00 [hooks] loaded 4 internal hook handlers
03:58:06+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
03:59:32+08:00 [bonjour] restarting advertiser (service stuck in announcing for 85174ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
04:00:28+08:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
04:00:33+08:00 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
04:00:46+08:00 (node:7656) [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.
04:00:46+08:00 [browser] control listening on http://127.0.0.1:18791/ (auth=token)
04:00:46+08:00 [bonjour] restarting advertiser (service stuck in announcing for 17472ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
04:00:46+08:00 [telegram] [default] starting provider

glossy bayBOT Apr 9, 2026, 8:01 PM

#

Thanks, this is actually pretty clear now.

The session cleanup helped rule things out, but it did not fix the main slowdown.

What your log shows is:

core gateway gets to ready in about 13s
then it spends a long time in sidecars/startup extras
only much later do we see:
- ACP backend
- browser control
- Telegram provider startup

So the next suspect is sidecar startup, not old sessions.

One last isolation test

#

Please run this in a fresh PowerShell:

$env:OPENCLAW_STATE_DIR='F:\openclaw-state'
$env:OPENCLAW_CONFIG_PATH='F:\openclaw-state\openclaw.json'
$env:OPENCLAW_SKIP_CHANNELS='1'
$env:OPENCLAW_SKIP_PROVIDERS='1'
$env:OPENCLAW_SKIP_GMAIL_WATCHER='1'
$env:OPENCLAW_SKIP_CRON='1'
$env:OPENCLAW_SKIP_CANVAS_HOST='1'
$env:OPENCLAW_SKIP_BROWSER_CONTROL_SERVER='1'
openclaw gateway stop
openclaw gateway run

Then tell me:

#

how long it takes to reach ready
whether it still feels hung after ready
whether openclaw gateway status works from a second shell with the same env vars

Why this test

This strips out almost everything except the core gateway path.

If this becomes fast/responsive, the slowdown is in sidecars / startup extras
If this is still slow, then we’re probably looking at a deeper Windows/runtime regression in 2026.4.9

If it’s still slow even in this stripped mode, I’ll help you package the evidence for a GitHub issue, because at that point it really does smell like a bug.

gray steeple Apr 9, 2026, 8:07 PM

#

it took almost like 2 minutes to reach [gateway] ready (5 plugins, 7.8s)
and it still feels hung afterward
i don't know whether if openclaw gateway status works from a second shell with the same env vars

glossy bayBOT Apr 9, 2026, 8:07 PM

#

I think we’ve got enough now, and I’m pretty convinced this is a native Windows bug/regression in 2026.4.9, not just stale sessions or the wrong config.

Why I think that:

you fixed the state/config path to F:\openclaw-state
dashboard works, so the gateway is not simply “dead”
Telegram is intermittent/slow, not consistently broken
openclaw gateway status keeps timing out
even stripped startup still feels hung
we ruled out the obvious config/session cleanup stuff

At this point, my recommendation is:

1) File a GitHub issue

I can’t open it for you, but this is the right escalation path:
https://github.com/openclaw/openclaw/issues

#

You can paste this summary:

Version: OpenClaw 2026.4.9 (0512059)
Platform: native Windows / PowerShell
Node: v24.13.1
State dir: F:\openclaw-state
Config path: F:\openclaw-state\openclaw.json

Symptoms:
- gateway reaches "ready" but often feels hung afterward
- `openclaw gateway status` frequently times out even though port 18789 is listening
- dashboard works
- Telegram sometimes replies, but very slowly / intermittently stops replying
- session cleanup + `/new` did not resolve it
- skipping channels did not fully resolve it either

#

- native Windows startup appears to stall around sidecars / startup extras

Notable logs:
- repeated `RPC probe: failed ... timeout`
- `stuck session: sessionId=unknown sessionKey=agent:main:main state=processing ...`
- long delays around Bonjour / ACP backend / browser control / Telegram provider startup

Important context:
- initial issue was made worse because CLI/service had fallen back to `C:\Users\<user>\.openclaw`
- that was corrected by setting:
  - OPENCLAW_STATE_DIR=F:\openclaw-state
  - OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json
- after that, the gateway became partially functional, but still slow/hung

2) If you need a practical workaround right now

#

I’d seriously use WSL2 instead of native Windows for the gateway. The docs already recommend that path for Windows setups.

If you want, I can give you the shortest WSL2 migration path next.

gray steeple Apr 9, 2026, 8:12 PM

#

is it complicated to setup the WSL2 and to do all the migration?

glossy bayBOT Apr 9, 2026, 8:13 PM

#

Honestly, not that complicated. I’d call it medium effort, not hard.

If WSL2 is not installed yet, maybe 30 to 60 minutes.
If WSL2 is already there, more like 15 to 30 minutes.

The good news

If you copy the whole state dir, you usually keep:

your config
Telegram/channel state
sessions
auth profiles

So you probably do not need to re-onboard from scratch.

Rough migration shape

#

Install WSL2 + Ubuntu on Windows
Docs: https://docs.openclaw.ai/platforms/windows
Enable systemd in WSL
Required for openclaw gateway install
Install OpenClaw inside WSL
using the normal Linux flow
Stop the Windows gateway
Copy your state dir
from F:\openclaw-state into the Linux side, ideally under your WSL home
(best to run from Linux filesystem, not /mnt/f/... long-term)
Run openclaw doctor and restart the gateway inside WSL

#

My honest recommendation

Given how weird native Windows has been for you, I think WSL2 is worth it.

If you want, I can give you the shortest exact WSL2 migration path next, with copy-paste commands and no fluff.

#upgraded to the latest 8-apr version of openclaw, the gateway doesn't stay open now

What I’d recommend

About the “stuck sessions/messages”

Do this

Under User variables for your account

Important after that

My recommendation now

I’d do these two recovery steps now

Why

Important

One last isolation test

Why this test

1) File a GitHub issue

2) If you need a practical workaround right now

The good news

Rough migration shape

My honest recommendation