Gateway barely working, extremely slow | Friends of the Crustacean 🦞🤝 | Page 1

tribal arch Apr 27, 2026, 7:34 PM

#

I have been trying to troubleshoot this with chatgpt to no avail.

A few days ago, my gateway started being extremely slow. I could eventually get it running and speak to my agent, but then on Friday, I don't know what happen but he completely stopped working. Since then, I've barely been able to fully connect. I have tried rolling back to 4.23, but that didn't really help. I was able to send maybe three messages to him last night, but it's back to not working almost at all. I'm wondering if just jumping ahead to the 4.25 update might help?

I wish I could send attachments, I'd show you in a .txt doc what my gateway looks like right now, trying to start up for about an hour.

velvet condorBOT Apr 27, 2026, 7:34 PM

#

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

silk mothBOT Apr 27, 2026, 7:35 PM

#

Yeah — I’d try 2026.4.25. Friday was April 24, and 4.25 includes several fixes around slow gateway startup, plugin/runtime-dependency repair, update hangs, and broken 4.24-ish states.

Before/after updating, please paste this output in a code block:

openclaw --version
openclaw status --all
openclaw gateway status --deep
openclaw logs --limit 300 --max-bytes 500000

status --all is meant to be safe to share and redacts tokens.

To move to 4.25:

#

openclaw update --tag 2026.4.25
openclaw doctor --repair
openclaw gateway restart
openclaw status --all

If it still takes forever to start, the most useful thing is the repeated log line from openclaw logs --follow — usually it’s stuck on plugin runtime deps, model/provider startup, a channel reconnect loop, or a stale service/install mismatch.

Docs for the triage ladder: https://docs.openclaw.ai/help/troubleshooting

tribal arch Apr 27, 2026, 7:42 PM

#

PS D:\Caelan.openclaw\workspace> 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 D:\Caelan.openclaw\workspace> openclaw status --all
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 status --all

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

PS D:\Caelan.openclaw\workspace> openclaw gateway status --deep
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 --deep

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

PS D:\Caelan.openclaw\workspace> openclaw logs --limit 300 --max-bytes 500000
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 logs --limit 300 --max-bytes 500000

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

silk mothBOT Apr 27, 2026, 7:43 PM

#

That output means PowerShell can’t find the OpenClaw CLI at all, so we’re not yet debugging the gateway — we’re debugging install/PATH.

Try this in PowerShell:

node --version
npm config get prefix
$prefix = npm config get prefix
Test-Path "$prefix\openclaw.cmd"
& "$prefix\openclaw.cmd" --version

If that last line works, it’s just PATH. For this session:

$env:Path += ";$prefix"

#

openclaw --version

Then rerun:

openclaw status --all
openclaw gateway status --deep
openclaw logs --limit 300 --max-bytes 500000

If Test-Path "$prefix\openclaw.cmd" is False, reinstall/upgrade directly to 4.25:

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.25 -NoOnboard

#

Then close/reopen PowerShell and run openclaw --version.

One more wrinkle: if you originally installed OpenClaw inside WSL2, then Windows PowerShell won’t know about it. In that case run:

wsl
openclaw --version

Docs: https://docs.openclaw.ai/install/installer#windows-openclaw-is-not-recognized

tribal arch Apr 27, 2026, 7:44 PM

#

PS D:\Caelan.openclaw\workspace> node --version
v24.14.1
PS D:\Caelan.openclaw\workspace> npm config get prefix
D:\npm-global-clean
PS D:\Caelan.openclaw\workspace> $prefix = npm config get prefix
PS D:\Caelan.openclaw\workspace> Test-Path "$prefix\openclaw.cmd"
False
PS D:\Caelan.openclaw\workspace> & "$prefix\openclaw.cmd" --version
& : The term 'D:\npm-global-clean\openclaw.cmd' 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:3

& "$prefix\openclaw.cmd" --version

