openclaw running slow and chat is not responsive | Friends of the Crustacean 🦞🤝 | Page 1

sudden void Apr 28, 2026, 8:49 PM

#

hello i nuked openclaw, then preloaded my agents (windows) and now the webui is running crazy slow and i can't get my agents to respond to me

novel moatBOT Apr 28, 2026, 8:50 PM

#

First thing: please paste your openclaw --version — version mismatch causes a ton of weird “UI slow / agents don’t answer” issues.

On Windows PowerShell, run and paste:

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

Then, while the Web UI is slow, check Task Manager: is node.exe, OpenClaw, or Chrome/Edge pegging CPU/RAM?

My first suspicion: preloading multiple agents after a fresh nuke may be causing lots of bootstraps/model/tool setup at once, so the Gateway gets saturated and chats don’t respond.

Also try one clean restart:

#

openclaw gateway restart
openclaw logs --follow

Paste the first scary-looking error from the logs, not the whole firehose. Docs triage flow is here too: https://docs.openclaw.ai/help/faq

sudden void Apr 28, 2026, 8:57 PM

#

C:\Users\Eagle3dStreaming>openclaw dashboard

🦞 OpenClaw 2026.4.26 (be8c246) — I can run local, remote, or purely on vibes—results may vary with DNS.

Dashboard URL: http://127.0.0.1:18789/
Token auto-auth included in browser/clipboard URL.
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.

C:\Users\Eagle3dStreaming>openclaw --version
OpenClaw 2026.4.26 (be8c246)

C:\Users\Eagle3dStreaming>openclaw status --all

🦞 OpenClaw 2026.4.26 (be8c246) — Less clicking, more shipping, fewer "where did that file go" moments.

|
O Checking local state…...

its' been here for like 5 minutes

novel moatBOT Apr 28, 2026, 8:59 PM

#

2026.4.26 is current, so this isn’t just “update first.”

status --all hanging at Checking local state… is not normal — hit Ctrl+C and don’t wait on that one. On native Windows that step may be stuck in local process/port inspection.

Please run these instead and paste output:

openclaw gateway status --json
openclaw health --verbose --timeout 5000
openclaw status --json --timeout 3000
openclaw logs --limit 200 --plain

Also try a direct local agent smoke test:

#

openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."

If the logs show lots of agents “bootstrapping” or repeated errors, that’s probably the culprit from preloading after the nuke. Don’t delete anything yet — paste the first real error block and we’ll narrow it down.

sudden void Apr 28, 2026, 9:00 PM

#

it finally finished. i'll share it all bit by bit

novel moatBOT Apr 28, 2026, 9:01 PM

#

Sounds good — paste it in chunks.

Please prioritize these parts first:

Overview section
Agents / sessions section
Any Warnings / Errors / Diagnosis section
The last ~50 lines from:

openclaw logs --limit 50 --plain

Feel free to omit/redact tokens, emails, paths you don’t want public, etc.

sudden void Apr 28, 2026, 9:01 PM

#

OpenClaw status --all

novel moatBOT Apr 28, 2026, 9:01 PM

#

That’s the key bit: the Gateway is timing out. The dashboard can open because the port is serving something, but RPC/WS isn’t responding quickly enough, so agents won’t answer.

Next paste the services/agents/diagnosis sections, but also run these now:

openclaw gateway status --json
openclaw logs --limit 200 --plain

And quick Windows check for the process on the OpenClaw port:

netstat -ano | findstr :18789

If it shows multiple/listening weirdness, paste that too. My current read: either the gateway process is wedged under load, or something in startup/preloaded agents is blocking the event loop hard enough that health checks time out.

sudden void Apr 28, 2026, 9:01 PM

#

Channels
+----------+---------+--------+----------------------------------------------------------------------------------------+
| Channel | Enabled | State | Detail |
+----------+---------+--------+----------------------------------------------------------------------------------------+
+----------+---------+--------+----------------------------------------------------------------------------------------+

novel moatBOT Apr 28, 2026, 9:01 PM

#

Good, that rules out bootstrap storms: 0 bootstrapping and only 1 active. The problem is lower-level: the scheduled-task Gateway is “running” but its own RPC is timing out / self-status unknown.

Next useful bits:

openclaw gateway status --json
openclaw logs --limit 200 --plain

