After upgrading from 2026.4.23 to 2026.4.25, node eats all system resources | Friends of the Crustacean 🦞🤝 | Page 1

ripe adder Apr 28, 2026, 11:53 AM

#

Everything slows to a complete crawl and nothing is accessible, every connection times out. I rolled back and it's fine. I tried going to 2026.4.26 and it does the same thing. I don't even know where to begin. Debugging seems impossible because nothing is accessible.

zinc kernelBOT Apr 28, 2026, 11:53 AM

#

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

charred finchBOT Apr 28, 2026, 11:59 AM

#

Yeah — treat this as a regression, not “debug your config.” 4.23 good + 4.25/4.26 melting the host is a strong signal.

There’s already an adjacent open 2026.4.26 issue: gateway alive but /readyz times out, main Node thread goes ~99.9% CPU, and control-plane requests stall. Your “everything times out” sounds in that family. (github.com)

If you can safely reproduce from console/SSH, I’d capture it without letting the service auto-restart:

openclaw --version
node --version
openclaw status --all > openclaw-423-status.txt

openclaw gateway stop
openclaw update --tag 2026.4.26 --no-restart --yes

OPENCLAW_GATEWAY_STARTUP_TRACE=1 timeout 90s openclaw gateway run --verbose 2>&1 | tee openclaw-426-startup-trace.log

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

#

status --all is meant as a pasteable redacted report, and --no-restart lets you update without immediately launching the bad gateway. (docs.openclaw.ai)

If it starts crawling, Ctrl-C / kill it and roll back. The useful bits to share here or on the GitHub issue are:

OS + RAM + install method
openclaw --version
node --version
channels/plugins enabled
last ~100 lines of openclaw-426-startup-trace.log
whether /readyz times out locally during the crawl

OpenClaw has startup tracing specifically for this kind of gateway startup/resource issue. (docs.openclaw.ai)

ripe adder Apr 28, 2026, 3:53 PM

#

$ OPENCLAW_GATEWAY_STARTUP_TRACE=1 timeout 90s openclaw gateway run --verbose 2>&1 | tee openclaw-426-startup-trace.log
-bash: timeout: command not found

charred finchBOT Apr 28, 2026, 3:53 PM

#

Ah, macOS doesn’t ship GNU timeout by default. Use the manual version:

OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --verbose 2>&1 | tee openclaw-426-startup-trace.log

Let it run until it starts crawling / about 30–90s, then press Ctrl-C.

If Ctrl-C doesn’t respond, from another terminal:

pkill -TERM -f "openclaw gateway"

Then roll back/start the good version again. The file we want is:

#

openclaw-426-startup-trace.log

If you want a macOS hard-timeout later, install coreutils and use gtimeout, but don’t bother right now — manual Ctrl-C is fine for this repro.

ripe adder Apr 28, 2026, 4:02 PM

#

well obviously openclaw 2026.4.26 is the version, node version v25.5.0, MacOS, 8gb RAM. And I can't send the lines unless I pay, apparently, so do you have any suggestions on how I get you that info?

charred finchBOT Apr 28, 2026, 4:03 PM

#

Yep — two practical things:

Node 25 is the first variable I’d eliminate. OpenClaw docs recommend Node 24; Node 22.14+ is supported, but 24 is the default/recommended runtime. Node 25 may work, but for a resource-meltdown regression, don’t debug on it. (docs.openclaw.ai)

If you use nvm:

nvm install 24
nvm use 24
npm i -g openclaw@2026.4.26
openclaw gateway stop
OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --verbose 2>&1 | tee openclaw-426-startup-trace.log

Don’t send the whole log. Send a tiny filtered snippet:

OpenClaw

Node.js - OpenClaw

#

{
  echo "=== versions ==="
  openclaw --version
  node --version
  uname -a
  echo "=== first 120 lines ==="
  sed -n '1,120p' openclaw-426-startup-trace.log
  echo "=== suspicious lines ==="
  grep -Ei 'startup|trace|phase|readyz|eventloop|memory|heap|cpu|plugin|npm|error|warn|timeout' openclaw-426-startup-trace.log | tail -120
  echo "=== last 120 lines ==="
  tail -120 openclaw-426-startup-trace.log
} > openclaw-snippet.txt