+ CategoryInfo          : ObjectNotFound: (D:\npm-global-clean\openclaw.cmd:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

silk mothBOT Apr 27, 2026, 7:45 PM

#

Yep — that confirms the CLI isn’t installed in your current npm global prefix.

Your state/workspace should still be safe; this is just the command wrapper missing. Reinstall 4.25 without onboarding:

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.25 -NoOnboard

Then close and reopen PowerShell, and run:

openclaw --version
openclaw doctor --repair
openclaw gateway restart
openclaw status --all

#

If openclaw is still not recognized after reinstall, run:

npm config get prefix
Get-ChildItem (npm config get prefix)

You’re looking for openclaw.cmd in that folder. If it exists but PowerShell can’t find it, add that folder (D:\npm-global-clean) to your Windows user PATH.

tribal arch Apr 27, 2026, 8:37 PM

#

so the install did something but then there's an error after it's done:

PS D:\Caelan.openclaw\workspace> & ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.25 -NoOnboard

OpenClaw Installer

[OK] Windows detected
[OK] Node.js v24.14.1 found
[*] Installing OpenClaw (openclaw@2026.4.25)...
npm.cmd : npm error code EPERM
At line:500 char:22

... npmOutput = & (Get-NpmCommandPath) install -g "$packageName@$Tag" 2>& ...
```
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
- CategoryInfo : NotSpecified: (npm error code EPERM:String) [], RemoteException
- FullyQualifiedErrorId : NativeCommandError

silk mothBOT Apr 27, 2026, 8:38 PM

#

That’s still before Gateway — the installer’s npm step is failing with a Windows permission/lock error in your global npm prefix.

I’d avoid fighting D:\npm-global-clean for now and switch npm’s global prefix back to the normal user-writable Windows location:

New-Item -ItemType Directory -Force "$env:APPDATA\npm"
npm config set prefix "$env:APPDATA\npm"
$env:Path += ";$env:APPDATA\npm"

Then retry:

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.25 -NoOnboard

Then close/reopen PowerShell and check:

#

openclaw --version
openclaw doctor --repair
openclaw gateway restart

Important: don’t delete D:\Caelan\.openclaw — that’s your state/workspace.

If it still says EPERM, paste the last npm log tail:

Get-ChildItem "$env:LOCALAPPDATA\npm-cache\_logs" |
  Sort-Object LastWriteTime -Desc |
  Select-Object -First 1 |
  ForEach-Object { Get-Content $_.FullName -Tail 80 }

#

Docs: https://docs.openclaw.ai/install/node#troubleshooting

tribal arch Apr 27, 2026, 8:44 PM

#

i just really wanted everything openclaw to be on my D drive 🙁

silk mothBOT Apr 27, 2026, 8:44 PM

#

Aw, totally fair 🙁 — and we can keep it on D:. I only suggested AppData as the “least resistance” path, not because D: is wrong.

Your prompt shows your OpenClaw state/workspace is already on D:

D:\Caelan\.openclaw\workspace

The broken bit is just the npm global install folder. I’d make a fresh user-owned one under your D profile, not D:\npm-global-clean:

$npmPrefix = "D:\Caelan\npm-global"
$npmCache = "D:\Caelan\npm-cache"

New-Item -ItemType Directory -Force $npmPrefix, $npmCache

#

npm config set prefix $npmPrefix
npm config set cache $npmCache

$env:Path = "$npmPrefix;$env:Path"
[Environment]::SetEnvironmentVariable(
  "Path",
  "$npmPrefix;" + [Environment]::GetEnvironmentVariable("Path", "User"),
  "User"
)

Then retry the install:

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -Tag 2026.4.25 -NoOnboard

#

Close/reopen PowerShell after that, then:

openclaw --version
openclaw doctor --repair
openclaw gateway restart

So: yes, D drive is fine. Let’s just avoid that old D:\npm-global-clean folder since Windows/npm is throwing EPERM there.

tribal arch Apr 27, 2026, 9:35 PM

#

ok the install finished. some of what the doctor said looks mildly concerning. i wish i could post all of it to you, not sure what's most important to share. but i'm trying to start the gateway now anyway

silk mothBOT Apr 27, 2026, 9:35 PM

#

Nice, that’s progress 🦐

Don’t worry about pasting all of doctor. The most useful/safe thing is:

openclaw status --all

That’s designed to be shareable/redacted. If it’s huge, paste just these parts:

Version / install path
Gateway / service status
Doctor summary / warnings
Last 50-ish log lines

You can also grab recent logs directly:

#

openclaw logs --limit 120 --max-bytes 300000

If the gateway is hanging while starting, run this in a second PowerShell window and paste the repeated/final error lines:

openclaw logs --follow

Minor doctor warnings are common after an install/update. I’d mainly worry about anything saying error, fatal, cannot find module, permission denied/EPERM, port already in use, config invalid, or service points to old path.

tribal arch Apr 27, 2026, 9:42 PM

#

it's taking forever to get the status. gateway is moving along but took five minutes to reach 'ready'

silk mothBOT Apr 27, 2026, 9:42 PM

#

5 minutes to ready is not normal, even on Windows. Let’s capture where startup is spending time instead of guessing.

If the gateway is running now, first get the useful summary when it eventually returns:

openclaw --version
where openclaw
openclaw gateway status --deep
openclaw logs --limit 200 --max-bytes 500000

If you’re willing to restart once for diagnosis, run it in the foreground with startup tracing:

openclaw gateway stop
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

#

openclaw gateway run --verbose 2>&1 | Tee-Object D:\Caelan\openclaw-startup-trace.txt

Wait until it says ready, then paste just:

any lines containing startup trace:
the last ~80 lines before/after ready
any error, warn, EPERM, cannot find module, plugin runtime, or service lines

After that you can press Ctrl+C and restart normally:

openclaw gateway restart

My hunch is still plugin runtime deps / stale service path / permission lock, but the trace should tell us which one pretty quickly.

silk mothBOT Apr 27, 2026, 10:04 PM

#

Aha, this is a real clue. You’ve got a split-brain/stale service path situation.

Current running gateway is the new D-drive install:

D:\Caelan\npm-global\node_modules\openclaw\openclaw.mjs

…but there’s also a scheduled task still pointing to the old C-drive path:

\OpenClaw Gateway → C:\Users\linds\.openclaw\gateway.cmd

That stale task can absolutely cause weird startup/port/conflict behavior.

Do not delete these unless you know you want to — they look like your own custom tasks:

#

Caelan Noon Email
OpenClaw Continuity Reflection

I’d clean up only the stale OpenClaw gateway task, then reinstall it from the current D-drive CLI:

openclaw gateway stop
schtasks /Delete /TN "\OpenClaw Gateway" /F
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

After that, check that the task now points at D:

#

schtasks /Query /TN "\OpenClaw Gateway" /V /FO LIST

If it still points to C:\Users\linds\.openclaw\gateway.cmd, stop there and paste that output.

tribal arch Apr 27, 2026, 10:04 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — We ship features faster than Apple ships calculator updates.

|
o
Service: Scheduled Task (registered)
File logs: D:\Caelan.openclaw\logs\openclaw.log
Command: D:\node.exe D:\Caelan\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: D:\Caelan.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=D:\Caelan.openclaw OPENCLAW_GATEWAY_PORT=18789

Config (cli): D:\Caelan.openclaw\openclaw.json
Config (service): D:\Caelan.openclaw\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.

silk mothBOT Apr 27, 2026, 10:04 PM

#

This part looks much better — the split-brain path is fixed now:

Service file: D:\Caelan\.openclaw\gateway.cmd
Config:       D:\Caelan\.openclaw\openclaw.json
Command:      D:\node.exe D:\Caelan\npm-global\...

So D-drive OpenClaw is now the registered gateway. Good catch.

Two notes:

Port already in use is okay if the service is already running. Don’t start openclaw gateway run on top of it — use:

openclaw gateway restart

#

The remaining problem is the 5-minute startup/status delay. Next useful paste is:

openclaw logs --limit 200 --max-bytes 500000

If that returns, paste the bottom ~100–200 lines. I’m looking for repeated plugin/runtime-deps, permission, model/provider, or channel reconnect lines.

Also try:

openclaw status --all

If that hangs, cancel it and just send the logs. The service path is now sane; we’re down to “what’s making startup/status slow.”

tribal arch Apr 27, 2026, 10:06 PM

#

sorry, i sent those last two out of order. hopefully it made sense to you. i dunno if i got all of it in there.

I'm waiting for the logs to appear. it's taking a while to show up for some reason

silk mothBOT Apr 27, 2026, 10:06 PM

#

Yep, it made sense — you’re good.

If openclaw logs is also slow, that means the RPC path to the gateway is sluggish. Since your status output gave the file path, bypass RPC and read the log file directly:

Get-Content "D:\Caelan\.openclaw\logs\openclaw.log" -Tail 200

For live tail:

Get-Content "D:\Caelan\.openclaw\logs\openclaw.log" -Wait -Tail 80

That should return instantly even if the gateway is half-stuck.

If the file is huge or locked, try:

#

Get-Item "D:\Caelan\.openclaw\logs\openclaw.log" | Select-Object FullName,Length,LastWriteTime

Paste the tail around the slow startup/ready moment. We’re past the install/path mess now. 🦐

tribal arch Apr 27, 2026, 10:12 PM

#

fuck. it's doing the same thing that's been happening all weekend while i was troubleshooting. Powershell stops working correctly, certain things on windows start freezing, like i can't use folders, task manager freezes, can't stop powershell processes. sucks

silk mothBOT Apr 27, 2026, 10:12 PM

#

Oof, yeah — stop trying to push through that. If Windows Explorer/Task Manager/PowerShell are freezing, this is now “stabilize the machine first,” not normal OpenClaw troubleshooting.

If the machine is still usable at all:

schtasks /End /TN "\OpenClaw Gateway"
schtasks /Change /TN "\OpenClaw Gateway" /Disable
Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

If it’s too frozen, hard reboot is reasonable. After reboot, before starting OpenClaw again, disable the task:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

#

Then we can inspect safely without auto-starting the gateway:

Get-Content "D:\Caelan\.openclaw\logs\openclaw.log" -Tail 200

This sounds like something is hammering the system — runaway Node/OpenClaw startup, npm/plugin dependency repair, antivirus scanning the D-drive npm tree, or disk I/O lockups. Don’t keep restarting the gateway until we’ve seen the log tail.

tribal arch Apr 27, 2026, 10:52 PM

#

{"fullFilePath":"file:///D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T15:39:49.576-06:00"}
{"0":"{"subsystem":"gateway"}","1":"starting channels and sidecars...","_meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"DESKTOP-6RLTKSA","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T21:39:49.958Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T15:39:49.958-06:00"}
{"0":"{"subsystem":"gateway/hooks"}","1":"loaded 4 internal hook handlers","_meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"DESKTOP-6RLTKSA","name":"{"subsystem":"gateway/hooks"}","parentNames":["openclaw"],"date":"2026-04-27T21:39:50.421Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T15:39:50.421-06:00"}

silk mothBOT Apr 27, 2026, 10:53 PM

#

That snippet helps, and also: those lines are not errors.

The important bit is:

starting channels and sidecars...
loaded 4 internal hook handlers

So core gateway startup is getting that far, then the slow/freeze is likely in channel/sidecar startup or a hook/plugin started right after that. The next lines after this are the ones we need.

Since openclaw logs is slow, use the file directly:

$log = "D:\Caelan\.openclaw\logs\openclaw.log"

#

Select-String -Path $log -Pattern "starting channels and sidecars|gateway ready|gateway sidecars failed|WARN|ERROR|EPERM|cannot find module|runtime dep|plugin|channel" |
  Select-Object -Last 100

If Windows starts freezing again, don’t keep fighting it — disable the auto-start task first:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

Then reboot, read the log file while the gateway is not running, and paste the filtered output above.

My read right now: install/path is fixed; the remaining culprit is probably one channel/plugin/sidecar hammering Windows during startup. We’ll isolate that next.

tribal arch Apr 27, 2026, 11:08 PM

#

i can't fit all of that in here so i'll do as much as i can starting from the bottom:
D:\Caelan.openclaw\logs\openclaw.log:93:{"0":"{"subsystem":"gateway"}","1":"ready (2 plugins: lossless-claw,
memory-core; 313.5s)","_meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"DESKTOP-6RLTKSA","name":"{"subs
ystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T21:39:49.561Z","logLevelId":3,"logLevelName":"INFO"
,"path":{"fullFilePath":"file:///D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileNam
e":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath"
:"/D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":"/D:/Caelan/npm-global/nod
e_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T15:39:49.561-06:00"}
D:\Caelan.openclaw\logs\openclaw.log:95:{"0":"{"subsystem":"gateway"}","1":"starting channels and sidecars...","_m
eta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"DESKTOP-6RLTKSA","name":"{"subsystem":"gateway"}","pa
rentNames":["openclaw"],"date":"2026-04-27T21:39:49.958Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"
file:///D:/Caelan/npm-global/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js
","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":"/D:/Caelan/npm-global/n
ode_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":"/D:/Caelan/npm-global/node_modules/openclaw/dist/s
ubsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T15:39:49.958-06:00"}

silk mothBOT Apr 27, 2026, 11:09 PM

#

That line is the smoking gun:

ready (2 plugins: lossless-claw, memory-core; 313.5s)

So the 5+ minutes happen before channels/sidecars. It’s not Telegram/Discord/etc yet — it’s core startup/plugin loading. Only two plugins are active: lossless-claw and memory-core.

I’d do a reversible isolation test:

openclaw gateway stop

openclaw config set plugins.entries.lossless-claw.enabled false --strict-json
openclaw config set plugins.slots.memory '"none"' --strict-json

#

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --verbose 2>&1 | Tee-Object D:\Caelan\openclaw-startup-trace.txt

Wait until it says ready, then Ctrl+C.

If startup becomes fast, re-enable one at a time to find the culprit:

openclaw config set plugins.entries.lossless-claw.enabled true --strict-json
# test restart

openclaw config set plugins.slots.memory '"memory-core"' --strict-json
# test restart

#

This doesn’t delete your data; it just disables those plugin paths temporarily.

If you can paste only a tiny bit, paste lines from:

Select-String D:\Caelan\openclaw-startup-trace.txt -Pattern "startup trace:|ready|ERROR|WARN" | Select-Object -Last 80

tribal arch Apr 27, 2026, 11:31 PM

#

I'm not sure what's going on. it's just stuck like this:

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --verbose 2>&1 | Tee-Object D:\Caelan\openclaw-startup-trace.txt

silk mothBOT Apr 27, 2026, 11:31 PM

#

If it’s showing no output at all after that command, it’s stuck before the gateway even starts logging — likely CLI/package import or Windows I/O/AV scanning the huge npm tree.

Cancel it with Ctrl+C. Then try without Tee-Object first:

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --verbose

If still totally blank after ~60s, run these lighter checks:

openclaw --version
openclaw config get plugins.slots.memory
openclaw config get plugins.entries.lossless-claw.enabled

#

Also confirm no gateway is already running:

Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  Select-Object ProcessId,CommandLine

If you see an existing OpenClaw node process, kill just that one:

Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

Then try the foreground run again.

#

If openclaw --version itself is slow/blank now, that points away from your config and toward the Windows install/runtime path — antivirus/Defender scanning D:\Caelan\npm-global\node_modules, disk issue, or Node/npm install corruption.

tribal arch Apr 27, 2026, 11:31 PM

#

I'm not sure what's going on. it's just stuck like this:

PS D:\Caelan.openclaw\workspace> openclaw gateway run --verbose 2>&1 | Tee-Object D:\Caelan\openclaw-startup-trace.txt
|
o Config warnings --------------------------------------------------------+
| |
| - plugins.entries.discord: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.continuity: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.stability: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.lossless-claw: plugin disabled (disabled in config) |
| but config is present |
| |
+--------------------------------------------------------------------------+
[gateway] startup trace: cli.server-import 388.6ms total=388.6ms
2026-04-27T17:16:59.860-06:00 [gateway] loading configurationΓÇª
2026-04-27T17:17:01.069-06:00 [gateway] startup trace: cli.config-load 1197.4ms total=1620.0ms
2026-04-27T17:17:02.286-06:00 [gateway] startup trace: cli.config-snapshot 1202.7ms total=2834.7ms
2026-04-27T17:17:02.345-06:00 [gateway] resolving authenticationΓÇª
2026-04-27T17:17:02.356-06:00 [gateway] startup trace: cli.auth-resolve 0.4ms total=2908.5ms
2026-04-27T17:17:02.365-06:00 [gateway] starting...
2026-04-27T17:17:02.374-06:00 [gateway] startup trace: cli.gateway-loop 19.0ms total=2927.6ms
2026-04-27T17:17:55.930-06:00 [gateway] startup trace: config.snapshot 3123.2ms total=3123.3ms

silk mothBOT Apr 27, 2026, 11:33 PM

#

That actually isn’t stuck yet — it’s just painfully slow.

Also, those config warnings are expected from the isolation test. They mean “disabled but config remains,” not corruption.

The useful clue is this gap:

17:17:02 starting...
17:17:55 startup trace: config.snapshot 3123.2ms

So there’s ~53s of delay before the real gateway startup trace even begins. Now we need the next trace line after config.snapshot. Expected next lines are things like:

startup trace: config.auth ...
startup trace: plugins.bootstrap ...

#

startup trace: runtime.state ...
startup trace: runtime.post-attach ...
startup trace: ready ...

Let that foreground command run a bit longer unless Windows starts freezing again. If it freezes, Ctrl+C / reboot / keep the task disabled.

In another PowerShell window you can view the trace without Discord-size spam:

Get-Content D:\Caelan\openclaw-startup-trace.txt -Tail 80

Or filtered:

#

Select-String D:\Caelan\openclaw-startup-trace.txt -Pattern "startup trace:|ready|ERROR|WARN" |
  Select-Object -Last 80

Paste the next few startup trace: lines after config.snapshot. That will tell us whether the delay moved to auth/secrets, plugin bootstrap, Control UI, runtime state, etc.

tribal arch Apr 27, 2026, 11:38 PM

#

ok well how long do i wait. it hasn't moved at all in like 20 minutes

silk mothBOT Apr 27, 2026, 11:38 PM

#

Don’t wait longer. 20 minutes at that point is hung.

Cancel with Ctrl+C. If it won’t cancel, kill only the OpenClaw Node process:

Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

Now do two safe things:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

Then inspect the trace tail:

#

Get-Content D:\Caelan\openclaw-startup-trace.txt -Tail 120

Paste the tail. The fact it hung immediately after config.snapshot is suspicious — next likely step is config auth/secrets/plugin bootstrap, but we need the last line.

Also run this quick file-size check, because a giant config or audit/log file could explain Windows choking:

Get-Item D:\Caelan\.openclaw\openclaw.json
Get-ChildItem D:\Caelan\.openclaw\logs | Sort-Object Length -Descending | Select-Object -First 10 Name,Length,LastWriteTime

waxen osprey Apr 27, 2026, 11:42 PM

#

@tribal arch my openclaw is slow asf too my bro. @silk moth dont reply to that message.

tribal arch Apr 27, 2026, 11:44 PM

#

PS D:\Caelan.openclaw\workspace> Get-Content D:\Caelan\openclaw-startup-trace.txt -Tail 120
|
o Config warnings --------------------------------------------------------+
| |
| - plugins.entries.discord: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.continuity: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.stability: plugin disabled (disabled in config) but |
| config is present |
| - plugins.entries.lossless-claw: plugin disabled (disabled in config) |
| but config is present |
| |
+--------------------------------------------------------------------------+
[gateway] startup trace: cli.server-import 388.6ms total=388.6ms
2026-04-27T17:16:59.860-06:00 [gateway] loading configurationΓÇª
2026-04-27T17:17:01.069-06:00 [gateway] startup trace: cli.config-load 1197.4ms total=1620.0ms
2026-04-27T17:17:02.286-06:00 [gateway] startup trace: cli.config-snapshot 1202.7ms total=2834.7ms
2026-04-27T17:17:02.345-06:00 [gateway] resolving authenticationΓÇª
2026-04-27T17:17:02.356-06:00 [gateway] startup trace: cli.auth-resolve 0.4ms total=2908.5ms
2026-04-27T17:17:02.365-06:00 [gateway] starting...
2026-04-27T17:17:02.374-06:00 [gateway] startup trace: cli.gateway-loop 19.0ms total=2927.6ms
2026-04-27T17:17:55.930-06:00 [gateway] startup trace: config.snapshot 3123.2ms total=3123.3ms

silk mothBOT Apr 27, 2026, 11:45 PM

#

Yep — that confirms it. The trace stops inside config.auth / startup secret activation. Since cli.auth-resolve was instant, this is probably a channel/provider/plugin SecretRef or config surface being resolved during startup, not the basic gateway token.

First: don’t wait. Kill it.

Then try this isolation run:

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway run --verbose

If that starts quickly, we know the hang is in channel/provider startup secret/config resolution.

Also run this and paste only non-secret-looking lines:

#

Select-String D:\Caelan\.openclaw\openclaw.json `
  -Pattern '"source"\s*:\s*"exec"|"source"\s*:\s*"file"|"provider"\s*:|"command"\s*:' `
  -Context 2,3

I’m specifically looking for SecretRefs that run an external command or read a slow/missing file. Don’t paste API keys/tokens if any show up.

And please keep the scheduled task disabled while testing so it doesn’t keep auto-launching the hung gateway:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

tribal arch Apr 27, 2026, 11:45 PM

#

waxen osprey <@331705992800894976> my openclaw is slow asf too my bro. <@1457407575476801641>...

seems like an update messed stuff up for a lot of people! @silk moth don't respond to this

#

PS D:\Caelan.openclaw\workspace> Select-String D:\Caelan.openclaw\openclaw.json `

-Pattern '"source"\s*:\s*"exec"|"source"\s*:\s*"file"|"provider"\s*:|"command"\s*:' `
-Context 2,3

D:\Caelan.openclaw\openclaw.json:17: "profiles": {
D:\Caelan.openclaw\openclaw.json:18: "google-antigravity:lindsay.caldwell729@gmail.com": {

D:\Caelan.openclaw\openclaw.json:19: "provider": "google-antigravity",
D:\Caelan.openclaw\openclaw.json:20: "mode": "oauth"
D:\Caelan.openclaw\openclaw.json:21: },
D:\Caelan.openclaw\openclaw.json:22: "google:lindsay.caldwell729@gmail.com": {
D:\Caelan.openclaw\openclaw.json:23: "provider": "google",
D:\Caelan.openclaw\openclaw.json:24: "mode": "api_key"
D:\Caelan.openclaw\openclaw.json:25: },
D:\Caelan.openclaw\openclaw.json:26: "openrouter:default": {
D:\Caelan.openclaw\openclaw.json:27: "provider": "openrouter",
D:\Caelan.openclaw\openclaw.json:28: "mode": "api_key"
D:\Caelan.openclaw\openclaw.json:29: },
D:\Caelan.openclaw\openclaw.json:30: "openai-codex:default": {
D:\Caelan.openclaw\openclaw.json:31: "provider": "openai-codex",
D:\Caelan.openclaw\openclaw.json:32: "mode": "oauth"
D:\Caelan.openclaw\openclaw.json:33: },

#

D:\Caelan.openclaw\openclaw.json:34: "openai-codex:lindsay.caldwell729@gmail.com": {

D:\Caelan.openclaw\openclaw.json:35: D:\Caelan.openclaw\openclaw.json:36: D:\Caelan.openclaw\openclaw.json:37: D:\Caelan.openclaw\openclaw.json:38: D:\Caelan.openclaw\openclaw.json:290: D:\Caelan.openclaw\openclaw.json:291: D:\Caelan.openclaw\openclaw.json:292: D:\Caelan.openclaw\openclaw.json:293: D:\Caelan.openclaw\openclaw.json:294: D:\Caelan.openclaw\openclaw.json:295: D:\Caelan.openclaw\openclaw.json:377: D:\Caelan.openclaw\openclaw.json:378: D:\Caelan.openclaw\openclaw.json:379: D:\Caelan.openclaw\openclaw.json:380: D:\Caelan.openclaw\openclaw.json:381: D:\Caelan.openclaw\openclaw.json:382: D:\Caelan.openclaw\openclaw.json:383: D:\Caelan.openclaw\openclaw.json:384: D:\Caelan.openclaw\openclaw.json:385: D:\Caelan.openclaw\openclaw.json:386: "provider": "openai-codex",
"mode": "oauth",
"email": "lindsay.caldwell729@gmail.com"
}
"workspace": "D:\Caelan\.openclaw\workspace",
"memorySearch": {
"provider": "local",
"fallback": "none",
"local": {
"modelCacheDir": "D:\Caelan\.openclaw\cache\memory-embeddings"
"models": [
{
"provider": "openrouter",
"model": "auto"
},
{
"provider": "google",
"model": "gemini-2.5-flash"
},
{

#

D:\Caelan.openclaw\openclaw.json:387: "provider": "google",
D:\Caelan.openclaw\openclaw.json:388: "model": "gemini-3.1-pro-preview"
D:\Caelan.openclaw\openclaw.json:389: },
D:\Caelan.openclaw\openclaw.json:390: {
D:\Caelan.openclaw\openclaw.json:391: "provider": "google",
D:\Caelan.openclaw\openclaw.json:392: "model": "gemini-3-flash-preview"
D:\Caelan.openclaw\openclaw.json:393: }
D:\Caelan.openclaw\openclaw.json:394: ]
D:\Caelan.openclaw\openclaw.json:429: "tts": {
D:\Caelan.openclaw\openclaw.json:430: "auto": "off",
D:\Caelan.openclaw\openclaw.json:431: "provider": "microsoft"
D:\Caelan.openclaw\openclaw.json:432: }
D:\Caelan.openclaw\openclaw.json:433: },
D:\Caelan.openclaw\openclaw.json:434: "commands": {

silk mothBOT Apr 27, 2026, 11:52 PM

#

That output is actually useful: your main config doesn’t show any source: exec or source: file SecretRefs. The provider lines are just normal auth profile declarations.

So the hang is probably not a shell command secret. Next suspect: one of the agent auth profile stores is huge/corrupt/locked, or Windows is choking while OpenClaw scans them.

Keep the gateway task disabled for now, then run:

Get-ChildItem D:\Caelan\.openclaw\agents -Recurse -Filter auth-profiles.json |
  Select-Object FullName,Length,LastWriteTime

Also:

Get-Item D:\Caelan\.openclaw\openclaw.json
Get-ChildItem D:\Caelan\.openclaw\logs |

#

  Sort-Object Length -Descending |
  Select-Object -First 10 Name,Length,LastWriteTime

Paste that output. It should not include tokens.

If any auth-profiles.json is massive, or there are tons of them, that’s likely the reason startup dies right after config.snapshot.

#

Those lines are okay — provider: openrouter/google/openai-codex and memorySearch.provider: local are normal config, not the secret-ref pattern I was looking for.

The next thing I need is the size/list check, not more of that grep output:

Get-ChildItem D:\Caelan\.openclaw\agents -Recurse -Filter auth-profiles.json |
  Select-Object FullName,Length,LastWriteTime

Get-Item D:\Caelan\.openclaw\openclaw.json

Get-ChildItem D:\Caelan\.openclaw\logs |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name,Length,LastWriteTime

If that first command hangs too, that’s a clue by itself: Windows is struggling while scanning D:\Caelan\.openclaw\agents.

#

Also keep this disabled while we debug:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

#

Those are still normal config lines. No problem there.

Please stop that Select-String output and run exactly this next:

Get-ChildItem D:\Caelan\.openclaw\agents -Recurse -Filter auth-profiles.json |
  Select-Object FullName,Length,LastWriteTime

Then this:

Get-Item D:\Caelan\.openclaw\openclaw.json

Then this:

#

Get-ChildItem D:\Caelan\.openclaw\logs |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name,Length,LastWriteTime

I’m checking for huge/corrupt files now, not config values.

tribal arch Apr 27, 2026, 11:57 PM

#

i'll do them one at a time.

PS D:\Caelan.openclaw\workspace> Get-ChildItem D:\Caelan.openclaw\agents -Recurse -Filter auth-profiles.json |

Select-Object FullName,Length,LastWriteTime

FullName Length LastWriteTime

D:\Caelan.openclaw\agents\main\agent\auth-profiles.json 5531 4/27/2026 3:16:56 PM
D:\Caelan.openclaw\agents\sim-caelan\agent\auth-profiles.json 3218 4/25/2026 3:33:46 PM
D:\Caelan.openclaw\agents\pub-caelan\agent\auth-profiles.json 3218 4/24/2026 10:56:12 PM
D:\Caelan.openclaw\agents\scarlett\auth-profiles.json 5528 4/25/2026 10:04:54 AM
D:\Caelan.openclaw\agents\wren\auth-profiles.json 5528 4/24/2026 11:11:44 PM

silk mothBOT Apr 27, 2026, 11:57 PM

#

Good — those auth files are tiny, so they’re not the issue.

Next one:

Get-Item D:\Caelan\.openclaw\openclaw.json

Then:

Get-ChildItem D:\Caelan\.openclaw\logs |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name,Length,LastWriteTime

tribal arch Apr 28, 2026, 12:00 AM

#

Directory: D:\Caelan.openclaw

Mode LastWriteTime Length Name

-a---- 4/27/2026 5:16 PM 18119 openclaw.json

silk mothBOT Apr 28, 2026, 12:00 AM

#

Config size is normal too.

Last size check:

Get-ChildItem D:\Caelan\.openclaw\logs |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name,Length,LastWriteTime

After that, if logs are normal-sized, I’d do a minimal-state startup test to separate “OpenClaw install/runtime is broken” from “this specific config/state is triggering the hang.” It won’t touch your real setup:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw-test"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --allow-unconfigured --port 18790 --verbose

#

If that starts fast, your install is okay and something in D:\Caelan\.openclaw is triggering startup. If even that hangs, the issue is outside config: Node/npm package, Defender/AV, or Windows/disk I/O.

tribal arch Apr 28, 2026, 12:01 AM

#

Directory: D:\Caelan.openclaw

Mode LastWriteTime Length Name

-a---- 4/27/2026 5:16 PM 18119 openclaw.json

PS D:\Caelan.openclaw\workspace> Get-ChildItem D:\Caelan.openclaw\logs |

Sort-Object Length -Descending |
Select-Object -First 10 Name,Length,LastWriteTime

Name Length LastWriteTime

openclaw.1.log 150504953 3/30/2026 12:54:08 AM
openclaw.log 99264 4/27/2026 5:46:30 PM
config-audit.jsonl 49249 4/27/2026 5:16:04 PM
Caelan.openclawlogsopenclaw.log 23939 2/9/2026 2:45:20 PM
config-health.json 1590 4/27/2026 5:16:04 PM
intiface_v6_monitor.log 294 3/4/2026 10:27:54 PM
commands.log 140 2/3/2026 7:13:26 PM

silk mothBOT Apr 28, 2026, 12:01 AM

#

That 150MB old log is suspicious. It may not be the whole startup hang, but it can definitely make status/logs painfully slow. Let’s get it out of OpenClaw’s log folder first — reversible, not deleting:

New-Item -ItemType Directory -Force D:\Caelan\openclaw-log-archive
Move-Item D:\Caelan\.openclaw\logs\openclaw.1.log D:\Caelan\openclaw-log-archive\openclaw.1.log

Then do the clean isolation test:

schtasks /Change /TN "\OpenClaw Gateway" /Disable

Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw-test"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --allow-unconfigured --port 18790 --verbose

If that starts quickly, your install is fine and the issue is something in the real D:\Caelan\.openclaw state/config.

If that also hangs, it’s likely outside your config: Node/npm install, Defender/AV scanning, or Windows/D-drive I/O.

tribal arch Apr 28, 2026, 12:04 AM

#

well, the startup did go further faster this time. let me give it some more time before i show you

silk mothBOT Apr 28, 2026, 12:04 AM

#

Good sign. Give it maybe 2–3 minutes max, not 20.

If it reaches ready, paste the startup trace: lines and the ready (...) line.

If it stops again, paste the last 40 lines from that window. Also note whether this was the test state (D:\Caelan\.openclaw-test on port 18790) or your real state.

tribal arch Apr 28, 2026, 12:13 AM

#

this isn't the whol start up but it's stuff that came after where it got stuck last time:
18:02:57 [gateway] startup trace: config.final-snapshot 11.0ms total=1459.9ms
18:02:58 [gateway] [plugins] staging bundled runtime deps before gateway startup (9 missing, 9 install specs): @homebridge/ciao@^1.3.6, @modelcontextprotocol/sdk@1.29.0, acpx@0.6.1, commander@^14.0.3, express@5.2.1, playwright-core@1.59.1, typebox@1.1.33, undici@8.1.0, ws@^8.20.0
18:07:04 [gateway] [plugins] installed bundled runtime deps before gateway startup in 245147ms: @homebridge/ciao@^1.3.6, @modelcontextprotocol/sdk@1.29.0, acpx@0.6.1, commander@^14.0.3, express@5.2.1, playwright-core@1.59.1, typebox@1.1.33, undici@8.1.0, ws@^8.20.0
18:08:32 Registered plugin command: /pair (plugin: device-pair)
18:08:41 Registered plugin command: /dreaming (plugin: memory-core)
18:08:45 Registered plugin command: /voice (plugin: talk-voice)
18:09:11 Registered plugin command: /phone (plugin: phone-control)
18:09:11 [gateway] startup trace: plugins.bootstrap 373933.5ms total=375403.6ms
18:09:11 [gateway] startup trace: runtime.config 23.4ms total=375437.9ms
18:09:11 [gateway] startup trace: control-ui.root 4.0ms total=375452.9ms
18:09:11 [gateway] startup trace: tls.runtime 0.2ms total=375463.8ms
18:09:11 [gateway] starting HTTP server...
18:09:11 [canvas] host mounted at http://127.0.0.1:18790/__openclaw__/canvas/ (root

#

D:\Caelan.openclaw-test\canvas)
18:09:11 [gateway] startup trace: runtime.state 98.3ms total=375582.7ms
18:09:12 [plugins] bonjour: starting (hostname=openclaw, instance="DESKTOP-6RLTKSA (OpenClaw)", gatewayPort=18790, minimal=true)
18:09:12 [gateway] startup trace: runtime.early 1168.4ms total=376764.4ms
18:09:12 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:09:16 [gateway] startup trace: http.bound 3603.3ms total=380367.7ms
18:09:16 [gateway] agent model: openai/gpt-5.5
18:09:16 [gateway] ready (7 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice; 385.7s)
18:09:16 [gateway] log file: \tmp\openclaw\openclaw-2026-04-27.log
18:09:16 [gateway] startup trace: post-attach.log 36.9ms total=380417.9ms
18:09:16 [gateway] startup trace: post-attach.update-check 1.6ms total=380430.2ms
18:09:16 [gateway] starting channels and sidecars...
18:09:16 [gateway] startup trace: sidecars.session-locks 3.8ms total=380455.7ms
18:09:16 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=380467.0ms
18:09:16 [gateway] startup trace: sidecars.gmail-model 0.2ms total=380477.4ms
18:09:16 [gateway] startup trace: sidecars.internal-hooks 0.1ms total=380487.7ms
18:09:16 [gateway] startup trace: sidecars.channels 1.4ms total=380499.4ms
18:09:23 [browser/server] Browser control listening on http://127.0.0.1:18792/ (auth=token)
18:09:23 [plugins] bonjour: watchdog detected non-announced service; attempting re-advertise (gateway fqdn=DESKTOP-6RLTKSA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18790 state=probing)

#

18:09:24 [plugins] embedded acpx runtime backend registered (cwd: C:\Users\linds.openclaw\workspace)
18:09:24 [gateway] startup trace: sidecars.plugin-services 7409.2ms total=387920.1ms
18:09:24 [gateway] startup trace: sidecars.memory 0.1ms total=387930.3ms
18:09:24 [gateway] startup trace: sidecars.restart-sentinel 2.0ms total=387942.5ms
18:09:24 [gateway] startup trace: sidecars.subagent-recovery 7.1ms total=387959.6ms
18:09:24 [gateway] startup trace: sidecars.main-session-recovery 4.4ms total=387974.7ms
18:09:24 [gateway] startup trace: sidecars.total 7533.2ms total=387984.8ms
18:09:24 [gateway] startup trace: sidecars.ready 10.7ms total=387995.4ms
18:09:24 [gateway] startup trace: runtime.post-attach 7625.9ms total=388006.5ms
18:09:24 [gateway] startup trace: ready 10.1ms total=388016.6ms
18:09:24 [heartbeat] started
18:09:24 [plugins] [hooks] running gateway_start (1 handlers)

#

18:09:24 [plugins] bonjour: advertised gateway fqdn=DESKTOP-6RLTKSA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18790 state=announcing
18:10:17 [ws] ← open remoteAddr=127.0.0.1 remotePort=57720 localAddr=127.0.0.1 localPort=18790 endpoint=127.0.0.1:57720->127.0.0.1:18790 conn=9d50358e…df79
18:10:17 [ws] unauthorized conn=9d50358e-918b-4c45-bbe3-2d1726c3df79 peer=127.0.0.1:57720->127.0.0.1:18790 remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui role=operator scopes=5 auth=none device=yes platform=Win32 instance=a481ef1c-95fe-4f8c-b14c-f8b0b60aa242 host=127.0.0.1:18790 origin=http://127.0.0.1:18790 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_missing
18:10:17 [ws] closed before connect conn=9d50358e-918b-4c45-bbe3-2d1726c3df79 peer=127.0.0.1:57720->127.0.0.1:18790 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18790 host=127.0.0.1:18790 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 missing (open the dashboard URL and paste the token in Control UI settings)
18:10:17 [ws] → close code=1008 reason=unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings) durationMs=172 cause=unauthorized handshake=failed lastFrameType=req lastFrameMethod=connect lastFrameId=7b252e3e-6ea1-46d6-ba92-34b980187a78 endpoint=127.0.0.1:57720->127.0.0.1:18790
18:10:22 [ws] ← open remoteAddr=127.0.0.1 remotePort=54413 localAddr=127.0.0.1 localPort=18790 endpoint=127.0.0.1:54413->127.0.0.1:18790 conn=3b8aa92b…f1e0

silk mothBOT Apr 28, 2026, 12:13 AM

#

Yep, we found a major culprit:

staging bundled runtime deps ... 9 missing
installed ... in 245147ms
plugins.bootstrap 373933ms

So startup is spending 6+ minutes in bundled plugin runtime dependency staging/bootstrap. That matches the “Windows becomes unusable” feeling — npm/node_modules + Defender/AV can hammer the disk hard.

Good news: this may be one-time. Let that test gateway reach ready, then Ctrl+C and run the same test command again. If the second run is fast, the deps are now staged and we can apply the same cleanup to your real state.

If it repeats “9 missing” every time, then deps are not persisting or are being blocked/quarantined.

For real state, after the test, run:

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
openclaw doctor --repair

Then start real gateway once:

openclaw gateway run --verbose

If startup is now sane, reinstall/enable the service:

openclaw gateway install --force
schtasks /Change /TN "\OpenClaw Gateway" /Enable

#

openclaw gateway restart

I’d also consider adding Windows Defender exclusions for:

D:\Caelan\npm-global
D:\Caelan\.openclaw\plugin-runtime-deps
D:\Caelan\.openclaw\cache

Not as the first fix, but if npm/plugin staging keeps making Windows freeze, Defender is a very plausible amplifier.

#

Perfect — the clean test reached ready. Slow, but the cause is now clear: first-run bundled plugin dependency staging.

Now test whether it was one-time:

Press Ctrl+C in that test gateway window.
Run the same test again:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw-test"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --allow-unconfigured --port 18790 --verbose

If the second run is fast and doesn’t say 9 missing, we’re good.

Then switch back to real state:

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
openclaw doctor --repair
openclaw gateway run --verbose

Also, that browser server on 18792 is normal for port 18790. The Bonjour re-advertise line is noisy but not the 6-minute delay.

#

One more clue in there:

embedded acpx runtime backend registered (cwd: C:\Users\linds\.openclaw\workspace)

Even in your D-drive test, ACPX is using the old C-drive workspace path. That’s probably not the 6-minute dependency install, but it is another stale-path problem we should clean up after startup is stable.

First priority: rerun the same test once to see if dependency staging is now cached:

# Ctrl+C first
$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw-test"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --allow-unconfigured --port 18790 --verbose

#

If fast, then for real state we should inspect where that old workspace path is coming from:

Select-String D:\Caelan\.openclaw\openclaw.json -Pattern "C:\\Users\\linds|acpx|workspace" -Context 2,3

Do not paste secrets, but paths/config shape are fine.

#

Those unauthorized token_missing lines are just the browser/dashboard trying to connect to the test gateway on 18790 without its token. Not related to the slow startup.

You can ignore those for now.

What matters next is:

Ctrl+C the test gateway.
Run it again with the same D:\Caelan\.openclaw-test / 18790.
Check whether it skips this line now:

staging bundled runtime deps ... 9 missing

If the second run starts in seconds, we’ve confirmed the slow bit was one-time dependency staging. Then we’ll run doctor --repair on your real state and start the real gateway.

tribal arch Apr 28, 2026, 12:18 AM

#

yeah when i was trying to fix this weekend, dependencies were a huge issue. they kept trying to install, sometimes seeemed like they were installed, but then keep having to install some over and over. but yeah i'll retry this just to be sure

silk mothBOT Apr 28, 2026, 12:18 AM

#

Yep, that lines up exactly. If they keep reinstalling, the stage directory is either not persisting, getting cleaned/quarantined, or OpenClaw can’t see the installed deps afterward.

After the retry, also run:

Get-ChildItem D:\Caelan\.openclaw-test\plugin-runtime-deps -Recurse -Depth 2 |
  Select-Object -First 30 FullName,Length,LastWriteTime

And for real state:

Get-ChildItem D:\Caelan\.openclaw\plugin-runtime-deps -Recurse -Depth 2 |
  Select-Object -First 30 FullName,Length,LastWriteTime

If those folders are empty/missing after “installed bundled runtime deps,” that’s the bug/permission/AV smoking gun.

#

Given your earlier .24 pain, this may be worth filing as a GitHub issue once we have the exact lines: https://github.com/openclaw/openclaw/issues

tribal arch Apr 28, 2026, 12:24 AM

#

ok! not the whole startup log but it didn't try to reinstall the dependencies!
18:20:19 [gateway] startup trace: cli.gateway-loop 20.3ms total=156.6ms
18:21:04 [gateway] startup trace: config.snapshot 749.9ms total=750.0ms
18:21:04 [gateway] startup trace: config.auth 3.4ms total=765.6ms
18:21:04 [gateway] startup trace: control-ui.seed 0.2ms total=777.5ms
18:22:02 Registered plugin command: /pair (plugin: device-pair)
18:22:09 Registered plugin command: /dreaming (plugin: memory-core)
18:22:14 Registered plugin command: /voice (plugin: talk-voice)
18:22:36 Registered plugin command: /phone (plugin: phone-control)
18:22:36 [gateway] startup trace: plugins.bootstrap 91237.9ms total=92026.8ms
18:22:36 [gateway] startup trace: runtime.config 6.2ms total=92043.8ms
18:22:36 [gateway] startup trace: control-ui.root 4.9ms total=92061.3ms
18:22:36 [gateway] startup trace: tls.runtime 0.2ms total=92073.6ms
18:22:36 [gateway] starting HTTP server...
18:22:36 [canvas] host mounted at http://127.0.0.1:18790/__openclaw__/canvas/ (root D:\Caelan.openclaw-test\canvas)
18:22:36 [gateway] startup trace: runtime.state 19.7ms total=92116.1ms
18:22:37 [plugins] bonjour: starting (hostname=openclaw, instance="DESKTOP-6RLTKSA (OpenClaw)", gatewayPort=18790, minimal=true)
18:22:37 [gateway] startup trace: runtime.early 1128.9ms total=93258.0ms
18:22:37 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:22:38 [gateway] startup trace: http.bound 1221.5ms total=94479.5ms
18:22:38 [gateway] agent model: openai/gpt-5.5
18:22:38 [gateway] ready (7 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice; 139.5s)

silk mothBOT Apr 28, 2026, 12:25 AM

#

Good news: deps persisted. Bad news: 139s is still way too slow — now it’s mostly:

plugins.bootstrap 91237ms

So I’d get you usable first by disabling optional heavy/default plugins. Basic chat should still work.

Stop the test gateway, then run on real state:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"

openclaw config set plugins.entries.acpx.enabled false --strict-json
openclaw config set plugins.entries.browser.enabled false --strict-json
openclaw config set plugins.entries.phone-control.enabled false --strict-json

#

openclaw config set plugins.entries.talk-voice.enabled false --strict-json
openclaw config set plugins.entries.bonjour.enabled false --strict-json

openclaw doctor --repair
openclaw gateway run --verbose

Tradeoff: disables ACP harnesses, browser plugin, phone/voice, and LAN discovery. Your agent/chat should be the priority right now.

If that starts fast, then later re-enable one at a time to find the slow plugin.

Also: don’t reinstall/enable the Scheduled Task until the foreground gateway run is stable.

tribal arch Apr 28, 2026, 1:01 AM

#

doctor has just been hanging her for 30 minutes:

🦞 OpenClaw 2026.4.25 (aa36ee6) — Shell yeah—I'm here to pinch the toil and leave you the glory.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

T OpenClaw doctor
|
o Config warnings --------------------------------------------------------------------------+
| |
| - plugins.entries.discord: plugin disabled (disabled in config) but config is present |
| - plugins.entries.continuity: plugin disabled (disabled in config) but config is present |
| - plugins.entries.stability: plugin disabled (disabled in config) but config is present |
| - plugins.entries.lossless-claw: plugin disabled (disabled in config) but config is |
| present |
| |
+--------------------------------------------------------------------------------------------+

silk mothBOT Apr 28, 2026, 1:01 AM

#

Yeah, don’t let doctor sit there. Kill it. We don’t need doctor right now; it’s probably doing the same plugin dependency/bootstrap work and hanging on Windows I/O.

Use config set directly, then run the gateway. No doctor:

# Ctrl+C doctor first. If it won't stop:
Get-CimInstance Win32_Process -Filter "name = 'node.exe'" |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"

openclaw config set plugins.entries.acpx.enabled false --strict-json
openclaw config set plugins.entries.browser.enabled false --strict-json
openclaw config set plugins.entries.phone-control.enabled false --strict-json
openclaw config set plugins.entries.talk-voice.enabled false --strict-json

#

openclaw config set plugins.entries.bonjour.enabled false --strict-json

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --verbose

If config set itself hangs, use the plugin CLI variant instead:

openclaw plugins disable acpx
openclaw plugins disable browser
openclaw plugins disable phone-control
openclaw plugins disable talk-voice
openclaw plugins disable bonjour

#

The goal is to get a minimal stable gateway up first. Doctor can wait.

tribal arch Apr 28, 2026, 1:27 AM

#

Yeah it's been stuck here for over ten minutes:

19:14:43 [gateway] startup trace: cli.server-import 113.3ms total=113.3ms
19:14:43 [gateway] loading configuration…
19:14:44 [gateway] startup trace: cli.config-load 1231.4ms total=1369.8ms
19:14:45 [gateway] startup trace: cli.config-snapshot 847.7ms total=2291.4ms
19:14:45 [gateway] resolving authentication…
19:14:45 [gateway] startup trace: cli.auth-resolve 0.4ms total=2319.4ms
19:14:45 [gateway] starting...
19:14:45 [gateway] startup trace: cli.gateway-loop 24.1ms total=2343.5ms
19:15:15 [gateway] startup trace: config.snapshot 6050.8ms total=6050.9ms

silk mothBOT Apr 28, 2026, 1:28 AM

#

Yeah, kill it. If it’s stuck there, the real state is hanging before config.auth finishes again.

Do this in order:

# stop any hung OpenClaw/npm/node work
Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw|plugin-runtime|npm" } |
  Select-Object ProcessId,Name,CommandLine

If that shows old/hung OpenClaw processes, kill them:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw|plugin-runtime|npm" } |

#

  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

Then check auth stores for weird secret refs/commands:

Get-ChildItem D:\Caelan\.openclaw\agents -Recurse -Include auth-profiles.json,auth.json |
  Select-String -Pattern '"source"\s*:\s*"exec"|"source"\s*:\s*"file"|\$\{|command' -Context 2,3

If that prints anything, paste it but redact tokens.

Then try real gateway with channels/providers skipped:

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

openclaw gateway run --verbose

If it still stops right after config.snapshot, then the problem is almost certainly in auth/profile/state activation, not plugins/channels.

tribal arch Apr 28, 2026, 1:31 AM

#

ok just showing you this but i did start the gateway as well:

Where-Object { $.CommandLine -match "openclaw|plugin-runtime|npm" } |
Select-Object ProcessId,Name,CommandLine
PS D:\Caelan.openclaw\workspace> Get-CimInstance Win32Process |
Where-Object { $.CommandLine -match "openclaw|plugin-runtime|npm" } |

At line:2 char:73

... here-Object { $.CommandLine -match "openclaw|plugin-runtime|npm" } |

An empty pipe element is not allowed.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : EmptyPipeElement

PS D:\Caelan.openclaw\workspace> ForEach-Object { Stop-Process -Id $.ProcessId -Force }
Stop-Process : Cannot bind argument to parameter 'Id' because it is null.
At line:1 char:37

ForEach-Object { Stop-Process -Id $_.ProcessId -Force }
```
                                ~~~~
```
- CategoryInfo : InvalidData: (:) [Stop-Process], ParameterBindingValidationException
- FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.StopProcess
  Command

silk mothBOT Apr 28, 2026, 1:31 AM

#

No worries — PowerShell is picky. Two issues happened:

It’s $_, not $
Don’t leave a trailing | at the end

Use this exact one-liner to show matching processes:

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'openclaw|plugin-runtime|npm' } | Select-Object ProcessId,Name,CommandLine

If you decide to kill them:

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'openclaw|plugin-runtime|npm' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

#

But if you already started the gateway and it’s progressing, let’s see where it lands. If it sticks after config.snapshot again, cancel and run the corrected process check.

tribal arch Apr 28, 2026, 1:51 AM

#

i don't think there are any processes. nothing shows when i do those commands.

startup hung in the same place so i killed it again

silk mothBOT Apr 28, 2026, 1:52 AM

#

Okay — that means the real config/state is hanging in the same startup-auth/config activation path. Let’s stop trying normal startup for a minute and isolate the specific config surface.

I suspect a disabled plugin config or web-tool config is still being scanned during startup. Run these searches:

Select-String D:\Caelan\.openclaw\openclaw.json -Pattern '"webSearch"|"webFetch"|"x_search"|"tools"\s*:\s*\{|"web"\s*:\s*\{' -Context 3,5

And:

Select-String D:\Caelan\.openclaw\openclaw.json -Pattern '"source"\s*:\s*"exec"|"source"\s*:\s*"file"|\$\{|keyRef|tokenRef|SecretRef' -Context 2,3

If either prints anything, paste it with secrets redacted.

Also try the most aggressive safe plugin bypass:

#

openclaw config set plugins.enabled false --strict-json
$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway run --verbose

If that starts, we’ve confirmed it’s plugin/config scanning. If it still hangs after config.snapshot, then I’d make a backup and do a minimal-config rescue next.

tribal arch Apr 28, 2026, 1:54 AM

#

i'll do this one at a time again:

PS D:\Caelan.openclaw\workspace> Select-String D:\Caelan.openclaw\openclaw.json -Pattern '"webSearch"|"webFetch"|"x_search"|"tools"\s*:\s*{|"web"\s*:\s*{' -Context 3,5

D:\Caelan.openclaw\openclaw.json:359: }
D:\Caelan.openclaw\openclaw.json:360: ]
D:\Caelan.openclaw\openclaw.json:361: },

D:\Caelan.openclaw\openclaw.json:362: "tools": {
D:\Caelan.openclaw\openclaw.json:363: "profile": "coding",
D:\Caelan.openclaw\openclaw.json:364: "web": {
D:\Caelan.openclaw\openclaw.json:365: "search": {
D:\Caelan.openclaw\openclaw.json:366: "enabled": true
D:\Caelan.openclaw\openclaw.json:367: },
D:\Caelan.openclaw\openclaw.json:368: "fetch": {
D:\Caelan.openclaw\openclaw.json:369: "enabled": true
D:\Caelan.openclaw\openclaw.json:630: "brave": {
D:\Caelan.openclaw\openclaw.json:631: "enabled": true,
D:\Caelan.openclaw\openclaw.json:632: "config": {
D:\Caelan.openclaw\openclaw.json:633: "webSearch": {
D:\Caelan.openclaw\openclaw.json:634: "apiKey": "redacted"
D:\Caelan.openclaw\openclaw.json:635: }
D:\Caelan.openclaw\openclaw.json:636: }
D:\Caelan.openclaw\openclaw.json:637: },
D:\Caelan.openclaw\openclaw.json:638: "openai": {

silk mothBOT Apr 28, 2026, 1:54 AM

#

Aha. That’s very likely relevant.

Because tools.web and brave.config.webSearch are present, startup takes the slower runtime web-tool resolution path. Let’s disable just that surface temporarily:

openclaw config set tools.web.search.enabled false --strict-json
openclaw config set tools.web.fetch.enabled false --strict-json
openclaw config set plugins.entries.brave.enabled false --strict-json

Then try the real gateway again:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_CHANNELS="1"

#

$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway run --verbose

If that gets past config.auth, we found the hang path. If it still hangs, run/paste the second search too:

Select-String D:\Caelan\.openclaw\openclaw.json -Pattern '"source"\s*:\s*"exec"|"source"\s*:\s*"file"|\$\{|keyRef|tokenRef|SecretRef' -Context 2,3

tribal arch Apr 28, 2026, 2:25 AM

#

ok so that one hung too. did the second search and came back with nothing

silk mothBOT Apr 28, 2026, 2:27 AM

#

Okay — then I’d stop chasing individual config keys. Time for a minimal-config rescue test that does not overwrite your real config.

Kill the hung gateway, then create a separate temp config:

@'
{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "port": 18791,
    "auth": {
      "mode": "token",
      "token": "local-test-token"
    }
  },

#

  "agents": {
    "defaults": {
      "workspace": "D:\\Caelan\\.openclaw\\workspace"
    }
  },
  "plugins": {
    "enabled": false
  },
  "channels": {}
}
'@ | Set-Content D:\Caelan\openclaw-minimal.json

Then run using the same real state dir but the temp config:

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-minimal.json"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If that starts fast, your install/state is okay and the hang is definitely in openclaw.json.

If that still hangs after config.snapshot, then something in the real state dir itself is being touched during startup. Then we’ll narrow state folders next.

When done testing, clear the temp config env before normal commands:

Remove-Item Env:OPENCLAW_CONFIG_PATH

tribal arch Apr 28, 2026, 2:31 AM

#

Started up so fast with that one:
20:30:18 [gateway] startup trace: cli.server-import 3.6ms total=3.6ms
20:30:18 [gateway] loading configuration…
20:30:19 [gateway] startup trace: cli.config-load 819.7ms total=943.4ms
20:30:20 [gateway] startup trace: cli.config-snapshot 417.2ms total=1376.1ms
20:30:20 [gateway] resolving authentication…
20:30:20 [gateway] startup trace: cli.auth-resolve 0.4ms total=1404.9ms
20:30:20 [gateway] starting...
20:30:20 [gateway] startup trace: cli.gateway-loop 25.4ms total=1430.3ms
20:30:25 [gateway] startup trace: config.snapshot 1005.9ms total=1006.0ms
20:30:25 [gateway] startup trace: config.auth 4.2ms total=1027.1ms
20:30:25 [gateway] startup trace: control-ui.seed 0.1ms total=1039.9ms
20:30:27 [gateway] startup trace: plugins.bootstrap 1776.9ms total=2828.2ms
20:30:27 [gateway] startup trace: runtime.config 127.7ms total=2971.1ms
20:30:27 [gateway] startup trace: control-ui.root 5.0ms total=2997.8ms
20:30:27 [gateway] startup trace: tls.runtime 0.2ms total=3012.3ms
20:30:27 [gateway] starting HTTP server...
20:30:27 [canvas] host mounted at http://127.0.0.1:18791/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)
20:30:27 [gateway] startup trace: runtime.state 92.1ms total=3132.1ms
20:30:27 [gateway] startup trace: runtime.early 271.4ms total=3416.9ms
20:30:27 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)

#

20:30:28 [gateway] startup trace: http.bound 1264.2ms total=4681.1ms
20:30:29 [gateway] agent model: openai/gpt-5.5
20:30:29 [gateway] ready (0 plugins, 8.8s)
20:30:29 [gateway] log file: \tmp\openclaw\openclaw-2026-04-27.log
20:30:29 [gateway] startup trace: post-attach.log 42.2ms total=4804.6ms
20:30:29 [gateway] startup trace: post-attach.update-check 1.8ms total=4817.6ms
20:30:29 [gateway] starting channels and sidecars...
20:30:29 [gateway] startup trace: sidecars.session-locks 21.1ms total=4916.6ms
20:30:29 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=4927.9ms
20:30:29 [gateway] startup trace: sidecars.gmail-model 0.1ms total=4940.2ms
20:30:29 [gateway] startup trace: sidecars.internal-hooks 0.1ms total=4952.9ms
20:30:29 [gateway] startup trace: sidecars.channels 1.5ms total=4967.0ms
20:30:29 [gateway] startup trace: sidecars.plugin-services 1.8ms total=4981.6ms
20:30:29 [gateway] startup trace: sidecars.memory 0.1ms total=4993.6ms
20:30:29 [gateway] startup trace: sidecars.restart-sentinel 1.6ms total=5006.7ms
20:30:29 [gateway] startup trace: sidecars.subagent-recovery 8.4ms total=5026.9ms
20:30:29 [gateway] startup trace: sidecars.main-session-recovery 6.3ms total=5045.6ms
20:30:29 [gateway] startup trace: sidecars.total 161.4ms total=5056.6ms
20:30:29 [gateway] startup trace: sidecars.ready 14.3ms total=5070.9ms
20:30:29 [gateway] startup trace: runtime.post-attach 321.7ms total=5083.7ms
20:30:29 [gateway] startup trace: ready 12.0ms total=5095.7ms
20:30:29 [heartbeat] started
20:30:29 [delivery-recovery] Found 1 pending delivery entries — starting recovery
20:30:30 [delivery-recovery] Delivery 5488efbf-8f74-4dc7-b12a-0afe3097a97d hit permanent error — moving to failed/: Outbound not configured for channel: discord
20:30:30 [delivery-recovery] Delivery recovery complete: 0 recovered, 1 failed, 0 skipped (max retries), 0 deferred (backoff)

silk mothBOT Apr 28, 2026, 2:31 AM

#

Excellent. That proves the install + real state dir are okay. The hang is in your real openclaw.json.

Next safest move: keep your real config backed up, then make a sanitized rescue copy by removing the two big suspicious sections: plugins and tools.web.

In PowerShell:

Copy-Item D:\Caelan\.openclaw\openclaw.json D:\Caelan\.openclaw\openclaw.json.before-rescue

$json = Get-Content D:\Caelan\.openclaw\openclaw.json -Raw | ConvertFrom-Json

# keep channels/agents/auth/etc, but remove plugin + web-tool startup surfaces
$json.PSObject.Properties.Remove("plugins")
if ($json.tools -and $json.tools.web) {
  $json.tools.PSObject.Properties.Remove("web")
}

#


$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue.json

Then test that rescue config:

# Ctrl+C the minimal gateway first
$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue.json"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If that starts fast, we can replace the real config with the rescue version or selectively remove just the bad sections.

#

Reminder when done:

Remove-Item Env:OPENCLAW_CONFIG_PATH

#

Yep — minimal config is healthy. The Outbound not configured for channel: discord is expected because that temp config has no Discord/outbound config. Not relevant to the hang.

Now test the rescue copy I described — it keeps your real channels/agents/auth, but removes plugin + web-tool startup surfaces:

Copy-Item D:\Caelan\.openclaw\openclaw.json D:\Caelan\.openclaw\openclaw.json.before-rescue

$json = Get-Content D:\Caelan\.openclaw\openclaw.json -Raw | ConvertFrom-Json
$json.PSObject.Properties.Remove("plugins")
if ($json.tools -and $json.tools.web) {
  $json.tools.PSObject.Properties.Remove("web")
}
$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue.json

Then:

#

# Ctrl+C the minimal gateway first
$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue.json"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If rescue starts fast and Discord works, we can swap it in as your real config.

tribal arch Apr 28, 2026, 2:34 AM

#

Ok so just started but I'm getting this:
20:32:59 [gateway] startup trace: cli.server-import 4.9ms total=4.9ms
20:32:59 [gateway] loading configuration…
20:33:00 [gateway] startup trace: cli.config-load 843.2ms total=910.9ms
20:33:00 [gateway] startup trace: cli.config-snapshot 472.5ms total=1398.9ms
20:33:00 [gateway] resolving authentication…
20:33:00 [gateway] startup trace: cli.auth-resolve 0.4ms total=1426.5ms
20:33:00 [gateway] starting...
20:33:00 [gateway] startup trace: cli.gateway-loop 19.3ms total=1445.8ms
20:33:07 Config write rejected: D:\Caelan\openclaw-rescue.json (size-drop:45449->16141). Rejected payload saved to D:\Caelan\openclaw-rescue.json.rejected.2026-04-28T02-33-07-615Z.
20:33:07 [gateway] failed to persist plugin auto-enable changes: Error: Config write rejected: D:\Caelan\openclaw-rescue.json (size-drop:45449->16141). Rejected payload saved to D:\Caelan\openclaw-rescue.json.rejected.2026-04-28T02-33-07-615Z.
20:33:07 [gateway] startup trace: config.snapshot 3364.7ms total=3364.7ms
20:33:07 [gateway] startup trace: config.auth 9.1ms total=3384.2ms
20:33:07 [gateway] startup trace: control-ui.seed 0.1ms total=3394.4ms
20:33:09 [gateway] [plugins] staging bundled runtime deps before gateway startup (6 missing, 9 install specs): @homebridge/ciao@^1.3.6, @modelcontextprotocol/sdk@1.29.0, acpx@0.6.1, commander@^14.0.3, express@5.2.1, playwright-core@1.59.1

silk mothBOT Apr 28, 2026, 2:34 AM

#

That’s okay — and it explains what happened.

The rescue config removed plugins, so OpenClaw tried to auto-enable default plugins again. The “Config write rejected” is a safety guard because the generated config was much smaller. Not fatal, but it means this rescue copy still allowed plugin auto-enable.

Stop that run. Make a new rescue config that explicitly disables plugins:

$json = Get-Content D:\Caelan\.openclaw\openclaw.json -Raw | ConvertFrom-Json

$json.PSObject.Properties.Remove("plugins")
$json | Add-Member -NotePropertyName plugins -NotePropertyValue ([pscustomobject]@{
  enabled = $false
}) -Force

if ($json.tools -and $json.tools.web) {
  $json.tools.PSObject.Properties.Remove("web")

#

}

$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-noplugins.json

Then test:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If that starts fast, we’ve confirmed the real blocker is plugin auto-enable/bootstrap, not your channels/auth/state. Then we can reintroduce only the minimum plugin(s) you actually need.

tribal arch Apr 28, 2026, 2:46 AM

#

ok that was fast. here's where it is now:
20:44:30 [gateway] startup trace: cli.server-import 3.9ms total=3.9ms
20:44:30 [gateway] loading configuration…
20:44:31 [gateway] startup trace: cli.config-load 984.8ms total=1052.5ms
20:44:32 [gateway] startup trace: cli.config-snapshot 642.5ms total=1708.0ms
20:44:32 [gateway] resolving authentication…
20:44:32 [gateway] startup trace: cli.auth-resolve 0.4ms total=1739.8ms
20:44:32 [gateway] starting...
20:44:32 [gateway] startup trace: cli.gateway-loop 25.3ms total=1765.1ms
20:45:06 [gateway] startup trace: config.snapshot 2659.0ms total=2659.0ms
20:45:07 [gateway] startup trace: config.auth 246.5ms total=2920.3ms
20:45:07 [gateway] startup trace: control-ui.seed 0.2ms total=2953.5ms
20:45:12 [gateway] startup trace: plugins.bootstrap 4948.6ms total=7914.1ms
20:45:12 [gateway] startup trace: runtime.config 145.8ms total=8076.2ms
20:45:12 [gateway] startup trace: control-ui.root 5.1ms total=8105.1ms
20:45:12 [gateway] startup trace: tls.runtime 0.2ms total=8118.8ms
20:45:12 [gateway] starting HTTP server...
20:45:12 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)

#

20:45:12 [gateway] startup trace: runtime.state 69.7ms total=8223.7ms
20:45:12 [gateway] startup trace: runtime.early 300.9ms total=8545.5ms
20:45:12 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
20:45:14 [gateway] startup trace: http.bound 1589.7ms total=10135.3ms
20:45:14 [gateway] agent model: openai-codex/gpt-5.5
20:45:14 [gateway] ready (0 plugins, 42.0s)
20:45:14 [gateway] log file: D:\Caelan.openclaw\logs\openclaw.log
20:45:14 [gateway] startup trace: post-attach.log 44.5ms total=10190.9ms
20:45:14 [gateway] startup trace: post-attach.update-check 1.9ms total=10204.7ms
20:45:14 [gateway] starting channels and sidecars...
20:45:14 [gateway] startup trace: sidecars.session-locks 22.5ms total=10256.1ms
20:45:14 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=10269.0ms
20:45:14 [gateway] startup trace: sidecars.gmail-model 0.1ms total=10279.3ms
20:45:15 [hooks:loader] Registered hook: boot-md -> gateway:startup
20:45:15 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
20:45:15 [hooks:loader] Registered hook: command-logger -> command
20:45:15 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
20:45:15 [hooks] loaded 4 internal hook handlers
20:45:15 [gateway] startup trace: sidecars.internal-hooks 1092.2ms total=11383.9ms

silk mothBOT Apr 28, 2026, 2:46 AM

#

Great — that’s the confirmation. With plugins disabled, startup is healthy. So the root problem is plugin auto-enable/bootstrap/runtime deps, not your workspace/state generally.

Let it finish to ready. If it says ready (0 plugins...), your rescue config is viable.

Then check whether your actual chat channel is still configured in this rescue config. Since we removed only plugins and tools.web, channels may still work depending on whether your Discord channel needs the bundled plugin path.

After it reaches ready, in another PowerShell:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
openclaw channels status --probe

If Discord shows usable/connected, you can run with this rescue config for now.

If it says Discord is unavailable because plugins are disabled, then we’ll make a smaller allowlist instead of plugins.enabled=false — likely enable only discord and maybe memory-core, while blocking acpx/browser/bonjour/phone/talk/brave.

#

Yep, that’s good. It’s “ready” in 42s, and most of that is still some Windows startup weirdness before config.snapshot; importantly, no 5–20 minute hang.

Let it finish sidecars, then run:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
openclaw channels status --probe

If Discord is missing/unavailable with 0 plugins, then we’ll make this version instead:

keep plugins.enabled true
allow/enable only discord
explicitly disable the heavy/default ones: acpx, browser, bonjour, phone-control, talk-voice, brave, lossless-claw

But first let’s see whether the channel status works with plugins off.

tribal arch Apr 28, 2026, 2:49 AM

#

PS D:\Caelan.openclaw\workspace> openclaw channels status --probe

🦞 OpenClaw 2026.4.25 (aa36ee6) — Your .zshrc wishes it could do what I do.

|
o
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: D:\Caelan\openclaw-rescue-noplugins.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: D:\Caelan\openclaw-rescue-noplugins.json
Mode: local

silk mothBOT Apr 28, 2026, 2:49 AM

#

That means the gateway wasn’t actually responsive yet, even though it printed ready. It may still be stuck in sidecars after internal-hooks, or the foreground run ended/was killed.

In the gateway window, what’s the last line after:

sidecars.internal-hooks ...

If it hasn’t printed:

sidecars.total
sidecars.ready
runtime.post-attach

then wait maybe another minute. If it still doesn’t move, Ctrl+C and run the rescue config with channel startup skipped so we can prove RPC works:

#

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

Then in another PowerShell:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
openclaw gateway status --deep

#

If RPC works with OPENCLAW_SKIP_CHANNELS=1, then something in sidecars/channel recovery is still hanging.

tribal arch Apr 28, 2026, 2:50 AM

#

20:45:14 [gateway] startup trace: sidecars.session-locks 22.5ms total=10256.1ms
20:45:14 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=10269.0ms
20:45:14 [gateway] startup trace: sidecars.gmail-model 0.1ms total=10279.3ms
20:45:15 [hooks:loader] Registered hook: boot-md -> gateway:startup
20:45:15 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
20:45:15 [hooks:loader] Registered hook: command-logger -> command
20:45:15 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
20:45:15 [hooks] loaded 4 internal hook handlers
20:45:15 [gateway] startup trace: sidecars.internal-hooks 1092.2ms total=11383.9ms

silk mothBOT Apr 28, 2026, 2:51 AM

#

Yep, it’s hanging after internal hooks, before sidecars.channels. So now we’ve isolated a second issue: sidecar/channel startup can hang even with plugins disabled.

Kill that run and start with channels skipped:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If that gets to sidecars.ready, then the remaining blocker is channel startup.

After that, we’ll re-enable only your needed channel. Quick question for that step: are you primarily using Discord, or another channel like Telegram/WhatsApp?

tribal arch Apr 28, 2026, 2:53 AM

#

ok, i started that next one.

I probably should have told you that my agent and I were trying to get another agent with its own discord bot and everything, so he created her sort of as her own thing? I am not sure what he did. So that could have messed with things, not sure. I don't know what sidecars are so maybe that's related?

I primarily use Discord, but also have the dashboard open most of the time and send messages in there if needed on occasion.

silk mothBOT Apr 28, 2026, 2:53 AM

#

Yes — that context matters a lot. Multiple Discord bots/agents can absolutely create weird startup/channel behavior if the config ended up with duplicate Discord accounts, stale bot tokens, or a second “agent” wired as its own channel/service.

“Sidecars” here just means the extra gateway services that start after core HTTP is up: channels like Discord, plugin services, hooks, recovery, etc. So yes, a bot/channel config issue fits the exact spot where you’re hanging.

Let the OPENCLAW_SKIP_CHANNELS=1 run finish. If it gets to sidecars.ready, then next inspect only Discord config shape — don’t paste tokens:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
openclaw config get channels.discord --json

Before pasting, replace any token-looking value with "REDACTED".

What I’m looking for:

multiple accounts
extra bot/account IDs
old C-drive paths

#

duplicate/default Discord configs
anything pointing the second agent at Discord directly

If you’d rather avoid manual redaction, use this safer summary:

$json = Get-Content D:\Caelan\openclaw-rescue-noplugins.json -Raw | ConvertFrom-Json
$json.channels.discord | ConvertTo-Json -Depth 20 |
  Select-String -Pattern '"accounts"|"enabled"|"agent"|"agentId"|"token"|"allowFrom"|"guild"|"channel"'

tribal arch Apr 28, 2026, 2:56 AM

#

oh also the sidecars say ready now:
20:52:14 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
20:52:14 [gateway] startup trace: sidecars.channels 13.0ms total=10405.5ms
20:52:14 [gateway] startup trace: sidecars.plugin-services 2.6ms total=10420.9ms
20:52:14 [gateway] startup trace: sidecars.memory 0.1ms total=10431.7ms
20:52:14 [gateway] startup trace: sidecars.restart-sentinel 3.9ms total=10448.2ms
20:52:14 [gateway] startup trace: sidecars.subagent-recovery 11.2ms total=10471.1ms
20:52:14 [gateway] startup trace: sidecars.main-session-recovery 4.9ms total=10488.3ms
20:52:14 [gateway] startup trace: sidecars.total 1108.4ms total=10501.5ms
20:52:14 [gateway] startup trace: sidecars.ready 10.6ms total=10512.1ms
20:52:14 [gateway] startup trace: runtime.post-attach 1219.0ms total=10527.4ms
20:52:14 [gateway] startup trace: ready 11.4ms total=10538.8ms
20:52:15 [heartbeat] started
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped
20:52:15 [hooks/boot-md] startup task skipped

silk mothBOT Apr 28, 2026, 2:56 AM

#

Great. That proves channel startup is the remaining sidecar hang.

The repeated boot-md startup task skipped is okay/noisy; not the blocker.

Now inspect Discord config shape. Since this gateway is running with the rescue config and channels skipped, run in another PowerShell:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"

$json = Get-Content D:\Caelan\openclaw-rescue-noplugins.json -Raw | ConvertFrom-Json
$json.channels.discord | ConvertTo-Json -Depth 30 |
  Select-String -Pattern '"accounts"|"enabled"|"agent"|"agentId"|"token"|"allowFrom"|"guild"|"channel"|"defaultTo"'

Paste that output, but if it shows an actual token value, replace it with REDACTED.

Given what you said about creating another agent with its own Discord bot, I’m specifically looking for multiple Discord accounts/bots or routing to that second agent.

tribal arch Apr 28, 2026, 2:59 AM

#

{
"enabled": false,
"accounts": {
"default": {
"token":
"REDACTED"
}
},
"groupPolicy": "allowlist",
"streaming": {
"mode": "off"
},

#

"guilds": {
"1065643297118363658": {
"slug": "wayfarer-game",
"requireMention": false,
"channels": {
"1467256651181592789": {
"requireMention": false,
"enabled": true
},
"1467831735927701514": {
"requireMention": false,
"enabled": true
},

#

"1482521229310296064": {
"enabled": true,
"systemPrompt": ""
},
"1494264999386939403": {
"enabled": true,
"requireMention": false
}
}
},
"1404158078626168953": {
"slug": "ai-human-relationships",
"requireMention": true,
"channels": {
"1468447435884855417": {
"requireMention": false,
"enabled": true,

silk mothBOT Apr 28, 2026, 2:59 AM

#

That’s interesting: in the rescue config, Discord is explicitly disabled:

"enabled": false

So your current fast rescue startup won’t connect Discord.

Let’s create a Discord-only rescue: plugins disabled, web tools removed, Discord enabled with only the default account.

Run:

$json = Get-Content D:\Caelan\openclaw-rescue-noplugins.json -Raw | ConvertFrom-Json

$json.channels.discord.enabled = $true

#


# make sure only default account remains
$defaultDiscord = $json.channels.discord.accounts.default
$json.channels.discord.accounts = [pscustomobject]@{
  default = $defaultDiscord
}

$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-discord.json

Then stop the current gateway and test with channels enabled:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-discord.json"

#

Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

openclaw gateway run --verbose

If this hangs at sidecars.channels, then the default Discord account/token startup is the channel blocker. If it starts, you should be able to talk via Discord again, minus optional plugins/tools.

#

Thanks — that looks like normal guild/channel allowlist shape.

Continue with the Discord-only rescue test from above. That’ll tell us whether the default Discord channel itself can start cleanly.

If it hangs, the next likely causes are:

Discord bot token/account has a startup conflict
duplicate bot process elsewhere
Discord plugin/channel runtime dependency issue
one of those allowed guild/channel entries is malformed farther down

But first let’s see whether openclaw-rescue-discord.json gets past:

sidecars.channels

#

Those entries also look structurally normal. The empty systemPrompt: "" is odd but shouldn’t hang startup.

Go ahead with the Discord-only rescue test. That result matters more than more config snippets right now.

tribal arch Apr 28, 2026, 3:02 AM

#

well this weekend when we were troubleshooting we disabled Discord, so that's why. The main problem was that gateway/openclaw itself was messed up so i dunno. I guess the other AI just felt like ruling certain things out one by one

silk mothBOT Apr 28, 2026, 3:02 AM

#

That makes sense — and honestly the “disable things one by one” instinct was reasonable. We’ve just narrowed it much further now:

OpenClaw install: works
Real state dir: works
Minimal/rescue config: works
Plugins enabled/auto-enabled: bad/very slow
Channel startup: can also hang unless skipped
Discord was disabled because of prior troubleshooting, not necessarily root cause

So I’d stop treating Discord as guilty until we test it.

The fastest path back to a usable bot is:

Use the rescue config with plugins disabled.
Re-enable only Discord.
Keep optional plugins/web tools off.

#

Run:

$json = Get-Content D:\Caelan\openclaw-rescue-noplugins.json -Raw | ConvertFrom-Json
$json.channels.discord.enabled = $true
$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-discord.json

Then:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-discord.json"
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"

#


openclaw gateway run --verbose

If Discord starts, great — you’re back online. If it hangs at sidecars.channels, then we know Discord/channel startup is the next concrete blocker.

tribal arch Apr 28, 2026, 3:12 AM

#

21:00:43 [gateway] startup trace: cli.server-import 3.5ms total=3.5ms
21:00:43 [gateway] loading configuration…
21:00:44 [gateway] startup trace: cli.config-load 933.2ms total=978.0ms
21:00:44 [gateway] startup trace: cli.config-snapshot 633.0ms total=1624.5ms
21:00:44 [gateway] resolving authentication…
21:00:44 [gateway] startup trace: cli.auth-resolve 0.5ms total=1651.2ms
21:00:44 [gateway] starting...
21:00:44 [gateway] startup trace: cli.gateway-loop 21.3ms total=1672.4ms
21:00:51 [gateway] startup trace: config.snapshot 2562.1ms total=2562.1ms
21:00:51 [gateway] startup trace: config.auth 9.7ms total=2591.4ms
21:00:51 [gateway] startup trace: control-ui.seed 0.2ms total=2604.8ms
21:00:56 [gateway] startup trace: plugins.bootstrap 5428.5ms total=8044.0ms
21:00:56 [gateway] startup trace: runtime.config 6.1ms total=8065.0ms
21:00:56 [gateway] startup trace: control-ui.root 5.2ms total=8083.9ms
21:00:56 [gateway] startup trace: tls.runtime 0.1ms total=8095.1ms
21:00:56 [gateway] starting HTTP server...
21:00:56 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)

#

21:00:56 [gateway] startup trace: runtime.state 17.2ms total=8136.8ms
21:00:56 [gateway] startup trace: runtime.early 30.8ms total=8181.0ms
21:00:57 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
21:00:58 [gateway] startup trace: http.bound 1622.9ms total=9804.0ms
21:00:58 [gateway] agent model: openai-codex/gpt-5.5
21:00:58 [gateway] ready (0 plugins, 13.8s)
21:00:58 [gateway] log file: D:\Caelan.openclaw\logs\openclaw.log
21:00:58 [gateway] startup trace: post-attach.log 44.3ms total=9863.5ms
21:00:58 [gateway] startup trace: post-attach.update-check 1.7ms total=9876.9ms
21:00:58 [gateway] starting channels and sidecars...
21:00:58 [gateway] startup trace: sidecars.session-locks 8.4ms total=9908.1ms
21:00:58 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=9919.3ms
21:00:58 [gateway] startup trace: sidecars.gmail-model 0.1ms total=9928.9ms
21:00:59 [hooks:loader] Registered hook: boot-md -> gateway:startup
21:00:59 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
21:00:59 [hooks:loader] Registered hook: command-logger -> command
21:00:59 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
21:00:59 [hooks] loaded 4 internal hook handlers
21:00:59 [gateway] startup trace: sidecars.internal-hooks 911.4ms total=10851.4ms

silk mothBOT Apr 28, 2026, 3:12 AM

#

This part is healthy so far. Let it continue until either:

it prints ready, then sidecars.channels, then sidecars.ready, or
it stops for ~2–3 minutes.

If it hangs, the exact last line matters. The key point we’re watching is whether it gets past:

sidecars.channels

If it reaches ready and Discord connects, you’re back to a usable minimal setup.

#

Same pattern: core is fine, then it reaches sidecars and stalls right before channels.

Give it ~2 minutes from 21:00:59. If no sidecars.channels appears, then Discord/channel startup is hanging.

If that happens, kill it and make a dashboard-only rescue config for now — usable in Control UI, no Discord channel:

# use the no-plugins rescue config as the real config temporarily
Copy-Item D:\Caelan\openclaw-rescue-noplugins.json D:\Caelan\.openclaw\openclaw.json.rescue-working

To actually run it as the service later, we’d replace D:\Caelan\.openclaw\openclaw.json with that rescue config after keeping backups. But before doing that, I want one more quick check if Discord hangs:

$json = Get-Content D:\Caelan\openclaw-rescue-discord.json -Raw | ConvertFrom-Json
$json.channels.discord.enabled = $false

#

$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-dashboard.json

Then run that without skip vars:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-dashboard.json"
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
openclaw gateway run --verbose

If dashboard-only gets sidecars.ready, then Discord specifically is the channel hang.

tribal arch Apr 28, 2026, 3:27 AM

#

ok. while that's getting started. what are hook handlers? It always starts to go real slow there

silk mothBOT Apr 28, 2026, 3:27 AM

#

Hook handlers are little built-in “event listeners” OpenClaw loads so it can react to lifecycle events.

The four you’re seeing are internal/default ones:

boot-md → runs/reads startup boot instructions if present
bootstrap-extra-files → adds extra bootstrap context files to agent sessions
command-logger → logs slash/command activity
session-memory → handles memory behavior on /new / /reset

In your traces, hooks themselves aren’t the big slowdown: they take about ~900–1100ms, which is annoying but not catastrophic.

The suspicious part is what happens immediately after:

sidecars.internal-hooks

#

Normally next should be:

sidecars.channels

When it stops there, it means it’s entering channel startup — likely Discord in your current test — and not returning. So the hook line is probably just the last thing printed before the actual hang.

tribal arch Apr 28, 2026, 3:32 AM

#

ok now it's stuck there this time. over five minutes:
21:25:13 [gateway] loading configuration…
21:25:14 [gateway] resolving authentication…
21:25:14 [gateway] starting...
21:25:24 [gateway] starting HTTP server...
21:25:24 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)
21:25:24 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
21:25:25 [gateway] agent model: openai-codex/gpt-5.5
21:25:25 [gateway] ready (0 plugins, 11.0s)
21:25:25 [gateway] log file: D:\Caelan.openclaw\logs\openclaw.log
21:25:25 [gateway] starting channels and sidecars...
21:25:26 [hooks:loader] Registered hook: boot-md -> gateway:startup
21:25:26 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
21:25:26 [hooks:loader] Registered hook: command-logger -> command
21:25:26 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
21:25:26 [hooks] loaded 4 internal hook handlers

silk mothBOT Apr 28, 2026, 3:32 AM

#

Yep — that’s the channel-start hang. The hooks are just the last visible line.

At this point I’d make a dashboard-only working config and skip Discord for the moment, so you can at least use Control UI while we preserve the broken config for later analysis.

Kill this run, then:

$json = Get-Content D:\Caelan\openclaw-rescue-discord.json -Raw | ConvertFrom-Json
$json.channels.discord.enabled = $false
$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-dashboard.json

Run it with channels skipped just to avoid the hang entirely:

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"

#

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-dashboard.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

openclaw gateway run --verbose

Then open dashboard:

openclaw dashboard

For Discord specifically, we’ve now got enough evidence for a bug report: native Windows 2026.4.25, plugins disabled, Discord-only channel startup hangs after internal hooks before sidecars.channels completes. You should file that with the startup trace and config shape, but redact token: https://github.com/openclaw/openclaw/issues

tribal arch Apr 28, 2026, 3:35 AM

#

do you think it's about that i might've shown my Token somewhere and that's why? or is it about the extra bot? Or just a bug with some other part of it?

silk mothBOT Apr 28, 2026, 3:36 AM

#

My read:

Exposed token? Possible security risk, but probably not the direct cause of this hang. A leaked/duplicated Discord bot token usually causes reconnect loops, login failures, or another process “stealing” the session — not a silent hang before sidecars.channels logs anything.
Extra bot / second agent? Very plausible. If the config got into a weird multi-bot/multi-agent state, or if there’s a stale account/service from that experiment, that fits the channel startup hang much better.
OpenClaw bug / Windows regression? Also plausible. We’ve seen clear evidence that 2026.4.25 on native Windows is struggling around plugin runtime deps/bootstrap, and now channel startup. So I wouldn’t blame you or your setup entirely.

Security-wise, if you think you pasted the Discord bot token anywhere public, rotate it anyway once the system is stable:
Discord Developer Portal → your app → Bot → Reset Token → update OpenClaw config. That’s separate from the startup debugging.

For now, I’d get dashboard working with Discord disabled/skipped, then file a GitHub issue with:

Windows native
2026.4.25
D-drive install/state
startup hangs after hooks loaded 4 internal hook handlers
Discord-only rescue config triggers it

#

plugins disabled starts core gateway fine
OPENCLAW_SKIP_CHANNELS=1 starts fine

That’s a pretty strong repro.

tribal arch Apr 28, 2026, 3:38 AM

#

meanwhile the dasboard is taking forever to load which is like this weekend. it just wouldn't load sometimes and when it finally did the connection was bad (not my internet, mind you, just with openclaw and whatever)

silk mothBOT Apr 28, 2026, 3:38 AM

#

Yeah, that tracks. If the gateway is half-stuck in startup/sidecars, the dashboard can load painfully or fail because the WebSocket/RPC side is busy or not fully ready. It’s not your internet — it’s local 127.0.0.1.

Don’t use the Discord test run for dashboard. Kill it and start the dashboard-only rescue with channels skipped:

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'openclaw' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

$json = Get-Content D:\Caelan\openclaw-rescue-discord.json -Raw | ConvertFrom-Json
$json.channels.discord.enabled = $false
$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-dashboard.json

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-dashboard.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

#

openclaw gateway run --verbose

Wait for sidecars.ready, then open:

openclaw dashboard

If dashboard is still slow after sidecars.ready, try a fresh browser/private window to avoid stale cached token/device state.

tribal arch Apr 28, 2026, 3:39 AM

#

i mean i'm pretty sure that's what i'm running right now

silk mothBOT Apr 28, 2026, 3:39 AM

#

You might be — but the last run you showed was the Discord-enabled rescue, and it hung before sidecars.channels. That state will make dashboard flaky.

Let’s verify what’s actually running instead of guessing. In a second PowerShell:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw" } |
  Select-Object ProcessId,CommandLine

And check the current shell env:

Get-ChildItem Env:OPENCLAW*

What we want to see for dashboard-only is:

#

OPENCLAW_CONFIG_PATH = D:\Caelan\openclaw-rescue-dashboard.json
OPENCLAW_SKIP_CHANNELS = 1
OPENCLAW_SKIP_PROVIDERS = 1

If OPENCLAW_CONFIG_PATH is openclaw-rescue-discord.json, or the skip vars are missing, then it’s not the dashboard-only run.

tribal arch Apr 28, 2026, 3:41 AM

#

ProcessId CommandLine

36060 "D:\node.exe" D:\Caelan\npm-global/node_modules/openclaw/openclaw.mjs gateway run --verbose

Name Value

OPENCLAW_STATE_DIR D:\Caelan.openclaw

silk mothBOT Apr 28, 2026, 3:41 AM

#

Yep — that confirms it’s not running the dashboard-only rescue. It’s using the real config path by default because OPENCLAW_CONFIG_PATH and skip vars aren’t set.

Kill that process and start the known-good dashboard-only run:

Stop-Process -Id 36060 -Force

$json = Get-Content D:\Caelan\openclaw-rescue-discord.json -Raw | ConvertFrom-Json
$json.channels.discord.enabled = $false
$json | ConvertTo-Json -Depth 100 | Set-Content D:\Caelan\openclaw-rescue-dashboard.json

$env:OPENCLAW_STATE_DIR="D:\Caelan\.openclaw"
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-dashboard.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

#

openclaw gateway run --verbose

Then verify before opening dashboard:

Get-ChildItem Env:OPENCLAW*

You should see all three: STATE_DIR, CONFIG_PATH, SKIP_CHANNELS, SKIP_PROVIDERS.

tribal arch Apr 28, 2026, 3:57 AM

#

ok i guess the command i'm putting in that you're giving me just isn't working right cause it still is hanging and says this:
PS D:\Caelan.openclaw\workspace> Get-ChildItem Env:OPENCLAW*

Name Value

OPENCLAW_STATE_DIR D:\Caelan.openclaw

silk mothBOT Apr 28, 2026, 3:58 AM

#

Yep, the env vars aren’t sticking in that PowerShell window. Let’s avoid env vars entirely and use inline env for the one command.

First kill the hanging gateway:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

Then run this single block exactly:

cmd /c "set OPENCLAW_STATE_DIR=D:\Caelan\.openclaw&& set OPENCLAW_CONFIG_PATH=D:\Caelan\openclaw-rescue-dashboard.json&& set OPENCLAW_SKIP_CHANNELS=1&& set OPENCLAW_SKIP_PROVIDERS=1&& openclaw gateway run --verbose"

That forces the env vars only for that gateway process, even if PowerShell isn’t keeping them.

#

If it starts correctly, the log should say config path is D:\Caelan\openclaw-rescue-dashboard.json when you run status/dashboard from a similarly wrapped command later.

rotund mulchBOT Apr 28, 2026, 4:05 AM

#

tribal arch Apr 28, 2026, 4:18 AM

#

stuck here again after doing that one:
21:58:42 [gateway] loading configuration…
21:58:44 [gateway] resolving authentication…
21:58:44 [gateway] starting...
21:58:54 [gateway] starting HTTP server...
21:58:54 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)
21:58:54 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
21:58:55 [gateway] agent model: openai-codex/gpt-5.5
21:58:55 [gateway] ready (0 plugins, 11.2s)
21:58:55 [gateway] log file: D:\Caelan.openclaw\logs\openclaw.log
21:58:55 [gateway] starting channels and sidecars...
21:58:56 [hooks:loader] Registered hook: boot-md -> gateway:startup
21:58:56 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
21:58:56 [hooks:loader] Registered hook: command-logger -> command
21:58:56 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
21:58:56 [hooks] loaded 4 internal hook handlers
21:58:56 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
21:58:56 [heartbeat] started

silk mothBOT Apr 28, 2026, 4:18 AM

#

That log actually found the issue: the gateway is not hung — it’s intentionally skipping channel startup:

skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)

So your assistant won’t fully connect to Discord/Telegram/etc until that env var is removed.

In PowerShell, run:

echo $env:OPENCLAW_SKIP_CHANNELS
echo $env:OPENCLAW_SKIP_PROVIDERS

Remove-Item Env:\OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:\OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue

Then check/remove persistent Windows env vars too:

#

[Environment]::GetEnvironmentVariable("OPENCLAW_SKIP_CHANNELS","User")
[Environment]::GetEnvironmentVariable("OPENCLAW_SKIP_PROVIDERS","User")

[Environment]::SetEnvironmentVariable("OPENCLAW_SKIP_CHANNELS",$null,"User")
[Environment]::SetEnvironmentVariable("OPENCLAW_SKIP_PROVIDERS",$null,"User")

Close that terminal, open a fresh one, then restart:

openclaw gateway restart

Also paste:

#

openclaw --version
openclaw status --all

If it gets slow again after removing those vars, then the real hang is likely during channel/provider startup — but right now we’re still in the “debug env var is blocking channels” state. Docs for the general triage flow: https://docs.openclaw.ai/help/faq 🦐

tribal arch Apr 28, 2026, 4:20 AM

#

What??? Are you losing memory about what we've talked about? You're the one who told me to remove Discord because you thought it was the problem

silk mothBOT Apr 28, 2026, 4:21 AM

#

You’re right — I screwed that up. I saw the last log in isolation and treated the skip vars like a mistake. In this thread’s actual context, those skip vars were the rescue mode I told you to use.

So correction:

OPENCLAW_SKIP_CHANNELS=1 / OPENCLAW_SKIP_PROVIDERS=1 means: dashboard/core gateway only, no Discord
That log is therefore expected for the dashboard-only rescue.
It is not the Discord test, and your Discord agent will not reply in that mode.

Right now, if your goal is “get Control UI/dashboard usable,” leave it running and try:

openclaw dashboard

If your goal is “test whether Discord is the hang,” then use the Discord rescue config without skip vars:

#

Remove-Item Env:\OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:\OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-discord.json"
openclaw gateway run --verbose

If that one hangs after the hook lines again, then yeah: that confirms the Discord/channel startup path is the broken part.

Sorry — that was confusing as hell, and you were right to call it out.

tribal arch Apr 28, 2026, 4:22 AM

#

we already tested the discord thing and you said it was the hang

silk mothBOT Apr 28, 2026, 4:22 AM

#

Yes. You’re right. We already tested it and the conclusion was:

Discord/channel startup is the hang.

So the OPENCLAW_SKIP_CHANNELS=1 state is intentional rescue mode, not something to undo right now. I misread the newest log without holding the earlier steps in mind — that’s on me.

Current state:

Gateway core starts ✅
Hooks load ✅
Heartbeat starts ✅
Channels are skipped ✅ expected in rescue mode
Discord is still the suspected/confirmed hang path ❌

So don’t remove the skip vars unless we are deliberately re-testing Discord.

Next best step: use this rescue mode to get Control UI/dashboard working first:

#

openclaw dashboard

Then once you’re in, we can treat Discord as the separate broken channel and stop thrashing the whole gateway around it.

tribal arch Apr 28, 2026, 4:23 AM

#

the dashboard is refusing to load

silk mothBOT Apr 28, 2026, 4:23 AM

#

Yep — if dashboard won’t load even in channel-skip rescue mode, that’s now a separate problem from Discord.

Most likely gotcha: openclaw dashboard may be reading your default config, while the running gateway is using the rescue config. Use the same env vars in the same PowerShell session:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

openclaw gateway status
openclaw dashboard --no-open

Then copy/open the exact URL it prints.

If that still refuses, paste the exact failure type:

#

browser says site can’t be reached / connection refused
Control UI opens but says unauthorized
Control UI opens but says offline / reconnecting
blank page / spinning forever

Also run:

openclaw health --verbose
openclaw status --all

Don’t re-test Discord yet. First we need to prove the gateway’s local HTTP/Control UI path works.

tribal arch Apr 28, 2026, 4:25 AM

#

Service: Scheduled Task (registered)
File logs: D:\Caelan.openclaw\logs\openclaw.log
Command: D:\node.exe D:\Caelan\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: D:\Caelan.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=D:\Caelan.openclaw OPENCLAW_GATEWAY_PORT=18789

Config (cli): D:\Caelan\openclaw-rescue-noplugins.json
Config (service): D:\Caelan\openclaw-rescue-noplugins.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 (pid 37500, state Disabled, last run 1, last run time 4/26/2026 3:15:16 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 37500: "node" "D:\Caelan\npm-global\node_modules\openclaw\openclaw.mjs" gateway run --verbose (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

silk mothBOT Apr 28, 2026, 4:25 AM

#

This is the important bit:

listener detected on port 18789
Connectivity probe: timeout
Port already in use by pid 37500: openclaw.mjs gateway run --verbose

So the gateway process is listening but wedged/unresponsive. That also explains the dashboard refusing to load. And it’s not the Scheduled Task instance — it’s the foreground gateway run --verbose process holding the port.

Kill that specific stuck process, then start exactly one rescue gateway:

Stop-Process -Id 37500 -Force
Start-Sleep 2
Get-NetTCPConnection -LocalPort 18789 -ErrorAction SilentlyContinue

If that last command prints nothing, port is clear. Then:

#

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

openclaw gateway run --verbose

Do not run openclaw gateway restart yet — the scheduled task state is weird/disabled and I don’t want two launch paths fighting.

If it reaches ready, open a second PowerShell and run:

openclaw gateway status --deep
openclaw dashboard --no-open

#

If the probe still times out immediately after a clean start with no plugins/channels, then Discord is not the only problem — the core gateway event loop is getting stuck.

tribal arch Apr 28, 2026, 4:31 AM

#

[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: D:\Caelan\openclaw-rescue-noplugins.json
Bind: loopback
at Timeout.<anonymous> (file:///D:/Caelan/npm-global/node_modules/openclaw/dist/call-DkJ_z7yy.js:284:9)
at listOnTimeout (node:internal/timers:605:17)
at process.processTimers (node:internal/timers:541:7)

silk mothBOT Apr 28, 2026, 4:32 AM

#

Got it. That error means the CLI is timing out while trying to talk to the already-running gateway. So dashboard/status aren’t the source of truth right now — they’re symptoms.

We need one lower-level check: is HTTP responding at all, or is only the WebSocket/RPC path wedged?

In a second PowerShell, run these while the rescue gateway is running:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest http://127.0.0.1:18789/readyz -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest http://127.0.0.1:18789/ -UseBasicParsing -TimeoutSec 5

Then paste the results/errors plus the last logs:

Get-Content D:\Caelan\.openclaw\logs\openclaw.log -Tail 120

#

Interpretation:

If /healthz also times out → the core gateway process is wedged after binding the port.
If /healthz works but CLI/dashboard time out → HTTP is alive, but the Gateway WebSocket/RPC path is stuck.
If / works but dashboard is blank/offline → browser/UI auth or JS layer.

Either way, we’re no longer at “Discord alone is hanging” — rescue mode with no channels/plugins should answer these probes quickly.

tribal arch Apr 28, 2026, 4:36 AM

#

PS D:\Caelan.openclaw\workspace> Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest : The operation has timed out.
At line:1 char:1

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -Ti ...

  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
 eption
  + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS D:\Caelan.openclaw\workspace> Invoke-WebRequest http://127.0.0.1:18789/readyz -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest : The operation has timed out.
At line:1 char:1

Invoke-WebRequest http://127.0.0.1:18789/readyz -UseBasicParsing -Tim ...

  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
 eption
  + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS D:\Caelan.openclaw\workspace> Invoke-WebRequest http://127.0.0.1:18789/ -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest : The operation has timed out.
At line:1 char:1

Invoke-WebRequest http://127.0.0.1:18789/ -UseBasicParsing -TimeoutSe ...

  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
 eption
  + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

silk mothBOT Apr 28, 2026, 4:37 AM

#

That proves it: the core HTTP server is wedged.

/healthz is intentionally the simplest probe. If that times out, this is not a dashboard auth problem, and not just “Discord is hanging.” The process bound the port, then stopped servicing requests.

Next isolation step: disable the remaining internal hooks in the rescue config. Those are still loading in your “no plugins/no channels” run.

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"

openclaw hooks disable boot-md
openclaw hooks disable bootstrap-extra-files
openclaw hooks disable command-logger
openclaw hooks disable session-memory

Then kill the wedged listener and start clean:

#

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }

$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway run --verbose

In another PowerShell, test only:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

If that still times out with channels + plugins + hooks disabled, this is likely a core gateway/runtime bug or bad install state, not your Discord config. Please also paste:

#

openclaw --version
Get-Content D:\Caelan\.openclaw\logs\openclaw.log -Tail 120

tribal arch Apr 28, 2026, 5:07 AM

#

SO this first one didn't even work:

PS D:\Caelan.openclaw\workspace> openclaw hooks disable boot-md

🦞 OpenClaw 2026.4.25 (aa36ee6) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

22:43:37 [channels] failed to load bundled channel qqbot: Timed out waiting for bundled runtime deps lock at D:\Caelan.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e.openclaw-runtime-deps.lock (waited=300071ms, ownerFile=ok, ownerFileSymlink=false, pid=2376 alive=true, ownerAge=24984925ms, ownerFileAge=24983018ms, lockAge=24985058ms, ownerFilePath=D:\Caelan.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e.openclaw-runtime-deps.lock\owner.json). If no OpenClaw/npm install is running, remove the lock directory and retry. | EEXIST: file already exists, mkdir 'D:\Caelan.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e.openclaw-runtime-deps.lock'

silk mothBOT Apr 28, 2026, 5:08 AM

#

Ah — this is the smoking gun. Stop the hooks path for now.

Your CLI isn’t failing because of boot-md; it’s blocking on bundled plugin runtime deps:

qqbot ... Timed out waiting for bundled runtime deps lock ... pid=2376 alive=true

So even basic CLI commands are getting stuck trying to load/stage plugin deps. This matches the .25 runtime-deps lock/staging mess we’ve seen.

Do this first:

Get-CimInstance Win32_Process -Filter "ProcessId=2376" |
  Select-Object ProcessId,Name,ExecutablePath,CommandLine

If that command line is openclaw, node, or npm related, kill it:

#

Stop-Process -Id 2376 -Force

Also kill the gateway listener if still present:

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }

Then rename the stuck lock dir — don’t delete it:

$lock = "D:\Caelan\.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e\.openclaw-runtime-deps.lock"
if (Test-Path $lock) {

#

  Rename-Item -LiteralPath $lock -NewName (".openclaw-runtime-deps.lock.stuck-" + (Get-Date -Format "yyyyMMddHHmmss"))
}

Then try the rescue gateway again:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway run --verbose

If /healthz still times out after this, we’ve got a strong case for a 2026.4.25 plugin-runtime-deps regression and should move this to a GitHub issue with that exact lock error: https://github.com/openclaw/openclaw/issues

tribal arch Apr 28, 2026, 5:10 AM

#

wait the first thing says this:

ProcessId Name ExecutablePath CommandLine

 2376 svchost.exe

silk mothBOT Apr 28, 2026, 5:10 AM

#

Good catch — do not kill that. svchost.exe is Windows service host, not the OpenClaw/npm owner we expected.

That means the lock’s owner.json has a stale/wrong PID collision: PID 2376 exists now, but it’s unrelated. So just move the stale lock directory.

First stop only OpenClaw/node listeners:

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) {
  Get-CimInstance Win32_Process -Filter "ProcessId=$gwPid" |
    Select-Object ProcessId,Name,ExecutablePath,CommandLine
}

If that shown process is node/openclaw, then:

#

Stop-Process -Id $gwPid -Force

Now rename the stale lock:

$lock = "D:\Caelan\.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e\.openclaw-runtime-deps.lock"
if (Test-Path $lock) {
  Rename-Item -LiteralPath $lock -NewName (".openclaw-runtime-deps.lock.stuck-" + (Get-Date -Format "yyyyMMddHHmmss"))
}

Then retry. If it creates a new lock and hangs again, the runtime-deps installer itself is stuck; if it moves past this, we found a stale lock poisoning every CLI/gateway start.

tribal arch Apr 28, 2026, 5:11 AM

#

wait i'm starting the gateway again after that?

silk mothBOT Apr 28, 2026, 5:11 AM

#

Yes — but only after the lock directory is renamed and the port is clear.

Use the rescue start, not the service/restart path:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

openclaw gateway run --verbose

Leave that PowerShell window open.

Then in a second PowerShell:

#

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

If /healthz responds, we finally have a working core gateway again. If it times out or you see another runtime-deps lock message, paste that.

rotund mulchBOT Apr 28, 2026, 5:12 AM

#

tribal arch Apr 28, 2026, 5:36 AM

#

healthz timed out again

silk mothBOT Apr 28, 2026, 5:37 AM

#

Okay — then we’re past “dashboard issue.” Core gateway is still wedging.

Given that openclaw hooks disable hit the qqbot runtime-deps lock, next rescue test is: disable bundled plugins entirely so it can’t touch that runtime-deps path.

Stop the current listener, then start with this extra env var:

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw gateway run --verbose

#

Then in a second PowerShell:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

If this works, the culprit is the 2026.4.25 bundled plugin runtime-deps path, not your config.

If it still times out even with OPENCLAW_DISABLE_BUNDLED_PLUGINS=1, paste the last ~80 log lines — at that point it’s a core startup wedge.

tribal arch Apr 28, 2026, 5:46 AM

#

It worked!

PS D:\Caelan.openclaw\workspace> Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

StatusCode : 200
StatusDescription : OK
Content : {"ok":true,"status":"live"}
RawContent : HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Connection: keep-alive
Keep-Alive: timeout=5
Content...
Forms :
Headers : {[X-Content-Type-Options, nosniff], [Referrer-Policy, no-referrer], [Permissions-Policy,
camera=(), microphone=(self), geolocation=()], [Connection, keep-alive]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml :
RawContentLength : 27

silk mothBOT Apr 28, 2026, 5:46 AM

#

YES. Okay, we have the culprit now. 🎉

This confirms the gateway core is fine when bundled plugins are disabled. The hang is in the 2026.4.25 bundled plugin runtime-deps/staging path — probably the same thing that produced the qqbot ... .openclaw-runtime-deps.lock timeout.

Next, keep this rescue gateway running and test dashboard:

openclaw dashboard --no-open

Open/copy the URL it prints.

For now, your “safe rescue env” is:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"

#

$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

That gets core/dashboard back. It will not bring Discord back yet.

For a durable fix, I’d file a GitHub issue with these exact facts:

OpenClaw 2026.4.25 (aa36ee6) on Windows
/healthz times out with normal bundled plugins
openclaw hooks disable boot-md blocks on qqbot runtime deps lock
OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 makes /healthz return {"ok":true,"status":"live"}
stale lock path: D:\Caelan\.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e\.openclaw-runtime-deps.lock

Issue tracker: https://github.com/openclaw/openclaw/issues

tribal arch Apr 28, 2026, 5:50 AM

#

yeah well in the dashboard he's just stuck in loops of trying to find a fallback model 🙁 none of them are working, even free ones 🙁

silk mothBOT Apr 28, 2026, 5:51 AM

#

Yeah 🙁 — that part is expected with the exact rescue flag that made /healthz work:

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1

That proves the runtime-deps/plugin path is the hang, but it also means some provider/model plugins may be unavailable, so the agent can get stuck falling through fallbacks. Rescue mode got us dashboard/core, not a usable full assistant yet.

Next move: make the disable more targeted. Since the actual lock error named qqbot, try disabling just that plugin/channel in the rescue config, then start without OPENCLAW_DISABLE_BUNDLED_PLUGINS.

In PowerShell:

$cfg = "D:\Caelan\openclaw-rescue-noplugins.json"
Copy-Item $cfg "$cfg.bak-$(Get-Date -Format yyyyMMddHHmmss)"

$json = Get-Content $cfg -Raw | ConvertFrom-Json

#

if (-not $json.plugins) {
  $json | Add-Member -NotePropertyName plugins -NotePropertyValue ([pscustomobject]@{})
}
if (-not $json.plugins.entries) {
  $json.plugins | Add-Member -NotePropertyName entries -NotePropertyValue ([pscustomobject]@{})
}
if (-not $json.plugins.entries.qqbot) {
  $json.plugins.entries | Add-Member -NotePropertyName qqbot -NotePropertyValue ([pscustomobject]@{})
}
$json.plugins.entries.qqbot | Add-Member -NotePropertyName enabled -NotePropertyValue $false -Force

if (-not $json.channels) {
  $json | Add-Member -NotePropertyName channels -NotePropertyValue ([pscustomobject]@{})
}
if (-not $json.channels.qqbot) {

#

  $json.channels | Add-Member -NotePropertyName qqbot -NotePropertyValue ([pscustomobject]@{})
}
$json.channels.qqbot | Add-Member -NotePropertyName enabled -NotePropertyValue $false -Force

$json | ConvertTo-Json -Depth 100 | Set-Content $cfg -Encoding UTF8

Then restart the rescue gateway without the bundled-plugin kill switch:

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"

#

$env:OPENCLAW_SKIP_PROVIDERS="1"
Remove-Item Env:\OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue

openclaw gateway run --verbose

Then test:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

If it hangs on a different plugin name next, paste that line. We’ll disable only the bad plugin(s), not the whole bundled plugin system.

tribal arch Apr 28, 2026, 6:03 AM

#

It's been here for five minutes. it might still have a chance to keep going. but healthz timed out
23:57:45 [gateway] loading configuration…
23:57:47 [gateway] resolving authentication…
23:57:47 [gateway] starting...
23:58:30 [gateway] starting HTTP server...
23:58:30 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root D:\Caelan.openclaw\canvas)
23:58:30 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:58:31 [gateway] agent model: openai-codex/gpt-5.5
23:58:31 [gateway] ready (0 plugins, 44.2s)
23:58:31 [gateway] log file: D:\Caelan.openclaw\logs\openclaw.log
23:58:32 [gateway] starting channels and sidecars...
23:58:32 [gateway] removed stale session lock: D:\Caelan.openclaw\agents\main\sessions\0dd3681b-d1e4-48c5-818b-d45258b909fc.jsonl.lock (dead-pid)
23:58:32 [gateway] removed stale session lock: D:\Caelan.openclaw\agents\main\sessions\ceccad72-54c4-4ad6-a03e-816f210749b4.jsonl.lock (dead-pid)
23:58:33 [hooks:loader] Registered hook: boot-md -> gateway:startup
23:58:33 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
23:58:33 [hooks:loader] Registered hook: command-logger -> command
23:58:33 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
23:58:33 [hooks] loaded 4 internal hook handlers
23:58:33 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
23:58:33 [heartbeat] started

silk mothBOT Apr 28, 2026, 6:04 AM

#

Don’t wait on that one — if /healthz times out after 5 minutes, that process is wedged again.

The only combination we’ve proven healthy is:

$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

So go back to that for now. The targeted qqbot disable wasn’t enough.

For the model fallback loop: that’s probably because rescue mode is now core-only, and your configured primary is:

openai-codex/gpt-5.5

…but with bundled plugins disabled, that provider path may not be usable. Also “free” models in the picker aren’t necessarily usable unless their provider/auth path is actually configured.

#

Do this next in a second PowerShell while the working rescue gateway is running:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw models status

Paste the Missing auth / Primary / Fallbacks part only — no tokens.

Also: if you have one known paid API key provider configured, use that for the rescue model. Right now don’t chase random “free” fallbacks; we need one boring known-good model/auth path to prove the agent can answer in dashboard.

tribal arch Apr 28, 2026, 6:05 AM

#

wait can you tell me how to get back on teh rescue one

silk mothBOT Apr 28, 2026, 6:05 AM

#

Yep. Do this exactly.

1) Stop whatever is currently holding the gateway port:

$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }
Start-Sleep 2

2) Start the working rescue gateway:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"

#

$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw gateway run --verbose

Leave that window open.

3) In a second PowerShell, confirm it’s alive:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

You want:

#

StatusCode : 200
Content    : {"ok":true,"status":"live"}

That’s the rescue mode that worked.

tribal arch Apr 28, 2026, 6:14 AM

#

yes that's working

silk mothBOT Apr 28, 2026, 6:14 AM

#

Good. Leave that rescue gateway running.

Now let’s fix the “fallback model loop” from the second PowerShell:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw models status

Paste the parts for:

Primary
Fallbacks

#

Missing auth
any auth/provider warnings

No tokens/API keys. Once we see which provider is actually usable in rescue mode, we’ll set one stable model instead of letting it spin through fallbacks.

tribal arch Apr 28, 2026, 6:17 AM

#

Config warnings:

plugins.entries.qqbot: plugin not found: qqbot (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.25 (aa36ee6) — Self-hosted, self-updating, self-aware (just kidding... unless?).

Config warnings:

plugins.entries.qqbot: plugin not found: qqbot (stale config entry ignored; remove it from plugins config)
Config : D:\Caelan\openclaw-rescue-noplugins.json
Agent dir : D:\Caelan.openclaw\agents\main\agent
Default : openai-codex/gpt-5.5
Fallbacks (21): openai-codex/gpt-5.5, openai/gpt-5.4, openai-codex/gpt-5.4, google/gemini-2.5-flash, openai-codex/gpt-5.1-codex-max, openrouter/arcee-ai/trinity-large-preview:free, openrouter/auto, openrouter/free, openrouter/z-ai/glm-4.7, openrouter/z-ai/glm-4.5-air:free, google/gemini-3.1-pro-preview, openrouter/google/gemini-3.1-pro-preview, google/gemini-3-flash-preview, openrouter/moonshotai/kimi-k2-thinking, google/gemini-3-pro-preview, openai/gpt-5.4-pro, openai/gpt-5.4, openai/gpt-5.5, openai/gpt-4o-2024-11-20, openai/gpt-4.1, openrouter/google/gemini-3-flash-preview
Image model : openrouter/auto
Image fallbacks (2): google-antigravity/gemini-2.5-flash, google-antigravity/gemini-3-flash-preview
Aliases (6) : wren-venice -> openrouter/cognitivecomputations/dolphin-mistral-24b-venice-edition:free, OpenRouter -> openrouter/auto, gemini -> google/gemini-3.1-pro-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview, gemini-flash -> google/gemini-3-flash-preview, gpt -> openai/gpt-5.4

#

Configured models (22): openrouter/google/gemini-3-pro-preview, google/gemini-2.5-flash, openai-codex/gpt-5.1-codex-max, openrouter/arcee-ai/trinity-large-preview:free, openrouter/cognitivecomputations/dolphin-mistral-24b-venice-edition:free, openrouter/auto, openrouter/free, openrouter/z-ai/glm-4.7, openrouter/z-ai/glm-4.5-air:free, google/gemini-3.1-pro-preview, google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview, openrouter/google/gemini-3.1-pro-preview, openrouter/moonshotai/kimi-k2-thinking, openai-codex/gpt-5.5, openai-codex/gpt-5.4, openai-codex/gpt-5.1, openai/gpt-5.4-pro, openai/gpt-5.4, openai/gpt-5.5, openai/gpt-4o-2024-11-20, openai/gpt-4.1

#

Auth overview
Auth store : D:\Caelan.openclaw\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): google-antigravity (1), openai-codex (2)

google effective=profiles:D:\Caelan.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google=redacted | models.json=redacted | source=models.json: D:\Caelan.openclaw\agents\main\agent\models.json
google-antigravity effective=profiles:D:\Caelan.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | google-antigravity:lindsay.caldwell729@gmail.com=OAuth (lindsay.caldwell729@gmail.com)
openai effective=env:redacted | env=redacted | source=env: OPENAI_API_KEY
openai-codex effective=profiles:D:\Caelan.openclaw\agents\main\agent\auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:default=OAuth, openai-codex:lindsay.caldwell729@gmail.com=OAuth (lindsay.caldwell729@gmail.com)
openrouter effective=profiles:D:\Caelan.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=redacted | models.json=OPENROUT..._API_KEY | source=models.json: D:\Caelan.openclaw\agents\main\agent\models.json

OAuth/token status

google-antigravity
- google-antigravity:lindsay.caldwell729@gmail.com (lindsay.caldwell729@gmail.com) expired expires in 0m
openai-codex
- openai-codex:default expired expires in 0m
- openai-codex:lindsay.caldwell729@gmail.com (lindsay.caldwell729@gmail.com) ok expires in 4d

silk mothBOT Apr 28, 2026, 6:18 AM

#

Yep — that output explains the loop.

You have 21 fallbacks, but that list does not prove any of them can actually run. “Free” OpenRouter models still need an OpenRouter API key for inference/probing.

Next step: find one actually-working model, then stop the fallback roulette.

In the second PowerShell, run:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw models status --probe

#

Paste only the probe/auth result lines — no keys.

If one provider shows working/ok, then we’ll do:

openclaw models set <that-working-provider/model>
openclaw models fallbacks clear

Also: the qqbot warning is from the stale entry I had you add while isolating the plugin issue. It’s harmless in rescue mode, but we can clean it later. Right now the priority is: one working model, zero fallback loop.

#

That’s only the configured list, not the probe result. The useful bit should say things like auth/probe/ok/missing/failed.

Can you run this narrower command and paste the whole output except any secrets?

openclaw models status --probe --json

If that’s too huge, try:

openclaw models status --probe | Select-String -Pattern "ok|ready|missing|failed|expired|auth|probe|openai|openrouter|google|codex"

What I’m looking for is: which provider actually has valid auth in this rescue mode. The model list alone can include unavailable models.

#

Okay, this is actually good news: you do have usable auth paths.

The obvious bad one is:

google-antigravity ... expired
openai-codex:default expired

So stop letting it spin through 21 fallbacks. For rescue mode, set one boring API-key model and clear fallbacks:

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

#


openclaw models set openai/gpt-4.1
openclaw models fallbacks clear

Then in dashboard, start a new chat/session and try a tiny message like “say hi”.

Why openai/gpt-4.1? Your output shows openai has an API key, and API-key OpenAI is the least weird path here. Once he answers, we can upgrade the model later. Right now we just need one stable working brain instead of fallback roulette.

rotund mulchBOT Apr 28, 2026, 6:27 AM

#

tribal arch Apr 28, 2026, 6:29 AM

#

would be nice to get a summary for the next one at least 🙁

silk mothBOT Apr 28, 2026, 6:29 AM

#

Absolutely — and yeah, this thread has been a lot. Here’s a clean handoff summary you can paste into a new thread:

OpenClaw 2026.4.25 (aa36ee6) on native Windows, config at:
D:\Caelan\openclaw-rescue-noplugins.json
state/logs under:
D:\Caelan\.openclaw\

Original issue: gateway extremely slow / dashboard and Discord unusable. Rolling back to 2026.4.23 did not fully help; trying 2026.4.25 showed severe hangs.

Key findings:
1. Normal gateway/service would bind port 18789 but local probes timed out.
   - `openclaw gateway status` showed listener on `127.0.0.1:18789`
   - `Invoke-WebRequest http://127.0.0.1:18789/healthz -TimeoutSec 5` timed out
   - Dashboard also refused to load

#

2. Discord/channel startup was initially suspected because gateway reached:
   - `starting channels and sidecars...`
   - hooks loaded
   - then stalled
   But later testing showed the problem was broader than Discord.

3. Rescue mode with channels/providers skipped:
   ```powershell
   $env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
   $env:OPENCLAW_SKIP_CHANNELS="1"
   $env:OPENCLAW_SKIP_PROVIDERS="1"

still resulted in /healthz timeouts unless bundled plugins were disabled too.

Important smoking gun:

#

   Running `openclaw hooks disable boot-md` blocked for ~5 minutes with:
   `failed to load bundled channel qqbot: Timed out waiting for bundled runtime deps lock`
   lock path:
   `D:\Caelan\.openclaw\plugin-runtime-deps\openclaw-2026.4.25-eb7d6f0fe52e\.openclaw-runtime-deps.lock`
   owner PID in lock was `2376`, but Windows showed PID 2376 was `svchost.exe`, so it looked like a stale/wrong PID collision.

5. Renaming the stale lock alone did not fix the gateway. The working rescue combination was:
   ```powershell
   $env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
   $env:OPENCLAW_SKIP_CHANNELS="1"
   $env:OPENCLAW_SKIP_PROVIDERS="1"
   $env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"
   openclaw gateway run --verbose

With that, /healthz returned:

#

   `{"ok":true,"status":"live"}`

Conclusion:
Core gateway works only when bundled plugins are disabled. Strong suspicion: 2026.4.25 bundled plugin runtime-deps/staging/lock regression on Windows, not just Discord.

Current rescue restart steps:
```powershell
$gwPid = (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue).OwningProcess | Select-Object -First 1
if ($gwPid) { Stop-Process -Id $gwPid -Force }

$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw gateway run --verbose

#


Then verify:
```powershell
Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5

Model situation:

Dashboard loads in rescue mode, but agent got stuck looping through fallbacks.
openclaw models status showed:
- Default: openai-codex/gpt-5.5
- 21 fallbacks configured
- google-antigravity OAuth expired
- openai-codex:default expired
- openai-codex:lindsay... ok, expires in 4d
- openai has env API key from OPENAI_API_KEY

#

  - `openrouter` has API key
- Suggested rescue model fix:
```powershell
$env:OPENCLAW_CONFIG_PATH="D:\Caelan\openclaw-rescue-noplugins.json"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"

openclaw models set openai/gpt-4.1
openclaw models fallbacks clear

Then start a new dashboard chat and test “say hi”.

Known cleanup:

There is now a stale warning:

#

  `plugins.entries.qqbot: plugin not found: qqbot`
  This came from an attempted targeted isolation step and can be cleaned later. It is not the main issue.

If this fixed/identified it, please mark the useful solution message so Answer Overflow can index it for the next poor soul who hits this 🙁
Right-click the solution message → Apps → ✅ Mark Solution.

silk mothBOT Apr 29, 2026, 12:39 PM

#

I’m running on Linux here — but for your gateway issue, your OS matters more. If you can share your OS + openclaw --version, that’ll help narrow it down. 🦐

#

Yep — specifically: native Windows PowerShell or WSL2/Ubuntu on Windows?

OpenClaw supports both, but WSL2 is the more stable path for Gateway stuff. If you’re native Windows and the gateway is taking an hour / barely connecting, that’s an important clue.

Please paste:

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

Docs: https://docs.openclaw.ai/platforms/windows
Troubleshooting ladder: https://docs.openclaw.ai/help/troubleshooting

#Gateway barely working, extremely slow