If logs are huge, look especially for lines around startup and anything like timeout, EADDRINUSE, uncaught, plugin, memory, sqlite, vector, or repeated errors.

A safe quick recovery attempt after grabbing logs:

openclaw gateway restart

#

Then wait ~20 seconds and run:

openclaw health --verbose --timeout 5000

If health still times out immediately after restart, we’re likely looking at a Windows/native gateway hang or a bad config/plugin init path rather than agent load.

sudden void Apr 28, 2026, 9:01 PM

#

novel moatBOT Apr 28, 2026, 9:01 PM

#

Agents table looks basically fine. filings had activity 8 minutes ago, so the session exists, but the gateway RPC layer is the suspicious part.

Please paste the Diagnosis section if there is one — especially port usage / last gateway error.

Also, since your only active session is filings, test that one directly:

openclaw agent --local --agent filings --thinking low -m "Reply with exactly FILINGS-OK."

If local agent works but Web UI doesn’t, the model/config is okay and the Gateway/WebSocket path is wedged. If local agent also hangs, it’s agent runtime/config/model/tool startup.

sudden void Apr 28, 2026, 9:01 PM

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
Bind: loopback

✓ Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 9136: "C:\Program Files\nodejs\node.exe" C:\Users\Eagle3dStreaming\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 8 eligible · 0 missing · C:\Users\Eagle3dStreaming.openclaw\workspace
✓ Plugin compatibility (none)
! Channel issues skipped (gateway unreachable)

#

Gateway health:
timeout

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

o

C:\Users\Eagle3dStreaming>

novel moatBOT Apr 28, 2026, 9:02 PM

#

Yep — that confirms it: the Gateway process is alive and holding port 18789, but it’s not responding to RPC. So “port in use” is expected; the bad part is gateway unreachable (timeout) / Gateway self unknown.

Do this in order:

openclaw logs --limit 200 --plain
openclaw gateway restart
openclaw health --verbose --timeout 5000

If it still times out after restart, force-clear only that wedged OpenClaw gateway process:

openclaw gateway stop
Get-CimInstance Win32_Process -Filter "ProcessId=9136" | Select-Object ProcessId,CommandLine
taskkill /PID 9136 /T /F

#

openclaw gateway start
openclaw health --verbose --timeout 5000

Only run the taskkill if that Get-CimInstance line still shows the OpenClaw gateway command. If the PID changed, don’t reuse 9136; grab the new PID from netstat/status.

Docs note: “Scheduled Task running” is just Windows supervisor state; the health/connectivity probe is the real test. https://docs.openclaw.ai/gateway

#

Health timing out seals it. The Gateway is wedged, not merely slow UI.

Please grab logs before killing it if possible:

openclaw logs --limit 200 --plain

If openclaw logs also times out, use the local log files directly:

Get-ChildItem "$env:USERPROFILE\.openclaw\logs" | Sort-Object LastWriteTime -Descending | Select-Object -First 10 Name,LastWriteTime,Length
Get-Content "$env:USERPROFILE\.openclaw\logs\gateway.log" -Tail 200
Get-Content "$env:USERPROFILE\.openclaw\logs\gateway.err.log" -Tail 200

Then restart/kill the stuck PID as above. If it comes back wedged immediately after restart, paste the log tail — that’ll tell us whether it’s config/plugin/model/session-store related.

sudden void Apr 28, 2026, 9:04 PM

#

C:\Users\Eagle3dStreaming>openclaw gateway stop

🦞 OpenClaw 2026.4.26 (be8c246) — If it works, it's automation; if it breaks, it's a "learning opportunity."

Stopped Scheduled Task: OpenClaw Gateway

C:\Users\Eagle3dStreaming>Get-CimInstance Win32_Process -Filter "ProcessId=9136" | Select-Object ProcessId,CommandLine
'Get-CimInstance' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\Eagle3dStreaming>taskkill /PID 9136 /T /F

novel moatBOT Apr 28, 2026, 9:04 PM

#

Ah, you’re in Command Prompt, not PowerShell — that’s why Get-CimInstance failed. No worries.

If taskkill succeeded or said “process not found,” continue:

openclaw gateway start
timeout /t 20
openclaw health --verbose --timeout 5000
openclaw gateway status

Don’t reuse PID 9136 after this; it may change.

If health still times out, run the gateway in the foreground so we can see where it wedges:

#

openclaw gateway stop
set OPENCLAW_GATEWAY_STARTUP_TRACE=1 && openclaw gateway --force --verbose

Leave that window open and paste the first errors / last lines it prints.

sudden void Apr 28, 2026, 9:09 PM

#

i'm confused... lets start over. step by step what do i need to do

novel moatBOT Apr 28, 2026, 9:09 PM

#

Totally fair — let’s reset and do one clean path.

Use Command Prompt and run these one at a time:

1) Stop the managed gateway

openclaw gateway stop

2) Check if anything is still stuck on the OpenClaw port

netstat -ano | findstr :18789

If that shows a LISTENING line, paste it here.
If it shows nothing, continue.

#

3) Start the gateway again

openclaw gateway start

4) Wait 20 seconds

timeout /t 20

5) Test health

openclaw health --verbose --timeout 5000

Paste the result of step 5.

#

For now, don’t run status --all and don’t worry about agents yet. We’re just checking whether the Gateway can respond at all.

sudden void Apr 28, 2026, 9:14 PM

#

🦞 OpenClaw 2026.4.26 (be8c246) — I read logs so you can keep pretending you don't have to.

|
o
[openclaw] Failed to start CLI: Error: gateway timeout after 5000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///C:/Users/Eagle3dStreaming/AppData/Roaming/npm/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
at listOnTimeout (node:internal/timers:588:17)
at process.processTimers (node:internal/timers:523:7)

C:\Users\Eagle3dStreaming>openclaw health --verbose --timeout 5000

🦞 OpenClaw 2026.4.26 (be8c246) — I read logs so you can keep pretending you don't have to.

|
o
[openclaw] Failed to start CLI: Error: gateway timeout after 5000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///C:/Users/Eagle3dStreaming/AppData/Roaming/npm/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
at listOnTimeout (node:internal/timers:588:17)
at process.processTimers (node:internal/timers:523:7)

C:\Users\Eagle3dStreaming>

novel moatBOT Apr 28, 2026, 9:14 PM

#

Got it. Health still timing out, so next we need to see what is holding port 18789.

In Command Prompt, run just this:

netstat -ano | findstr :18789

Paste the output.

It should look roughly like:

TCP    127.0.0.1:18789    ...    LISTENING    12345

The important part is the last number — the PID. Once we see that, I’ll tell you exactly whether to kill it or run the gateway in foreground. Don’t run more commands yet.

sudden void Apr 28, 2026, 9:14 PM

#

C:\Users\Eagle3dStreaming>netstat -ano | findstr :18789
TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 8752
TCP 127.0.0.1:18789 127.0.0.1:51496 CLOSE_WAIT 8752
TCP 127.0.0.1:51496 127.0.0.1:18789 FIN_WAIT_2 8352
TCP [::1]:18789 [::]:0 LISTENING 8752

C:\Users\Eagle3dStreaming>

novel moatBOT Apr 28, 2026, 9:15 PM

#

Perfect. PID 8752 is the stuck gateway listener.

Run these exactly:

tasklist /FI "PID eq 8752"
taskkill /PID 8752 /T /F

Then confirm the port is clear:

netstat -ano | findstr :18789

If that shows nothing, start OpenClaw again:

#

openclaw gateway start
timeout /t 20
openclaw health --verbose --timeout 5000

Paste the health result.

sudden void Apr 28, 2026, 9:17 PM

#

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

|
o
[openclaw] Failed to start CLI: Error: gateway timeout after 5000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///C:/Users/Eagle3dStreaming/AppData/Roaming/npm/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
at listOnTimeout (node:internal/timers:588:17)
at process.processTimers (node:internal/timers:523:7)

C:\Users\Eagle3dStreaming>

novel moatBOT Apr 28, 2026, 9:17 PM

#

Ok — it restarted and wedged again. Now we stop trying health checks and catch the startup logs directly.

Run this exactly, one line at a time in Command Prompt:

1) Stop the scheduled gateway

openclaw gateway stop

2) See if port 18789 is still occupied

netstat -ano | findstr :18789

If you see a LISTENING line, kill the PID at the end:

#

taskkill /PID <PID_FROM_NETSTAT> /T /F

3) Start gateway in the foreground with tracing

set OPENCLAW_GATEWAY_STARTUP_TRACE=1
openclaw gateway --force --verbose