Then either paste chunks here, or on macOS:

#

pbcopy < openclaw-snippet.txt

If Discord still complains, make a GitHub issue and attach openclaw-snippet.txt there: https://github.com/openclaw/openclaw/issues

Also: if Node 24 fixes it, that’s useful data by itself. If Node 24 still melts the machine, we’ve ruled out the runtime and the startup trace is the next thing.

ripe adder Apr 28, 2026, 4:04 PM

#

nvm: command not found

charred finchBOT Apr 28, 2026, 4:04 PM

#

Yep, my bad — I assumed nvm. Use fnm instead; it’s the easiest on macOS.

brew install fnm

eval "$(fnm env --use-on-cd --shell bash)"
fnm install 24
fnm use 24

node -v
npm i -g openclaw@2026.4.26

Then retry the repro:

#

openclaw gateway stop
OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --verbose 2>&1 | tee openclaw-426-startup-trace.log

If brew is also missing, skip version managers and install Node 24 from the Node.js macOS installer, then run:

node -v
npm i -g openclaw@2026.4.26

OpenClaw docs: Node 24 is the recommended runtime; Node 22.14+ is supported. Node 25 is not the runtime I’d debug this on. https://docs.openclaw.ai/install/node

ripe adder Apr 28, 2026, 4:13 PM

#

Old one won't die, how do I kill what's on port 18789

charred finchBOT Apr 28, 2026, 4:14 PM

#

Use macOS lsof:

lsof -nP -iTCP:18789 -sTCP:LISTEN

That shows the PID. Then:

kill -TERM <PID>
sleep 3
lsof -nP -iTCP:18789 -sTCP:LISTEN

If it’s still there:

#

kill -KILL <PID>

If it immediately comes back, the managed service is restarting it. Stop that first:

openclaw gateway stop
openclaw gateway status

Then check/kill the port again.

You can also run the repro with OpenClaw’s built-in port cleanup:

#

OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --force --verbose 2>&1 | tee openclaw-426-startup-trace.log

Gateway CLI docs: https://docs.openclaw.ai/cli/gateway

ripe adder Apr 28, 2026, 4:19 PM

#

So it's running, but here's the thing: there are no errors in the log. There are no timeouts of any kind. It just chugs away forever at nothing.

charred finchBOT Apr 28, 2026, 4:20 PM

#

That’s actually useful: no errors + endless CPU usually means hot loop / stuck startup phase, not a normal failure.

Let’s stop looking for “errors” and grab where Node is spending time.

While it’s chugging, in another terminal:

PID="$(lsof -tiTCP:18789 -sTCP:LISTEN | head -1)"
echo "PID=$PID"
ps -p "$PID" -o pid,ppid,%cpu,%mem,rss,vsz,etime,command
pgrep -P "$PID" -af .
sample "$PID" 10 -file openclaw-node-sample.txt

Then send just:

#

head -40 openclaw-node-sample.txt
grep -A40 -E "Call graph|Heavy|Thread" openclaw-node-sample.txt | head -160

Also run this quick bisect:

openclaw gateway stop

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
openclaw gateway run --force --verbose 2>&1 | tee openclaw-no-bundled-plugins.log

If that doesn’t chug, the problem is almost certainly in bundled plugin startup/runtime-dep staging. If it still chugs, it’s lower-level gateway/core/Node/runtime.

#

And please confirm after the Node change:

node -v
which node
which openclaw

Tiny note: if you’re still on Node 25, I’d strongly switch to Node 24 before we trust the sample. But the sample output will be the most useful evidence either way.

ripe adder Apr 28, 2026, 4:21 PM

#

I'm on Node 24, I'm just trying to see if I can get the thing to show up but without being able to actually post the log here I don't know how much usefulness this is going to be

charred finchBOT Apr 28, 2026, 4:22 PM

#

Totally fair. Don’t fight Discord upload limits — for this kind of bug, one tiny digest + one yes/no bisect is enough.

First, while it’s chugging, run this:

PID="$(lsof -tiTCP:18789 -sTCP:LISTEN | head -1)"

{
  echo "=== versions ==="
  openclaw --version
  node -v
  which openclaw
  which node
  sw_vers

  echo "=== process ==="

#

  ps -p "$PID" -o pid,ppid,%cpu,%mem,rss,vsz,etime,command

  echo "=== child processes ==="
  pgrep -P "$PID" -af . || true

  echo "=== last trace-ish lines ==="
  grep -Ei 'startup|trace|phase|eventloop|readyz|plugin|npm|memory|heap|cpu|warn|error' openclaw-426-startup-trace.log | tail -80
} > openclaw-digest.txt

Then paste only openclaw-digest.txt if it’s small.

Second, do the no-log bisect:

#

openclaw gateway stop

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
openclaw gateway run --force --verbose

Then just tell me one of these:

“No bundled plugins fixes it”
“No bundled plugins still chugs”

That one result is genuinely useful.

If you want to share the full files without paying for Discord upload, make a GitHub issue and attach them there as .txt or zipped files: https://github.com/openclaw/openclaw/issues
But we can keep going here with just the digest + bisect result.

ripe adder Apr 28, 2026, 4:23 PM

#

running that blew up, lsof permission denied trying to access the timemachine drive

charred finchBOT Apr 28, 2026, 4:23 PM

#

Ah, macOS lsof can be annoyingly noisy around protected volumes. It’s not necessarily fatal — suppress the permission spam:

PID="$(lsof -nP -tiTCP:18789 -sTCP:LISTEN 2>/dev/null | head -1)"
echo "PID=$PID"

If that prints a PID, continue:

ps -p "$PID" -o pid,ppid,%cpu,%mem,rss,vsz,etime,command
pgrep -P "$PID" -af . 2>/dev/null || true

If it prints nothing, use the process-name fallback:

#

pgrep -fl "openclaw|node" | grep -Ei "gateway|openclaw"

For now, you can also skip PID detection entirely and just do the useful bisect:

openclaw gateway stop

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
openclaw gateway run --force --verbose

The key answer I need is just: does disabling bundled plugins stop the chugging, yes or no?

ripe adder Apr 28, 2026, 4:25 PM

#

It is faster than lightning now

charred finchBOT Apr 28, 2026, 4:26 PM

#

That’s a real signal 🎯

So the bad path is bundled plugin startup, not Node 24, not your gateway config in general.

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 is only a diagnostic hammer though — it’ll also disable lots of useful stuff. Next best workaround is to bound the default-enabled bundled plugins to only what you actually need.

First get the enabled plugin list:

openclaw plugins list --enabled --verbose | sed -n '1,140p'

If you want a temporary safe-ish workaround, backup config, then allow only your model provider(s) + essentials. Example for Anthropic/OpenAI:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)

#


openclaw config set plugins.allow '[
  "anthropic",
  "openai",
  "openrouter",
  "browser",
  "web-readability",
  "document-extract",
  "device-pair",
  "bonjour"
]' --strict-json

Then start normally, without OPENCLAW_DISABLE_BUNDLED_PLUGINS=1.

If that fixes it, we’ve narrowed it to “one of the default-enabled bundled plugins outside that allowlist.” If it still chugs, the culprit is probably one of those essentials or an explicitly enabled channel plugin.

#

Docs bit this is based on: plugins.allow bounds default-enabled bundled runtime dependency repair. https://docs.openclaw.ai/tools/plugin

If you can’t paste logs, just paste the output of:

openclaw plugins list --enabled --verbose | sed -n '1,80p'

That should be small enough and useful.

ripe adder Apr 28, 2026, 4:37 PM

#

There are 16 plugins enabled now but that output is twice as long as I can paste

#

And the system still won't load, node uitilizes 100% cpu and it does nothing at all

charred finchBOT Apr 28, 2026, 4:38 PM

#

Yep, don’t use --verbose then — it’s too chatty.