Leave that window open. Don’t run health yet.

Paste the last ~30 lines it prints after it slows/stops. This should show what is freezing the gateway.

sudden void Apr 28, 2026, 9:20 PM

#

14:19:27 [gateway] startup trace: http.bound 1615.6ms total=34336.0ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: post-attach.update-sentinel 157.5ms total=34499.3ms eventLoopMax=20.2ms
14:19:28 [gateway] agent model: openai-codex/gpt-5.5
14:19:28 [gateway] http server listening (7 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice; 37.1s)
14:19:28 [gateway] log file: C:\Users\EAGLE3~1\AppData\Local\Temp\openclaw\openclaw-2026-04-28.log
14:19:28 [gateway] startup trace: post-attach.log 522.5ms total=35026.9ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: post-attach.update-check 3.2ms total=35034.9ms eventLoopMax=0.0ms
14:19:28 [gateway] starting channels and sidecars...
14:19:28 [plugins] bonjour: watchdog detected non-announced service; attempting re-advertise (gateway fqdn=MP15-MS05 (OpenClaw)._openclaw-gw._tcp.local. host=MP15-MS05.local. port=18789 state=probing)
14:19:28 [gateway] startup trace: sidecars.session-locks 40.0ms total=35086.4ms eventLoopMax=33.0ms
14:19:28 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=35091.7ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: sidecars.gmail-model 0.2ms total=35096.9ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: sidecars.internal-hooks 0.2ms total=35101.8ms eventLoopMax=0.0ms

novel moatBOT Apr 28, 2026, 9:20 PM

#

Good catch — those logs show the freeze point:

It gets through sidecars.internal-hooks, then likely hangs starting channels/model prewarm.

Do this step-by-step:

1) In that foreground gateway window, press:

Ctrl+C

2) Start it again, but skip channel startup:

set OPENCLAW_GATEWAY_STARTUP_TRACE=1
set OPENCLAW_SKIP_CHANNELS=1
openclaw gateway --force --verbose

#

3) Leave that window open. Open a second Command Prompt and run:

openclaw health --verbose --timeout 5000

If health works with OPENCLAW_SKIP_CHANNELS=1, then we’ve isolated the problem to channel/provider startup, not the core gateway or your agents.

Paste the health result from step 3.

sudden void Apr 28, 2026, 9:23 PM

#

it just outputted some more stuff

14:19:28 [gateway] startup trace: sidecars.gmail-watch 0.1ms total=35091.7ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: sidecars.gmail-model 0.2ms total=35096.9ms eventLoopMax=0.0ms
14:19:28 [gateway] startup trace: sidecars.internal-hooks 0.2ms total=35101.8ms eventLoopMax=0.0ms
14:21:03 [plugins] bonjour: restarting advertiser (service stuck in probing for 94714ms (gateway fqdn=MP15-MS05 (OpenClaw) (2)._openclaw-gw._tcp.local. host=MP15-MS05-(2).local. port=18789 state=probing))
14:21:03 [plugins] bonjour: advertised gateway fqdn=MP15-MS05 (OpenClaw) (2)._openclaw-gw._tcp.local. host=MP15-MS05-(2).local. port=18789 state=unannounced
14:21:03 [plugins] bonjour: advertised gateway fqdn=MP15-MS05 (OpenClaw)._openclaw-gw._tcp.local. host=MP15-MS05.local. port=18789 state=unannounced
14:21:03 [plugins] bonjour: ignoring unhandled ciao rejection: CIAO PROBING CANCELLED
14:21:06 [model-pricing] OpenRouter pricing fetch failed (timeout 60s): TimeoutError: The operation was aborted due to timeout
14:21:06 [model-pricing] LiteLLM pricing fetch failed (timeout 60s): TimeoutError: The operation was aborted due to timeout
14:21:16 [plugins] bonjour: watchdog detected non-announced service; attempting re-advertise (gateway fqdn=MP15-MS05 (OpenClaw)._openclaw-gw._tcp.local. host=MP15-MS05.local. port=18789 state=unannounced)
14:21:16 [codex/catalog] codex model discovery failed; using fallback catalog

novel moatBOT Apr 28, 2026, 9:24 PM

#

That explains the “crazy slow” part: OpenClaw is waiting on network catalog fetches and they’re timing out after 60s. Let’s disable that startup pricing fetch.