Give me just the plugin IDs as one line:

openclaw plugins list --json | node -e 'const fs=require("fs"); const d=JSON.parse(fs.readFileSync(0,"utf8")); console.log(d.plugins.filter(p=>p.enabled).map(p=>p.id).join(" "))'

That should be tiny, like:

anthropic openai browser discord ...

If even that’s too much, run this and paste the numbered list:

#

openclaw plugins list --json | node -e 'const fs=require("fs"); const d=JSON.parse(fs.readFileSync(0,"utf8")); d.plugins.filter(p=>p.enabled).forEach((p,i)=>console.log(`${i+1}. ${p.id}`))'

Once we have just the 16 IDs, we can bisect the allowlist instead of reading giant logs.

#

Don’t keep letting it burn CPU — stop it first:

openclaw gateway stop
pkill -TERM -f "openclaw gateway" 2>/dev/null || true
pkill -TERM -f "node.*openclaw" 2>/dev/null || true

At this point we know: bundled plugins disabled = fast, your current 16-plugin set = hot loop. So don’t paste logs; we need to shrink the plugin set.

Try the smallest possible allowlist for your actual model provider:

If Anthropic:

openclaw config set plugins.allow '["anthropic"]' --strict-json

#

If OpenAI:

openclaw config set plugins.allow '["openai"]' --strict-json

If OpenRouter:

openclaw config set plugins.allow '["openrouter"]' --strict-json

Then run:

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

If that starts cleanly, we add plugins back one at a time. If even one provider only still hits 100% CPU, that’s a much smaller bug report.

#

Also: please run this after stopping the gateway — it should be tiny enough to paste:

openclaw plugins list --json | node -e 'const fs=require("fs"); const d=JSON.parse(fs.readFileSync(0,"utf8")); console.log(d.plugins.filter(p=>p.enabled).map(p=>p.id).join(" "))'

ripe adder Apr 28, 2026, 4:39 PM

#

I'm using ollama, the models are specified manually in the config, not sure if that's relevant for what to enable/disable

charred finchBOT Apr 28, 2026, 4:40 PM

#

Yes, that’s relevant: for manual Ollama models, the bundled provider plugin id is ollama. Start with only that.

Stop the hot process, then:

openclaw gateway stop
pkill -TERM -f "openclaw gateway" 2>/dev/null || true
pkill -TERM -f "node.*openclaw" 2>/dev/null || true

openclaw config set plugins.allow '["ollama"]' --strict-json

Then retry:

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

#

Expected result:

Fast with ["ollama"] → one of the other bundled plugins is the culprit.
Still 100% CPU with only ["ollama"] → we’ve narrowed it way down to the Ollama provider path / model config interaction.

Manual model config doesn’t remove the need for the provider plugin; it just means ollama is the one we should allow first. Docs: https://docs.openclaw.ai/tools/plugin

ripe adder Apr 28, 2026, 4:50 PM

#

node stays pegged for about 10 minutes after startup but then settles down... maybe this is just my lot in life?

charred finchBOT Apr 28, 2026, 4:51 PM

#

Nope, that shouldn’t be your lot in life 😅 A 10-minute 100% CPU startup is still a bug or bad startup path, even if it eventually settles.

Since you’re using manual Ollama model config, the next thing I’d disable is Ollama discovery. You don’t need startup discovery if your models are already specified.

openclaw gateway stop

openclaw config set plugins.entries.ollama.config.discovery.enabled false --strict-json
openclaw config set plugins.allow '["ollama"]' --strict-json

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

If that starts fast, the culprit is likely Ollama provider discovery / probing local models.

Also check whether this is only a one-time post-upgrade thing:

#

# after it settles once
openclaw gateway stop
OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --force --verbose

If the second startup is also 10 minutes, that’s not normal and we should file/narrow it.

Docs note: Ollama discovery can be disabled via plugins.entries.ollama.config.discovery.enabled: false. https://docs.openclaw.ai/providers/ollama

ripe adder Apr 28, 2026, 4:55 PM

#

While it's starting up again: for whatever it's worth, every release in the last 2 months has made things slower and less reliable for me each time... I keep upgrading hoping it'll fix it but that just proves to make me look foolish and overly-optimistic each time. We're at 4 minutes right now and still pegged 100%

charred finchBOT Apr 28, 2026, 4:56 PM

#

You’re not foolish — this is exactly what “stable updates” are supposed to make safe. If 4.23 works and 4.25/4.26 spend minutes pegged at 100%, pin 4.23 and stop burning time on the broken path.

At 4+ minutes, I’d stop the repro now:

pkill -TERM -f "openclaw gateway" 2>/dev/null || true
pkill -TERM -f "node.*openclaw" 2>/dev/null || true

Then roll back and stay there for now:

npm i -g openclaw@2026.4.23
openclaw doctor
openclaw gateway restart

#

The useful bug summary is already pretty strong:

macOS, 8GB RAM
Node 24
OpenClaw 2026.4.23 works
2026.4.25/2026.4.26 peg Node at 100% for minutes on startup
disabling bundled plugins makes startup fast
using Ollama with manual model config

If you can tolerate one last diagnostic while it’s pegged, the most useful thing is a macOS sample, not logs:

PID="$(ps ax -o pid=,command= | awk '/[o]penclaw gateway/ {print $1; exit}')"
sample "$PID" 10 -file openclaw-hotloop-sample.txt

Attach openclaw-hotloop-sample.txt to a GitHub issue: https://github.com/openclaw/openclaw/issues

#

But honestly: roll back first. This is not “your lot in life”; this is a regression that needs a maintainer fix.

ripe adder Apr 28, 2026, 5:22 PM

#

Everything is a regression.
sample cannot find any existing process you have access to which has a name like ''; try running with sudo.

charred finchBOT Apr 28, 2026, 5:23 PM

#

Yeah, that failure means my PID command returned empty — not that sample is useless. Sorry, that’s frustrating as hell.

While Node is pegged, run this and pick the top high-CPU node/openclaw PID:

ps ax -o pid,ppid,%cpu,%mem,etime,command | grep -Ei '[n]ode|[o]penclaw' | sort -k3 -nr | head -20

Then:

sample <PID> 10 -file openclaw-hotloop-sample.txt

If macOS says permission denied, then use:

#

sudo sample <PID> 10 -file openclaw-hotloop-sample.txt

If no process shows up there, it’s probably already dead or running under a different service/user. In that case:

sudo lsof -nP -iTCP:18789 -sTCP:LISTEN 2>/dev/null

But honestly, I’d still prioritize rolling back to 2026.4.23 and filing the issue with what we already know. The key finding is strong: bundled plugins disabled makes startup fast; normal bundled plugin path pegs CPU for minutes.

ripe adder Apr 28, 2026, 5:24 PM

#

I have 742 lines in that file now, for openclaw-gateway... what shall I do with it?

charred finchBOT Apr 28, 2026, 5:25 PM

#

Perfect — that file is the good evidence.

Don’t paste all 742 lines here. Do this:

{
  echo "=== summary ==="
  grep -Ei 'Call graph|Total number in stack|Sort by top of stack|openclaw|node|javascript|v8|fs|readdir|stat|realpath|require|import|jiti|plugin|ollama|npm' openclaw-hotloop-sample.txt | head -120

  echo "=== top of file ==="
  sed -n '1,80p' openclaw-hotloop-sample.txt
} > openclaw-sample-summary.txt

Paste openclaw-sample-summary.txt if it fits.

If it still doesn’t fit, attach the full openclaw-hotloop-sample.txt to a GitHub issue instead: https://github.com/openclaw/openclaw/issues

#

Issue title suggestion:

2026.4.25+ macOS startup hot loop / 100% CPU in bundled plugin path

Issue body can be short:

macOS, 8GB RAM, Node 24.
2026.4.23 works.
2026.4.25 and 2026.4.26 peg Node/openclaw-gateway at 100% CPU for many minutes during startup.
No obvious errors in logs.
OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 makes startup fast.
Using Ollama with manually configured models.
Attached: macOS sample while CPU is pegged.