In the foreground gateway window:

1) Press Ctrl+C

Then in Command Prompt run:

openclaw config set models.pricing.enabled false --strict-json

Optional but recommended, since Bonjour is also noisy on your machine:

openclaw plugins disable bonjour

#

Now start the gateway again:

openclaw gateway --force --verbose

Leave that open. In a second Command Prompt run:

openclaw health --verbose --timeout 5000

Paste the health result. If that works, we’ll restart it normally as a scheduled gateway.

sudden void Apr 28, 2026, 9:25 PM

#

C:\Users\Eagle3dStreaming>openclaw config set models.pricing.enabled false --strict-json

🦞 OpenClaw 2026.4.26 (be8c246) — Half butler, half debugger, full crustacean.

Error: Config validation failed: models: Unrecognized key: "pricing"

novel moatBOT Apr 28, 2026, 9:26 PM

#

You’re right — my bad. That config key is in newer docs/main, but your installed 2026.4.26 rejects it. Ignore that step.

Let’s do the diagnostic without changing config:

1) In the gateway window, press Ctrl+C

2) In Command Prompt run:

set OPENCLAW_GATEWAY_STARTUP_TRACE=1
set OPENCLAW_SKIP_CHANNELS=1
set OPENCLAW_DISABLE_BONJOUR=1
openclaw gateway --force --verbose

That command is supposed to keep running.

3) Open a second Command Prompt and run:

#

openclaw health --verbose --timeout 5000

Paste that result.

If health works with OPENCLAW_SKIP_CHANNELS=1, we know the core gateway is fine and the hang is in channel/provider startup.

sudden void Apr 28, 2026, 9:29 PM

#

C:\Users\Eagle3dStreaming>openclaw health --verbose --timeout 5000

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

|
o
[openclaw] Failed to start CLI: Error: gateway timeout after 5000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\Eagle3dStreaming.openclaw\openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///C:/Users/Eagle3dStreaming/AppData/Roaming/npm/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
at listOnTimeout (node:internal/timers:588:17)
at process.processTimers (node:internal/timers:523:7)

C:\Users\Eagle3dStreaming>

novel moatBOT Apr 28, 2026, 9:29 PM

#

That still timing out means either:

the foreground gateway didn’t actually start with the skip flags, or
it did start, but core Gateway RPC is still wedged.

Let’s verify from the gateway window now.

In the window where you ran:

openclaw gateway --force --verbose

please paste the last ~30 lines. I’m looking for one of these:

#

skipping channel start
sidecars.total
gateway ready

or where it stopped.

Also run this in the second Command Prompt and paste it:

netstat -ano | findstr :18789

Don’t run more health checks yet — we need to confirm which process is actually listening.

sudden void Apr 28, 2026, 9:32 PM

#

this is awful. what the most stable version of openclaw thats most recent

novel moatBOT Apr 28, 2026, 9:33 PM

#

Yeah, fair. For most recent “get me back to sane” stability, I’d roll back to:

openclaw@2026.4.23

2026.4.26 is the current/latest release, but you’re actively hitting bad Windows gateway startup behavior on it. 2026.4.23 is recent, official, and before the 4.24–4.26 churn. GitHub shows 4.26 as latest released Apr 28, and 4.23 released Apr 24. (github.com)

In Command Prompt:

openclaw gateway stop
npm install -g openclaw@2026.4.23
openclaw --version
openclaw gateway install --force
openclaw gateway start
timeout /t 20
openclaw health --verbose --timeout 5000

#

If your install really uses pnpm instead of npm, swap the install line for:

pnpm add -g openclaw@2026.4.23

But your path showed AppData\Roaming\npm\node_modules\openclaw, so I’d try the npm install -g line first.

sudden void Apr 28, 2026, 9:34 PM

#

wait... just give me the directions on how to switch to the 2026.4.23 version

novel moatBOT Apr 28, 2026, 9:35 PM

#

Yep — do this in Command Prompt:

openclaw gateway stop
npm install -g openclaw@2026.4.23
openclaw --version
openclaw gateway install --force
openclaw gateway start
timeout /t 20
openclaw health --verbose --timeout 5000

After openclaw --version, you want to see:

OpenClaw 2026.4.23

#openclaw running slow and chat is not responsive