#

That sample is way more actionable than the normal log.

ripe adder Apr 28, 2026, 5:26 PM

#

Yeah this is beyond what I can place here, even the sample is hundreds of lines

charred finchBOT Apr 28, 2026, 5:26 PM

#

Totally fine — don’t force it into Discord.

Best path now: attach the full file to a GitHub issue. GitHub issue attachments are exactly for this.

zip openclaw-hotloop-diagnostics.zip \
  openclaw-hotloop-sample.txt \
  openclaw-426-startup-trace.log 2>/dev/null

Then file here and attach the zip: https://github.com/openclaw/openclaw/issues

Use this body:

macOS, 8GB RAM, Node 24.

#

2026.4.23 works.
2026.4.25 and 2026.4.26 peg openclaw-gateway/Node at 100% CPU for many minutes during startup.
No obvious log errors.
OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 makes startup fast.
Using Ollama with manually configured models.
Attached macOS sample while CPU was pegged.

If you don’t want to file the issue right now, just keep that zip and roll back to 2026.4.23. You’ve already narrowed it enough that this needs maintainer eyes, not more Discord paste gymnastics.

ripe adder Apr 28, 2026, 5:34 PM

#

ok, posted bug. these have historically gone nowhere, so I'm not optimistic this time, but last question. When I roll back I get this warning... do I care about it?
$ npm i -g openclaw@2026.4.23
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

charred finchBOT Apr 28, 2026, 5:34 PM

#

No, you can ignore that one.

npm warn deprecated node-domexception@1.0.0 is just an npm dependency warning from somewhere in the tree. It’s not the rollback failing, and it’s not related to the 100% CPU startup issue.

What matters is whether this succeeds afterward:

openclaw --version
openclaw doctor
openclaw gateway restart
openclaw gateway status

If openclaw --version says 2026.4.23 and the gateway comes back healthy, you’re good to stay pinned there for now.

And yeah — I get the pessimism. But the sample + “bundled plugins disabled fixes it” is at least a concrete repro trail, not just vibes.

ripe adder Apr 28, 2026, 5:36 PM

#

There are so many systemic issues that confuse me to thinking it must be a configuration issue otherwise everyone would be freaking out. I had to stop using Discord because any time the agent ran an exec command it would post the results to a new session that was confused beyond belief at what was happening and then kill the process, which then made the original agent think everything was just dying on the vine. How can one debug something like this when the system that would debug it is the one causing the problem?

charred finchBOT Apr 28, 2026, 5:37 PM

#

You’re thinking about it exactly right: don’t debug the system from inside the broken delivery path.

Make a “break-glass / boring mode” and debug from Terminal, not Discord:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)

openclaw config set channels.discord.enabled false --strict-json
openclaw config set tools.exec.notifyOnExit false --strict-json
openclaw config set plugins.allow '["ollama"]' --strict-json
openclaw config set plugins.entries.ollama.config.discovery.enabled false --strict-json

npm i -g openclaw@2026.4.23
openclaw doctor
openclaw gateway restart

#

Then only use:

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw gateway run --verbose

Once that’s stable, add layers back one at a time:

Ollama-only local gateway works.
Add browser/document tools if needed.
Add Discord last.
Re-enable exec notifications last.

The Discord exec thing you described sounds like a routing/session-completion bug, not normal behavior. tools.exec.notifyOnExit=false should reduce that “background command woke the wrong/confused session” chaos while you stabilize.

#

And yeah — if the debugger is part of the thing malfunctioning, you don’t keep trusting it. You shrink OpenClaw down to a local CLI-controlled gateway, prove that works, then reintroduce features until the bad layer is obvious.

ripe adder Apr 28, 2026, 6:06 PM

#

I should lower my expectations from a system that's had a missing favicon since day one.

charred finchBOT Apr 28, 2026, 6:06 PM

#

That’s fair frustration. I wouldn’t try to talk you out of it — when the system is eating the machine and even the debug path is flaky, a missing favicon starts feeling like a symbol of the whole thing.

My practical recommendation: pin 2026.4.23, strip it down, and stop upgrading until the specific bug you filed gets a maintainer response/fix. You already did the useful work: narrowed it to bundled plugin startup and got a sample.

If 4.23 is usable, treat it as your stable baseline:

npm i -g openclaw@2026.4.23
openclaw config set channels.discord.enabled false --strict-json
openclaw config set tools.exec.notifyOnExit false --strict-json
openclaw gateway restart

Then don’t chase 4.25/4.26 unless someone explicitly asks you to verify a fix. That’s not lowering expectations; that’s protecting your time.

ripe adder Apr 28, 2026, 6:06 PM

#

The problem now is that it's a mess b/c of the node downgrade but I'll just deal w/it. Or give up.

charred finchBOT Apr 28, 2026, 6:07 PM

#

Yeah — at this point, don’t fight the Node downgrade too. If Node 25 + OpenClaw 2026.4.23 was the last working combo, go back to that exact combo. “Recommended runtime” matters less than “your machine works.”

To untangle the mess, first see what shell is actually using:

which -a node npm openclaw
node -v
npm prefix -g
openclaw --version

Then install 4.23 into the same npm prefix your current npm reports:

npm i -g openclaw@2026.4.23
hash -r

#

openclaw --version
openclaw gateway restart

If openclaw --version still shows the wrong version, run the exact binary from npm’s prefix:

"$(npm prefix -g)/bin/openclaw" --version
"$(npm prefix -g)/bin/openclaw" gateway restart

And honestly: if it’s stable after that, stop there. Don’t keep debugging tonight. You already filed the useful bug and got a sample.

ripe adder May 1, 2026, 12:35 AM

#

Just FYI I updated to 29 after seeing that this was fixed. It ain't fixed. Not even close. Product is unusable.

regal yoke May 1, 2026, 12:45 AM

#

Same here. Definitely have the same exact problem.

wicked crown May 1, 2026, 12:51 AM

#

Yep same here too. This is getting extremely frustrating.
2026.4.27 didn't this issue though, I'll downgrade if I can.

regal yoke May 1, 2026, 1:19 AM

#

the last one that felt good to me was .23

ripe adder May 1, 2026, 1:22 AM

#

I just ditched back to 23

weak isle May 1, 2026, 1:22 AM

#

Had enough of these breaking changes, I ended up going back to .23

ripe adder May 1, 2026, 1:24 AM

#

Yeah it's super frustrating spending your life trying to get the thing that's supposed to help save you time to work like it used to. I don't understand why it's intermittent like this. I ran Claude Code and it said the ollama plugin was crashing every 300ms but idk if I believe ollama was the reason.

regal yoke May 1, 2026, 1:25 AM

#

here's what my claude said:

The CPU is high because it's actually working â€” there's an active agent run happening. Look at this:

[trace:embedded-run] prep stages: totalMs=39099 core-plugin-tools:12458ms
[trace:embedded-run] startup stages: totalMs=44633 model-resolution:2141ms
liveness warning: eventLoopDelayMaxMs=41607 active=1 queued=1
The gateway is spending 12+ seconds just loading plugin tools per message, and 39-44 seconds total prep before it even calls the model. That's a .29 regression â€” previously this was much faster. The node.list 41612ms (41 seconds!) shows the event loop is blocked during these runs.

Also new: hindsight: waitForReady called before service.start() â€” hindsight isn't fully initialized when agent runs start, adding more delay.

This isn't a loop or a warmup issue â€” it's genuine per-message overhead that's way higher than it should be. Is the bot actually responding, just slowly? And is this happening on every message or only the first one after startup?

ripe adder May 1, 2026, 1:27 AM

#

Yeah that tracks because mine was saying that each message was taking 2+ minutes. What LLM provider are you using?

regal yoke May 1, 2026, 1:28 AM

#

openai/gpt-5.5

ripe adder May 1, 2026, 1:34 AM

#

So it's not the service provider. I love the the rollback leaves a trashed config too. It's all going very well

#After upgrading from 2026.4.23 to 2026.4.25, node eats all system resources